谈微服务架构

标签: IT咨询 | 发表时间:2016-03-22 03:38 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性。


从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的。

而对于微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。

把这个核心搞清楚后,再来看下网上找到的对微服务架构的一些定义和阐述:

微服务 可以在“自己的程序”中运行,并 通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。


对于上面红色字体标注的两点,再强调下即:

首先对于应用本身暴露出来的服务,是和应用一起部署的,即服务本身并不单独部署,服务本身就是业务组件已有的接口能力发布和暴露出来的。了解到这点我们就看到一个关键,即我们在进行单个应用组件设计的时候,本身在组件内部就会有很大接口的设计和定义,那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务,而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。

其次,微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。这个也可以看到在互联网开放能力服务平台基本都采用了Http API的方式进行服务的发布和管理。从这个角度来说,组件超外部暴露的能力才需要发布为微服务,其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑,组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。

微服务的基本思想在于考虑 围绕着业务领域组件来创建应用,这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。

对于互联网谈到微服务架构一定会谈到Devops即开发测试和部署运维的一体化。当我们的单体应用以及拆分为多个小应用后,虽然整体架构可以松耦合和可扩展,但是如果拆分的组件越多,这些组件之间本身的集成和部署运维就越复杂。即任何一个组件,当他依赖的外部其它应用组件越多的时候,整个集成,部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量,一是增加出错概率。

原来谈组件化开发谈的最多的是单个组件的持续集成,包括配置环境集成,自动打包部署,自动化的冒烟测试等。对于微服务架构下首先仍然是要做好单个组件本身的持续集成,其次在这个基础上增加了多个组件的打包部署和组件间的集成。里面的核心思想就是Devops的思路,希望能够实现开发设计到部署运维的一体化。

由于微服务架构里面强调了单个组件本身是可以在独立的进程里面运行,各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性,我们可以用虚拟机,但是当几十个进程都完全用独立的虚拟机就不现实的,而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情,每个Docker是独立的容器刚好又完全做到进程级别的隔离,资源占用率又最小,这些特点刚好满足微服务架构的开发测试和自动化部署。

前面这些问题思考清楚后就是考虑所有暴露的微服务是否需要一个统一的服务管控和治理平台,按照当前微服务架构的整体思路,虽然单个服务的实现和发布仍然是在组件内部完成的,但是这些组件暴露的服务本身的调用情况,服务本身的安全,日志和流量控制等仍然需要一个统一的SOA服务管理平台来完成。

由于微服务尽量都是通过HTTP API的方式暴露出去的,因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。但是最基本的服务注册,服务代理,服务发布,服务简单的路由,安全访问和授权,服务调用消息和日志记录这些功能还是需要具备。类似淘宝的Dubbo架构,即可以做为微服务架构下的服务管控平台。

对于这种服务管控平台,核心需要讨论的就是服务每次调用本身的消息传递,输入和输出日志是否需要记录,当前就有两种做法,一种是不记录,管理平台只负责服务注册和目录发布,安全授权,实际的服务访问仍然是两个组件之间的点对点连接完成,这种方式下整个架构下获取更高的性能,同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈;另外一种方式就是完全记录,在这种方式下就需要考虑服务管理平台本身的集群化不是,高并发下的性能问题。而个人建议最好的方式还是SOA服务管理平台应该提供两种管理能力,同时仅仅对核心的需要Log日志的服务进行日志记录,而其它服务只提供服务目录和访问控制即可。

 

相关 [微服务 架构] 推荐:

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

[服务器架构]微服务的深入思考

- - CSDN博客推荐文章
微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能. 举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: . 计算新的库存该存到什么地方. 计算在仓库内将库存运往正确放置点的路线. 计算仓库内指定一组订单的拣货路线. 以上这些功能(可能还会有更多)都是由单个微服务实现的.

微服务架构--服务框架,metrics 和调用链数据

- - 行业应用 - ITeye博客
微服务化以后,为了让业务开发人员专注于业. 务逻辑实现,避免冗余和重复劳动,规范研发. 提升效率,必然要将一些公共关注点推到框架. 服务框架 ( 图 9) 主要封装公共关注点. 服务注册、发现、负载均衡和健康检查,. 假定采用进程内 LB 方案,那么服务自注. 册一般统一做在服务器端框架中,健康检.

怎么用API网关构建微服务|架构

- - 企业架构 - ITeye博客
转于http://www.tuicool.com/articles/bMnEbmv. 当选择将应用程序构建为一组微服务时,需要确定应用程序客户端如何与微服务交互. 在单体应用程序中,只有一组(通常是重复的、负载均衡的)端点. 然而,在微服务架构中,每个微服务都会暴露一组通常是细粒度的端点. 在本文中,我们将讨论一下这对客户端与应用程序之间的通信有什么影响,并提出一种使用API网关的方法.