面向服务与微服务架构

标签: 服务 微服务 架构 | 发表时间:2014-04-27 21:06 | 作者:mindfloating
出处:http://blog.csdn.net

背景

最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发。本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化。


面向服务架构(SOA)

面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过。当时 java 企业应用领域 J2EE 依然是主流,应用程序被部署在庞大统一的符合 J2EE 规范的容器中运行,在单一进程中提供所有的功能。 而 SOA 提出的一些架构原则,在当时看来无疑是革命性的。 由于业已存在的大量单一庞大的应用,按照 SOA 的思想和架构原则来改造无疑相当于推翻重新开发一遍,在成本上很难接受。 因此早期的 SOA 通常和另外一个术语关联在一起——ESB(企业服务总线)。 当时在 SOA 的实施思路上无一例外的选择了 ESB 模式来整合集成大量单一庞大的应用,以保护企业前期投入成本。因此 ESB 其实是 SOA 特定历史阶段的一种实现方式。

然而,愿望总是美好的,现实却要残酷的多。过去这些年我们看到了很多实施 ESB 搞砸了的项目,投入几百万,产出几乎为 0,因此 SOA 这个概念也蒙上了不详的标签。 近几年流行起来的服务化架构,其拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签,而称其为微服务架构(Microservices Architecture Style)。但事实上 微服务架构依然是 SOA 架构思想的一种实现。


微服务架构(Microservices)

对微服务架构我们没有一个明确的定义,但简单来说微服务架构是:

采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。


微服务架构特征(Characteristics)

1. 通过服务实现组件化
传统实现组件的方式是通过库(library),传统组件是和应用一起运行在进程中,组件的局部变化意味着整个应用的重新部署。 通过服务来实现组件,意味着将应用拆散为一系列的服务运行在不同的进程中,那么单一服务的局部变化只需重新部署对应的服务进程。 另外将服务作为组件可以更明确的定义出组件的边界,因为服务之间的调用是跨进程的,清晰的边界和职责定义是设计时必须考虑的。

