写点什么

软件架构治理与混沌工程

作者:码猿外
  • 2022 年 1 月 22 日
  • 本文字数:1938 字

    阅读完需:约 6 分钟

软件架构治理与混沌工程

在文章《架构混沌之谜》中我把软件架构比作一个房子,需求总是无法预测的,特别是在当前信息量巨大,网络非常发达的时代。只要对这个房子的使用场景做个简单的重新定义或补充定义,它就有了非常多的可能性,比如每个房间都需要接入网络,比如有一个房间要做成暗房用来冲洗照片,再比如有一个房间要用来摆放玩具,等等。脑洞再大些,如果未来无人机送快递到家普及了,假设每个房子都要有一块接收快递的地方,这对于上个世纪建造的房子来说,大概率需要做大规模的扩展。


软件架构治理也是一样,既需要解决现在的问题,也要为未来的扩展留有可能性。软件架构治理并不是一项单纯的技术工作,治理工作需要考虑到现在的问题,也需要考虑到未来的业务发展,单纯的从技术角度来思考软件的架构治理无疑是在雪上加霜。即便是倡导技术驱动的公司,本质上也是通过创新技术创造了新的业务,改变了人们的生活方式,从而用技术改变了世界。只有找到真实的业务价值,才能把技术的价值发挥到最大,因此软件架构治理一定是问题或价值驱动的


架构师在实际做架构治理的过程中,一个难点是当系统复杂度高到超出个体认知上限时,就很难看清系统问题全貌,只能从已知问题入手。然而,已知问题往往只是冰山一角,随着系统复杂度上升,很多随机的、不可预测的问题经常发生,这种问题有些是很难重现的,每次表现也不完全一样,在这种场景下,如何能有效发现系统根本的脆弱点,防患于未然,就是一个很大的挑战。

混沌工程

为了解决软件系统复杂后的稳定性问题,近几年,混沌工程作为一种以实验来提升软件系统韧性的学科,开始逐渐在众多大企业中开始实践起来。 混沌工程的概念由来已久,为什么最近几年才被大家越来越多的提及,才开始变得流行呢?我觉得原因有以下几个:


  • 开源工具的发展和完善,让大家应用混沌工程实验的成本降低。

  • 最近几年因为互联网业务的发展,微服务架构等技术的流行,软件系统的复杂度在不断提升,已远远超出人类能够记忆和认知的范围,定位问题成本越来越高,而混沌工程通过实验的方式能够快速帮助架构师找到架构上的问题。

  • 提升了研发团队对软件系统的理解,道长在他的文章《混沌工程赋能:规模化地应对上云后的未知暗债》中提出混沌工程是一种赋能活动,可以帮助开发团队理解复杂系统是如何运行和如何失效的。


那么混沌工程到底是怎样一种实验?是不是我们把各种猴子扔到生产环境中,让它们随机的搞一些破坏,看哪里出问题就修哪里?答案显然是否定的,试想如果随便扔几只搞破坏的猴子在生产环境,不可预知到底会发生什么问题,这无疑是一种自杀式的实验,任谁也不会放心大胆地去进行这样一种实验。



混沌工程实验并不是盲目的,也不是试探性的,它一定是有目的的,可控的一种实验。在混沌工程原则的网站上,定义了应用混沌工程的几个高级原则:


  1. 建立一个围绕稳定状态行为的假说

  2. 多样化真实世界的事件

  3. 在生产环境中运行实验

  4. 持续自动化运行实验

  5. 最小化爆炸半径


在第 1 个原则中,首先要定义一种可测量的稳定状态,并依据团队对系统的理解,定义一个假说:在某种故障发生时,系统依然能保持这种稳定状态。这里的关键点在于稳态假说,如果已经确定当故障发生时,系统一定无法保持稳态,那就没有必要进行实验了,而需要针对当前的问题去想对策。


接下来的 4 个原则描述了如何具体实施混沌工程实验:


  • 要模拟真实的事件,以确保实验结果的可靠性

  • 要尽量在生产环境中实验,以避免不同环境的差异(数据量,数据多样性,网络环境,并发请求数量等等)产生的影响

  • 要把实验过程自动化并持续执行,自动化以降低每次执行的成本,持续运行以便能够在有问题时及时发现

  • 要做到最小化爆炸半径,确保每次实验的影响范围都是可控的,而且是最小的

在软件架构治理中应用混沌工程

回到软件架构治理的话题上,既然混沌工程可以帮助架构师以及开发团队更好的理解系统,发现系统的弱点,那么应该如何应用混沌工程,提高研发团队对架构的掌控力,找到架构设计的问题,并加以治理?


首先,要对软件系统进行一次整体的盘点:有哪些组件(比如微服务、数据库、缓存等),运行环境如何(网络,VM/主机,存储等),三方依赖等等。


其次,针对系统中的这些组件,进行优先级的排序,通常可以按下面的方式定义优先级:


  1. 基础设施环境相关,基础设施出问题,往往都是大问题

  2. 三方集成系统相关,集成系统不可控,一旦出问题,处理不好影响非常大

  3. 自研的各个组件,自研组件受控性最强,往往问题发生后修复起来更快基于以上的优先级,可以再根据业务的影响范围,在每个层级里进行进一步的优先级定义。


最后,根据上面定义好的优先级,逐一定义稳定状态假说,并判断是否需要进行混沌工程实验,如果有必要,需要设计完整的实验过程和恢复方案,控制好实施范围,如果前期信心不足,可以先在非生产环境尝试,等信心足够时,再放到生产环境自动执行。

发布于: 刚刚阅读数: 2
用户头像

码猿外

关注

功不求戾,但求有恒 2018.10.07 加入

Thoughtworks高级咨询师,CAC认证专业敏捷教练,资深软件架构师 拥有10多年的架构设计和敏捷软件开发管理经验,专注于分布式软件架构设计、微服务架构设计和敏捷软件开发。 个人主页:https://maguangguang.xyz

评论

发布
暂无评论
软件架构治理与混沌工程