GitChat · 架构 | 为何微服务实施那么难？如何高效推动微服务架构演进

GitChat 做者：顾宇
原文：为何微服务实施那么难？如何高效推动微服务架构演进
关注公众号：GitChat 技术杂谈，一本正经的讲技术

前言

笔者从 2013 年加入 ThoughtWorks 至今共 4年时间。在这 4 年的时间里，我分别以 开发人员， DevOps 工程师、DevOps 咨询师、微服务架构师以及微服务咨询师的角色参与了共计 7 个产品和项目的微服务咨询和实施。其中有有成功，有失败，有反思，更多的是学习和总结。如下是我这些年来在微服务咨询上的经验总结，但愿能给陷入微服务实施困境的人带来一些帮助。

难点1：“一步到位”的认知错觉

这些年微服务大红大紫，可是真正可以拿出来作为可实践的案例少之又少。大部分的微服务案例只能看到微服务架构的“演进结果”，可是看不到微服务架构的“演进过程”。这就像每一个人看到一个架构的高峰，却没有看到攀登高峰的路径。

这就给不少架构师一个假象：微服务的架构是经过能力极高的架构师一步到位设计出来的。

这和不少团队自上而下的架构设计感觉和类似。因而架构师们蜂拥而至，各类分析方法论层出不穷，讨论和分享络绎不绝。然而真正落地实施的却不多，使得微服务在网络上慢慢变成了一种“玄学”：微服务的实施在“理论研究”的阶段。

这违反了软件架构的最基本规律：架构是解决当前的需求和痛点演进的，而没法对没有出现的问题和痛点进行设计。所以，一步到位的总体的微服务架构设计彻底没有必要。何况一个集中化的设计，很难体现微服务的轻量级优点。

我相信技术的发展必定是向不断下降成本的方向上发展的。若是新技术没有下降成本反而提高了成本，要么这个新技术有问题，要么必定是姿式不对，走错了路。

所以，准备实施微服务必定要有一个长期的思想准备。不过跨过了最初的门槛以后，剩下的工做能够被复制并且速度会愈来愈快。

难点2：“架构师精英主义”

不少产品对架构师的依赖很大，即“架构师精英主义”：认为产品架构只有这个组织的“技术精英”——架构师才能够完成，而团队其它成员只须要实现架构师的设计就能够。这是大型企业和大型系统的常见问题，这来源于长期的重量级企业级架构习惯。

而微服务则相似于一种“敏捷边际革命”：即由一个不超过2~8我的的小团队就能够完成的功能。并且这种规模的团队即便从整个产品团队移除也对总体产品的研发进度没有影响。所以，即便失败了不会带来太多的损失。不过，当第一个微服务改形成功，那么成功经验的复制带来的乘数效应却能带来很大的收益。

从架构改造投资的风险收益比来看，这是很是划算的。

所以，微服务团队彻底不必大张旗鼓，只须要两三我的就能够动工。可是，谁也没有微服务的实践经验啊，万一失败了怎么办？

这就带来了下一个难点。

难点3：缺少一个信任并鼓励创新的环境

面对未知的领域，失败再所不免。而面对这个不肯定性频发的世界，成功和失败每每再也不重要：也许今天的失败，明天再看就是成功，反之亦然。

成功意味只是代表结果符合本身的假设预期，而失败仅仅意味着结果不符合本身的假设预期。可是不管成败，咱们都能从行动的过程当中有所学习和反思，而这样的经验才是研发活动中最有价值的。

然而，不少组织，尤为“精英主义”的产品团队，责任和压力每每从上至下分解。因为组织庞大，金字塔的结构每每会构建一种以“不信任”为基础的制度。这种制度每每营造了一种“宁肯不做为，也不能犯错”的文化。因为上层则须要对失败负责，使得任何创新只是一个停留在组织上层的想法，难以落实推动。在这种状况下，组织的长期合做造成了稳定的工做习惯和思惟定势，并造成了利益平衡，这会使得整个组织在面对创新的时候“卡壳”。

