阿里是如何抗住双11的？看完这篇你就明白了!(2)

稳定性保障的核心目标如下：

尽早的预防故障，降低故障发生几率。

及时预知故障，发现定义故障。

故障将要发生时可以快速应急。

故障发生后能快速定位，及时止损，快速恢复。

故障后能够从中吸取教训，避免重复犯错。

仔细思考一下，所有的稳定性保障手段都是围绕这些目标展开的。

稳定性保障体系

上图涵盖了稳定性体系的各个方面，下面我来一一讲解。

应用架构稳定性

应用架构稳定性相对是比较广的话题，按我的理解主要包括很多设计原则和手段：

①架构设计简单化。系统架构简单清晰，易于理解，同时也需要考虑到一定的扩展性，符合软件设计中 KISS 原则。

现实中存在太多的“过度设计”和“为了技术而技术”，这些都是反例，架构师需懂得自己权衡。

②拆分。拆分是为了降低系统的复杂度，模块或服务“自治”，符合软件设计中“单一职责”原则。拆分的太粗或者太细都会有问题，这里没有什么标准答案。

应该按照领域拆分(感兴趣同学可以学习下 DDD 中的限界上下文)，结合业务复杂程度、团队规模(康威定律)等实际情况来判断。可以想象 5 个人的小团队去维护超过 30 多个系统，那一定是很痛苦的。

③隔离。拆分本质上也是一种系统级、数据库级的隔离。此外，在应用内部也可以使用线程池隔离等。分清“主、次”，找出“高风险”的并做好隔离，可以降低发生的几率。

④冗余。避免单点，容量冗余。机房是否单点，硬件是否单点，应用部署是否单点，数据库部署是否单点，链路是否单点…硬件和软件都是不可靠的，冗余(“备胎”)是高可用保障的常规手段。

（编辑：ASP站长网）