微服务带来的心理阴影

架构的演进基本上是按照最早的单体服务架构开始，将所有的功能模块(service)打包到一起。

再到后来的微服务架构，就是将复杂臃肿的单体应用进行细粒度的服务拆分，每个微服务可以交给小的团队进行开发和维护，拆分出来的服务各自独立打包部署。

那么经历过整个架构演进过程的技术专家们，他们在研发工作过程中，有哪些明显的感受，对于解决技术问题有哪些更好的经验？对未来的架构趋势有哪些预判？

在此前的一次ArchSummit全球架构师峰会上，我就邀请了业界几位技术老师：赵宇辰（听云）、雷卷（阿里）、李智慧（同程艺龙）、张宏伟（美菜网）、冯湧（Shopee），一起探讨了这个问题，总结来说，单体架构不是那么苦，微服务架构也不那么香，中台架构也不甜。（内容太多，分为上下篇）

微服务之——初体验

首先，能经历过这三个过程的技术人，一般年纪都比较大，所以他们的经验值得你细品。

雷卷老师一直在阿里硅谷 Office 做云原生和 Reactive 研究。2006年加入阿里的时候，当时阿里是巨型的单体应用（买家、卖家、CRM），慢慢的基于 Spring boot，Spring Cloud 框架调整到微服务架构。现在往中台方向发展。雷卷老师认为这样的道理是正确的，需要把同类型的应用进行收敛，提升扩展能力，形成中台能力。

李智慧老师2008年的时候也在阿里，当时做分布式服务，Dubbo 就是当时所在的团队做出来的。李智慧老师当时主要做架构支持，遇到过很多Java War打包的伤心历史，所以现在会扪心自问：我们究竟想要通过微服务得到什么？服务拆分确实有它的好处，例如分布式服务好管理，开发编译更方便，运维工作更简单等等。但紧随其后需要考虑服务能不能有更大的用途？是否可以复用到其他业务？拆分容易，复用可没那么简单。

做微服务能够解决技术性问题，但是做中台其实解决的不只是技术的问题，那么其实难度和复杂度会更大，挑战也会很多。

美菜网的张宏伟老师说，他们现在的中台团队主要的学习对象就是阿里，微服务框架也是用Dubbo。美菜网从单体应用到微服务，然后到中台，为什么要做这样的升级？

美菜网 1.0 版本就是为了验证商业模式是否可行，业务是否能正常运转。2.0 版本是在研发人员规模扩大之后，当时因为业务增多，导致数据不一致，也直接影响测试结果。结果只能做服务的拆分，向为微服务发展。在随后的4年里，微服务体系支撑了上百个城市，每天几十万的订单量业务。

技术上的问题解决了，业务上的问题又来了——分销类业务，还有其他各种各样的创新业务，但各业务本质上都是类似的，很多相同部门在做相同的事情，效率还很低。所以最终找到的解决方法就是中台。上线半个月发现效果很不错。中台一方面能解决技术上的问题，另一方面也能解决业务上的问题，能让业务快速裂变。

王启军老师来自于华为公司架构部，主要是做云原生和微服务架构推广。做过消费者云，还有 PaaS 框架、微服务框架、多云管理系统 Manage One 等工作，都涉及到微服务和中台的概念。但是理论上来说，团队在做项目的时候，并没有刻意追求微服务概念，主要是为了解决一些问题，可能刚开始的时候在做服务拆分，后来研发团队太大了，自然而然要拆分，为了解决效率低下的问题。

拆分之后又讲究垂直拆分，如果开始的时候做很多水平拆分，可能会导致调用关系很复杂，性能很低。垂直拆分之后，很多地方组合起来不太方便，导致 API Gateway 特别臃肿，那只能把一些业务分层，也就变成了我们现在所说的中台。

冯湧老师目前在新加坡电商Shopee（虾皮），主要做风控，反欺诈工作。之前任职于苏宁易购和美团金服。在Shopee工作阶段发现东南亚每个国家的电商有自己的特色，例如语言多样化，文化多样性，购物习惯不同，不同的支付合规要求，各个国家独立的政策，不同的宗教等等，一个功能要面临7个国家分支。

所以 Shopee 更需要中台/平台能力，对灵活性要求更高，而微服务架构更能满足商业复杂度需求，服务治理、服务可用性，服务稳定性以及灵活性更有保障。

什么时候拆？怎么拆？拆多细？

实际工作中，也听到很多技术人的吐槽，什么情况下单体要拆微服务，有没有一步到位的办法，传统的应用到底怎么拆？拆多细？如何去衡量？

赵宇辰老师就提到，类似于银行、军工传统这些客户，帮助他们将服务部署到本地，但是客户没有很好的机器，硬件配置较低。另外，ToB客户在部署应用的时候，遇到问题不知道如何去解决，这样比较头疼。

针对这样的问题，雷卷老师说，如果只是做ERP、CRM或者OA的，就是一个单机的应用，部署到客户环境，客户每天的访问量不大，单机又没有成为瓶颈；或者对于小型创业公司，刚开始做第一个应用，那就没必要做微服务。

另外从技术层面上讲，比如用 HBase 在设计的时候，对事务一致性要求极致，若拆成微服务，就会有网络延迟之类的问题。关于部署问题，如果客户还没有做容器化、虚拟化，通常也不建议采用微服务。不过，现在 K8s 比较流行，随着技术的变革，之前认为不可能的事情就会变得有可能。但一些典型的场景，比如多租户情况下对流量、扩容有强烈要求，那肯定需要采用微服务架构。

