系统的熵与架构的可扩展性

作者孤尽

——《阿里巴巴 Java 开发手册》、《码出高效》作者，前阿里巴巴高级技术专家，曾担任阿里巴巴代码平台、资产平台部产研负责人职务，承担过双十一、国际化、代码中心等大型项目，在高并发、研发效能、系统架构等领域有着长期的深耕经验。

熵，曾经我以为读音与“滴”完全相同，原来念“shang”，水火不相容，滴熵音不同。熵是火偏旁，容易和火力发电等关联起来，的确这就是热力学领域的概念：更加契合能量守恒定律，一个孤立系统与环境没有能量交换或外力做功，这时能量总是自发地向混乱度增大的方向变化，使整个系统的熵值增大。熵反映的是自发过程不可逆性的物质状态参量，也就是无用的、混乱的部分。通俗地说，熵是衡量我们这个世界中事物混乱程度的一个指标。就好比当我们的汽车轮胎磨损、刹车片老化后，系统能量、系统风险就会往这些方向倾斜。一个孤立系统总是存在从有序转变成无序的趋势，这就是熵增的原理。

熵增对于公司的发展也是如此。无论管理制度多么完美，随着时间的推移，如果没有与时俱进的变革，一定会日趋混乱，政策在变，环境在变，人性在变，公司如果固步自封、因循守旧，那么熵就会不断增加，慢慢变得无序且混乱，甚至到难以收场的地步。比如，公司合伙人创业之初，极少会设立合规廉政部，打击内部的商业腐败行为。随着公司的迅速扩大，业务多元化和组织架构复杂度会急剧增加，如果没有相应的管理制度，有些政策空子就会成为商业犯罪的温床。这时，企业要么乖乖接受行政处罚后进行痛定思痛地纠正，要么提前预警，完善制度以杜绝腐败苗头的滋生。

在业务系统持续运行中，随着时间的推移，版本的迭代，人员的更替，业务系统的运行会日趋混乱。当产品缺少体系规划，只是不断满足非目标用户的需求，或者目标用户的伪需求，而不去思考用户真正需求时，系统会变得越来越臃肿。系统在需求的垂直叠加中，熵增也必然会随之出现，需求越是无效，熵的增速就会越快。如果没有良好的架构、清晰的调用链路、抽象通用的功能设计，系统将会变得越来越无序，这就是系统熵增的表现。

而在代码层面上，如果没有代码的规范制约，就会造成代码的随意复制，代码的过时注释，代码熵就会不断增加，从而使代码变得越来越难维护。如果代码涉及很多业务方的调用，而对外提供的接口，方法名、参数名、返回值，一旦暴露出来，且谁也不重构那个摇摇欲坠的老代码，那么代码熵就会成为代码殇！

想要对抗熵增，就要引入一个非常重要的理论：“耗散结构”。耗散结构就是一个远离平衡的，包含多组分多层次的开放系统。该系统通过不断与外界进行物质和能量交换，在耗散过程中产生负熵流，从原来的无序状态转变为一种时间、空间或功能的有序状态。耗散结构有两个最为重要的特性，一是开放性；二是非平衡性。当一个系统具备了“耗散结构”后，它就可以有效对抗熵增。开放性是系统能够有序接纳外部能量的能力，而非平衡性是内部自我升级、自我净化的能力。我们的架构设计和系统重构就是对抗熵增的过程，而想要实现有效熵减，就要具备一种面向未来有序开放的能力，这就是可扩展性设计。简单的说就是业务与技术设计的实现上，要与项目当前实际情况相契合，并且设计上需要留口子，以适应将来的变动。经典的设计模式；高内聚、低耦合的架构设计；封装继承和文档沉淀等都是系统反熵增的有效方法。

系统商增的根源往往是用户量的急剧增长。用户量增加不仅带来系统压力的上升，也会使用户分层变得模糊，用户画像变得更加困难，需求分析变得复杂而多变。可扩展性就是应对未来变化的一切可能性。变化分为刚性变化和柔性变化。刚性变化好比K12的政策落地，系统没有任何缓冲空间地调整；柔性变化指的是我们可以控制的软着陆变化，比如把本地日志接入阿里云的分布式日志分析系统等。从变化的可能性来分，又分为必然性变化、概率性变化、忽略性变化。如果刚性+必然性变化，那么意味重构概率很大。而柔性+忽略性变化，一般通过变通方案就可解决。而一切的变化都要看我们系统有没有留下足够的可扩展空间。

可扩展性可以理解为耗散结构中的开放性，可以从架构合理、配置能力、模块解耦性角度来扩展。而重构是控制内部非平衡性的一个很重要因素。我在2019年发表过一个《软件工程危机与系统重构之道》的专题演讲，读者可以参考，本文着重于扩展性设计。可扩展性可以分为硬件扩展性和软件扩展性。硬件可扩展性可以狭义为系统的分布式能力，广义则指是否可以支持硬件设备升级兼容性、多机部署、多机房部署等；软件可扩展性是指需求叠加能力、框架的升级能力、系统的限流降级能力。而异地多活、容灾能力与两者都有关。

