架构设计系列文章，请参见连接。

概述

随着公司的业务、团队的不断更迭、增长，原有的软件系统已经不能很好的解决现在的问题。这样的一个软件系统已经在各个方面产生了问题，它已经限制了公司的业务的持续增长、甚至已经不能进行正常的维护开发工作。

• 不可避免
  从软件系统初始阶段，所有的衔接上下文都是清晰可变的。而随着业务的增长会想限界上下文中添加概念。而在此过程中，通常团队并不清楚应该何时停止向领域模型中注入越来越多的概念。或许刚开始时这个模型很小也能被管理。然而随着团队不断地注入更多概念，很快便出现了 一个大麻烦。不仅概念太多，而且模型中的语言也变得模糊不清，因为在你思考它时，会发现在这个巨大的、混乱的、漫无边际的模型中实际存在着多种语言。因为这样或那样的错误，团队常常会将全新的软件产品变成一个所谓的大泥球。

• 总会发生
  对于随着公司的成长而不断成长的软件系统来说，走到这一步是迟早的问题。而走到这一步只取决于团队的技术能力，团队的技术能力好一些这个时刻会晚到一些，技术能力弱一些这个时刻会早到一些。

• 饮鸩止渴
  对于这类问题公司基本可以想到的解决办法就是外部招聘有能力，有经验的人帮助解决问题。但对于一个新加入的或者是咨询师来说对公司业务的了解需要时间，对公司未来的发展也需要时间的理解。而对于现在浮躁的互联网界来看新入职的人有这样耐心的几乎没有，再加上浮躁的互联网公司的处理这件事的耐心。导致人员与公司之间永远在时间上匹配上。这样就导致公司不断的招聘新的处理业务混乱的人才，而这些人在又在不断的流失。

对于限制业务发展、代码无法维护的问题是怎么发生的？有哪些解决策略？以及具体怎样解决这些问题？将会在后面逐步进行讨论。

问题原因

一个有几年沉淀的公司来说都面对着同样的问题，技术已经制约了业务的发展，原来可以很快上线的功能到现在很难上线，上线了也经常有很多问题。随着一个软件系统经过多年的发展，经过多个不同开发人员的手之后变得难以维护，难以迭代更新。这种问题在有几年历史的公司中非常常见，而这种公司基本上没有办法解决这个问题。

为什么发生这种问题的公司没有自己解决？

• 如果发生这种问题，代表公司的技术水平有限；
  对于技术水平的有限是在业务的持续演化过程中未能将技术实施计划、设计落实到具体的工作中，或是因为根本没有技术实施计划导致的。这说明整体公司的技术水平有限，因为公司中任何人都未能提出并未解决这个问题。
• 如果发生这种问题，代表公司的从业人员能力有限；
  而从业人员能力预示着一个公司遇到这类问题的时间是长是短，人员能力好一些则公司遇到这类问题的时间会长，人员能力弱一些则在很快的时间内就会遇到类似问题。
• 能严重到这种地步代表着公司整体的监管能力有限。
  监管能力说明公司对与业务和团队的管控力，如果遇到这样的问题，也说明公司对于团队和业务的管控能力都不足。

要弄懂这个怎么解决，就必须明确问题是怎么产生的。并且明确问题所在之后才可以针对问题制定解决方案。而解决这个问题不可能一次性解决所有问题，所以最少应该朝着规避这些问题的方向前行。这里总结的问题都经过了抽象，并进行进一步解释。但为了保护作者所在公司的利益，不对具体问题进行描述。下面就具体说明其中会有哪些问题：

四类问题

• 限制业务发展

在业务服务发展到一定阶段之后，会发现修改代码非常困难。在这个过程中直接感受是修改代码过于麻烦，但问题的根源并不是在代码这个层面上。

1. 数据模型未跟着业务的发展持续演进
   在持续的迭代过程中数据模型被各种的业务不断的拉扯，让其从原来规整的数据模型变成一个张牙舞爪的数据模型。这样其实就会造成各种业务错综复杂，并且这种方式还会在不同的业务模块间传播。
2. 业务支持不完善
   在业务实现过程中，对于现有业务抽象不足造成问题在发展新的业务时都需要进行实现。这样就造成了不断的实现新的业务，不断的为新业务造代码。越来越多的代码不断的添加。
3. 业务逻辑分散修改困难
   划分了微服务之后，新业务会随着最靠近的服务进行实现。在实现过程中总会遇到业务边界不清晰的问题，这个时候就会随意的选择一个服务对业务进行实现。而这样的事情越来越多，就会发现业务逐渐的分散在不同的服务中。再加上需要串联起来的业务，就变成了一个业务分散在不同的服务中。
4. 业务过于庞杂，直接理解
   业务模型中的细节在持续的迭代中不断的增加，而这些增加过程有遗落在每次的需求中。使业务细节无法使用一个文档整体的描述，也无法一次性学习。这样造成业务越发展越大、越发展越乱。
5. 人员能力要求高
   在上述问题下就变成了，需要的人的能力越高越好。只有能力高的人才可以将业务了解，并对其进行修改。

• 知识体系丢失

作者在《04.软件产品公司竞争力》说明过业务知识是公司的核心竞争力。对于核心竞争力的承载是业务知识，而业务知识的承载可能性就很多。例如：工作人员人脑中的知识、需求PRD中、数据库设计中、代码中、文档中等。但对于这些承载形式最终还是要让团队内部达成共识。

1. 业务知识流失殆尽
   随着人员的流动业务知识也在不断的流失。而团队成员之间的业务知识传递不畅造成从一个业务知识丰富的人将业务知识流转到低业务知识的人是一个因人而异的问题。所以，业务知识在没有其他承载形式的情况下就会不断的流失。直至流失殆尽为止。
