在《??软件架构治理 之 架构混沌之谜??》一文中，我将软件架构比作房子，需求总是不可预测的，尤其是在信息量巨大、网络发达的当今时代。只要对这个房子的使用场景做一个简单的重新定义或者补充定义，就有很多的可能性，比如每个房间都需要联网，比如把一个房间做成暗房对于洗照片，又比如有放玩具的房间等等。如果你脑洞大一点，如果未来无人机送快递到你家，假设每家每户都必须有一个收快递的地方，对于上个世纪建造的房子，大概率是将需要扩展。软件架构治理也是如此，不仅要解决当前的问题，还要为未来的扩展留下可能性。软件架构治理不是一项纯粹的技术工作。治理需要考虑当前的问题和未来的业务发展。单纯从技术角度思考软件架构治理，无疑会使事情变得更糟。即使是提倡技术驱动技术的企业，本质上也是通过创新技术创造新的业务，改变人们的生活方式，从而用技术改变世界。只有找到真正的商业价值，技术的价值才能最大化，所以软件架构治理必须以问题或价值为驱动。架构师在实际做架构治理的过程中的难点之一是，当系统的复杂度超过个人认知的上限时，很难看到系统问题的全貌，只能从已知问题入手.然而，已知的问题往往只是冰山一角。随着系统复杂度的增加，经常会出现许多随机的、不可预测的问题。其中一些问题很难重现，而且每次的表现都不完全一样。在这种场景下，如何有效地发现系统的根本漏洞，防患于未然，是一个很大的挑战。混沌工程为解决复杂软件系统的稳定性问题，近年来，混沌工程作为一门通过实验提高软件系统弹性的学科，逐渐开始在许多大型企业中实践。混沌工程的概念由来已久。为什么近年来被越来越多的人提起，然后火了起来？我认为原因有以下几点：开源工具的发展和完善降低了应用混沌工程实验的成本。近年来，由于互联网业务的发展和微服务架构等技术的普及，软件系统的复杂度不断增加，远远超出了人类记忆和认知的范围，定位问题的成本越来越高越来越高。混沌工程实验的方式可以快速帮助架构师发现架构问题。提高了研发团队对软件系统的理解。在他的文章《混沌工程赋能：规模化地应对上云后的未知暗债》中，Taoist提出混沌工程是一种赋能活动，可以帮助开发团队了解复杂系统如何运行以及它们如何失败。那么混沌工程是一个什么样的实验呢？是不是把各种猴子丢到生产环境里，让它们随便搞点破坏，哪里有问题就修？答案显然是否定的。试想一下，如果你在生产环境中扔几只破坏猴子，你无法预测会发生什么。这无疑是一场自杀实验，没有人会自信大胆。一种实验。混沌工程实验既不是盲目的，也不是试探性的，一定是有目的、可控的实验。在PrinciplesofChaosEngineering网站上，定义了应用混沌工程的几个高级原则：围绕稳态行为建立假设多样化的现实世界事件在生产中运行实验连续自动化运行实验最小化爆炸半径1在这个原则中，首先要定义一个可测量的稳定状态，并根据团队对系统的理解定义一个假设：当某个故障发生时，系统仍然可以保持这个稳定状态。这里的关键点是稳态假设。如果已经确定系统在发生故障时将无法保持稳定状态，那么就没有必要进行实验，需要针对当前的问题想对策。接下来的四个原则描述了如何实现混沌工程实验：模拟真实事件以保证实验结果的可靠性，尽量在生产环境中进行实验，避免不同环境（数据量、数据多样性、网络环境、数量）的差异。并发请求等）使实验过程自动化并持续执行，自动化降低每次执行的成本，并持续运行以便及时发现问题，最大限度地减少爆炸半径，确保每个影响范围混沌工程在软件架构治理中的应用回到软件架构治理的话题，既然混沌工程可以帮助架构师和开发团队更好地理解系统，发现如何应用混沌工程来提高研发团队的控制力overthearchitecture，找出架构设计的问题gn，并解决它们？首先，需要对软件系统进行整体盘点：有哪些组件（如微服务、数据库、缓存等），运行环境如何（网络、VM/主机、存储等）。)、三方依赖等。其次，对于系统中的这些组件，进行优先级排序。通常，优先级可以定义为：与基础设施环境相关，基础设施出问题往往是大问题，与三方集成系统相关，集成系统不可控。一旦出现问题，如果处理不当，将会极大地影响到自研组件的各个组件。自主研发的部件是最可控的，往往出现问题后修复得更快。在层次结构中进行进一步的优先级定义。最后，根据上面定义的优先级，逐一定义稳态假设，判断是否有必要进行混沌工程实验。必要时，需要设计完整的实验流程和恢复方案，并控制实施范围。如果前期信心不足，可以先在非生产环境试一试，等信心足够了再放到生产环境自动执行。