至于拆分到多小，按什么力度来拆分？有很多方法论值得参考，例如 DDD 方法论，它会告诉你如何识别业务系统，如何拆分微服务，怎样做通讯等等。

李智慧说这是一个挺沉重的话题，因为李老师之前给一些企业提供咨询服务，关于微服务架构，有一些痛苦的经历。

什么时候应该微服务？李智慧老师的个人经验是，如果要做一个创业公司，做一个新的应用，建议刚开始的时候就设计微服务架构。因为服务本来就是隔离的，可以强制你去独立思考业务模块，逼迫你每天去思考：服务之间的关系是什么？应用之间如何用服务进行组合？这样的思考有助于架构设计，模块之间的关系会更清晰。

现在的单体应用要不要开始去做微服务？该怎么做？这属于特殊情况。但是直白点讲，微服务就是接口进行远程调用的问题。微服务的建立基础是要有一些独立的模块，这些模块便于在微服务过程中进行远程部署。而这些模块本身应该是独立的，逻辑关系和依赖关系应该是清晰的。有的应用可以是微服务调用，有的应用还是本地调用。

比较痛苦的经历是，给企业做咨询期间，他们认为远程调用就是实现了微服务，但是模块之间边界，调用依赖关系没整理清楚，互相之间不断的重新循环，服务A依赖B，B依赖C，C又依赖A。最后导致任何一个需求变更，整个系统全垮。需求一上线出Bug，然后两三周进行修复。这个痛苦过程简直不愿再去回想。所以说，横向的分层关系与纵向的垂直关系一定要搞清晰。

张宏伟也很赞同互联网服务最好是从微服务开始做。微服务其实是偏工程型的代码系统，也代表着协作模式上的变化。所以建议根据团队规模和后续发展规划来拆分微服务，不要拆的太零散。

王启军老师强调了一点，不要只是拆分服务，只是把服务拆开其实没有什么意义。还要考虑相关配套东西，比如说部署的时候要用到 Kubernetes、容器、持续交付等等，这些配套服务也要考虑进去。

冯湧老师关注微服务中的成本问题，例如业务试错成本，先验证一下商业模式，在这种情况下，把一个服务拆的太细并不是明智的选择。其次是要考虑建设成本。微服务可以理解为一艘航空母舰，它周边是有很多舰艇组成战斗群。它需要很多的能力支撑，包括服务治理、运维上线、质量保障等等。如果现在还是小团队，小业务，那就安心做业务吧。

微服务实践中踩过实实在在的坑

雷卷老师工作20多年，他说踩坑经历肯定是有的。从原来单一进程改为跨进程分布式调用就会出现很多问题，比如 Transaction事务没法控制，之前设计的API 会失效。

这里雷卷老师举了个例子，之前淘宝店铺里卖家都会装修店铺，让店铺变得很好看，装修了十几个页面，在六一儿童节、三八妇女节、双十一的时候一次性发布，这些大促时间比较长，有可能在某一个环节就会出现问题。比如远程调 API 的时候出现一次失败，且没有分布式的事务来控制，所以就比较麻烦。

所以在拆成微服务之后，远程网络确实是一个很大的问题，同时对接口设计也有很大的挑战。因为在一些关键性事务上，不能按照 Rest API 来做设计，要提供更面向业务性、原则性的 API 暴露给外部调用。解决的办法也有，把 API 各种页面状态更改之后归拢形成一个原子化，增加一个幂等性判断，以确保最终的事务一致性。

李智慧老师回忆起当初看到微服务概念提出者 Martin Fowler 撰写的《企业应用架构模式》这本书的时候，惊为天书，佩服他对软件理解的透彻程度，所以当时对 Martin Fowler 非常崇拜。而且很清晰的记得书中讲到的分布式第一定律，那就是“不要使用分布式“。但事后来工作中要解决业务问题，也看到使用分布式服务能带来更多好处，所以最后也积极参与了进去。

李老师这么多年的实践，会促使他去反思：投身微服务之前要问问目标是什么，当前的问题究竟是什么？如果没想清楚，建议不要盲从，适合阿里的技术，不一定适合你。

另外，不能用看待 Kafka、Redis、RocketMQ 等技术的眼光来看待微服务，它和业务密切相关联，但它不是一个技术问题。

虽然微服务听起来越微越好，但李智慧老师认为，“微”只是一个目标和愿景，建议刚开始做的时候先往大范围拆，业务独立出来，其他服务或者核心逻辑拆成一个大服务，看起来像没拆，但可以根据这个思路去验证技术，验证完之后再往往小拆，循序渐进，会更轻松，更顺利，即使踩坑了，也知道在哪踩了坑。

李老师经历了一个代价非常大的循环依赖项目，不断的投入优秀的人力进去填坑，耗尽心力，精疲力竭。项目结束后，这些技术人对公司、对项目、甚至对技术产生了心理阴影，最后选择辞职。

所以李老师建议大家，选择微服务之前谨慎谨慎再谨慎。

冯湧老师更关注服务治理，当公司越来越大的时候，服务内容的治理，比服务本身健康度治理更重要。

例如研发团队上千人的公司，每个团队负责一个业务方向，且都以微服务的方式来进行相关的系统能力建设。一旦遇到公司级促销活动，对于类似于“对账、营销”等底层技术能力的时候，会很疑惑这么多五花八门的技术，到底该用哪个？所以，冯湧老师建议，在未来做规划架构、架构治理工作的人，要更加关注技术上如何合并，哪些适合微服务体系，哪些适合底层基础建设体系，防患于未然。同时在做服务拆分的时候，服务定义要明确：业务职责、业务场景，避免给服务治理风暴留下潜在风险。