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



“当我们面临复杂问题时，首先要考虑scale down，能否能把规模变小，再看能否scale out，也就是所谓的水平扩展，去变成一个自治的群体。我们最终追求的是敏捷的规模化，让整个组织都能变得越来越敏捷，能更快的去响应，不管是像阿里这样的，还是像那个亚马逊那样“两个披萨”的团队，其实都是一种水平扩展的方案，也就是先Scale down再Scale out的方式。这一定是代表未来方向的。”



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



01



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



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



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





02



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



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



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



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



03



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



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



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



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



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

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

• 可定制化程度高

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



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

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

• 简单，清晰

• 适应性差些



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



04



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



觉得文章不错，顺手转发给朋友们吧。



分割线 卡通



面对疫情这样的复杂问题，有什么招呢？

刘华：上云后，你的架构设计可以更飞



关于作者

• 敏捷、精益、DevOps专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit、中国规模化敏捷大会等论坛发表主题演讲

• 阿里云、谷歌云认证架构师

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书和专栏《软件交付那些事儿》







关注公众号看其他原创作品

敏于思 捷于行 

坚持原创高质量软件交付相关文章



觉得好看就转发给朋友们，欢迎你留言。