当微服务以一种政治任务从上而下派发的时候，为了不失败，团队内部会相互推诿。经过不断的分析讨论和设计来论证这个事情的难度。在我看来，只要想搞，就必定能找到办法，而不是先设想出一堆尚未遇到的问题和责任。在行进中解决问题是比设计和讨论更加有效率的方法。

而组织解决“卡壳”的办法就是引入“背锅侠”：例如新聘请的架构师或外部咨询师，来完成这个事情。出了问题就不用本身来承担责任了。这样虽然是解决问题的一种折中办法，但可让事情毫无风险的执行下去。但这是一种短时间效应，没法解决组织自己的创新窘境，长期依赖外部力量来解决最有价值的问题不会让本身提高，反而造成了对外部力量的依赖。对于组织的凝聚力来讲不是一件好事。

只有打破当前的工做习惯和思惟定势，充分认识到创新的困难、风险以及价值的组织才能够占领创新的高点，吸引人才。

难点4：微服务技术栈的“选择困难症“

因为“精英主义”的架构师须要担负很大的责任并承担着很重的压力。他们必需要为微服务架构谨慎的选择技术栈。所以会在不一样的技术栈之间不断尝试。对于习惯了在大型研发组织里“精心设计，加班生产”的架构师而言。“长设计，慢反馈”节奏彷佛是理所应当的。

微服务开源社区的快速发展助长了“架构师焦虑”：若是采用落后的技术会被同行鄙视，被不懂技术的老板鄙视，甚至被下属鄙视。所以架构师们疲于在各类新型的技术栈之间比较和学习。此外，不熟悉技术每每会增大风险，架构师就须要更多的时间研究。带着“一步到位”的架构幻想对微服务技术栈精挑细选。而不会采用现有低成本的方案快速迭代的解决问题。

微服务的核心在于采用“小规模，快反馈”的机制下降软件系统的复杂性并经过虚拟和自动化技术分散风险，从而能够快速面对市场变化带来的各类挑战，并可以快速销售创新，得到市场的反馈。而不只仅是利用到了时下新兴的语言，编程框架或工具。

学习和实践是相辅相成的过程，在实践的时候学习，并把学习到的知识应用到实践中。而不是准备一场考试，先停下来学习，准备好了再尽心尽力。

以上四点会让大型组织面对微服务实施的时候“卡壳”，而这每每会致使微服务实施容易忽略的最重要一点，我认为也是核心的一点：

难点5：对微服务的技术变革估计太高，而对微服务带来的组织变革估计严重不足

做为架构师，永远要不要低估康威定理的威力： “设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。”

从制度经济学角度上讲，软件产品自己就是企业内部组织（员工）和外部组织（用户）沟通制度的计算机程序表达。这个制度的发展必定是在不断缩小内部组织之间以及内外部组织沟通成本的。

所以，系统的架构必定是和组织的架构相吻合的，若是不吻合，势必会带来问题阻碍组织的渐进。

这就引出了一个推论：若是企业组织的架构不是惟一的，那么微服务的架构方案也不是惟一的。

当架构和组织结构相一致的时候，一切都会很顺畅。反之，就会出现各类问题。

这个关系就像鞋和脚的关系，只有穿上合适的鞋，走起路来才会舒服。过大太小的鞋都不会让你加快前进的步伐。固然，你能够选择买鞋（引入产品），虽然并非很合脚，但还能够凑合穿。可是在换鞋的时候你不得不停下来试。你也能够花高价为本身定制一套，只不过，这个不会让你走得更快，只会愈来愈合脚。

若是全部人穿上了新鞋，都能跑得很快。那么这就不是鞋的问题，而是你脚的问题，这就不是换鞋能解决的了。你得先把脚的问题解决了，而后再看鞋的问题。固然，也能够经过鞋来矫正脚，只不过会花些功夫，但必定会比不停的换鞋更加有效。

