知其然,知其所以然。
微服务大行其道之时,不少有识之士大声疾呼“致传统企业朋友:不够痛就别微服务,有坑”,“能不能拆分服务就不拆分”,但仍然无法阻挡对于微服务实施的热情和向往。
一则,开源全家桶用了之后,找工作方便一点。
二则,“上面领导”让用的,我们coding发现写代码测试麻烦了,我们无能为力。
本文仅仅探讨一下你选择什么,获得什么,承受什么。如果没有做好评估,则“得无所得”,可能陷入一地鸡毛的泥潭。
为什么要做服务化?
笔者习惯把单体架构和服务化架构作为对照,“微服务” 在微上面容易陷入争议和费解。
一位朋友说他觉得公司很折腾。
“几个开发,微服务数量有30个之多,数据访问DAO层和应用逻辑层也是独立的进程,写代码麻烦”!
克里斯·理查森在《微服务架构设计模式》一书中,对于单体架构和微服务做了一个对比,笔者用表格表达如下:
单体架构 | 微服务架构 | |
部署 | 将应用程序构建为单个可部署单元 | 将系统分解为一组可独立部署的服务,每个服务都有自己的数据库 |
应用复杂度 | 是简单应用的不错选择 | 大型复杂应用的更好选择 |
可容忍需求同一周期发布频度的团队 | 小型自治团队能够并行工作,从而加快软件开发的速度。 |
从表格可以看到,微服务架构并不是代表领先,而是取决于应用的复杂度,越复杂,单体架构铁板一块(同频研发、同频发布)遭遇的挑战越大,而微服务架构越有优势。
from (秦金卫:微服务架构深度解析与最佳实践)
结论:
1、服务化架构(微服务)更适合复杂领域的应用系统。
2、服务化架构(微服务)并不代表业务交付效率更高。
对于这2个结论的细节,后面酌情补充。
业务高速发展的早期形态1:臃肿单体架构
潘志伟老师曾经总结在传统的软件开发中遇到下面的“痛”,标志着应该从单体架构走向服务化架构:
1、代码冲突加剧
多个人或者一个团队一起维护一个模块,共同开发。当提交代码的时候发现大量冲突,每次提测或者发版的时候需要花大量的时间来解决冲突。随着团队规模的增大以及项目复杂程度增加,代码冲突的现象越严重;
2、模块耦合严重
模块之间通过接口或者DB相互依赖,耦合越来越严重。而且不同的人,写代码的风格不一样,代码质量也不一样,上线前需要协调多个团队,任何小模块的异常都会导致整个项目发布失败;
3、项目质量下降
由于所有的代码都是在一个服务里面,做一次改动,可能会牵一发而动全身,代码冲突以及耦合严重,导致测试覆盖范围不充分,经常会出现没有更改的模块在线上突然出现问题,查询后发现是由于工程师不小心做了某种改动,但是测试用例并没有覆盖;
4、团队效率下降
由于大量时间在处理代码冲突,消耗了研发人员大量的时间;而测试人员为了提高项目质量,不得不在每次发版之前做全方位的回归测试,本身一次小的迭代结果项目时间却很长。
业务高速发展的早期形态2:烟囱型架构
以头哥分享的传统金融的架构演进为例,烟囱型架构并不代表不能支持业务。甚至应对业务的效率不低。比如发展一块新业务,就有一个团队去支持,没有人甩锅,大家all-in。
随着业务规模发展到,人员的增长不能按照线性增长去满足业务的时候,问题就凸显出来。
一般存在几个问题。
1、功能的复用问题,大家都在修改用户服务,能不能一个全功能团队维护,更快一点。当然,我们先假设这样是美好的。
2、人员能力问题,涉及到中间件,大家想用什么用什么,各团队的TL和架构师存在感都很强,但存在搞不定的情况, 如果出故障多了,老板就火大了。
还有其它问题,老王总结为下面几个方面:
服务的大小并不重要
微服务这个术语的一个问题是会将你的关注点错误地聚焦在微上。它暗示服务应该非常小。实际上,大小不是一个重要的考虑因素。
更好的目标是将精心设计的服务定义为能够由小团队开发的服务,并且交付时间最短,与其他团队协作最少。理论上,团队可能只负责单一服务,因此服务绝不是微小的。相反,如果服务需要大型团队或需要很长时间进行测试,那么拆分团队或服务可能是有意义的。另外,如果你因为其他服务的变更而不断需要同步更新自己负责的服务,或者你所负责的服务正在触发其他服务的同步更新,那么这表明服务没有实现松耦合。你构建的甚至可能是一个分布式的单体。
微服务架构把应用程序通过一些小的、松耦合的服务组织在一起。结果,这样的架构提升了开发阶段的效率,特别是可维护性、可测试性和可部署性,这也就让组织的软件开发速度更快。微服务架构也同时提升了应用程序的可扩展性,尽管这不是微服务的主要目标。
进入服务化架构的误区
业务早期进行服务化阶段要慎重
笔者旗帜鲜明的反对早期就进行过度服务化的考虑。比如以一个代驾业务为例。我的想法,服务端程序早期一个war就够了;移动端涉及到安卓、ios甚至小程序需要考虑多端问题。至于用户服务、用户选择代驾、代际服务入驻等都可以慢慢来。说不定,一年,这条业务线又关了呢。
淘宝和支付宝往往是几百人维护一个前台和后台系统,才进行服务化拆分。当然当时还没进入移动时代,就需求上线特性的速度来讲,也不是太慢。按周进行发布。在一个单体架构中,进行较好的模块化,按照团队分而治之。研发态的团队组织关系和发布态的可以辩证看待。不是说那段经历是完美,是说明可以容忍,甚至不是最关键的阻碍,在支持业务上。
建议在单体架构阶段采取较好的架构决策,而不是匆忙进行服务拆分
同样,在Medium,他们在早期的单体应用程序中做出了一些很好的架构决策。
他们的单体应用程序由组件高度模块化,即使它已经发展成为一个非常复杂的应用程序,包括Web服务器,后端服务和离线事件处理器。这使得将一大块业务逻辑剥离到单独的服务相对容易,只要新服务提供与原始实现相同(高级)的接口即可。
整体应用程序在较低级别封装了数据存储详细信息。每种数据类型(例如,数据库表)具有两层实现:数据层和服务层。
数据层处理对一种特定类型数据的CRUD操作。
服务层处理一种特定类型数据的高级逻辑,并为系统的其余部分提供公共API。服务不共享它们之间的数据存储。
这有助于我们采用微服务架构,因为一种类型数据的实现细节完全隐藏在代码库的其余部分。创建新服务来处理某些类型的数据相对容易且安全。
单体应用程序还可以帮助我们对微服务进行建模,并使我们能够灵活地专注于系统中最重要的部分,而不是从头开始为所有微服务建模。
一些bad case 供参考
一:组织和服务划分配套。
曾经有一个国外的case,没有做对应的改变,导致微服务没有owner。他们大约有12个开发人员分布在两个功能团队和一个支持团队。工作波动性很大,没有专职负责团队。所有团队同时接触同一批代码很正常,不能将某个微服务指定给一个团队。
考虑架构时候一定要记得Conway's Law,其意思是软件架构会模仿组织和团队架构增长。微服务架构对于不同团队负责不同业务逻辑是比较有效的,然而,共享代码功能的工作模式最好采用单体式架构。
二:谨慎引入新的技术栈
某一个创业团队,由于技术负责人的喜好,引入了go语言做微服务。后来又由于招聘困难,同时维护了java语言的一套服务,分别取名V1.0,V2.0。目前升级V3.0 暂时还没有把V1.0下线。后续的维护成本是一个问题。
三:过犹不及的服务数量
Uber支付体验平台的工程经理Gergely Orosz称其所在的团队正将许多微服务转移到宏服务(macroservice,即大小适中的服务)。
他们声称在构建新平台时,在新服务方面做的规划要周到得多。这些服务不仅仅只做一件事:服务于一个业务职能部门。它们由一个团队(5至10位工程师)构建和维护。与那些早期的微服务相比,它们更具弹性,并且在开发和维护方面获得多得多的投入。
我的意思是当大家在学Uber的时候,最好一开始就想好服务粒度。
总结:
可能进入服务化阶段的几个征兆:
1、开发人员庞大,比如大于100人。众多人维护一个系统变得不可行,代码冲突和代码分支众多可能导致成本。
2、代码逻辑复杂,缺少层次。改动代码成本高,系统脆弱。如早期蘑菇街采用php ,后转向java,同时实现了服务化。
3、业务多元化发展,共享业务服务逐步凸显
我们说服务化,便于服务/能力共享,总要回答共享什么嘛。多业务发展让服务共享具备可能性。否则也就是沉淀一些会员服务。
4、扩展性瓶颈
比如数据库链接,系统共用的底层资源随着机器增加而大幅度增加。比如对于单体应用中的支付模块,订单模块需要不同的tps/qps要求。
当我们应用微服务/服务化,我们大致从这些维度进行评估。只有想清楚了,才能评估实施后的收益和成本支出。
微服务架构谈系列预告
之二:思辨SOA和微服务
之三:服务化对于研发利好是过程,对于业务反应效率才是结果
之四:服务化架构承受之重:增加了哪些复杂度
之五:分布式事务
之六:服务治理和监控
往期推荐:
……
关注本公众号,欢迎订阅。
技术琐话
以分布式设计、架构、体系思想为基础,兼论研发相关的点点滴滴,不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。