2. 业务知识沉淀不足
   现在很多软件过程都不推荐使用文档的形式进行需求的管理。而且现在软件研发人员的文档编写能力都很弱。导致几乎没有文字资料可以反应业务模型的情况。有文字资料也不能很好的描述一个模型。
3. 业务知识获取困难
   业务知识散落在不同的地方，所有的PRD都是针对迭代需求进行编写的。而针对业务模型进行描述的文档在没有业务驱动的情况下是不会被编写的。所以一个业务模型的规则分散在不同的文档中，而且还有一部分在人们头脑中的隐含知识。这样就造成如果要学习业务知识编程很困难的一件事。

• 持续迭代又无治理导致大泥球

不断的向限界上下文中添加概念，而这个添加的过程又不知道什么时候结束。这样就会造成在限界上下文中概念过多，关系过多。而造成大泥球的问题。

1. 设计缺失
   重要功能未有技术设计文档及评审。注重业务可用性，而未考虑技术设计合理性。
2. 监管缺失
   重要功能设计未受监管、实现过程也未受监管。为了追求业务快速上线，跳过了监管。
3. 治理缺失
   在发生问题之后不进行治理动作，而使用修改的办法去解决问题。再此过程中也会有业务治理工具缺失、技术治理工具缺失的问题。

• 能力体系建立能力欠缺

在业务发展过程中为了更快的建立业务能力，而建立起针对性的能力。而随着发展下次还有类似的需求，又建立一个类似的而又偏向于这个场景下的能力。能力就变成了哪里都有而任何一个其他地方都用不了的情况。

1. 半拉子工程
   为了快速的试错，而建立的系统。建立起来之后是不是就不管了？建起来之后具体怎样淘汰？怎样从mvp到真正产品阶段？对于一个系统的生命周期管理不进行管理造成问题。

2. 重复造轮子
   之前mvp造过一次，后面有个其他方向的mvp有造一遍。在发展出来两个完成体系之后没有对原先的能力进行熟悉而直接再造一个的。

3. 公共服务维护力度不够
   因为组织变更造成业务重新划分，但提供公共能力的服务永远会落在两个团队之间不管的地带。这样的服务对于两个团队来说都不是自己的业务核心那么就以为这不会有专门的规划去完成这部分的维护。

4. 运维体系不完善
   故障预案是运维最基本的能力体系。在很多时候都是线上发生问题了之后进行问题解决，这其实就凸显了运维能力、体系不完善的问题。

解决策略

遇到了问题不要退缩而应迎难而上，而且要解决根本性问题才对问题有意。如只是解决表面问题下回总是还会遇到类似问题。只有持续改进才能真正的解决问题。

幸福的家庭都是相似的，不幸的家庭各有各的不幸。-- 托尔斯泰《安娜·卡列尼娜》

• 约束
  上一章节说明了具体的问题，而解决这些问题还有一些限制。这因为这些限制导致解决问题的难度大大的增加。故这些约束也是解决问题的前提。

  1. 尽量少影响现有业务
  2. 尽量可以利用原有数据
  3. 提供完善的中台能力
  4. 提供演进方法

• 方法
  基于重构还是基于重写去完成服务治理？根据上面的约束可以很容易的得出结论。
  

• 业务模型
  团队中每个人认为的业务模型都是不一样的，所以需要通过共识的方法将所有的人的模型达到共识。
  

• 实现方法
  原先一个接口中包含的业务过多，需要将业务拆分成不同的接口。以原子化的方式提高接口的通用能力。
  

解决问题

具体解决问题也分步骤，根据步骤完成服务治理工作。步骤的前后全系承载着业务的逐渐梳理过程。

• 按照业务场景梳理所有业务
  通过场景的信息建立对于场景下业务模型的知识。可以更好的梳理出业务模型的规则。

• 制定中台实施规范
  通过规范去建立规范的平台。例如：服务平台整体设计、知识库梳理、基础服务平台接口规范、基础服务平台质量规范、基础服务平台日志规范、基础服务平台异常规范、基础服务平台工程规范等。

• 进行服务治理
  通过梳理与遵循规范对服务进行治理。例如：对服务进行拆分和下线、减除同层横向依赖、建立补偿机制、剪除第三方依赖等。

• 建立能力体系
  根据业务模型，建立起可以支撑业务创新的业务能力体系。

• 建立技术体系
  通过建立研发体系和运维体系达成技术体系建立的目标。建立技术体系可以通过：满足四化完成

  1. 数据化
  2. 可视化
  3. 标准化
  4. 体系化

例如：研发体系中事件通知机制建立、分布式任务调度、服务间通信机制、ID生成器、文件存储服务、日志服务、分布式事务管理、调用链管理、限流、降级、熔断、特性开关、QRCode，运维体系中K8s、弹性伸缩、发布方法（蓝绿或灰度）、自动恢复、故障预案

总结

对于解决这类问题有两个最重要的问题：

1. 冰冻三尺非一日之寒
   对这类问题需要有耐心去处理，如果想着处理一段时间就会将这类问题处理好。根据墒增原理，如果一个系统不经过外部作用永远都会趋向于无须。
2. 不积跬步无以至千里
   有真正的投入才有真正的收获。对于解决这类纠缠不清、难于理顺的问题来说，需要拖入的不止时间，还需要精力的投入。正面面对这个问题，问题才可以得到解决。

对于看完上面内容的读者来说，作者在这里给出的终极路径只有一条：整体设计，渐进式重构，渐进式上线。

感谢

感谢在这个过程中帮助过我们的人们。