微服务架构实践感悟

标签: 微服务 Microservices blog | 发表时间:2015-05-14 00:00 | 作者:
出处:http://mindwind.me/

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

在微服务架构(Microservices)这个命名被正式提出来之前,我们做系统也有一套著名的思想理论,叫做面向服务架构(SOA)。 去年初我就写过一篇文章 《面向服务与微服务架构》 来阐述面向服务和微服务架构的关系,当时并没有给出明确定义,只是有个模糊认知,而在近一年的实践过程中两者的关系越发清晰起来, 我们就从定义两者的关系这里开始吧。

微服务(Microservices)与 面向服务(SOA)架构

You should instead think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.

上面这段引用自 《Building Microservices》 一书, 通过过去一年的实践认知,我对这个定义是认同的,面向服务架构(SOA)的概念已有十多年,它提出了一种架构设计思想, 但没有给出标准参考实现,而早期企业软件业界自己摸索了一套实践方式 —— 企业服务总线(ESB)。 但历史证明 ESB 的实现方案甚至在传统企业软件行业也未取得成功,Martin Fowler 说正是因为 ESB 当年搞砸了很多项目, 投入几百万美金,产出几乎为 0,因此 SOA 这个概念也蒙上了不详的标签,所以当微服务架构出现时, 其拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签,而直接称其为微服务架构(Microservices Architecture Style), 让人以为是一套全新的架构思想,我也因此困惑了一段时间,但事实上它的本质依然是 SOA 的一种实现。 正如上面引文所说,就像早年流行的 XP(极限编程)和近年流行的 Scrum(好像没有标准的中文说法)实际都是敏捷软件开发思想 的具体实践方法而已。

为什么选择微服务架构

首先,当然是该套架构方法有著名的成功经验才导致我去了解与学习它。 微服务架构中的 “微” 体现了其核心要素,即服务的微型化,就是每个服务微小到只需专注做好一件事。 这件事紧密围绕业务领域,形成高度内聚的自治性。

以前我做过的一些大型应用系统,采用模块化的分层式架构,所有的业务逻辑代码最终会打进一个代码库中统一部署。 这种应用架构的问题是,全部开发人员会共享一个代码库,不同模块的边界模糊,实现高内聚、松耦合极其困难。 如果你接手过这类应用的遗留系统,尝试去做重构改进时,肯定碰到过这类场景,改了一个地方好几个其他模块也需要同步改动, 模块的边界轻易被穿透,这种应用的架构有一个很形象的名字叫 “洋葱架构”,洋葱的特点就是一层又一层的粘连, 重构这样的系统就像切洋葱一样让人忍不住飙泪。

微服务架构强调 “微”,但之前有些采用了 SOA 服务化架构思想的系统会搞出很多胖服务来,一点也不微,这依然带来耦合。 这一点只能依赖系统架构师的服务化建模能力了,但微服务架构强调每个服务一个进程, 使用进程为边界来隔离代码库至少让同一应用系统不同层次的开发人员享有自己完全自治的领地,每个微服务都有一个掌控者。 从某种程度上让不小心做错事,例如:跨出服务边界的代码耦合依赖,变得没那么容易。

去年对我们应用系统的代码行数做了个统计,有超过 40 万行。 一个 20 人的团队维护一个 40 万行共享代码库的单一应用,在里面修改 bug 和添加功能都将十分困难。 有一篇文章 《程序员的成长和代码行数的关系》 里提到大部分普通程序员成长生涯的瓶颈在 2 万行代码左右, 超过这个代码行数的应用系统维护起来将倍感吃力,所以我们系统这两年的高速发展膨胀,已让团队维护起来倍感吃力了。 所以我们想要把一个大系统拆分成许多不同的微服务,每个微服务的规模大小控制在一个普通程序员的舒适维护区能力范围内。

微服务架构实施

把 1 个应用进程部署到 1 台主机,部署复杂度是 1 x 1 = 1,我们有 200 台主机,那么部署复杂度是 1 x 200 = 200。 把 1 个应用进程拆分成了 50 个微服务进程,则部署复杂度变成了 50 x 200 = 10000。 部署变得复杂和麻烦多了,同时监控的进程数也大幅增加,监控的复杂度也上升了很多。

所以实施微服务架构是有很高成本的,只有系统的规模到了一定程度才适合,这也是为什么微服务架构实践诞生于大型互联网公司。 微服务推崇一切自动化的文化,这也是因为其运维复杂度的乘数级飙升, 从开发之后的构建、测试、部署都需要一个高度自动化的环境来支撑才能有效降低边际成本。

《Building Microservices》 一书对实施微服务架构有系统性的描述和很多业界案例的简单引用描述,这里不展开讲实施细节,那样就太长了。 我们这里简单总结下实施的要点:

  1. 自动化文化与环境:自动构建、自动测试、自动部署。
  2. 围绕业务能力建模服务,松耦合、高内聚、暴露接口而隐藏实现细节。
  3. 服务协作模型:中心化(乐队模型:中心指挥)和去中心化(舞蹈模型:群舞自组织),各自场景不同。
  4. 服务交互方式:RPC/REST/WS 技术很多但考虑统一。
  5. 服务部署的独立性、失败隔离性、可监控性。
  6. 服务流控:降级、限流
  7. 服务恢复:多考虑故障发生如何快速恢复而非如何避免发生故障。
  8. 服务发布:灰度。
  9. 服务部署:一服务一主机模型,需要虚拟化(Hypervisor)、容器化(LXC, Docker)等技术支持,实现硬件资源隔离。
  10. 服务配置:中心化配置服务支持
  11. 康威定律:任何设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。系统架构的设计符合组织沟通结构取得的收益最大。
  12. 伯斯塔尔法则:服务健壮性原则 —— 发送时要保守,接收时要开放。

