刘华：我最近听到最对味的话，就是“先Scale down再Scale out”

何勉老师（中国最懂精益的男人）在“2020 China DevOpsDays大咖说”里提到：

这是我最近听到最对味的一段话。其中精髓就是先Scale down，再Scale out。

所谓组织架构，就是如何组织资源，包括人员的方式。一个国家、企业、组织的力量，不在于人的多少，而是其组织资源的能力。

在一个小区，作为人数大大占优的业主，往往无法有效对付物管。因为业主虽然人多，但每个人的诉求和利益往往不统一，其实是一盘散沙，难以组织有效的力量。而物管作为一个企业，有统一的目标，也有老板的意志，员工虽然人少，但能被统一的目标和意志组织起来，总体的力量比业主要强太多。

相对应的，应对复杂需求，系统架构往往也应遵循先Scale down，再Scale out的原则，这也就是服务化和微服务架构。所谓微服务架构，其实就是把一个复杂的单体系统Scale down成一个个相对简单的微服务，然后Scale out扩展能力。也是解耦的极致表现。

这也是我经常说的把一个复杂问题（单体系统）降维成一个繁杂问题（以架构的繁杂取代单个应用的复杂）的过程。

我之所以有感而发，是因为最近两年我一直在思考我们部门的组织架构和系统架构到底应该如何优化。

由于不管是业务还是IT高层，都一直很强调我们的业务是全球业务，我们的系统是全球系统。所以一直是使用一套系统支撑全球包括亚洲和欧洲多个国家和地区的业务。

由于每个国家和地区的市场情况和监管要求都不一样，这些国家和地区的业务模式不尽相同，这套系统需要满足各地的复杂需求，也不得不与当地的周边系统产生复杂的对接和依赖关系。

再加上最近几年不断上新一些大客户，这些大客户每个都有大量的定制化需求。所有这些复杂的需求都是在同一套系统上实现。这势必导致系统越来越复杂。上新这些客户的大型项目之间也因此彼此产生了大量的依赖，使每个项目的复杂度都大大提升。

有人问，既然我们提供的是全球的业务，为什么不能有一套统一的业务模式，限制定制化开发？

其实我们能赢取那么多的新客户，靠的恰恰是灵活，对客户需求的有求必应，才是我们业务的核心竞争力。如果每家公司都提供标准的服务，特别是核心业务是通过采购供应商产品来实现的，那别人为什么要选择你呢？

有人总结得很好，To C（面向消费者）靠的是产品，To B（面向企业）靠的是销售和服务。试图用统一的业务模式，标准化的产品，限制定制化需求，是用To C的思维应对To B的问题，会死得很惨。

所以，多样和复杂的需求是我们无法回避的问题，而把所有这些需求都放在一个系统上，显然会把问题的复杂性不断升级，也会使这个系统的越来越难以开发和维护，这是一个增熵的过程。

小结我们面对的最大的问题是，有很多不同的干系人代表不同客户和业务的需求和利益，他们之间无法统一意见，而支持的系统又高度耦合，依赖关系复杂。讨论、分析、开发、测试都涉及多个团队大量人员的参与，沟通和协作成本高昂，效率低下。

我想到的解决方案就是拆！

近年来上新的这些大客户，个个体量巨大，每一个对我们来说都是VIP，完全值得我们为其建立专门的运营团队，搭建专属的系统。其他普通客户的业务则可以由现有的统一运营团队和系统支持，但亚洲和欧洲也应该考虑拆分，以应对不同的时区，也为系统在每个工作日都能预留更多的维护时间。

通过这样的拆分，其实就是解耦和减熵的过程。也是把原来一个复杂系统和多个互相影响的复杂项目和团队进行Scale down和Scale out的过程。

而且这也能满足“从项目到产品”的趋势，负责VIP客户的团队做完开发后，就继续留下来做该系统的运维和后续开发，形成一个产品团队，也满足“谁开发，谁运维”的DevOps原则。

这样的拆分会不会有重复和浪费呢。在一定程度上是有的，但是我也看到在Dr. Mik Kersten在介绍“Project To Product”的视频里说的，要做产品化，就是要容忍一定重复。

而且复用问题其实有更好的解决方法。我们知道，这些业务很多核心功能是一样的，它们被拆分成若干套代码和部署后，势必存在如何更有效地开发和维护一些共有功能的问题。其实在代码层面，完全可以把这些公用功能封装成公用代码库，供各个代码分支调用。

复用有分白盒复用和黑盒复用。

白盒复用：源代码可见，可修改和扩展

• 复制已有代码当正在开发的系统，进行修改

• 可定制化程度高

• 对其修改增加了软件的复杂度，且需要对其内部充分的了解

黑盒复用：源代码不可见，不能修改

• 只能通过API接口来使用，无法修改代码

• 简单，清晰

• 适应性差些

我们应该尽量采用黑盒复用，这也是我们广泛使用开源的方法。

复杂业务和需求，是我们无法回避的问题。面对复杂问题，我们大可通过先Scale down再Scale out，也就是把复杂问题降维和拆解成繁杂问题，不管是组织架构还是系统架构，这都是业内的大方向。