微服务落地反思以及有效落地

作者简介

顾宇

ThoughtWorks高级咨询师

在正式开始之前，做一个调查，当你听到微服务的时候，你是开心的还是质疑的，还是痛苦的？

我今天的分享是微服务落地反思以及高效落地，我提前预告一下，这是针对团队的内容，如果你在网上看到微服务的视频和教程，你可以在云上自己去实现微服务的技术。当你碰到一个团队要落地微服务的时候，它就会有一些问题，这些内容主要是针对这部分。

一. 三个微服务案例带来的反思

1.1 Java遗留系统解耦

这个服务项目是我加入ThoughtWorks 第一年，2013 年 9 月 份，当时还不知道是微服务项目，2014 年微服务的概念才出现。当时是做Java的解耦，这是国外的客户，做垂直搜索引擎。

这个公司选择的时间和切入点非常好，很快就有成为澳大利亚这个行业的第一名。他们用的老技术没有办法打败竞争对手，他们几乎是当时每个月都有新的竞争对手用更新、更快、更便宜的技术跟它竞争，所以他们当时想解耦。

如何在这个情况下合理拆分应用？我们一开始是用老的 spring 2.5，用的是 Java ESB 做总线，在上面挂了很多服务，老的 SOL 模型。后来，我们用 Restful 的 API 把模型解耦，从整个的 Java 大的外包上拆下来变成独立的服务。我们能让拆出来的应用做到各自的独立部署，这是我们当时碰到的问题。我们当时的理解很简单，做微服务就是做持续部署 Restful API。

我完成项目经历了七个月时间，在这之后，我们开始把这个经验开始复制。

1.2 某电信运营商

这个项目是澳大利亚的运营商，当时的项目的问题是这样的，当时收购了一家公司，做移动运营商，收购了做宽带的运营商。它的用户群极速扩张，所以要改线上的应用。我们当时面对的问题是如何快速稳定的部署应用、如何提高团队的生产率，特别是自动化水平，以及如何解除流程瓶颈，跨部门协作。

当时我们的 Ops 团队只有4人，要提升团队的生产率。瓶颈以外的改进都是假象，我们做 DevOps 的咨询和改进，我们把开发的效率提升了 300%，其实不到 300%。对上层来说，改进的效果是一样的，还是一个月部署一次版本。

跟我对接的团队是三个月部署一次版本，如果出了问题，只能等下个月。我当时想的是，即使你做了 DevOps，你仍然没有加速。我们当时的解决方案是把它的其中一部分跟我们的合作方相关的部分割离出来，变成单独的服务，我们这部分则用我们的方式，这样大家就变成异步了。DevOps 做到了极致就得到微服务。

当你有一个单体应用，不断提升持续交付流水线的速度和质量的时候，再往下提升只能拆它去提升了。你可以按需扩张应用，你可以得到更小的风险点，因为每次部署都是一个点，带来的生产影响是非常小的。所以，我觉得 DevOps 做到极致就是得到微服务。

1.3 某大型IT集团云计算产品

这是国内的客户，总部在深圳，做的也是云计算产品。我做完上一个微服务项目之后发现微服务的套路，你要找到真正解决问题的瓶颈。当时的项目瓶颈是如何缩短发布时间、如何独立发布、微服务迟迟落不了地。

这个项目需要八周时间才能发布，我们想这么大的云计算平台系统要发一个整包是很困难的，所以我们拆分出一部分。但是有一个问题，这个微服务的拆分方案迟迟落地不了。

2015 年圣诞前前一周说要做这个事情，我加入到这个项目是 2016 年 4 月 1 日前一周，我了解这个事情的时候，发现他们已经经过三个月左右时间，除了一堆汇报和会议纪要，以及各方咨询师的评估方案，没有一点是落地的。我在想，微服务通过我之前的经历是很简单的事情，为什么会变得这么难落地？

你的瓶颈往往是从组织上来的，从组织结构的调整做微服务是有效的。我们要做微服务，把系统架构画起来，我们来拆分、设计，做出来的效果又慢又不好，到了后面出了新问题还要修改原先的方案。

1.4 三个案例的共同点

都是开发团队和应用在规模增长情况下，要保持团队的高效率部署；

要在团队上实践持续交付以及 DevOps ；

要让应用程序在空间和时间上无冲突发布；

如果你有一个单体应用，一定会建一对分支，合并的时候要处理冲突，测试完后上线还不一定可行。所以，我们要做到这些，我们需要做一些巨大的调整。

1.5 如何面对增长

这是我们在需求和规模增长时碰到的增长模式。当你碰到 SCALE UP 的时候，资源增长就需要管理，这就带来额外的成本。

有一个规律叫边际收益递减规律，所以我们会做另外一种扩张，就是 SCALE OUT，是线性扩展，但是我们需要强而有力的制度，我们可以把一个团队的成功和一个应用的成功随着规模的增长不断扩大，这就是做微服务的基本思想。你所面对的问题是在快速增长或规模很大的情况下，解决时间和空间上开发和部署的冲突问题。

