研发高可用架构和系统设计经验

从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用的系统需要有哪些关键的设计和考虑。

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

1.可用性和高可用概念

可用性是一个可以量化的指标，计算的公式在维基百科中是这样描述的：根据系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。行业内一般用几个9表示可用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。

高可用（High Availability）的定义：（From 维基百科）是 IT 术语，指系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

服务不可能 100% 可用，因此要提高我们的高可用设计，就要尽最大可能去增加我们服务的可用性，提高可用性指标。一句话来表述就是：高可用就是让我们的服务在任何情况下都尽最大可能能够对外提供服务。

2.高可用系统设计思想

高可用系统的设计，需要有一套比较科学的工程管理套路，要从产品、开发、运维、基建等全方位去考量和设计，高可用系统的设计思想包括但不限于：

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

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

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

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

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

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

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

二、研发规范层面

1.方案设计和编码规范

研发规范层面这个是大家容易忽视的一个点，但是，我们所有的设计，都是研发人员来完成的，包括从设计文档到编码到发布上线，因此，研发层面也是有一个规范流程和套路，来让我们更好的去研发和维护一个高可用的系统：

1）设计阶段

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

方案设计后一定要进行评审，在我们团队中，新项目一定要评审，重构项目一定要评审，大的系统优化或者升级一定要评审，其他的一般研发工作量超过一周的建议要评审的。

2）编码阶段

不要随便打日志；

要接入远程日志；

要能够分布式链路追踪；

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

包括增量覆盖率、全量覆盖率，具体的覆盖率要达到多少可以根据团队内部的实际情况来定，在我们团队，定的规则是 50% 的覆盖率；

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

遵循团队内部的代码规范，一般公司都有对应语言的规范，如果没有则参考官方的规范，代码规范可以大大减少 bug 并且提高可用性；

执行代码规范；

单测覆盖率；

日志规范。

3）发布上线阶段，

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

2.容量规划和评估

容量评估，是指我们需要评估好，我们这个系统，是为了应对一个什么体量的业务，这个业务请求量的平均值、高峰的峰值大概都在一个什么级别。如果是新系统，那么就需要根据产品和运营同学对业务有一个大体的预估，然后开发同学根据产品给的数据再进行详细的评估。如果是老系统，那么就可以根据历史数据来评估。评估的时候，要从一个整体角度来看全局的量级，然后再细化到每个子业务模块要承载的量级。

容量规划，是指我们系统在设计的时候，就要能够初步规划好我们的系统大致能够抗多少的量级，比如是十万还是百万级别的请求量，或者更多。不同的量级对应的系统架构的设计会完全不一样，尤其到了千万、亿级别的量级的时候，架构的设计会有很多的考量。当然这里需要注意的是，我们不需要一上来就设计出远超于我们当前业务真实流量的系统，要根据业务实际情况来设计。

同时，容量规划还涉及到，我们系统上下游的各个模块、依赖的存储、依赖的三方服务，分别需要多少资源，需要有一个相对可以量化的数据出来。容量规划阶段&#x