2. 按业务能力来划分服务与组织团队
康威定律(Conway's law)指出:

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
任何设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。

传统开发方式中,我们将工程师按技能专长分层为前端层、中间层、数据层,前端对应的角色为UI、页面构建师等,中间层对应的角色为服务端业务开发工程师,数据层对应着DBA等角色。 事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。 而微服务架构的开发模式不同于传统方式,它将应用按业务能力来划分为不同的服务,每个服务都要求在对应业务领域的全栈(从前端到后端)软件实现,从界面到数据存储到外部沟通协作等等。 因此团队的组织是跨功能的,包含实现业务所需的全面的技能。 近年兴起的全栈工程师正是因为架构和开发模式的转变而出现,当然具备全栈的工程师其实很少,但将不同领域的工程师组织为一个全栈的团队就容易的多。

3. 服务即产品
传统的应用开发都是基于项目模式的,开发团队根据一堆功能列表开发出一个软件应用并交付给客户后,该软件应用就进入维护模式,由另一个维护团队负责,开发团队的职责结束。 而微服务架构的倡导者提议避免采用这种项目模式,更倾向于让开发团队负责整个产品的全部生命周期。Amazon 对此提出了一个观点:

You buidl it, you run it.

开发团队对软件在生产环境的运行负全部责任,让服务的开发者与服务的使用者(客户)形成每天的交流反馈,来自直接客户端的反馈有助于开发者提升服务的质量。

4. 智能终端与哑管道
微服务架构抛弃了 ESB 过度复杂的业务规则编排、消息路由等。 服务作为智能终端,所有的业务智能逻辑在服务内部处理,而服务间的通信尽可能的轻量化,不添加任何额外的业务规则。

5. 去中心统一化
传统应用中倾向采用统一的技术平台或产品来解决所有问题。 不是每个问题都是钉子,也不是每个解决方案都是一个锤子。 问题有其具体性,解决方案也应有其针对性。 用最适合的技术方案去解决具体的问题,在大一统的传统应用中其实很难做到,而微服务的架构意味着,你可以针对不同的业务服务特征选择不同的技术平台或产品,有针对性的解决具体的业务问题。

6. 基础设施自动化
单一进程的传统应用被拆分为一系列的多进程服务后,意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。 必须要有合适的自动化基础设施来支持微服务架构模式,否则开发、运维成本将大大增加。

7. Design for failure
正因为将服务独立在不同的进程中后,引入了额外的失败因素。 任何时刻对服务的调用都可能因为服务方不可用导致失败,这就要求服务的消费方需要优雅的处理此类错误。 这其实是相对传统应用开发方式的一个缺点,不过随着一些开源服务化框架的出现,对业务开发人员而言适当的屏蔽了类似的错误处理,不过开发人员依然需要知道对服务的调用是完全不同于进程内的方法或函数调用的。

8. 进化设计
一旦采用了微服务架构模式,那么在服务需要变更时我们要特别小心,服务提供者的变更可能引发服务消费者的兼容性破坏,时刻谨记保持服务契约(接口)的兼容性。 对于解耦服务消费方和服务提供方, 伯斯塔尔法则(Postel's law)特别适用:

Be conservative in what you send, be liberal in what you accept.
发送时要保守,接收时要开放。

按照伯斯塔尔法则的思想来设计实现服务调用时,发送的数据要更保守,意味着最小化的传送必要的信息,接收时更开放意味着要最大限度的容忍信息的兼容性。 多余的信息不认识可以忽略,而不应该拒绝或抛出错误。


微服务架构应用

采用微服务架构面临的第一个问题就是如何将一个单一应用拆分为多个服务。 有一个一般的原则是,单一服务提供的功能是可以独立被替换和升级的。 也就是说如果有 A 和 B 两个功能,如果 A 功能发生变化时同时 B 功能也需要变化,那么 A 和 B 这两个功能应该被划在一个服务中。

微服务架构应用的成功经验近年已越来越多,例如国外的 Amazon,Netflix,国内如阿里都采用微服务架构取得了很多正面的成功案例。 但通过上文所述微服务架构特征看出,其实微服务架构模式有利有弊,需要根据实际的业务、团队、环境进行仔细权衡利弊。 其中的服务拆分带来的额外开发、测试、运维、监控的复杂度,在现有的环境、团队下是否能够很好的支持。

另外,有人可能会说,我一开始不采用微服务架构方式,而是在单一进程内基于清晰定义的模块化方式,模块之间通过接口调用,到了适当阶段,必要的时候再将模块拆分为服务。 其实这个想法显得过于理想,因为进程内良好定义的接口通常不是很好的服务化接口。 一开始没有考虑服务化的设计方法,那么后期拆分时依然是一个痛苦的过程。


总结

正如,Martin Fowler 在其文中所说,微服务架构是否就是企业应用开发的未来,还有待时间的检验。 就目前的情况看,对此我们可以保持谨慎的乐观,这条路依然值得去探索。 实际任何的架构决策都是基于我们不完美的现状做出的,这正是架构取舍的微妙之处,超越任何的方法论。

作者:mindfloating 发表于2014-4-27 13:06:48 原文链接
阅读:0 评论:0 查看评论

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

谈微服务架构

- - 人月神话的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和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

微服务实战(一):微服务架构的优势与不足 - DockOne.io

- -
【编者的话】本文来自Nginx官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战. 正如作者所说,微服务架构更适合用于构建复杂的应用,尽管它也有自己的不足. 如果你想和我或者更多微服务专家交流,可以加我微信liyingjiese,备注『加群』. 群里每周都有全球各大公司的最佳微服务实践以及行业最新动态.

微服务架构之事件驱动架构 - 简书

- -
为了解决传统的单体应用(Monolithic Application)在可扩展性、可靠性、适应性、高部署成本等方面的问题,许多公司(比如Amazon、eBay和NetFlix等)开始使用微服务架构(Microservice Architecture)构建自己的应用. 微服务(Microservices) 是一种软件架构风格 (Software Architecture Style),它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯.