文档章节

云智慧技术分享之微服务架构应用实践

cloudwiseAPM
 cloudwiseAPM
发布于 2016/12/14 09:53
字数 1638
阅读 18
收藏 0

 

Allen Lai

随着Docker等云技术的大量应用,企业的互联网业务复杂度不断提升,传统整体应用架构模式越来越臃肿,难以适应灵活多变的业务需求。微服务架构(Microservices Architecture)应运而生,它放弃了传统大规模的单块集成应用,改为细粒度、松耦合、可灵活组合的自治单元,成为云计算时代应用的主要构建方式。

微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注,在Netflix、Amazon、Airbnb等公司获得了成功应用,并逐渐成为互联网行业最受关注的技术架构。今天就由云智慧开发经理 Allen Lai为大家带来关于Microservices Architecture微服务架构应用实践的分享内容。

什么是微服务?

微服务是一种全新的互联网架构,它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成,譬如REST API。微服务本质上是SOA (Serviceoriented Architecture) 的扩展延伸。相对来说,微服务的可操作性更强,可以逐步安排合理资源,对一个大的系统进行分解,或是至少停止让它继续肥大。

微服务的好处包括:

  • 按照业务功能的独立垂直开发机制;
  • 异构开发语言,更多的技术选择;
  • 高效的部署机制(自动化部署) 和尽可能短的部署周期;
  • 高效的测试机制,易于构建基于服务接口的自动化测试,能尽可能早的发现问题;
  • 面对下游消费者透明,如采用Swagger,可详细描述输入,输出标准(见下图)。

 

 

Restful API集成Swagger1

整体应用 vs 微服务应用

那么,我们来看看另一种过去常用的架构,单体架构Monolithic application的情况,单体架构也有它的优势,对于项目应用或是公司创业初期是个很好的选择,可以更快的解决有和没有的问题,适合小团队开发实现,而且横向扩展方便,例如镜像部署的时候。但当公司大了以后,随着应用越来越多、第三方系统的不断接入或者企业的并购,问题会慢慢的暴露出来。

主要体现在如下方面:

  • 功能多了,应用肥大;
  • 接口污染,jar包冲突;
  • 部署困难,任何修改都需部署整体,带来整体服务downtime;
  • 测试/检查比较困难,任何修改,切入点过于依赖于从前到后的测试;
  • 问题定位困难,不易找到具体的问题点,通常需要从前到后筛查,或者从海量的log里筛查;
  • 某个服务出现OOM后对整体应用产生影响;
  • 无法通过具体服务对资源的需求搭配硬件资源/网络资源,只能安装最高需求整体满足;
  • 新进人员对开发环境搭建,应用的熟悉需要很长的时间,很难快速通过以点及面的方式切入系统。

我曾经遇到过一个超过400M的大Jar包,启动应用超过5分钟,那段时间简直被OPS骂死。举个例子,一个产品犹如一条鱼,开始的是后游得很畅快,但是有一天,这条鱼变成这样:

 

整体应用架构

它每次的转身、变更都很慢,因为太重了。后来我们意识到,不能再往它身上放东西了,经过逐步的调整,变成了如下的结构:

 

Microservices Architecture

Tomcat上承载的东西变少了,有明确边界的服务都被拆分成了独立的restful应用,这样面向众多客户的web app,部署节奏加快,后端的若干子服务部署节奏也加快。

公司大了以后,异构系统和Hybrid都是在所难免的,有朝一日云智慧也会面临这个场景。监控宝透视宝平台提供的功能由php, java, Ruby on Rails, Python Django, .net mvc等组成,同时对于外部服务的集成,集成后对主应用的影响不亚于功能性的要求。比如集成一个外部服务,他的服务升级很快,那么对这块功能的变更和主应用应该是隔离的,而微服务架构确实能隔离这个问题。

微服务架构的实现,目前国内有阿里的dubbo,国外有Twitter的Finagle框架,他们都是基于RPC的。如果我们的微服务是基于restful服务,那么无须选择他们,考虑到异构系统,基于http rest依旧是最合适方案。

任何一种架构都有它的适用场景和一些不足,微服务什么问题呢?

  • 需考虑服务间通讯的局部不可用问题。