很不幸，大多数的组织并无准备好迎接微服务架构带来的组织变化。仍然把“系统架构问题”和“组织问题”割裂成两个不一样领域的问题：微服务是技术问题，组织问题是管理问题。

有竞争力的组织，是一个经过融合优点达到 1+1> 2 的组织。而不是把优点割裂开，获得 1 + 1 <= 2 的组织。所以，技术问题和管理问题并非两个问题，而是同一个问题的两个侧面。

所以，若是你的组织结构是去中心化的小团队结构，那么不用担忧，你的应用架构会朝组织架构的方向演进。反之，若是你不是一个去中心化的小团队结构，那么微服务的架构会和组织架构格格不入。

那么，如何高效的推进微服务架构演进呢？

若是以上 5 点都让你膝盖中箭。那么根据我我的的经验，综合解决微服务实施难点的第一步就是：

步骤1：以终为始，先构建一个独立的敏捷微服务团队

咱们对微服务的期待就是：能够独立开发，独立部署，独立发布，而且去中心化管理。那么，咱们就先构造一只“能够独立开发，独立部署，而且去中心化管理”的团队。

这个团队为了达到这个目标，会采起各类方法（例如：DevOps，全功能团队）解决阻碍”独立开发，独立部署，独立发布 和 去中心化的问题。而根据康威定理，系统的架构会慢慢向去中心化方向发展。

必定要意识到，这个过程会打破大型系统自上而下的既有流程并采用更有生产力的方式构建新的组织结构。你索要作的就是要充分信任团队，把它看作是一个微型的技术管理创新。不要用老的方式控制团队的运做，这会打击团队的士气。

管理建议：

1. 让微服务团队彻底脱离以前的工做，专心于微服务的工做中。若是分心同时作几件事，每件事都不会作到最好。
2. 给微服务团队一些特权，为了知足“全功能微服务团队的”诉求，特事特办。
3. 若是团队在执行的过程出现了依赖从而阻碍了进度。则须要把依赖标明出来。代码中的依赖容易看见，但组织中的流程依赖很难发现。
4. 为了不团队对外部的“依赖惯性”，让团队本身想办法在内部解决依赖。
5. 组织流程的改变也是很重要的微服务架构产物，而不只仅是微服务代码或基础设施。

技术建议：

1. 为微服务创建一个全新的代码库，而不要从原先的代码库上克隆或者复制，避免和原团队的开发依赖。
2. 建设一个独立的持续交付流水线，最好是经过“流水线即代码技术”（例如 Jenkinsfile）来自动生成流水线。

步骤2：构建微服务的“电梯演讲”

成立了微服务团队以后，接下来就是要选择第一个实现的微服务。可是这个微服务应该多大，边界在哪是个问题。这不须要进行严格的设计和反复的论证，只要发现当前的痛点或者想要完成一个假设就足够上路了。让整个过程变轻，而不是变重。

个人建议是经过“微服务电梯演讲”的方式来定义微服务。格式能够是：

（XX微服务）用来

在（出现痛点的场景）的状况下

解决了（解决现有的某个问题）

从而（达到什么样的效果）

提高了（微服务的价值）

例如：

（订单查询微服务）用来

在（订单查询数量快速）的状况下

解决了（访问数量迅速升高致使总体应用性能降低的问题）

从而（分离了订单查询请求）

提高了（提高了其余功能的性能）

当构造了微服务的电梯演讲，团队就能够以此为原则启动了。当碰到和现有系统冲突的问题，替换几个词比较有帮助你作决策。（语言必定程度上也是具备魔力的）

把“拆分”换成“移除”。例如：“从现有系统中拆分出订单查询功能” 转变为 ”从现有系统中移除订单查询功能“。思惟方式就从一个团队负责两个系统变成了两个团队负责两个系统。

把“集成”换成“调用”。例如：”用户注册和用户登陆须要集成”转变为“用户登陆服务须要调用用户注册服务的信息”。思惟方式就把两个系统的关系更精确了，从而明确了微服务之间的关系和沟通方式。

管理建议：