我们碰到规模问题之后，有一个成本拐点。

X轴是成本，Y轴是规模，黑线是单体应用，绿色线是微服务应用。微服务应用开始是分布式系统，开始的成本会比单体应用高一点。过一段时间，它们会走到X点，在这一点的时候，单体应用和微服务应用没有什么差别了。但是，应用在增长的时候，如果是单体应用，会碰到成本极限。到了成本极限的时候支撑不了规模的扩张，所以有一个增长极限，这叫X’。当应用复杂增长规模和成本到一定程度的时候，转化成微服务应用。

事实是非常残酷的，大部分企业不撞南头不回头，这是理想的。职责分离的概念很早就有了，微服务就是用新技术，新瓶装旧酒，微服务并没有带来新的方法论上的突破。

所以，把微服务改造看作是一种投资，是对企业增长极限的投资，你获得更高的扩展能力后就获得更远的极限，因为你可以复制你的优势。

1.6 微服务解决的问题

微服务本质上在解决什么问题？

处于团队和应用处于高增长；

通过独立部署和独立发布提升整体的交付效率；

解决在时间和空间将单一代码库的冲突访问；

如果你在做微服务，先检视一下自己有没有这样的问题。

二. 微服务落地的难点

我们看看微服务落地的难点。这些是我过去参与的微服务项目中常见的问题，说难点是因为这些问题需要更多的时间去思考和讨论，为微服务的架构决策提供依据。

不知道怎么拆分；

架构落地困难；

管理越来越复杂；

技术栈不知道该怎么选；

团队不知道该怎么组织；

微服务应该怎么管理；

2.1 技术问题 vs 非技术问题

微服务是技术问题还是非技术问题？其实它两个方面都是。《人件》这本书我非常推荐，它的序言有两句话“软件系统的重要问题不在于技术，而在于社会性因素。” “如果我们所面对的问题天生就属于社会学范畴，再好的技术可能也提供不了什么帮助。”

微服务是一个掩盖在技术问题之下的管理问题，如果你的技术栈如果缺乏管理，如果一开始用很好的重构方案不断优化代码，你后面做微服务，做单一职责是很好的，可以一步迁移。我们的代码库其实已经隔离了，合并代码的时候合并在一起，我们有自动化测试，所以我们一键切换就是把代码库复制一份，改为API调用，这样可以保证微服务上线后没有太大的问题。

没有意识到微服务是一个组织转型问题。

这个图片是来自于Netflix，Netflix在网上有自己做微服务的感受经验，这个图也是从那里来。它说微服务是一项组织变革，组织变革都是困难的。

微服务并非一帆风顺的，但是管理是你看不到的，我们要让很多团队看到管理问题，看见是改变的开始，能看到问题才知道怎么去改变。

《人件》中有一个萨提亚改变模型，当你有现有架构，引入微服务后会引起混乱，介入和辅导后，进行实践与整合，进行反馈和强化形成微服务架构。如果你做微服务做得很开心，说明到了微服务架构阶段了。难点就是中间混乱的部分，而且混乱是不可逾越的过程，你碰到新的东西，你要突刺自己的新习惯，肯定经历不习惯。

2.2 怎么才算高效？

说到微服务高效落地的步骤，怎么才算高效？

从结果出发，找最短的距离。通过原先的开发模式，分析完再落地，就离微服务越来越远了，它没有让你变得更快，也不会变得更简单；

最难的事情最优先解决。技术的改变往往是最简单的部分，最难的部分是技术实施的部分；

低成本、低风险，绝对没有浪费；

三. 高效落地微服务的五个步骤

3.1 以终为始，组建团队

首先不要考虑技术，首先组建微服务的团队。如果按照传统方式做微服务，只会重蹈覆辙。一个自治的全功能团队是可以独立发布微服务的团队，需要1名微服务经理，解决流程依赖和干扰；2-4名开发/测试，专注于微服务开发和测试；1-2个运维，用来提供最快速的发布和部署。如果你的组织是DevOps的分离团队，建议有1-2个运维。

独立的小团队就是避免依赖，在原先的开发流程和环境里习惯了一种开发方式，你切换另外一种方式后，你总想着以前的方式开发。

但是，我们要强调，在一个团队里所有东西都是团队干的，一方面是提升人员的能力，另一方面是让大家感觉可以有更多控制的东西，心情也比以前好，按正确的方式做正确的选择。还有特事特办，如果按照原先的方式走，效率不会提高。要把微服务放到最高优先级，要有仪式感。

这是技术上的建议——一个微服务、一个代码库、一条流水线。

有两种组织，一种是松散的扁平化的组织，它有很强的管理规约，如果应用了一个软件系统后，它会很快适应这个软件系统的架构。如果是另外一种，会把软件架构改成组织结构，这就是所谓的康威定律，即你的组织结构和系统架构基本上是等价的。

