微服务由来

著名互联网公司(Amazon、Netflix 等)实践摸索出新的大型系统架构方法论,并取得成功 > 技术理论派人士命名为微服务架构(Microservices)

Microservices之前,做系统著名的思想理论:面向服务架构(SOA)

十多年SOA概念提出架构设计思想,但没给出标准参考实现

企业软件实践得出 ESB,但历史证明甚至在传统企业软件行业也未成功,Martin Fowler 说正是因为 ESB 当年搞砸了很多项目, 投入几百万美金,产出几乎为 0,因此 SOA 这个概念也蒙上了不详的标签

所以微服务架构出现时,拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签,而直接称其为微服务架构,让人以为是一套全新的架构思想,但事实上本质依然是 SOA 一种实现

早年流行的 XP(极限编程)和近年流行的 Scrum实际都是敏捷软件开发思想的具体实践方法而已

为什么选择微服务架构

架构方法著名成功经验 > 服务微型化,每个服务小到只专注做好一件事,这件事紧密围绕业务领域,形成高度内聚的自治性

传统模块化的分层式架构

以前一些大型系统,所有的业务逻辑代码最终会打进一个代码库中统一部署

开发人员共享一个代码库,不同模块边界模糊。高内聚、松耦合极其困难

遗留系统重构时,改一个地方,好几个其他模块也要同步改动,模块边界轻易被穿透

应用的架构很形象:“洋葱架构”,一层又一层的粘连,重构就像切洋葱一样让人忍不住飙泪

微服务架构

强调 “微”,之前有些采用SOA思想的系统会搞出很多胖服务来,一点也不微,依然带来耦合

微服务架构强调每个服务一个进程, 用进程为边界来隔离代码库,至少让同一应用系统不同层次的开发人员享有自己完全自治的领地,每个微服务都有一个掌控者

从某种程度上让不小心做错事,例如:跨出服务边界的代码耦合依赖,变得没那么容易

要把大系统拆分成许多不同的微服务,规模大小控制在一个普通程序员的舒适维护区能力范围内

微服务架构实施

1个应用进程部署到 1 台主机,部署复杂度是 1 x 1 = 1

200 台主机,部署复杂度是 1 x 200 = 200

1个应用进程拆分成50个微服务进程,部署复杂度变成了 50 x 200 = 10000

部署,监控复杂度上升很多

所以实施有很高成本,只有系统规模到了一定程度才适合,这也是为什么微服务架构实践诞生于大型互联网公司

微服务推崇一切自动化的文化,这也是因为其运维复杂度的乘数级飙升

从开发之后的构建、测试、部署都需要一个高度自动化的环境来支撑才能有效降低边际成本

《Building Microservices》

  • 自动化文化与环境:自动构建、测试、部署

  • 围绕业务能力建模服务,松耦合、高内聚、暴露接口而隐藏实现细节

  • 服务协作模型:中心化(乐队模型:中心指挥)和去中心化(舞蹈模型:群舞自组织),各自场景不同

  • 服务交互方式:RPC/REST/WS 技术很多但考虑统一

  • 服务部署的独立性、失败隔离性、可监控性

  • 服务流控:降级、限流

  • 服务恢复:多考虑故障发生如何快速恢复而非如何避免发生故障

  • 服务发布:灰度

  • 服务部署:一服务一主机模型,需要虚拟化(Hypervisor)、容器化(LXC, Docker)等技术支持,实现硬件资源隔离

  • 服务配置:中心化配置服务支持

  • 康威定律:任何设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。系统架构的设计符合组织沟通结构取得的收益最大

  • 伯斯塔尔法则:服务健壮性原则 —— 发送时要保守,接收时要开放

自进化的微服务架构

软件开发和建筑学作类比,Architect 这个词来就源于建筑学,但软件产品和建筑物的性质完全不同

建筑物本身一旦建成则几无变化了,唯有老化后被替代了

软件系统会在其生命周期中不断变化,唯一不变的就是变化,拥抱变化,需用进化的观点看待架构演进

与此类似的是城市的演进,发展总是渐进式的,不会在一座旧城旁建一座新城,然后把旧城的居民迁到新城然后再把旧城废弃了

但经常会用这样的方法重写一个新系统并替换掉旧系统,付出高昂的成本

而微服务架构思路是不鼓励这种方式的,系统的演进是通过局部的新增、改进或替换微服务来实现的

而微服务本身的变化周期是不同步的,从整体上就形成了一种渐进式的、符合自然进化的系统演进道路

所以 Architect(架构师)更像是城市规划师而非建筑师,对软件系统进行类似城市划

区域的规划

常识上知道把学校和住宅放在一个区域内是合理的,但再放一个垃圾处理厂则不合理

学校和住宅就提供两种不同能力的服务,垃圾处理厂是另一种服务

但现实中软件系统的规划其实不像城市规划那么有常识性,这是架构师能力和经验发挥作用的地方

前期规划的不合理会在后期带来维护成本的放大

每个历史悠久的城市都有各自不同的味道,城市中的人、时间、技术进步共同决定了今天城市的面貌

