工作十年，谈谈我的高可用架构和系统设计经验.pdfVIP

本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六

大层面去剖析一个高可用的系统需要有哪些关键的设计和考虑

一、高可用架构和系统设计思想

可用性和高可用概念

可用性是一个可以量化的指标，计算的公式在维基百科中是这样描述的：根据系统损害、无法使用的时

间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。行业内一般用几个9表示可

用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到4个

9（99.99%）的可用性才能谈得上高可用。

高可用（HighAvailability）的定义：（From维基百科）是IT术语，指系统无中断地执行其功能的能

力，代表系统的可用性程度，是进行系统设计时的准则之一。服务不可能100%可用，因此要提高我们

的高可用设计，就要尽最大可能的去增加我们服务的可用性，提高可用性指标。一句话来表述就是：高

可用就是让我们的服务在任何情况下都尽最大可能能够对外提供服务。

高可用系统设计思想

高可用系统的设计，需要有一套比较科学的工程管理套路，要从产品、开发、运维、基建等全方位去考

量和设计，高可用系统的设计思想包括但不限于：

做好研发规范，系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个规范和标准

做好容量规划和评估，主要是让开发人员对系统要抗住的量级有一个基本认知，方便进行合理的架

构设计和演进。

做好服务层面的高可用，主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。

做好存储层面的高可用，主要是冗余备份（热备、冷备）、失效转移（确认，转移，恢复）等。

做好运维层面的高可用，主要是发布测试、监控告警、容灾、故障演练等。

做好产品层面的高可用，主要是兜底策略。

做好应急预案，主要是在出现问题后怎么快速恢复，不至于让我们的异常事态扩大。

二、研发规范层面

方案设计和编码规范

研发规范层面这个是大家容易忽视的一个点，但是，我们所有的设计，都是研发人员来完成的，包括从

设计文档到编码到发布上线，因此，研发层面也是有一个规范流程和套路，来让我们更好的去研发和维

护一个高可用的系统：

设计阶段

规范好相关方案设计文档的模板和提纲，让团队内部保持统一，可以参考我的文章《技术方

案设计模板》

方案设计后一定要进行评审，在我们团队中，新项目一定要评审，重构项目一定要评审，大

的系统优化或者升级一定要评审，其他的一般研发工作量超过一周的建议要评审的。

编码阶段

不要随便打日志

要接入远程日志

要能够分布式链路追踪

代码编写完需要有一定的单测来保证代码的健壮性，同时也能保障我们后续调整逻辑或者优

化的时候可以保证代码的稳定

包括增量覆盖率、全量覆盖率，具体的覆盖率要达到多少可以根据团队内部的实际情况来

定，在我们团队，定的规则是50%的覆盖率。

工程的layout目录结构规范，团队内部保持统一，尽量简洁

遵循团队内部的代码规范，一般公司都有对应语言的规范，如果没有则参考官方的规范，代

码规范可以大大减少bug并且提高可用性。

执行代码规范

单测覆盖率

日志规范

发布上线阶段，参考下面运维部署层面那一章节的灰度发布和接口测试相关说明

容量规划和评估