不同的组织，有可能系统架构改变了组织架构，有可能是组织架构改变你的系统架构，如果团队规模超过200人以上，通过技术手段改变管理组织的方式一般不会成功，除非有很强有力的领导来做这个事情。

3.2 构建微服务电梯演讲

电梯演讲来自于麦肯锡，即保持微服务的概念简单。一开始做的时候就要变得简单，把边界很容易地切分开。最重要的是不要15秒，在15秒内把微服务说完。

这是我们公司的标题——不带手机和电脑，会议沟通效果好，所以要挂到墙上，形成仪式感，不断形成暗示。微服务团队的电梯演讲要达成共识，然后快速地实现。

3.3 取得快速胜利

用最小的代价发布第一个微服务，这会给团队带来很大的士气。目标不宜太高，Showcase驱动开发，要演示什么就开发什么，每天都有有效的产出。第一天制定目标，明天展示这个，确保明天能展示。

什么是用最小的代价发布第一个微服务？最小的代价是团队规模2-8人，时间是2-4周，选择代价较小的技术栈。

当你做微服务上线切分的时候有一个特性开关，一定要用这个，不要用分支。而且，要强调单主干开发，如果你用了分支，就代表有分支，你的代码就有耦合，有耦合证明你可以再拆，最不好的是给自己一个不做持续交付的接口。你一定要快速上线，快速部署到生产环境里，而不是在测试环境里自high。

3.4 代码微微动，DevOps 先行!

工程师很容易看到代码就先导代码细节里，这就不好弄和不能搞。当你听到借口的时候，就没有到达目的地的方向。如果你的组织是Dev和Ops分离的组织，先咨询一下Ops工程师的意见。最好是能够给微服务团队里面配备一名Ops工程师。如果不具备实施DevOps的条件，微服务架构就要从运维侧，而不是开发侧开始进行。

做DevOps就是做CLAMS。一定要有度量，没有度量就没有改进。自动化就是除了代码提交和发布，一切自动化，这是对团队的要求，如果质量控制做得很好后，发布也可以自动化，中间不需要任何人做任何验证，任何验证都可以用自动化解决。

列了关键的自动化，第一是自动化测试，有功能和非功能自动化测试。

第二是自动化基础设施管理，主要是基础设施及代码，基础设施还需要人工弄的话，微服务的速度就不达标不。

第三是自动化部署，不是发布，微服务部署到生产环境上还是需要人为手工的验证步骤，因为不是很习惯，刚开始是需要这么做的。

部署是一个技术动作，你把应用部署放到生产环境上，而发布是一个业务动作，是确定哪一部分用户可以看到你的微服务。

第四是自动化监控告警，微服务的自动化监控告警跟以前的监控告警是不一样的，要提前想好怎么埋点的问题。

用精益通过可视化来发现问题，通过看板发现各种存在的问题。这方面我不多说了，大家可以找相关的参考资料。通过可视化来发现问题，这个问题不是架构上的问题，而是管理上的问题。在团队里，有了问题都是大家的，构建分享和分担的理念，不要指责别人。

打造完整的DevOps 文化，DevOps 说是文化是有一定道理的。这有四个文化：灵活性、沟通、学习、打造氛围。

DevOps 有几个核心实践，第一是持续交付，

第二是基础设施即代码，做资源配置和资源编排，

第三是基础设施对微服务是透明的。

我碰到一些情况，微服务和基础设施代码放到一个代码库里，每个微服务有不同的基础设施需求，改动的话牵涉的动作太多，不要把整套基础设施放到一个代码库里。

3.5 持续改进，复制成功经验

什么叫知识诅咒？当你学会一个知识之后，你再无法想象你作为初学者的状态。你做完微服务之后，你再去教初学者，效果不会很好。所以，在做微服务开始的时候，要做好微服务各种问题的记录，把一部分的成功经验交给新人，要比你找一个微服务很有经验的人去教新人要好得多。因为一个很有经验的人去教一个新人的话，他会中了知识的诅咒，他会忘了他是怎么作为一个初学者开始的。

复制成功经验需要总结出来的关键产出，要做到微服务开发到发布的端到端流程规范，最好是做成自动化，自动化本身就是一种管理制度。微服务开发的技术质量的规范，以及团队中合作的坚持最佳实践，以及一些问题的总结，要通过回顾会议进行不断地改进。

最后，要做团队交叉轮换，有一个微服务团队后，中间拿掉一点人，补充新人，要适应微服务的文化。微服务本身需要比较小的团队来简化整个部署。

想与更多同行见面相互交流，想聆听更多专家的技术解读

DevOps 国际峰会正是一场头脑风暴的盛会

让 DevOps 回到更本质的地方，并进一步领会 DevOps 的精神

想看更多微服务专场？欢迎来到DOIS！

大会前瞻视频 新鲜出炉▼