从单体应用到分布式应用，从 SOA（Service-Oriented Architecture 面向服务架构）到微服务，从软件即服务（SaaS）到函数计算（FaaS）、Serverless，分布式技术蓬勃发展。
系统也在技术与业务的双轮驱动下，不断演进，在看似越来越先进，越来越繁荣的技术与业务的表层现象之下，涌动着系统经常需要推倒重来的暗流。
在业务蓬勃发展的情况下，需求三天两头在变，技术不断冒出新名词，设计的系统很难能历经时间的考验，看似理所当然，是技术人无法避免的系统之殇。
但在当前互联网流量见顶、整个IT产业“脱虚向实”、大厂纷纷裁员的大背景下，之前系统不可维护再找一帮人来重构的路子的粗放式系统发展模式，可能会越来越走不通了。是时候从之前系统的不断推倒重来的现象中，总结一些共通的规律，以便在设计系统的时候加以参考，从而更好的避免系统之殇。
基于此，本文将逐一讨论：
系统之殇发生的原因是什么？
什么样的原则是能更好应对系统之殇？
当前比较热门的技术有哪些？
希望对大家在做系统设计时有所帮助。
系统之殇究其原因有三个方面：
越来越复杂的业务逻辑，导致系统无法维护，必须推倒重来。
不可预知的动态变化，比如要引入新的业务角色：业务从 B2C 发展为 B2B2C，从品牌直销到大代理运营、品牌只管发货等。
在日常开发中，为满足业务，突破原有架构约束，导致原有架构规范被破坏，出现的架构失灵。
下文我们将对每个原因逐一深入分析。
第一个复杂性：面对越来越复杂的业务逻辑，我们在开发过程中，会想尽办法，用不同的抽象和封装，让系统看起来更加条理和简单，但伴随着的是事倍工半的无力感。
一个是新的抽象和封装，不可避免的带来了新边界的定义，而正如《系统之美》中所讲述的：边界的定义正是复杂性的源头。
封装本身就比较复杂，很难保证自己的封装是最适合业务的维护和扩展。而且过多的封装和新的系统架构方式本身也会带来新的理解成本，衍生新的复杂度。
有人把系统的封装比作收纳盒，整整齐齐码好的收纳盒，看似非常美好。但在实际复杂的业务的边界定义中，怎么封装组件、模块，定义交互、功能划分，就像我们拿着一个火车轨道里的火车玩具，放在轨道的收纳盒里看似理所当然。但架不住，孩子平常不玩轨道，把喜欢的轨道火车，老是跟其他小车玩具一起玩，再顺手放在小车收纳盒里。
业务的实际运转可能经常跟你基于统一原则的领域分析相冲突。越复杂的业务越没有简单的边界定义。即使彻底把业务搞清楚，设计跟业务保持一致了，系统结构与类结构都很清楚了，但是在系统本质上复杂度也不会低于业务复杂度本身。
只是让系统的复杂度无限趋近业务复杂度，这也是系统复杂度能无限趋近的最低值；比如笔者在实际项目中，曾经将复杂的业务关系用 DSL 的方式进行建模，用类似图的操作执行业务的操作，对业务层屏蔽底层的存储各种 NoSQL/SQL 存储实现，实现业务语言与技术开发语言的统一，业务实现理解起来也更方便了。但是因为业务本身太复杂，整个业务逻辑有上千页的行业业务规范文档（英语），谁也记不全这么复杂的业务逻辑，团队对业务的理解需要代码中去找（比英语文档好理解点）。
因此，秉持长期主义来应对复杂业务带来的系统之殇，学会对复杂度的适应，通过系统的观察性来从线上实际运行情况理解线上业务，或者在系统之外去解决业务的复杂性，比如复杂业务逻辑的文档梳理，业务基础知识的全员普及与深入理解等。这也许是在大量裁员、HC 限制的形势下，应对系统复杂度的另一种选择。
正如任正非在其“流程型组织变革”中所说：“华为的变革就是对个人权威的消灭过程。什么时候华为不依靠一个人或几个人的影响力了，华为就真正成熟了。”复杂度的消灭过程，也是逐渐不依靠一个人或几个人的影响力的过程，大家对复杂都能把控的过程。
第二个系统之殇是不可预知的动态变化。
我们对系统的假设都建立在之前的经验之上，而经验是有其成立前提的。从本质上讲，我们对系统的理解都是滞后的。就像一个人不能两次踏入同一条河流。
很多时候，业务会不断去打破系统的假设。比如 B2C 的系统突然要支持平台大代理，是在之前的系统架构上去别扭的适配？还是推翻重来，重新设计？很多时候我们可以依赖的只有经验，但经验有其局限性，不一定能帮助我们找到当前系统的最优选择。在《系统之美》中提出应对不可预知的动态变化可以通过系统的自组织和反馈回路增强实现。
在业务系统的设计，我们也常常强调系统的可观测性，通过观测的结果反馈回路执行系统预案，应对某些外部环境变化带来的稳定性隐患。但是要用反馈回路应对业务的不可预知变化，就如同在大自然中，从最初的生命体各自应对大自然的不可预知的动态变化，逐渐演变出来各种物种。究其本质，是物种拥有的自组织、进化能力，在一个相对较长的时间里大自然对物种进行了适应性、完备性的验证，才有现在的各种物种跟大自然的和谐共存。
因此，系统的自组织、自进化能力，才是应对不可预知的动态变化的核心能力。而现有的系统架构技术，虽然有各种动态扩缩容的技术，但几乎不可能完成动态自组织和进化这个任务。
笔者看到的情况，大多都是一个系统还没重构完就面临着需要重新重构的情况。技术人当前面临的是看似是无休止和无可救药的推翻重写，怎么去应对？建立在不变的基础设施基础上的微服务架构，从本质上是借力基础设施的红利，实现去中心化，在一定程度上能将变化的影响限制在最小范围。但在人效提升的大背景下，不可避免的会出现各种平台、中台，跟去中心化的趋势是背道而驰的。因此平台、中台在人效提升同时，另一个要求是对业务的低耦合和高内聚。当前利用 Service Mesh 与 eBPF 打通南北向流量，实现平台、中台的低侵入升级、部署、可观察，是微服务演进的一个重要方向。
第三个系统之殇是架构失灵。
系统之美关键在其架构。架构保证其适应力与稳定性。就像一座高楼，一座精美的建筑，最能震撼人心的在于其架构之美。不论是其与环境的相得益彰，还是其整然有序、恢宏雄伟..…
正如《系统之美》所说：“为什么系统会运作得如此精妙？请选定一个你所熟悉的高效运作的系统，比如一台机器、一个社区或者生态系统，并认真观察。幸运的话，你可能会看到以下三个特征中的一个或几个：适应力、自组织和层次性”，系统之美背后是架构的层次、适应性的有效组织。
但技术系统往往没有自组织能力，正因为此，假设越多，架构契合度就越高，最美的技术架构，也可能是最脆弱的，最难避免牵一发而动全身的轰然倒塌。另一方面，架构本身并没有强制的约束力，经常出现不按架构规范开发的情况。
假设越多的架构规范，在日常开发中就越容易出现某个假设条件不适应，需要突破架构约束的情况。可持续发展和演变的架构是应对架构失灵的必然选择，这才是系统真正的适应力，而不是跟当前业务的完美适应的适应力。因此，在系统设计的时候，需要考虑后续系统的逐步演进方式，与不同业务发展策略下系统的扩展性支撑。
正如《敏捷软件开发：原则、模式与实践》中强调在设计代码时参考的：单一职责、开闭原则、里氏替换、依赖倒置等5大原则一样，系统设计的也需要从基本的原则出发，而不是一上来就套用流行的架构与模式。
复杂性和变化应对之道没有银弹，在《失控》中，凯文凯利的总结了应对的九条规律：
分布式；
自下而上的控制；
递增收益；
模块化生长；
边界最大化；
鼓励犯错误；
不求最优化，但求多目标；
谋求持久的不均衡态；
变自生变。
从中可以看出复杂性的应对，除了封装、模块化、良好的边界划分定义，更多在于模块和边界的可生长性与可持续性。换句话说，好的系统，不在于满足业务的现状，而在满足业务的未来；不在于满足业务的日常运营，而在满足业务的天马行空试错；不在于满足单目标的最优解，而在满足多目标的动态均衡。
从业务的未来、试错、多目标来考虑系统的设计，是对架构师应对复杂业务最核心的要求；而“分布式，自下而上的控制”追求的是极致的分布式。不论是不变的基础环境、用类似声明式实现硬件的分布式动态扩缩，还是微服务、存储技术的分离，都是在用越来越极致的分布式来应对不可预知的动态变化。分布式的发展，可以展望未来在极致的分布式技术加持下，加以系统反馈增强回路建设，配合强化学习、进化算法等技术，可以使系统逐步具有的自组织、自进化能力。极致的分布式就像是把原来成形的架构（即组织器官），还原成极致可拆分的微服务（即细胞、DNA），并通过极致的反馈回路增强、自组织，这些个微服务（即细胞、DNA），能具有根据业务的发展逐步演变成任何满足业务要求架构的能力（即组织器官能力）。这也许是基础架构演进的终极目标。
另外这些规律中体现三个简单的原则也能帮助我们面向未来设计应对系统之殇的系统。
第一个原则：去中心；功能不断叠加的出现的平台、中台、中心等，往往出现“分久必和、和久必分”的情景。而“去中心”追求的是垂直业务的自恰。公有的功能或许可以通过类似 Mesh 的方式，自组织的成为业务的自身的一部分，流量不需要从平台、中心转发，也不需要去调用属于某个平台（中心）集群的接口。通过代码声明的方式，公共服务自组织成为业务的一部分。各业务资源隔离存在，而又共用代码。
第二个原则：一体化；一体化不但包括平台与业务的一体，数据与业务的一体，还包括基础设施的一体，多业务的一体，数据与AI的一体。拿领先的 RPA+AI 公司“来也科技”最近推出的智能自动化处理平台产品方案来说，它是多个AI能力、数据服务与自动化处理平台、人机协同中心一体的互相协调配合，才实现业务的智能自动化处理。缺了任何一环，任何的能力没有底层一体化控制与访问的能力，都无法支持在真实复杂业务场景的智能运转。比如：新版式单据无法识别却无人机协同，影响业务正常运转；流程挖掘却无业务实际运转数据投喂等等，无法对接业务实际运转等。
第三个原则：多样性；客户是多样的，业务是多样的。“非均衡的动态持久性”要求系统本身对多样性的支持，最好能像百花齐放、相得益彰的公园。不论是语言上的支持，java、python、go各有长短，还是部署方式的支持，docker-compose、k8s各有优劣。还是中间件，redis队列、消息队列各有适应的场景。多样性的支持也为应对业务的“变自生变”提供了更多的可能。
基于上述的分析和相关技术、原则的介绍，相信大家对怎么让系统变得更加具有规划性、更加具有逐步小范围迭代升级演进的能力，有了更多自己的理解。
总的说来，构建可应对系统之殇的系统设计是在从之前追求拼速度、拼人力到当下拼耐力、拼深度的历史趋势下，技术人系统演进方式的新选择。也是技术人追求的系统之美需要不断去应对和深入思考的不变主题。
本文作者：谭繁华