1. 把微服务的电梯演讲打印出来挂到墙上，让团队成员铭记于心。这会强化组织对微服务的边界认识。
2. 随着团队的反思和学习，电梯演讲有可能会变动，但必定要让团队造成共识好和一致的意见。
3. 不要指望一次就能划分正确。划分是一个持续权衡取舍的过程。

技术建议：

1. 明确了微服务的职责和边界以后再去看代码，不然会被代码的复杂度影响。
2. 领域驱动设计（DDD）能够帮助你更好的划分微服务。领域驱动设计很好的遵循了“关注点分离”（Separation of concerns，SOC）的原则，提出了更成熟、清晰的分层架构。
3. 不会领域驱动设计（DDD）也没有关系。简单的使用“关注点分离原则”也能够帮你达到这一点。例如：从接口中分离出流量较大的接口独立部署，把读数据库和写数据库的 API 分开独立部署，把静态和动态访问分离……等等。

步骤3：以最小的代价发布出第一个微服务

要注意两个关键点：一个是“最小的代价”，另外一个是“发布”（Release）。

正如前文所述，微服务架构自己就觉了微服务必定是低成本低风险的渐进式演进。而最大的浪费在于：

1. 级别/职责分工明确的组织沟通结构。

2. “长时间，慢反馈”的行动习惯。

3. 先进且学习成本较高的技术栈。

所以，“最小的代价”包含了如下三个方面：

1. 最精简的独立敏捷全功能团队。

2. 最快的时间。

3. 代价最小的技术栈。

此外，不少微服务的“爱好者”因为惧怕失败，所以将微服务技术始终放在“实验室”里。要敢于面对失败，在生产环境中面对真实的问题，但要采起一些规避风险的措施。

管理建议：

1. 尽可能让现有微服务团队本身学习解决问题，成为全功能团队。如无必要，毫不增添新的人手。
2. “扯破嗓子不如甩开膀子”，先动起来，在前进中解决问题。
3. 先考虑最后如何发布，根据发布流程倒推。

技术建议：

1. 根据当前技术采用的状况选择代价较小的技术栈。
2. 采用动态特性开关（Feature Toggle），在发布后能够在生产环境动态的控制微服务的启用，下降失败风险。
3. 若是采用了特性开关，必定要设立删除特性开关和对应旧代码的时间，通常不超过两个月。不然后面大量的特性开关会带来管理成本的提高和代码的凌乱。
4. 因为团队比较小，功能比较单一，不建议采用分支来构建微服务，而应该采用单主干方式开发。

步骤4：取得快速胜利（Quick wins），演示（Showcase）驱动开发

刚开始进行微服务改造的时候必定会是一个试错的过程。若是目标定得太大，会让团队倍感压力，从而士气低落。而制定每日的短时间目标，赢得快速胜利则会不断激励团队的士气。经过设定当天结束的产出来肯定今天须要作什么是一个很是有效的办法。

每日演示（Daily Showcase）就是一种推动产出的作法。天天向团队分享今天的工做内容，使小组可以共同窗习。而且以当天或者明天的 showcase 做为目标。每一个人showcase 的内容通常不超过20分钟，一天的 showcase 时间不超过一小时。能够早上 showcase，也能够下班后 showcase。

常见的快速胜利目标以下：

1. 构造第一条微服务流水线。
2. 上线第一个微服务 HelloWorld。
3. 构造出第一个微服务自动化测试。

而如下的目标不适合做为快速胜利的目标：

1. 构造出微服务 DevOps 平台。
2. 完成整个产品的微服务架构拆分。
3. 构造微服务自动化运维体系。

管理建议：

1. 要防止团队画大饼，完成好每日和每周的工做目标便可。微服务开发自己就没有很长周期。
2. 强迫团队有所产出，这样才能用关键产出驱动开发。产出不必定是代码或者基础设施，一篇总结，或者学习的文章分享，甚至是踩过的坑和遇到的问题均可以展现，目的是要打造自治学习的团队。
3. 贵在坚持，不要计划太远。超过一个月，就要对目标是否是范围过大进行反思。
4. 以天为单位拆分任务，超过一天的必需要拆分。没法在一天完成的工做须要拆分出阶段性产出。
5. 若是能结对，而且可以天天交换结对，showcase 没必要要。
6. 可视化全部任务，用敏捷看板来管理任务是了解现状的最好方式。