从系统耦合度来说。度量一个开发框架、设计模式或编程语言优劣的一个重要标准，就是能否让软件开发过程和软件产品更加低地耦合。高内聚、低耦合，是每一个学习计算机的人最初就接触到的一个“口号”，它是度量开发框架、设计模式的一个尺子，那么，什么样的系统才符合这个标准呢？我们看一反例就会有所领会。如下图，在京郊一个小山村，健身系统和垃圾处理系统耦合在一起，我在想：“还有人来健身吗？闻着垃圾的恶臭，然后愉快地健起身来？”这是典型的违反同类内聚原则的事例。

低耦合系统更加容易被使用，也更加容易扩展，模块更加容易被复用。历史上最懂得分析系统架构的是庖丁，因为他在解牛时，总可以找到系统的解耦点。一个NB的架构师，既知道如何定义系统、分解系统，模块化系统，又知道如何定义模块界面、接口形态、通过搭积木的方式设计系统。架构师的核心能力就是把一个庞大的项目分解为N个目标模块，并且能够清晰地讲清楚为啥不是N-1个或者N+1个。模块与模块之间的关系，应该是尽可能少地发生关联。下图是我在美国计算机博物馆拍摄的，模块之间的关系已经杂乱无章，这个时候如果能够运行起来，就不要轻易去触碰了，因为你不知道下一秒它会发生什么。

从需求分析角度来说。想要实现系统的可扩展性，我们就要把熵增的影响，分解到如下四个维度的问题上进行分析，然后区别对待。即：用户问题，业务问题，产品问题，技术问题，这四个问题任何时候都不要揉成一团来讲。在很多需求分析会上，开发同学容易陷入几个怪圈，一是仅凭技术实现难度就直接否定用户问题；二是聊着聊着，大家就不知道开发的最终目标是什么了。而这都是没有充分分析问题，拆解问题的结果，将会严重影响系统的可扩展性。如果对每一层问题都能够分析到位，并且清洗无效方案或错误方案，那么最后的呈现就会更加清晰。从代码的实现角度来说。持续定期的代码整理和架构升级；运用云原生保持良好的文档维护；淘汰过时的配置、运维方式、持续重构等手段都是实现低代码、高扩展性的有效路径。

系统具备高度可扩展性，可快速实现未来的多变需求，减少测试回归工作量，减少日后的重构频率。但是过度追求可扩展性，没有架构和业务的全局思维，来谈可扩展性设计就是笑话。可扩展性需要很强的预见性才能设计出来，这就难免出现高出预期的可能，过度高扩展性的代价是协同困难、调试困难、部署困难，是否有扩展性以5年为界是极限，不要设计出来能够兼容未来10年变化的系统，首先基本不可能做到，其次是对当前的工作来说代价会很大。架构师这个岗位被人诟病的原因，在于拆解系统时往往众筹大家的意志，或者跟着自己的感觉一味画概念大饼，没有清晰背后的架构推演逻辑，而这种逻辑正是对技术能力、业务理解、人性把握等的高度认知和抽象。

总之，想要有效减少系统熵增，实现架构可扩展性，首先要配置化实现系统需求，有序地模块化系统，远离平衡态，适度重构，即敢于下线老模块，勇于上线新模块。

“孤尽”取自“孤帆远影碧空尽”,是刚调动到淘宝时取的花名,之后在发布《码出高效》时的自我介绍改成了“独孤九剑,破尽天下武功”,圆自己在技术领域的“武侠梦”。以技术出圈的孤尽不仅热衷源码分析、前沿技术研究,还关注教育与公益领域。孤尽曾将《码出高效》稿费全部捐赠,用于“第83行公益”计划,帮助盲人工程师或山区学生;除此之外,孤尽在阿里内部还组织了柚子班训练营、外部Java特种兵培训机制的DIY班,帮助新入职场的程序员进阶提升自己的能力;在赋能企业的同时,也与浙江大学、北京大学、复旦大学等多所高校学生进行技术成长交流,帮助高校产教融合。孤尽同时也是阿里巴巴代码规约《阿里巴巴Java开发手册》的主要编写者。截至2021年9月1日,代码规约下载量已达到350万人次,插件安装人数超过245万人,基本成为业界普遍认可的开发规范。

11月19-20日，即将于上海举办的“K+全球软件研发行业创新峰会”，孤尽老师作为K+峰会特邀演讲嘉宾，将携《系统的熵增与架构的可扩展性》演讲议题作Keynote分享，感兴趣的小伙伴绝对不容错过！扫描下方海报二维码报名参会，获得与孤尽老师面对面交流机会，早鸟购票更享优惠！

本届“K+全球软件研发行业创新峰会”秉承“开放×连接×预见”的宗旨，就科技企业技术研发方向，特设工程创新、管理创新、产品创新、技术创新和效能创新五大分论坛。融合数字化转型、产品创新、运营和增长、云原生、DevOps创新、质量创新、微服务、高并发架构、智能金融、应用性能优化、工具的革命等十几大专场。特邀近百位全球软件领域的技术领袖与一线实战专家，融合主题演讲、互动研讨、案例分享、实战演练等多种形式，共同探讨软件领域的前沿发展、最佳实践和创新应用，打造大师智慧+实践干货的技术盛宴。

更多大会详情，请点击下方阅读原文