微服务架构的妙处就在于它符合城市历史演进规律,随着人员变化、时间、技术改进而引发自然渐进式的进

微服务架构与架构师

架构师的一个角色是技术决策者,技术决策涉及很多权衡取舍(trade-off),而微服务架构给了架构师更多权衡取舍的空间

每个微服务实现层面的技术决策更多由服务负责人决定,服务的分拆伴随着决策权和责任的分拆,减轻了整体应用负责人的责任负担

架构师解放出来从整体和全局上将更加关注服务之间是如何交互,并确保能正确的监控系统全局的健康性

分拆了服务实现的技术决策权,那何时又该适当的介入以避免服务实现不当危及整体系统的安全?

就像教孩子骑车,你无法代替它们去骑,你小心的看着他们骑的歪歪扭扭,担心他们摔倒

事实上,孩子骑车摔倒的次数比你担心的要少,但如果每次快摔倒时都去扶住,那么他们也许永远学不会骑车

当孩子骑车失控时冲向了繁忙的马路或要冲下路边的深沟,那时才有必要介入去稳住他们

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

  • 架构是一项技术工作,技术工作要服务于组织的战略目标

  • 大量的工程实践在每日的工作中不断变化,而渐渐稳定的实践方式被抽象提炼为一系列原则

  • 原则的普及带来整体效率的提升和边际成本的下降,以更有效的支持组织战略目标的快速达成

  • 另外也要确保这些原则不是让开发人员的生活变得更凄惨而是更美好

  • 跟踪新技术发展确保能在合适的时候做出正确的取舍折衷

  • 让开发人员理解某项技术决策的影响和制约以便最有效的执行,甚至在特定情形下深入到代码的实现层面

微服务化架构演进与人员组织

初期版本单一应用模式,核心开发团队只有五、六人

团队扩张到 20 人左右,单一应用的维护协作成本已变得不可忽视

服务化拆分是进入第二版时做出的一个选择,但当时拆分粒度其实较粗,方便把团队拆分为几个小组来分别维护不同的服务和子系统

随着业务的发展,每个当初拆分的子系统或服务都膨胀到了一定的复杂度

单一进程应用实际承载了数十个业务服务,单人维护单一服务进程应用开始变得有负担,而类同业务大量需求导致的定制化开发严重拖累团队的生产力,进一步的微服务化与业务组件平台化将是进入第三版的主题

微服务的粒度

随公司运维基础设施(编译、部署、发布、监控和预警)逐步成熟为微服务化的生产应用铺平了道路

微服务拆分遵循了两个纬度,一个是业务服务分级化、目前定为三级(0、1、2)

0 级服务为最核心

越是核心的业务拆分的职责越单一和正交化,实现功能的最小集

足够的简单单一对于确保稳定、性能和控制变更都有莫大益处,边际成本递减效应明显

微服务规划与设计

与城市规划类似

首先一个城市会化成几个大的片区,每个片区承担着城市发展所需要不同功能职责(商业、居住、工业、科技等) 只有大的片区划分是不够的,仅仅完成了顶层设计

微服务化的设计需进一步深入到这个片区到底是否需要安置一个 “购物中心”或“学校” 之类

微服务化设计完成后,每个微服务的契约与主要职责就应该像 “购物中心”或“学校” 这样的描述那么明确了

微服务功能职责仅仅是服务契约中的一部分,另一部分则是非功能规约

例如一个 “购物中心” 的确定则隐含对周围的交通流量提出了要求,否则过于拥堵的交通压力会影响

“购物中心” 功能的可用性 因此当设计一个微服务的契约时,需要描述清楚它提供的功能职责、承诺的响应时间分布、承载的最大流量(TPS)等设计要素

人员角色的变化

按微服务拆分系统后,按照 “服务即产品” 的思路,人员角色将发生变化

普通工程师从仅仅开发功能到开发、运营服务,工作性质的转变将带来思路和关注点的变化

每个服务至少有一个工程师作为负责人,当然能力更强的人可能会负责更多的服务

大量拆分的微服务带来开发人员交集的减少,对于大规模的团队并行开发好处明显

而服务负责制对个人能力要求更高,自驱动和自学习能力更强的人会得到更多的成长机会,个人成长路线的发展也打开了空间

这时团队的构成会变得类似 NBA 球队的组成,工程师的角色类似球员,架构师或技术经理类似主教练,而部门经理则是球队经理

球员只管打好球,教练负责球员训练、培养与战术安排,经理则掌握着人事权,控制着球员的薪水升迁,招聘到优秀的球员

一只篮球队场上实际只有五个位置,对应不同服务的负责人,如果人员少于服务分类,实际会有能力强的球员同时打多个位置

而当人员多于服务分类时,必然有人是首发主力队员,而有人则是后补队员,甚至也有人是长期坐冷板凳的

谁能成为首发主力,甚至成长为明星球员这多取决于个人努力、能力以及比赛的受欢迎程度

球队要打出好成绩需要优秀的球员、教练相互默契的配合,这一点也是与按微服务化组织的开发团队相一致的 当然最好能在更受欢迎比赛上打球