技术建议：

1. 除了让第一个 HelloWord 微服务尽快发布到生产环境，其它的不要想太多。
2. 完成了 HelloWord 的发布，而后要考虑如何对发布流程进行改进。而不是上线业务。

步骤5：代码未动，DevOps 先行

微服务解耦的本质是把代码内部的复杂性经过一些工具转化外部复杂性。把代码内部的复杂性分散到各个微服务中以下降总体复杂性和架构风险。在这个过程当中会大量采用了 DevOps 技术和工具。也能够说，微服务是 DevOps 文化和技术在走到极致的必然结果。

以 J2EE 的应用为例，之前Web Server + App Server + MiddleWare + Database 的传统架构被代码更少，更多的基础设施工具所取代。由于基础设施相对于代码来讲更加稳定，更加利于扩展。

我把微服务的技术架构问题比做“搭台唱戏”：首先须要创建好微服务交付和运行的平台，而后让微服务上台“唱戏”。

这个平台一开始不须要很完善，只须要知足生产上线的必要要求便可。而在不少企业里，这个部分是由 Ops 团队在交付流程的末尾把关的。所以，把最后一道关卡的确认工做放到最前面考虑能够减小后期的返工以及没必要要的浪费。

之前，软件的开发和测试过程是分开的。然而，随着 DevOps 运动的兴起和各类自动化运维工具的兴起，这之间的必要性不如从前，只要有足够的自动化测试作质量保证，就能够很快的将微服务快速部署和发布到生产环境上。

最开始的时候，哪怕是发布一个 Hello World 程序，都代表微服务的持续交付和运行的平台已经搭建好，微服务交付流程已经打通，这一点是重中之重。

从技术交付产物来讲，DevOps 主要交付两点：

1. 持续交付流水线。
2. 微服务运行平台。

为了保证微服务交付的高效，须要把这两者经过自动化的方式有机的结合起来，而不是各为其主。让开发和运维的矛盾变成“自动化的开发运维矛盾”

此外，DevOps 指的不光是一系列技术，更是一种工做方式。从团队工做方式来讲，DevOps 要作到：

1. 要让 Dev 和 Ops 共同参与决策，设计，实现和维护。
2. 团队彻底独立自主，打破对现有流程的依赖。
3. 不断的追求改进，让团队行程改进的团队文化。

管理建议：

1. 给团队继续前进最大的动力就是新程序快速投入生产。
2. 若是你的组织是 Dev 和 Ops 分离的组织，先咨询一下 Ops 工程师的意见。最好是可以给微服务团队里面配备一名 Ops 工程师。
3. 若是不具有实施 DevOps 的条件，微服务架构就要从运维侧，而不是开发侧开始进行。

技术建议：

1. 微服务的平台一开始能够很简单，能够之后慢慢加强和扩展。可是必定要部署到生产环境里使用。
2. 若是想使用现成的微服务平台能够参考 Spring Cloud。
3. 微服务运行平台能够经过反向代理和生产环境并行运行。
4. 采用灰度发布技术在生产环境中逐步提高微服务的使用占比。
5. 基础设施即代码是 DevOps 核心实践，能够帮助开发人员迅速在本机构建生产环境类似的开发环境，减小环境的不一致性。能够采用 Docker，Ansible，Vagrant 等工具来完成。
6. 基础设施对微服务应该是透明的。微服务不该该也不必知道运行环境的细节。只要可以正常启动并执行业务就完成了它的任务。所以，基础设施代码要和微服务业务代码分开，且微服务不该该告诉平台本身如何部署。
7. 服务注册和发现是微服务架构的核心部分。consul 和 Eureka 是这方面的佼佼者。
8. 部署（Deploy）和发布（Release）要分开。

