置之死地而后生，面向失败的架构设计

Posted 2021-04-10 Java架构师社区

 
   
   
 

  
    
    
  
 
   
 
    关注我们,设为星标,每天7:30不见不散,架构路上与您共享  
   
 
  
 
   
   
 

搜一下“宕机”，就能看到很多系统问题导致的服务不可用新闻，当然，这其中包括多种原因，例如系统恶化，流量超出预期，外部DDoS攻击，数据库问题，架构设计问题等等。

所以，就有了“面向失败而设计的架构”，有点类似于《史记·淮阴侯列传》：“‘陷之死地而后生，置之亡地而后存。’……其势非置之死地，使人人自为战”的意味。其初衷是以“失败”为对象，设想可能存在各种失败原因的设计思想，在系统设计阶段就考虑到各种失败场景，把失败当成是设计的一部分，未雨绸缪，利用积极的心态提前规划好从失败中恢复的策略。

在架构设计方面，通过面向失败的设计，贯穿整个软件生命周期来防范已知的确定性风险及未知的不确定性风险。阿里巴巴在2012年开始积累这方面的经验，有成熟的方案来支持每年的双11，从容应对各种挑战。整个方案包括“容灾设计、架构设计、预案、自动化运维、智能监控等”。以下是阿里技术团队总结出来的几个阶段各个原则。

架构设计阶段

简单化设计原则

系统架构简单清晰，具备水平扩展能力 。与之相反的就是过度设计，如何更好的平衡必要复杂度与意外复杂度是关键。“不是在不能添加更多的时候，而是没有什么可以去掉的时候，才能达到完美”。

监控设计原则

监控系统架构及监控规则应该是简单的，易于理解的。监控项覆盖度高，需要控制好有效报警数，监控围绕四大黄金指标：延迟，流量，错误，饱和度展开。

管控设计原则

需避免权限过大，系统应具备逃生能力，灰度能力。线上很多p1级故障发生，都是因为权限过大或者不具备灰度能力导致的。管控系统作为服务提供方，理应当对自身行为带来的危害负责，需要具备自保护能力。

开发发布阶段

敏捷设计原则

敏捷开发，小规模，多批次迭代。敏捷开发对面向失败设计来说可以有效预防，降低故障发生，同时能够快速定位及恢复故障。

变更设计原则

可灰度，可监控，可回滚。无论系统发布还是配置项的改动，都需要遵从变更三板斧。线上60%故障是由于变更发布导致的，渐进式发布，快速准确检测到问题，同时快速回滚是非常必要的。

运行运维阶段

容量设计原则

基于稳态容量及尖刺容量规划，适当冗余，具备快速弹性扩容能力。通过自然需求增长模型来预测稳态容量，通过适当冗余，流控，快速弹性扩容能力保障非自然需求增长。同时做好周期性压力测试。

依赖设计原则

最小化依赖，避免循环依赖，通过异步化，服务降级，限流，隔离等手段控制由于依赖带来的影响面。上下游依赖需要建立基于接口，服务，应用等级别的SLO，了解更多上下游信息，做好防护手段。

自动化设计原则

对重复，人肉的操作尽可能通过自动化来保障操作一致性，提升效率。

快恢设计原则

标准化的故障恢复流程， 从故障被监控发现开始，人员上线响应，故障定位 ，恢复等一系列流程是人与系统共同参与的活动。从人的角度需要具备oncall能力，快速上线能力，快速登录系统定位处理问题能力，系统需要具备快速报警，回滚，隔离，容灾等能力。

在2020年12月20-21日QCon全球软件开发大会（上海站），来自阿里的高级技术专家隐寒，多年从事高可用领域相关的工作，将会分享“面向失败的架构设计核心思想和实践”话题，介绍如何时刻关注系统的可用性，提前预防甚至解除风险，做到系统的持续可用。本专题下还有其他大厂的技术分享，感兴趣的可以关注下：

目前大会门票9折抢购中，限时立减680元！优惠截至12月20日。了解大会议程和演讲嘉宾可以扫描下图二维码或点击【阅读原文】查看！大会咨询：17310043226（同微信）

免费福利