架构设计系列5：如何设计高可用架构

#1024程序员节｜参与投稿，赢限定勋章和专属大奖#

概要

当今的数字时代，高可用架构已经成为了现代应用和服务的基石。无论是企业级应用、云计算平台还是互联网服务，高可用性都是确保系统在面临各种挑战时保持稳定运行的关键要素。

本文将探讨什么是高可用架构，为什么它如此重要，以及如何提升系统的可用性。

一、什么是高可用架构

高可用架构是一种设计和架构方法，它旨在确保系统在面对各种故障、异常、硬件或软件问题，以及不可预测的事件下，继续提供稳定的服务。简单来说，高可用就是让我们的系统在任何情况下都尽最大可能能够对外提供服务。

高可用架构追求提供连续的服务，不受单点故障、服务中断或其他问题的影响。这通常涉及到复制、冗余、负载均衡和自动故障转移等技术手段，以保持系统的稳定性和可用性。

---

二、为何高可用架构如此重要

高可用架构之所以如此重要，有以下几个关键原因：

1. 用户满意度：用户期望系统7*24可用，如果系统不可用，可能会损害用户体验，并导致用户流失。
2. 业务连续性：如果系统不可用，将无法为用户提供连续的服务，可能给用户和公司造成业务损失。

由此可见，高可用架构的目标就是最大限度地减少系统停机时间，并确保用户能够无间断地访问和使用系统。

那么，一般有哪些因素会影响系统的稳定性呢？

1. 人为因素：如误操作、配置错误、不合理的变更等
2. 软件因素：如代码bug、设计漏洞、GC问题、线程池异常、上下游异常等
3. 硬件因素：如网络故障、存储故障、机器故障等
4. 安全因素：如安全漏洞、未授权的访问、恶意攻击等
5. 负载因素：如突发的流量激增、恶意攻击、系统资源不足等

---

三、如何提升系统的可用性

面对诸多影响系统稳定的因素，我们应当如何去保障系统是高可用的呢？

通常为了保障系统是高可用的，我们需要有一套比较科学的管理方法，要从产品、设计、开发、测试、运维等全方位去考量和设计。

接下来，我们一起来探讨下具体可以从哪些方面着手提升系统的可用性。

1. 研发规范层面

1.1 方案设计和编码规范

1.2 容量规划和评估

1.3 小结

系统都是研发人员设计和编码写出来的，因此一个好的研发规范和标准，可以让我们更好的去研发和维护一个高可用的系统。

2. 应用服务层面

2.1 无状态设计和负载均衡设计

无状态+负载均衡，既可以提高系统的可用性，也可以提高系统的并发能力。

2.2 弹性伸缩和资源隔离设计

2.3 异步解耦和流量削峰设计

2.4 故障和容错设计

2.5 过载保护设计

2.6 小结

在当前的互联网时代，应用服务基本都是无状态的，因此要实现应用服务的高可用相对会比较简单。

3. 数据存储层面

接下来，我们一起来探讨下，具体我们要如何保障数据存储的高可用。

第一，数据存储高可用本质上如何实现的？

数据存储高可用本质上是通过数据冗余的方式来实现的。

简单来说，就是通过将数据复制到多个存储介质里面，来有效的避免数据丢失，同时还可以提高并发能力。

第二，要保障数据存储的高可用，通常会面临哪些问题？

1. 数据如何复制？
2. 各个节点的职责是什么？
3. 如何应对复制延迟？
4. 如何应对复制中断？

第三，常见的解决存储高可用的方案有哪些？

常见的解决存储高可用的方案有两种：集群存储和分布式存储。业界大多是围绕这些来构建，或者是做相关衍生和扩展。

3.1 集群存储（集中式存储）

集中式存储，就是在不同的机器上存放完整的相同数据，把多台机器组合成一个集群，对外提供统一的服务。

通常我们说的集中式存储，指的就是 一主多备 或者 一主多从 的架构，写数据通过主机，读数据一般通过从机。

架构模式

适合场景
集群存储，适合数据量规模一般的场景，一般中大型互联网公司，默认都是集群存储的方式。比如 Redis、MySQL 等存储类型。

3.2 分布式存储

分布式存储，是指将不同的业务数据，分开存储在不同的地方，分布式中的每一个节点，都可以做集群。

架构模式

个人理解

• Redis 集群模式，按照slot区间进行路由，一定程度上也是分布式存储的体现。
• MySQL 分库分表，按业务因子进行路由，一定程度上也是分布式存储的体现。

适合场景

分布式存储，适合数据量规模巨大的场景，常见的分布式存储比如 Hadoop(HDFS)、HBase、ES 等。

3.3 小结

由于数据是有状态的，因此要实现数据存储的高可用，相对应用服务来说，会复杂很多。

4. 系统运维层面

4.1 开发阶段

于系统运维而言，在开发阶段如何提高系统的可用性呢？通常我们可以对如下几个方面进行考量和设计。

4.2 部署阶段

于系统运维而言，在部署阶段，我们通常通过容灾设计来提高系统的可用性。

容灾系统通常分为：数据容灾和应用容灾。备份系统通常分为：同城备份和异地备份。

一般的业务系统，如果规模不大，通常单机房部署就可以了。当业务发展到一定规模，在条件允许的情况下，可以考虑多机房部署，甚至多区域部署。

容灾和备份有何区别？

• 容灾：核心目标是保证业务连续性。 举例：当A发生故障后，业务自动切换到B。
• 备份：核心目标是保证数据的完整性、安全性。 举例：B仅作为A的备份数据，不对外提供服务，当A故障后，需要大量的人工干预和操作，花费大量的时间才能让B承载业务。

4.3 线上运行阶段

于系统运维而言，在线上运行阶段，我们通常可以通过如下方式来保障系统的可用性。

4.4 小结

提高系统运维效率的关键在于可观测，因此构建可观测性系统，对保障系统的稳定性至关重要。

5. 故障处理层面

前面做了这么多保障，但是终究架不住线上的各种异常情况，如果真出现异常，那么该如何将损失降低到最小呢？

在实际的工作中，发现故障或收到故障告警后，往往存在响应不及时，或不知道如何响应的情况。

为了提升团队对故障的处理能力，通常我们会制定一个标准化的故障处理流程，使得大家能够及时、快速、有序地对故障进行响应。

故障处理流程的目标是，将系统中的服务或组件责任到人，当出现故障后，各司其职，快速分析并解决问题，将损失降至最低，避免出现问题后，手忙脚乱导致事态扩大。

5.1 故障处理流程

具体见：故障处理流程规范（新）

5.2 小结

需特别注意，故障处理流程，越简单越易落地，千万不要搞复杂，否则难以落地。

四、最后

对于一个持续迭代、不断演进的系统而言，我们没有办法将故障发生的概率降为0，能做的只有尽可能的预防故障的发生，以及当故障发生后缩短故障的恢复时间。

当然我们也不用一味的追求可用性，毕竟提升稳定性的同时，维护成本、机器成本等也会跟着上涨，所以需要结合系统的业务要求选择合适的方案，适合的才是最好的。

最后，一句话总结，高可用就是最大限度地减少系统不可用的时间。

---

架构设计系列文章

1. 架构设计系列：什么是架构设计
2. 架构设计系列：几个常用的架构设计原则
3. 架构设计系列：高并发系统的设计目标
4. 架构设计系列：如何设计可扩展架构
5. 架构设计系列：如何设计高性能架构
6. 架构设计系列：如何设计高可用架构
7. 架构设计系列：如何应对软件变化
8. 架构设计系列：常用设计模式的实践

---