步骤6：除了提交代码和发布，微服务平台一切都应当自动化

在完成了微服务的基础设施和交付流程以后，就能够开始实现微服务的业务了。这时候须要依据电梯演讲划分出来的微服务进行业务逻辑的开发。在以 DevOps 的方式工做一段时间以后，团队应该养成了一些自动化的习惯，若是没有，就应该检查一下本身的自动化程度。最佳的自动糊理想的状态就是除了代码提交和发布。在这之间的每个流程和环节都应当由自动化的手段来完成。

固然，也有不能自动化的部分。根据个人经验，不能自动化的缘由主要来自于流程管理的制度要求，而非技术困难。这每每是组织没有依据微服务进行流程变革致使的。这时候须要反省不能自动化的部分是否是有存在的必要。

另外一方面，虽然自动化能够大量缩短微服务交付时间，提高微服务交付效率。可是自动化的同时须要考虑到安全因素和风险，不能顾此失彼。对于生产来讲，可用性和安全性是最重要的部分。

关键的自动化：

• 自动化功能性测试（UI/集成/单元/回归）
• 自动化构建
• 自动化部署
• 自动化性能测试
• 自动化安全扫描

管理建议：

1. 鼓励团队成员自发的进行自动化的改进，这会给将来微服务批量开发带来不少裨益。
2. 不要一开始就追求全面的自动化，自动化须要花费必定时间。根据团队的进度视状况适度进行。

技术建议：

1. 采用 TDD 的方式开发不光能够提高质量，也完成了测试的自动化。
2. 注意自动化的安全隐患。机密信息须要独立管理。
3. 关键步骤须要准备自动手动两种方式，必要时能够干预自动过程。
4. 采用 git 的 hook 技术，在代码 push 以前就能够完成测试和静态检查，提高 CI 的成功率。

步骤7：总结并复制成功经验，创建起微服务交付的节奏

当完成了第一个微服务，不要着急开始进行下一个微服务的开发。而是须要进行一次关于可复制经验的总结，识别微服务开发中的经验教训并总结成可复制的经验和产出。

如下是一些须要总结出来的关键产出：

1. 微服务开发到发布的端到端流程规范。
2. 微服务开发的技术质量规范。
3. 团队合做中的坚持的最佳实践。
4. 常见技术问题总结。

有了以上的关键产出，就能够对微服务开发团队进行扩张。这时候有了微服务开发的老司机，带着刚加入的同事一块儿开发，风险会相对低不少。

管理建议：

1. 刚开始的时候能够每周进行一个回顾会议，团队须要快速的反馈和调整。
2. 不要急于扩张团队，要在成功经验稳定并造成模式以后再快速扩充。
3. 避免微服务良好的开发氛围被稀释，刚开始的时候扩充团队能够慢一点。新老成员的配比不要超过1:1。
4. 虽然微服务平台趋于稳定，但在微服务没有上规模以前，不要让团队里缺乏 Ops 成员。
5. 注意知识的传递和人员的培养。

技术建议：

1. 不要急于在微服务应用规模不大的时候造成微服务模板，不然会限制将来微服务的开发和扩展。
2. 在微服务不成规模的时候不要放松对微服务平台的改进。

参考书目

《微服务设计》 是一本微服务各个方面技术的综合参考材料。若是你在实施微服务的过程当中碰到了问题，它就是一个解决方案的分类汇总。

《持续交付》聚集了不少交付最佳实践，当你的微服务实施碰到阻碍时，里面的建议可以让你解决当前的困境。

《领域驱动设计》和《实现领域驱动设计》为拆分微服务提供了方法论，当团队之间对于微服务的拆分有困难的时候，采用领域驱动的方法每每会获得更好的效果。·

《微服务架构与实践》是一本快速启动微服务的工具和实践的总结，可以帮助微服务入门者快速跨越门槛。

---

实录：《顾宇：微服务架构高效推动实战解析》

---