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

可用性和高可用概念

可用性是一个可以量化的指标，计算的公式在维基百科中是这样描述的：根据系统损害、无法使用的时 间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。行业内一般用几个9表示可 用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。 高可用（High Availability）的定义：（From 维基百科）是 IT 术语，指系统无中断地执行其功能的能 力，代表系统的可用性程度，是进行系统设计时的准则之一。服务不可能 100% 可用，因此要提高我们 的高可用设计，就要尽最大可能的去增加我们服务的可用性，提高可用性指标。一句话来表述就是：高 可用就是让我们的服务在任何情况下都尽最大可能能够对外提供服务。

高可用系统设计思想

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

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

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

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

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

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

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

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

二、研发规范层面

方案设计和编码规范

研发规范层面这个是大家容易忽视的一个点，但是，我们所有的设计，都是研发人员来完成的，包括从 设计文档到编码到发布上线，因此，研发层面也是有一个规范流程和套路，来让我们更好的去研发和维 护一个高可用的系统： 设计阶段 规范好相关方案设计文档的模板和提纲，让团队内部保持统一，可以参考我的文章《技术方 案设计模板》

方案设计后一定要进行评审，在我们团队中，新项目一定要评审，重构项目一定要评审，大 的系统优化或者升级一定要评审，其他的一般研发工作量超过一周的建议要评审的。 编码阶段 不要随便打日志 要接入远程日志 要能够分布式链路追踪