稳定性-稳定性架构
分布式系统稳定性架构模式
这里我们不探讨某个具体系统的稳定性架构,我们先来认识一下稳定性架构,通过这个概念拉齐我们探讨稳定性治理的开展模式.
在一个微服务架构组成的分布式系统中,一个稳定性保障的目标对象(这个对象的颗粒度可以稍后再定义)在东西向通常有上游(调用来源方)和下游(调用依赖方),于此同时,在南北向上通常也有上游(App/小程序/IoT)和下游(数据库/中间件/大数据等),这样一个类似围棋棋子结构中,稳定性不仅和自身有关、还和上下游有关.
这个 Service 对象非常类似围棋棋子, 棋子的"气"决定了棋子是否可以继续存活, Service 对象的稳定性一方面由自身决定,但同时还由周围四个方向的关联对象所决定.因此,稳定性架构需要有开放的视野,才能够穷尽所有可能影响稳定性的要素,不断提升对风险的认知,这是稳定性治理最基础的第一步.
这里最后我需要填一下前面挖的一个坑,稳定性保障对象的颗粒度如何确定. 我们知道一个微服务、多个微服务组成的应用、多个应用组成的业务系统都可以称之为稳定性保障对象,不同粒度的架构模式相同,在执行过程中不断由大到小,最终无法继续拆下去为止.
稳定性架构的水位评估
稳定性架构是一个持续评估和持续治理的过程,稳定性架构的水位评估原则将直接影响治理目标和最终效果.经过多年的实践,这里推荐一个经过多次迭代的评估模型:
- 变更影响对象数量,即稳定性保障对象变更时影响到的变更对象数量,影响数量越多故障事件波及范围越大
- 变更影响对象的类型和等级,即影响对象中多少重点对象,重点对象越多说明变更故障事件严重程度越高
- 变更三板斧成熟度,即变更的过程可否监控、灰度、快恢,当前对象和关联对象变更可否小步试错、可否观测变更对系统的影响
- 故障应急成熟度,即自身和关联对象的所有变更场景的故障是否能够快速恢复,具体来说,有预案优于无预案,自动化优于手动操作,有演练优于无演练这三个原则排序
- 变更事件订阅和风险防御机制成熟度,即当前对象对于依赖的下游对象的变更事件可否及时感知, 对自身的变更是否建立了变更前、变更中(主要是灰度)和变更后的风险防控平台化能力.
未完待续, 20250103