假如一个请求需要2个或者多个服务共同组装数据,某个服务不可用,本质上这个应该取决于业务,具体该请求判决为成功或失败取决于该故障服务提供的数据权重,比如一个提供商品评论的服务暂时不可用,该数据是次要的。

  • 服务线性依赖问题

这是个设计问题,从设计上微服务不应该依赖别的业务微服务,如果设计成了服务A—>服务B>服务C..那么带来的问题会较多。

  • 带来更多的单点考虑

采用合理的负载均衡可以解决,但是显然会带来部署的复杂性。

  • 应用管理复杂度会上升

这方面,业界也有解决方案,比如Docker / Kubernetes集群化方案。

今晚主要是从High level介绍一下微服务架构,具体细节要有合适的应用场景,下次分享我们会准备了一个Demo,一起来尝试如何让web app更轻,如何用spring boot构建一个微服务。

© 著作权归作者所有

共有 人打赏支持
cloudwiseAPM
粉丝 27
博文 135
码字总数 278629
作品 0
海淀
私信 提问
SDCC 2017轻量级微服务架构实践之路专场介绍!

2017年,SDCC(中国软件开发者大会)延续了去年的节奏,已分别在上海、深圳两地顺利举办。 10月28日-29日在北京举办的中国软件开发者大会将是SDCC在2017年的完美收官!届时,人工智能、区块链...

OSC_Lucy
2017/08/09
2.7K
6
PHP开发者年会

2018第二届PHP年会,旨在为PHP程序员、架构师解决大数据、分布式、微服务和服务治理的过程中,可能会遇到的各种问题,以及解决方案。本期大会将力争借助广大同仁一如既往的积极参与和支持,将...

mjc199252
2018/11/06
0
0
数人云Meetup|Building Microservice NO.1 深圳站

发展变革,容器化的兴起,带来应用开发部署的变革,也带来应用设计架构和运维部署变化; 敏捷为王,造就Cloud Native技术及文化大势已成,云原生不仅是技术,在技术之上更是一种团队技术文化...

数人云
2018/01/04
8
0
数人云Meetup|Building Microservice NO.1 深圳站

发展变革,容器化的兴起,带来应用开发部署的变革,也带来应用设计架构和运维部署变化; 敏捷为王,造就Cloud Native技术及文化大势已成,云原生不仅是技术,在技术之上更是一种团队技术文化...

数人云
2018/01/04
0
0
PHP开发者年会

2018第二届PHP年会,旨在为PHP程序员、架构师解决大数据、分布式、微服务和服务治理的过程中,可能会遇到的各种问题,以及解决方案。本期大会将力争借助广大同仁一如既往的积极参与和支持,将...

mjc199252
2018/11/06
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Netty如何实现Reactor模式

在前面的文章中(Reactor模型详解),我们讲解了Reactor模式的各种演变形式,本文主要讲解的则是Netty是如何实现Reactor模式的。这里关于Netty实现的Reactor模式,需要说明的是,其实现的模式...

爱宝贝丶
19分钟前
1
0
前端面试:谈谈 JS 垃圾回收机制

摘要: 不是每个人都回答的出来... 原文:前端面试:谈谈 JS 垃圾回收机制 作者:前端小智 最近看到一些面试的回顾,不少有被面试官问到谈谈JS 垃圾回收机制,说实话,面试官会问这个问题,说...

Fundebug
20分钟前
0
0
修改django中的querydict

修改django中的querydict 在正常的请求/响应周期中访问时,request.POST和request.GET上的QueryDicts将是不可变的.要获得可变版本,您需要使用QueryDict.copy().或者,使用一个小技巧 # da...

_Change_
29分钟前
0
0
php简易缓存函数

不需要特别复杂的缓存的时候可以采用简易缓存,设置缓存有效期,有效返回数据,无效返回无效.然后每日清空一下所有缓存.毕竟缓存太多了也占地方 /** * 缓存 * @param $key 缓存名 * @p...

xiaogg
32分钟前
0
0
linux 使用文件增加虚拟内存 swap

之前买了个云服务器玩,不过是最低配置的1核1G,后来发现这个内存太小了,随便装几个软件就不行了,内存消耗较大的像 redis 运行起来很多问题。 这些时间了解了下 docker 容器,去尝试了下发...

非摩尔根
36分钟前
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部