知其然，知其所以然。
微服务大行其道之时，不少有识之士大声疾呼“致传统企业朋友：不够痛就别微服务，有坑”，“能不能拆分服务就不拆分”，但仍然无法阻挡对于微服务实施的热情和向往。
一则，开源全家桶用了之后，找工作方便一点。
二则，“上面领导”让用的，我们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和微服务
之三：服务化对于研发利好是过程，对于业务反应效率才是结果
之四：服务化架构承受之重：增加了哪些复杂度
之五：分布式事务
之六：服务治理和监控
往期推荐：
……
关注本公众号，欢迎订阅。
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。
1657
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