自进化的微服务架构

早期人们把软件开发和建筑学作类比,Architect 这个词来就源于建筑学,但软件产品和建筑物的性质完全不同。 建筑物本身一旦建成则几无变化了,唯有老化后被替代了。 软件系统会在其生命周期中不断变化,唯一不变的就是变化,拥抱变化,需用进化的观点看待架构演进。 与此类似的是城市,城市的演进发展总是渐进式的,我们不会在一座旧城旁建一座新城,然后把旧城的居民迁到新城然后再把旧城废弃了。 但经常我们会用这样的方法重写一个新系统并替换掉旧系统,付出高昂的成本。

而微服务架构思路是不鼓励这种方式的,系统的演进是通过局部的新增、改进或替换微服务来实现的。 而微服务本身的变化周期是不同步的,从整体上就形成了一种渐进式的、符合自然进化的系统演进道路。 所以 Architect(架构师)更像是城市规划师而非建筑师,对软件系统进行类似城市划分区域的规划。 从常识上我们知道把学校和住宅放在一个区域内是合理的,但如果再放一个垃圾处理厂则不合理。 学校和住宅就是提供两种不同能力的服务,垃圾处理厂是另一种服务,但现实中软件系统的规划其实不像城市规划那么有常识性, 这是架构师能力和经验发挥作用的地方,前期规划的不合理会在后期带来维护成本的放大。

每个历史悠久的城市都有各自不同的味道,城市中的人、时间、技术进步共同决定了今天城市的面貌。 微服务架构的妙处就在于它符合城市历史演进规律,随着人员变化、时间、技术改进而引发自然渐进式的进化。

微服务架构与架构师

架构师的一个角色是技术决策者,技术决策涉及很多权衡取舍(trade-off),而微服务架构给了架构师更多权衡取舍的空间。 每个微服务实现层面的技术决策更多由服务负责人决定,服务的分拆伴随着决策权和责任的分拆,这也减轻了整体应用负责人的责任负担。 架构师解放出来从整体和全局上将更加关注服务之间是如何交互,并确保能正确的监控系统全局的健康性。

分拆了服务实现的技术决策权,那何时又该适当的介入以避免服务实现不当危及整体系统的安全? 就像教孩子骑车,你无法代替它们去骑,你小心的看着他们骑的歪歪扭扭,担心他们摔倒。 事实上,孩子骑车摔倒的次数比你担心的要少,但如果每次快摔倒时都去扶住,那么他们也许永远学不会骑车。 当孩子骑车失控时冲向了繁忙的马路或要冲下路边的深沟,那时才有必要介入去稳住他们。

架构师工作在抽象和具体两个层面:

  • 架构是一项技术工作,技术工作要服务于组织的战略目标。
  • 大量的工程实践在每日的工作中不断变化,而渐渐稳定的实践方式被抽象提炼为一系列原则。
  • 原则的普及带来整体效率的提升和边际成本的下降,以更有效的支持组织战略目标的快速达成。
  • 另外也要确保这些原则不是让开发人员的生活变得更凄惨而是更美好。
  • 跟踪新技术发展确保能在合适的时候做出正确的取舍折衷。
  • 让开发人员理解某项技术决策的影响和制约以便最有效的执行,甚至在特定情形下深入到代码的实现层面。

文章开头说了,这是我们实施系统的第四个大版本,而之前每一个大版本升级都是一次旧城到新城的整体搬迁。 而微服务架构天然的自然进化属性是否预示着这应该是最后一个大版本升级了? 微服务架构述说着没有永恒的架构,只有进化的架构,但微服务架构不是银弹,也没有银弹。

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

微服务架构实践感悟

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

详解微服务实践从架构到部署

- - IT瘾-dev
这段时间公司事情多,这篇文章写了放、放了写…耽搁了一些进度. 各个自媒体的更新也慢了很多,这里给大家说句抱歉了. 现如今“微服务”遍地开花,已经成软件架构领域最受欢迎的热门话题之一. 网上和书籍中都有很多关于微服务基础和优势的学习材料,但是我们可能会发现这东西在现实世界企业场景中似乎好像没那么普及,真正能跑的微服务资源其实也不是很多,大多是停留在概念和摸索阶段.

从单体架构迁移到微服务, 8 个关键的思考、实践和经验

- - 互联网 - ITeye博客
随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多. 去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上. 毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix、Uber这样的公司都是非常成功的应用案例.

谈微服务架构

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

微服务与架构师

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

面向服务与微服务架构

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

微服务架构成功之路

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

微服务架构-模块迁移

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

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

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

迁云架构实践

- - 博客园_知识库
  云计算作为信息技术领域的一种创新应用模式,自其诞生以来一直备受关注. 由于其具备低成本、弹性、易用、高可靠性、按需服务等特点,近年来被看作是新一代信息技术变革和商业模式变革的核心. 互联网、游戏、物联网等新兴行业纷纷积极拥抱云计算,对大部分企业用户来说,受限于传统IT技术架构的束缚,往往缺乏迁移到云计算的动力和技术实现参考.