这些年中台、微服务都是技术浪潮中的弄潮儿。两者的命运似乎是所有技术新词的缩影：先谈，再建，后拆，最后平静。
如中台，开始时聊什么都得带上中台，战略层喜欢谈，执行层也喜欢谈，再后面跟随一线大厂纷纷搭建自己的中台，然后就是反思，拆除中台，最后平静看待中台。
中台可以说已经经历完整的生命周期，而微服务周期也差不多，但对于“拆掉”，两者的声势与目标却不太相同。
在《中台是什么》中提出，“效能下限”与“创新上限”就像翘翘板，产生了哑铃效应，而中台则是追求效能的极致，同时却也降低了创新上限
建中台是为了效能，拆中台是为了创新。
以阿里为代表的大厂对拆中台真是高举高打，但看看微服务，可没哪个大厂高喊要拆掉微服务，可见他们俩还是有本质差别的。
更神奇的是，不管是拆微服务还是拆掉微服务，本质需求却是一致的：提升效能。
为什么都是提升效能，从两种行为分别阐述一下
为什么拆分微服务
首先一起回顾一下，为什么要拆分微服务？对于这个问题不得不再向前回退，回到单体架构时代
在微服务架构出现之前，单体架构是永恒，天经地义的。以致于“单体架构”一词都没人提出。
项目起初，单体架构无疑是最佳选择，不仅易于开发、易于测试、易于部署，且由于系统中各个功能、模块、方法的调用都是进程通信，性能是最高的。
甚至在项目从小型发展为中型时，也没有那么不堪。虽然是单体架构，但内部结构并非“铁板一块”，在业务量级可承载范围内，也有一定程度的扩展性。
从两个视角观察扩展性
在纵向角度，绝没有一个项目完全是个“大泥球”形态，至少都会以分层架构风格对代码进行纵向层次划分。
在横向角度，单体架构也支持以功能、技术等维度划分，拆分成各个模块，以便代码重用和管理，甚至提取出各种形体组件，如jar
那拆微服务解决了哪些效能问题？
第一程序效能
在于应用程序的某个方面给基础设施带来了过重负担，这反过来又很可能会导致糟糕的用户体验。
如，图像处理需要大量CPU，如果CPU负载变得非常高，这将会导致应用其他处理资源的饿死现象。影响系统延迟，甚至影响系统可用性。
也就是说应用程序中局部缺陷会造成全局问题。局部间没有隔离能力，一旦出现内存泄漏、线程爆炸、阻塞、死循环等问题，将影响整个程序。不仅导致单个功能不可用，甚至整个程序的效能都降至为零。
从程序维护性来说，所有代码都在同一进程，无法做到单独停止、更新、升级某一部分代码。只能制定专门停机更新计划，整体做灰度发布，A/B测试。
第二团队效能
与应用的关系不大，但关系到如何组织团队。在应用程序的特定部分，投入工作的人越多，开发和部署就会越慢，而且越容易出错。
如，抢占持续部署同一服务，出现排队现象，意味着本可以交付产品的工程师只能坐等轮到他们进行部署。出事“紧急事件”时，多个团队代码都需要回滚。
综上所述，简单总结一下，单体架构并不是一无是处，项目起始阶段依然是最佳选择；
当对应用程序性能要求超过单机能力，以及软件的开发人员规模明显超过了“2 Pizza Team”时，
不管是程序效能还是团队效能都已经达到瓶颈，此时可以通过微服务架构来解决这些问题。
微服务怎么解决效能问题？
对于程序效能，在单体架构时代，想要整体系统的可靠性，我们只能努力让每一个模块，每一行代码都可靠，以达到整体系统的最终可靠性。
然而常常事与愿违，战术层面再优秀，也难以弥补战略层面的缺陷。在构建大规模系统时，人们的观念也从“尽量不出错”向正视“出错是必然”转变，在此前提下，历史悠久的单体架构终被挑战。
微服务把独立的单体架构内部依赖组件，由“编译时期”推迟到了“运行时期”，对时间维度的解耦，带来了运行时动态扩展、服务间技术异构、服务独立交付等好处。
也就解决了上面所述的局部间没有隔离能力造成的全局性故障，导致整体程序效能降至为零的情况。也实现了局部维护的能力，提升系统整体可维护性，保障系统整体可靠性与可用性。
对于团队效能，系统不再是一块整体，团队更加独立地工作，独立地部署，从而发布更多产品。
尤其在康威定律的指导下，划分组织边界以及服务职责范围，让组织之间更高效默契的沟通以及相互配合提升整体效益。
为什么拆掉微服务
微服务的确带来了很大的收益，不管在系统扩展性，还是在组织扩展性，都促使商业最大限度的规模化。
然业务不是永远增长的，随着业务增长乏力，收益萎缩，需要探索新商业机会，原先高成长的业务团队规模也慢慢收缩，之前的服务系统也慢慢沦为遗留系统。
从原先增长期的每个系统0.5人，到维护期每个人10个系统，服务与团队与康威定律极度不匹配。
简而言之，在高增长期康威定律带来的所有收益，随着时间的推移，业务收缩，都变成了“遗留”团队的负债。
所以需要拆掉微服务，改变服务边界以匹配团队边界，平稳回归康威定律。当然也不是彻底拆掉所有微服务回归单体架构。重点是重新调整职责范围，拆分成符合团队的服务边界。
此时再回头看微服务概念时，当初纠结的“微”到底是多大的问题，已经完全不重要。微服务只是相对单体架构(Monolithic)的称呼，“微”不代表任何实际的内容。
我们需要更多的关注“合适大小”，服务经过了恰当地设计，以满足其需求：它负责“合适数量”的功能。而且，至于什么是“合适”并不是一个静态的概念，它取决于团队，即团队的技能集、组织的状态、投资回报率（return-on-investment，ROI）的计算、持有成本以及该服务运行的时间点。
简单总结一下，拆掉微服务，相对程序效能，更多的关注点在团队效能，服务边界匹配团队边界。其次，在整合团队，回归康威定律的过程中，业务流量也是在减少的，程序效能问题也再像扩张时期那么显著。
总结
一切技术都得服务于业务，而业务形态决定了技术形态。
没有完美的业务，也必然没有完美的技术，只有两者相匹配时，才能相得益彰。
不管是建，还是拆。都是适时的选择。架构只有顺应环境才能生存，最大化业务价值。
参考
拆掉微服务
