【工作10年+的大厂资深架构师万字长文总结精华收藏！】怎样设计高可用、高性能系统？关于高可用高性能系统架构和设计理论和经验总结...

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

O、前言

随着业务在线化互联网化的高速发展，企业对核心业务系统的稳定性、可靠性、有效性、业务连续性等有了更高的要求。采用高可用系统架构支持重要系统、为关键业务提供7x24的不间断服务，已经成为众多企业保障业务稳定、持续运转的主要选择。但如何从海量实践中提炼出值得借鉴复制的高可用架构之道，实现适合自身的高可用系统架构，是需要企业深思熟虑的问题。

本文将依据高并发用户、突发高流量场景下的真实案例，分享在高可用架构建设过程中的经验总结，以期待帮助更多企业做好业务高可用建设。

在亿级用户场景下的大型网站的高并发架构设计，在业务系统、缓存、数据库、MQ、CDN、静态化、分库分表、NoSQL、搜索、分布式文件系统、反向代理，等等层面的架构设计都会跟小流量场景有较大的不同。

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

可用性和高可用概念

高可用：系统无中断地执行其功能的能力。

高可用（High Availability）的定义：（From 维基百科）是 IT 术语，指系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。服务不可能 100% 可用，因此要提高我们的高可用设计，就要尽最大可能的去增加我们服务的可用性，提高可用性指标。一句话来表述就是：高可用就是让我们的服务在任何情况下都尽最大可能能够对外提供服务。

可用性度量：几个9？

可用性是一个可以量化的指标，计算的公式在维基百科中是这样描述的：

根据系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。

行业内一般用几个9表示可用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。

故障原因

系统宕机原因主要有以下：

无计划的

系统级故障，包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。
数据和中介的故障，包括人员误操作、硬盘故障、数据乱了。
还有自然灾害、人为破坏，以及供电问题等。

有计划的

日常任务：备份，容量规划，用户和安全管理，后台批处理应用。
运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。
升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级。

我们再给它们归个类。

网络问题。网络链接出现问题，网络带宽出现拥塞……
性能问题。数据库慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足……
安全问题。被网络攻击，如 DDoS 等。
运维问题。系统总是在被更新和修改，架构也在不断地被调整，监控问题……
管理问题。没有梳理出关键服务以及服务的依赖关系，运行信息没有和控制系统同步……
硬件问题。硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题……

什么是高可用的系统架构？

通常，企业级应用系统为提高系统可用性，会采用较昂贵的软硬件设备，当然这样的设备也比较稳定。

互联网公司或一些初创型公司基于成本考虑，更多采用 PC 级软硬件设备，节约成本所付出的代价就是设备较为不稳定。服务器一年中出现几次宕机，高强度读写磁盘导致磁盘损坏等事件实属正常。

综上，硬件出现故障应视为必然的，而高可用的系统架构设计目标就是要保证当出现硬件故障时，服务依然可用，数据依然能够保存并被访问。实现高可用的系统架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上；如果磁盘损坏，则从备份的磁盘读取数据。

大型系统的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。关闭服务或服务器宕机时产生的影响也不相同，高可用的解决方案也差异甚大。大致可以分为：

高可用的应用 - 主要手段是：负载均衡
高可用的服务 - 主要手段是：分级管理、超时重试、异步调用、限流、降解、断路、幂等性设计
高可用的数据 - 主要手段是：数据备份和失效转移

高可用架构模式

主备复制

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等。

主备复制要点：

存在一主多备。
主机负责读&写，并定期复制数据给备机。
一旦主机宕机，可以通过人工手段，将其中一个备节点作为主节点。

优点

主备复制架构中，客户端可以不感知备机的存在。即使灾难恢复后，原来的备机被人工修改为主机后，对于客户端来说，只是认为主机的地址换了而已，无须知道是原来的备机升级为主机。
主备复制架构中，主机和备机之间，只需要进行数据复制即可，无须进行状态判断和主备切换这类复杂的操作。

缺点

主备复制架构中，故障后需要人工干预，无法自动恢复。

适用场景

综合主备复制架构的优缺点，内部的后台管理系统使用主备复制架构的情况会比较多，例如学生管理系统、员工管理系统、假期管理系统等，因为这类系统的数据变更频率低，即使在某些场景下丢失数据，也可以通过人工的方式补全。

主从复制

主从复制和主备复制只有一字之差，区别在于：主从复制模式中，从机要承担读操作。

主从复制要点：

存在一主多从。
主机负责读&写，并定期复制数据给从机。
从机只负责读。
一旦主机宕机，可以通过人工手段，将其中一个从节点作为主节点。

优点

主从复制架构中，主机故障时，读操作相关的业务可以继续运行。
主从复制架构中，从机提供读操作，发挥了硬件的性能。

缺点

主从复制架构中，客户端需要感知主从关系，并将不同的操作发给不同的机器进行处理，复杂度比主备复制要高。
主从复制架构中，从机提供读业务，如果主从复制延迟比较大，业务会因为数据不一致出现问题。
主从复制架构中，故障时需要人工干预。

适用场景

综合主从复制的优缺点，一般情况下，写少读多的业务使用主从复制的存储架构比较多。例如，论坛、BBS、新闻网站这类业务，此类业务的读操作数量是写操作数量的 10 倍甚至 100 倍以上。

集群+分区

在主备复制和主从复制模式中，都由一个共性问题：

每个机器上存储的都是全量数据。但是，单机的数据存储量总是有上限的，当数据量上升为 TB 级甚至 PB 级数据，单机终究有无法支撑的时候。这时，就需要对数据进行分片（sharding）。

分片后的节点可以视为一个独立的子集，针对子集，任然需要保证高可用。

总结一下：系统的高可用方案五花八门，但万变不离其宗，本质上都是通过“冗余”来实现高可用，增加机器，增加通道（移动、电信、联通一起上）等等。通过增加更多机器来达到目的。

与高性能中增加机器的本质区别在于：

高性能增加机器目的在于“扩展”处理性能；

高可用增加机器目的在于“冗余”处理单元。

计算高可用（业务的逻辑处理）

增加任务分配器，选择合适的任务分配器需要综合考虑性能、成本、可维护性、可用性等各方面因素。任务分配器和真正的业务服务器之间有连接和交互，需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。任务分配器需要增加分配算法。例如，常见的双机算法有主备、主主，主备方案又可以细分为冷备、温备、热备。

这个高可用集群相比双机来说，分配算法更加复杂，可以是 1 主 3 备、2 主 2 备、3 主 1 备、4 主 0 备，具体应该采用哪种方式，需要结合实际业务需求来分析和判断，并不存在某种算法就一定优于另外的算法。例如，ZooKeeper 采用的就是 1 主多备，而 Memcached 采用的就是全主 0 备。

存储高可用

无论是正常情况下的传输延迟，还是异常情况下的传输中断，都会导致系统的数据在某个时间点或者时间段是不一致的，而数据的不一致又会导致业务问题；但如果完全不做冗余，系统的整体高可用又无法保证，所以存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。

分布式领域里面有一个著名的 CAP 定理，从理论上论证了存储高可用的复杂度。也就是说，存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多满足其中两个，这就要求我们在做架构设计时结合业务进行取舍。

番外篇：CAP 定理

又称为 CAP 原则，指的是：在一个分布式系统中， 一致性（C：Consistency）、可用性（A：Availability） 和 分区容忍性（P：Partition Tolerance），最多只能同时满足其中两项。

BASE 是 基本可用（Basically Available）、软状态（Soft State） 和 最终一致性（Eventually Consistent） 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

高可用系统设计思想

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

• 做好研发规范，系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个规范和标准
• 做好容量规划和评估，主要是让开发人员对系统要抗住的量级有一个基本认知，方便进行合理的架构设计和演进。
• 做好服务层面的高可用，主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。
• 做好存储层面的高可用，主要是冗余备份（热备、冷备）、失效转移（确认，转移，恢复）等。
• 做好运维层面的高可用，主要是发布测试、监控告警、容灾、故障演练等。
• 做好产品层面的高可用，主要是兜底策略。
• 做好应急预案，主要是在出现问题后怎么快速恢复，不至于让我们的异常事态扩大。

Frequently Asked Questions (FAQs)
常见问题 (FAQ)

What is meant by high availability?
高可用性是什么意思？
High availability, or HA, is a label applied to systems that can operate continuously and dependably without failing. These systems are extensively tested and have redundant components to ensure high quality operational performance. In short, high availability systems will be available no matter what occurs.
高可用性或 HA 是应用于可以连续可靠地运行而不会出现故障的系统的标签。这些系统经过广泛测试并具有冗余组件，以确保高质量的运行性能。简而言之，无论发生什么情况，高可用性系统都将可用。

What is the difference between high availability and redundancy?
高可用性和冗余之间有什么区别？
Redundancy is often a component of high availability, but they have different meanings. High availability means that a system will be available regardless of circumstances, while redundancy in a system means that multiple components can replace one another to keep things running in case something happens.
冗余通常是高可用性的组成部分，但它们具有不同的含义。高可用性意味着系统在任何情况下都可用，而系统中的冗余意味着多个组件可以相互替换以在发生某些情况时保持运行。

Why is high availability important?
为什么高可用性很重要？
Customer satisfaction often relies on whether or not customers can access your product or service when they need to and whether or not they can depend on it to work. High availability architecture ensures that your website, application, or server continues to function through different demand loads and failure types.
客户满意度通常取决于客户是否可以在需要时访问您的产品或服务，以及他们是否可以依靠它来工作。高可用性架构可确保您的网站、应用程序或服务器在不同的需求负载和故障类型下继续运行。

What is high availability in cloud computing?
什么是云计算中的高可用性？
You can create high availability in cloud computing by making clusters. When a group of servers work together as a single server to deliver continuous uptime, those servers are called a high availability cluster. If one server fails or is otherwise unavailable, the other servers can step in.
您可以通过创建集群来创建云计算中的高可用性。当一组服务器作为单个服务器一起工作以提供连续的正常运行时间时，这些服务器称为高可用性集群。如果一台服务器出现故障或不可用，其他服务器可以介入。

What is AWS high availability & fault tolerance architecture?
什么是 AWS 高可用性和容错架构？
AWS has services, like S3, SQS, ELB, and SimpleDB, and infrastructure tools, like EC2 and EBS, to help you create a high availability and fault tolerant system in the cloud. The high-level services are designed to support HA and fault tolerance, while infrastructure tools come with features like snapshots and availability zones.
AWS 拥有 S3、SQS、ELB 和 SimpleDB 等服务以及 EC2 和 EBS 等基础设施工具，可帮助您在云中创建高可用性和容错系统。高级服务旨在支持 HA 和容错，而基础设施工具则具有快照和可用性区域等功能。

番外篇：系统复杂度的来源（高性能、高可用）

高性能：软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

单机复杂度

操作系统：

批处理（指令清单并进行处理）--》进程（独立的内存空间，CPU 时间分片，多进程间通信）

线程（进程内部的子任务，共享同一份进程数据。为了保证数据正确性，又发明了互斥锁机制）

多个 CPU 能够同时执行计算任务。

操作系统发展到现在，如果我们要完成一个高性能的软件系统，需要考虑如多进程、多线程、进程间通信、多线程并发等技术点，而且这些技术并不是最新的就是最好的，也不是非此即彼的选择。在做架构设计的时候，需要花费很大的精力来结合业务进行分析、判断、选择、组合，这个过程同样很复杂。举一个最简单的例子：Nginx 可以用多进程也可以用多线程，JBoss 采用的是多线程；Redis 采用的是单进程，Memcache 采用的是多线程，这些系统都实现了高性能，但内部实现差异却很大。

集群的复杂度

复杂的业务，单机的性能无论如何是无法支撑的，必须采用机器集群的方式来达到高性能。例如，支付宝和微信这种规模的业务系统，后台系统的机器数量都是万台级别的。通过大量机器来提升性能，并不仅仅是增加机器这么简单，让多台机器配合起来达到高性能的目的，是一个复杂的任务。

1. 任务分配

每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行。

当业务服务器增加数量较少时，除了需要增加业务服务器，还需要增加一个任务分配器，这个分配器可能是硬件网络设备（例如，F5、交换机等），可能是软件网络设备（例如，LVS），也可能是负载均衡软件（例如，Nginx、HAProxy）等等。选择合适的任务分配器也是一件复杂的事情，需要综合考虑性能、成本、可维护性、可用性等各方面的因素。

任务分配器和真正的业务服务器之间有连接和交互（即图中任务分配器到业务服务器的连接线），需要选择合适的连接方式，并且对连接进行管理。例如，连接建立、连接检测、连接中断后如何处理等。

任务分配器需要增加分配算法。例如，是采用轮询算法，还是按权重分配，又或者按照负载进行分配。如果按照服务器的负载进行分配，则业务服务器还要能够上报自己的状态给任务分配器。

当业务服务器增加数量较多时，除了需要增加业务服务器，任务分配器之外，任务分配器本身也需要扩展为多台机器，因为随着性能的增加，任务分配器本身又会成为性能瓶颈，当业务请求达到每秒 10 万次的时候，单台任务分配器也不够用了，

这个变化带来的复杂度就是需要将不同的用户分配到不同的任务分配器上（即图中的虚线“用户分配”部分），常见的方法包括 DNS 轮询、智能 DNS、CDN（Content Delivery Network，内容分发网络）、GSLB 设备（Global Server Load Balance，全局负载均衡）等。

任务分配器和业务服务器的连接从简单的“1 对多”（1 台任务分配器连接多台业务服务器）变成了“多对多”（多台任务分配器连接多台业务服务器）的网状结构。

机器数量从 3 台扩展到 30 台（一般任务分配器数量比业务服务器要少，这里我们假设业务服务器为 25 台，任务分配器为 5 台），状态管理、故障处理复杂度也大大增加。

上面这两个例子都是以业务处理为例，实际上“任务”涵盖的范围很广，可以指完整的业务处理，也可以单指某个具体的任务。例如，“存储”“运算”“缓存”等都可以作为一项任务，因此存储系统、运算系统、缓存系统都可以按照任务分配的方式来搭建架构。此外，“任务分配器”也并不一定只能是物理上。

2.任务分解

通过任务分配的方式，我们能够突破单台机器处理性能的瓶颈，通过增加更多的机器来满足业务的性能需求，但如果业务本身也越来越复杂，单纯只通过任务分配的方式来扩展性能，收益会越来越低。

把原来大一统但复杂的业务系统，拆分成小而简单但需要多个系统配合的业务系统。从业务的角度来看，任务分解既不会减少功能，也不会减少代码量（事实上代码量可能还会增加，因为从代码内部调用改为通过服务器之间的接口调用），那为何通过任务分解就能够提升性能呢？

主要有几方面的因素：

a.简单的系统更加容易做到高性能

系统的功能越简单，影响性能的点就越少，就更加容易进行有针对性的优化。而系统很复杂的情况下，首先是比较难以找到关键性能点，因为需要考虑和验证的点太多；其次是即使花费很大力气找到了，修改起来也不容易，因为可能将 A 关键性能点提升了，但却无意中将 B 点的性能降低了，整个系统的性能不但没有提升，还有可能会下降。

b.可以针对单个任务进行扩展

当各个逻辑任务分解到独立的子系统后，整个系统的性能瓶颈更加容易发现，而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升，不需要改动整个系统，风险会小很多。例如某系统如果用户数增长太快，注册登录子系统性能出现瓶颈的时候，只需要优化登录注册子系统的性能（可以是代码优化，也可以简单粗暴地加机器），其他子系统完全不需要改动。

既然将一个大一统的系统分解为多个子系统能够提升性能，那是不是划分得越细越好呢？其实不然，这样做性能不仅不会提升，反而还会下降，最主要的原因是如果系统拆分得太细，为了完成某个业务，系统间的调用次数会呈指数级别上升，而系统间的调用通道目前都是通过网络传输的方式，性能远比系统内的函数调用要低得多。

虽然系统拆分可能在某种程度上能提升业务处理性能，但提升性能也是有限的，因为最终决定业务处理性能的还是业务逻辑本身，业务逻辑本身没有发生大的变化下，理论上的性能是有一个上限的，系统拆分能够让性能逼近这个极限，但无法突破这个极限。因此，任务分解带来的性能收益是有一个度的，并不是任务分解越细越好，而对于架构设计来说，如何把握这个粒度就非常关键了。

二、研发规范层面

方案设计和编码规范

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

• 设计阶段
- • 规范好相关方案设计文档的模板和提纲，让团队内部保持统一，例如，制定《技术方案设计模板》【后面附录】、开发规范工具、研发流程规范等。
- • 方案设计后一定要进行评审，在我们团队中，新项目一定要评审，重构项目一定要评审，大的系统优化或者升级一定要评审，其他的一般研发工作量超过一周的建议要评审的。
• 编码阶段
- • 不要随便打日志
- • 要接入远程日志
- • 要能够分布式链路追踪
- • 代码编写完需要有一定的单测来保证代码的健壮性，同时也能保障我们后续调整逻辑或者优化的时候可以保证代码的稳定
- • 包括增量覆盖率、全量覆盖率，具体的覆盖率要达到多少可以根据团队内部的实际情况来定，在我们团队，定的规则是 50% 的覆盖率。
- • 工程的 layout 目录结构规范，团队内部保持统一，尽量简洁
- • 遵循团队内部的代码规范，一般公司都有对应语言的规范，如果没有则参考官方的规范，代码规范可以大大减少 bug 并且提高可用性。
- • 执行代码规范
- • 单测覆盖率
- • 日志规范
• 发布上线阶段，参考下面运维部署层面那一章节的灰度发布和接口测试相关说明

容量规划和评估

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

容量规划，是指我们系统在设计的时候，就要能够初步规划好我们的系统大致能够抗多少的量级，比如是十万还是百万级别的请求量，或者更多。不同的量级对应的系统架构的设计会完全不一样，尤其到了千万、亿级别的量级的时候，架构的设计会有很多的考量。当然这里需要注意的是，我们不需要一上来就设计出远超于我们当前业务真实流量的系统，要根据业务实际情况来设计。同时，容量规划还涉及到，我们系统上下游的各个模块、依赖的存储、依赖的三方服务，分别需要多少资源，需要有一个相对可以量化的数据出来。容量规划阶段，更多是要依靠自身和团队的经验，比如要了解我们的 log 的性能、redis 的性能、rpc 接口的性能、服务化框架的性能等等，然后根据各种组件的性能来综合评估自己设计的系统的整体性能情况。

容量评估和容量规划之后，我们还需要做一件事情，就是性能压测，最好是能够做到全链路压测。性能压测的目的是为了确保你的容量规划是准确的，比如我设计的这个系统，我规划的是能够抗千万级别的请求，那么实际上，真的能够抗住吗？这个在上线之前，首先要根据经验来判断，然后是一定要经过性能压测得出准确结论的。性能压测要关注的指标很多，但是重点要关注是两个指标，一个是 QPS、一个是响应耗时，要确保压测的结果符合预期。压测的步骤可以先分模块单独压测，最后如果情况允许，那么最好执行全链路压测。

QPS 预估（漏斗型）

QPS 预估（漏斗型），指的是一个真实的请求过来后，从接入层开始，分别经过了我们整个系统的哪些层级、哪些模块，然后每一个层级的 QPS 的量级分别有多少，从请求链路上来看，层级越往下，那么下游层级的量级应该会逐步减少的，因为每经过一个层级，都有可能会被各种条件过滤掉的一部分请求。比如说进入活动页后查看商品详情然后下单这个例子，首先进入活动页，所有的请求都会进入访问；然后只会有部分用户查询商品详情；最后查看商品详情的这些用户又只会有部分用户会下单，因此这里就会有一个漏斗，从上层模块到下层模块的量级一定是逐步减少的。

QPS 预估（漏斗型）就是需要我们按照请求的层面和模块来构建我们的预估漏斗模型，然后预估好每一个层级的量级，包括但不限于从服务、接口、分布式缓存等各个层面来预估，最后构成我们完整的 QPS 漏斗模型。

番外篇：Perplexity.ai 辅助写作：What is High Availability System architecture

什么是高可用系统架构？

High availability (HA) is a system's capability to provide services to end users without going down for a specified period of time[1][2][5]. HA architecture ensures that multiple components, modules, or services work together to maintain optimal performance, irrespective of peak-time loads[1]. This is achieved through the use of redundant hardware, data backup and recovery, automatic failover, and load balancing[2][3].

高可用性 (HA) 是系统在指定时间段内不停机的情况下向最终用户提供服务的能力[1][2][5]。HA 架构确保多个组件、模块或服务协同工作以保持最佳性能，而不管高峰时间负载如何[1]。这是通过使用冗余硬件、数据备份和恢复、自动故障转移和负载平衡来实现的[2][3]。

High availability clusters are groups of hosts that merge as a single system to prevent downtime[1]. If one server in a high availability cluster goes down, the mission-critical app is immediately transferred to another server in the cluster[1][2].

高可用性集群是合并为单个系统以防止停机的主机组 [1]。如果高可用性集群中的一台服务器出现故障，关键任务应用程序会立即转移到集群中的另一台服务器 [1][2]。

High availability is important for mission-critical systems as it minimizes or eliminates service disruptions due to hardware or software failures[5]. To achieve high availability, organizations should implement best practices such as using redundant hardware and ensuring all components meet the desired availability standard[3][4][5].

高可用性对于任务关键型系统很重要，因为它可以最大限度地减少或消除由于硬件或软件故障造成的服务中断 [5]。为实现高可用性，组织应实施最佳实践，例如使用冗余硬件并确保所有组件满足所需的可用性标准[3][4][5]。

high availability system components

高可用性系统组件

PERPLEXITY ：

A high availability (HA) system architecture is a set of components, modules, or services that work together to maintain optimal performance and prevent downtime[1][2][3][4]. This type of architecture typically includes redundant data, backup database servers, automatic failover, and load balancing[1]. It is often used for mission-critical applications that require 24/7 uptime[2].

高可用性 (HA) 系统架构是一组组件、模块或服务，它们协同工作以保持最佳性能并防止停机 [1][2][3][4]。这种类型的架构通常包括冗余数据、备份数据库服务器、自动故障转移和负载平衡[1]。它通常用于需要 24/7 正常运行时间的关键任务应用程序 [2]。

High availability clusters are a group of hosts that merge as a single system to prevent downtime[3]. If one server in the cluster goes down, the mission-critical app is immediately redirected to another server in the cluster[3]. To ensure optimal performance levels are maintained regardless of inevitable failures, businesses must have a backup plan in place should a service go down[4].

高可用性集群是一组主机，它们合并为一个系统以防止停机 [3]。如果集群中的一台服务器出现故障，关键任务应用程序将立即重定向到集群中的另一台服务器 [3]。为确保在不可避免的故障情况下保持最佳性能水平，企业必须制定备份计划以应对服务中断 [4]。

What is high availability architecture?
什么是高可用架构？

参考阅读：https://redis.com/blog/high-availability-architecture/

A high available architecture is when there are a number of different components, modules, or services that work together to maintain optimal performance, irrespective of peak-time loads.
高可用架构是指有许多不同的组件、模块或服务协同工作以保持最佳性能，而不管高峰时间负载如何。

In its purest sense, this system allows businesses to work continuously without failure over a given period of time. Many businesses can’t afford even a minute of downtime. Considering that data is the lifeblood of many businesses, even just a short period of downtime can be incredibly costly.
从最纯粹的意义上讲，该系统允许企业在给定的时间段内连续工作而不会出现故障。许多企业甚至无法承受一分钟的停机时间。考虑到数据是许多企业的生命线，即使是很短的停机时间也可能造成难以置信的代价。

In certain real-life scenarios, lives may depend on a database built for high availability. When a patient arrives in the emergency room, medical professionals need instant access to their medical health records to understand what treatment decisions are best. Any delay in accessing this information could have a devastating impact.
在某些现实生活场景中，生活可能取决于为高可用性而构建的数据库。当患者到达急诊室时，医疗专业人员需要即时访问他们的医疗健康记录以了解最佳治疗决策。访问此信息的任何延迟都可能产生毁灭性的影响。

Note: High availability is often measured in the percentage of time that a service is available to users. According to the Microsoft Network Developer Glossary, for a server to be considered “highly available”, it needs to achieve 99.999% network uptime.
注意：高可用性通常以服务对用户可用的时间百分比来衡量。根据 Microsoft Network Developer Glossary，要使服务器被视为“高可用”，它需要达到 99.999% 的网络正常运行时间。

What are high-availability clusters?
什么是高可用集群？

High availability clusters are a group of hosts that merge as a single system to prevent downtime. If one server in a high availability cluster goes down, the mission-critical app is immediately transferred to another server as soon as the fault has been detected.
高可用性集群是一组主机，它们合并为一个系统以防止停机。如果高可用性集群中的一台服务器出现故障，一旦检测到故障，关键任务应用程序会立即转移到另一台服务器。

No system is immune to failure, and high availability clusters ensure that optimal performance levels are maintained regardless of inevitable failures. As a result, these tend to be used for the most mission-critical applications, websites, and transaction processing systems.
任何系统都无法避免故障，而高可用性集群可确保在发生不可避免的故障时保持最佳性能水平。因此，这些往往用于最关键的应用程序、网站和交易处理系统。

How does high availability clustering work?
高可用性集群如何工作？

A high availability cluster will utilize multiple systems that are already integrated, so should a failure cause one system to fail, another can be efficiently leveraged to maintain the continuity of the service or application being used.
高可用性集群将利用多个已经集成的系统，因此如果故障导致一个系统出现故障，则可以有效地利用另一个系统来维持正在使用的服务或应用程序的连续性。

The high availability load balancing cluster plays a crucial role in preventing system failures. Having a load balancer in place essentially distributes traffic across different web nodes that are serving the same website or application users. This reduces the pressure on any one server, allowing each cluster to work more optimally while allowing traffic only to be sent to healthy servers.
高可用性负载均衡集群在防止系统故障方面起着至关重要的作用。拥有一个负载均衡器本质上是在为同一网站或应用程序用户提供服务的不同网络节点之间分配流量。这减少了任何一台服务器的压力，让每个集群更优化地工作，同时允许流量只被发送到健康的服务器。

High availability cluster concepts
高可用性集群概念

Active-Passive cluster 主动-被动集群

The active/passive cluster is made up of at least two nodes. As the name implies, not all of the nodes will be active. If one node is active, the second is a read-only on standby. The passive server acts as a backup and will be utilized should the active server fail to work.
主动/被动集群由至少两个节点组成。顾名思义，并非所有节点都将处于活动状态。如果一个节点处于活动状态，则第二个节点是只读的备用节点。无源服务器充当备份，并在活动服务器无法工作时使用。

Active-Active cluster 双活集群

This type of cluster typically uses at least two nodes that execute the same service at the same time. In an active-active cluster, both nodes act as primary nodes, meaning either can accept reads or writes. Should one node fail, the user will automatically be connected to the other to ensure continuity of service. Once the first node has been replaced, users will then be split between the two original nodes.
这种类型的集群通常使用至少两个同时执行相同服务的节点。在双活集群中，两个节点都充当主节点，这意味着任一节点都可以接受读取或写入。如果一个节点发生故障，用户将自动连接到另一个节点以确保服务的连续性。一旦第一个节点被替换，用户将在两个原始节点之间分配。

The overarching benefit of the active/active cluster is that it allows you to accomplish node-network balance. If server failure instances are detected a load balancer will transmit user requests to the servers that are readily available and then analyze node-network activity. The load balancer will then push traffic to the nodes that are capable of serving that traffic allowing for greater levels of fault tolerance
主动/主动集群的首要好处是它允许您实现节点网络平衡。如果检测到服务器故障实例，负载平衡器会将用户请求传输到随时可用的服务器，然后分析节点网络活动。然后，负载均衡器会将流量推送到能够为该流量提供服务的节点，从而实现更高级别的容错

This strategy follows a cyclical process, similar to the round-robin model, whereby users are spread randomly across available nodes, or conversely, may adhere to a weighing scheme where one node is prioritized over another based on a percentage.
该策略遵循一个循环过程，类似于循环模型，用户随机分布在可用节点上，或者相反，可能会遵循一种权重方案，其中一个节点根据百分比优先于另一个节点。

Shared-nothing vs. shared-disk clusters
无共享与共享磁盘集群

A general rule that’s followed in distributed computing is to avoid single points of failure at all costs. This requires resources to be actively replicated or replaceable, without a single factor being disrupted should the full service go down.
分布式计算遵循的一般规则是不惜一切代价避免单点故障。这需要资源被主动复制或替换，如果整个服务出现故障，任何一个因素都不会中断。

Imagine if you had fifty running nodes that were powered by one database. If one node fails, it will not have an impact on the persistent state of others, irrespective of the number of running nodes.
想象一下，如果您有五十个由一个数据库提供支持的运行节点。如果一个节点发生故障，它不会对其他节点的持久状态产生影响，与运行节点的数量无关。

But should the database fail, the entire cluster will go down, making the database a single point of failure? This is referred to as a shared disk cluster.
但是如果数据库出现故障，整个集群就会宕机，从而使数据库成为单点故障？这称为共享磁盘集群。

On the other hand, should each node maintain its database, a node failure will not impact the entire cluster. This is referred to as a shared nothing cluster.
另一方面，如果每个节点维护其数据库，则节点故障不会影响整个集群。这称为无共享集群。

Note: If you want to discover more about high availability clustering technology then make sure to watch this webinar. With over 20 years of experience in the software industry, George Carbonnel will unpack everything you need to know about how clustering technology with Redis Enterprise delivers high performance as well as high availability.
注意：如果您想了解有关高可用性集群技术的更多信息，请务必观看此网络研讨会。George Carbonnel 在软件行业拥有超过 20 年的经验，将解开您需要了解的有关 Redis Enterprise 集群技术如何提供高性能和高可用性的所有信息。

Requirements of a highly available architecture
高可用架构的要求

There are a number of different requirements that you’ll need to maximize durability and high availability. These include:
您需要满足许多不同的要求才能最大限度地提高耐用性和高可用性。这些包括：

Load balancing 负载均衡

Load balancing is crucial to any highly available architecture. Its primary function is to distribute traffic across backend servers to transmit data more efficiently as well as prevent server overloads. A prerequisite of any load balancing system is to identify what failover process should be carried out when there’s a node failure.
负载平衡对于任何高可用性架构都至关重要。它的主要功能是在后端服务器之间分配流量以更有效地传输数据并防止服务器过载。任何负载平衡系统的先决条件是确定在节点出现故障时应执行的故障转移过程。

Data scalability 数据可扩展性

The ability to scale databases or disk storage units must be taken into account by all highly available architectures. There are two solutions you can pick between to achieve scalability:
所有高可用性架构都必须考虑扩展数据库或磁盘存储单元的能力。您可以选择两种解决方案来实现可扩展性：

Utilizing the architecture’s main database and using replication or partitioning to make it highly available; or
利用架构的主数据库并使用复制或分区使其具有高可用性；或者
Ensuring that individual application instances are capable of maintaining their own storage of data
确保各个应用程序实例能够维护自己的数据存储

Geographical diversity 地理多样性

We live in a fast-paced digital world where being able to distribute highly available clusters across the globe is now mandatory. Doing so will ensure that if a natural disaster strikes a single location, the impact made will not hinder their ability to provide the service.
我们生活在一个快节奏的数字世界中，现在必须能够在全球范围内分发高可用性集群。这样做将确保如果自然灾害袭击一个地点，所造成的影响不会妨碍他们提供服务的能力。

Backup and recovery (disaster recovery)
备份与恢复（灾难恢复）

For all its consistency, highly available architectures will always be susceptible to some sort of malfunction that can disrupt service. Therefore, should a service go down, businesses must have a recovery strategy available to get the entire system running again as quickly as possible.
尽管具有一致性，但高可用性架构总是容易受到某种可能中断服务的故障的影响。因此，如果服务出现故障，企业必须有可用的恢复策略，以使整个系统尽快重新运行。

This is often referred to as disaster recovery – a set of policies and procedures designed to return a service to full functionality in the event of a disruptive event.
这通常被称为灾难恢复——一组旨在在发生中断事件时将服务恢复到完整功能的策略和程序。

How to measure high availability 如何衡量高可用性

High availability is often measured in the percentage of time that a service is available to users. This is done by dividing the total uptime by the system period, which is then multiplied by 100 to get a percentage. According to the Microsoft Network Developer Glossary, for a server to be considered “highly available”, it needs to achieve 99.999% network uptime.
高可用性通常以服务对用户可用的时间百分比来衡量。这是通过将总正常运行时间除以系统周期，然后乘以 100 得到一个百分比来完成的。根据 Microsoft Network Developer Glossary，要使服务器被视为“高可用”，它需要达到 99.999% 的网络正常运行时间。

Quite often the percentage availability is referred to as the number of nines in the digits. So four nines would be 99.99%.
可用性百分比通常指的是数字中 9 的个数。所以四个九就是 99.99%。

Note: 99.99% availability is considered the industry standard.
注意：99.99% 的可用性被认为是行业标准。

Best practices for high availability
高可用性的最佳实践

There are a number of steps you can take to maximize high availability, ranging from the number of components you have to check through to replacing failed servers. Here are some practices that you can use to achieve high availability.
您可以采取许多步骤来最大化高可用性，从必须检查的组件数量到更换故障服务器。以下是您可以用来实现高可用性的一些做法。

参考阅读：https://www.filecloud.com/blog/an-introduction-to-high-availability-architecture/

Achieve geographic redundancy 实现地理冗余

Geo-redundancy is a crucial line of defense against the outbreak of natural disasters that can lead to service failures. This practice involves deploying numerous servers across different geographical locations, thereby spreading the risk and allowing the architecture to fall back on a different server should a natural disaster strike one region.
地理冗余是防止可能导致服务故障的自然灾害爆发的重要防线。这种做法涉及在不同的地理位置部署大量服务器，从而分散风险并允许架构在自然灾害袭击一个地区时回退到不同的服务器上。

Note: You can easily achieve this with a database that has Active-Active Geo-Distribution.
注意：您可以使用具有 Active-Active Geo-Distribution 的数据库轻松实现此目的。

Use failover solutions 使用故障转移解决方案

High availability architectures usually involve numerous loosely coupled servers that provide failover capabilities. A failover is seen as a backup operational mode that is automatically utilized when the functions of a primary system go down.
高可用性架构通常涉及许多提供故障转移功能的松耦合服务器。故障转移被视为一种备份操作模式，当主系统的功能出现故障时会自动使用该模式。

Implement load balancers 实施负载均衡器

As mentioned previously, a load balancer will spread incoming traffic across different servers to mitigate the risk of any downtime. Be sure to configure your load balancer to utilize an algorithm that’s tailored to your needs to fully optimize this solution.
如前所述，负载均衡器会将传入流量分散到不同的服务器上，以降低任何停机的风险。请务必配置您的负载均衡器，以利用根据您的需求量身定制的算法来全面优化此解决方案。

Ensure that your data synchronization meets your Recovery Point Objective (RPO)
确保您的数据同步符合您的恢复点目标 (RPO)

RPO is a marker for the maximum amount of data you can lose without causing harm to your organization. This highlights the data-loss tolerance of your business as a whole and it tends to be measured in time units, e.g. 1 minute or 1 day.
RPO 是在不对组织造成损害的情况下可以丢失的最大数据量的标记。这突出了您的业务作为一个整体的数据丢失容忍度，并且往往以时间单位来衡量，例如1 分钟或 1 天。

Setting your RPO to less or equal to 60 seconds will help you maintain maximum availability. Doing so will ensure that if there is a primary source failure, you won’t lose more than 60 seconds worth of data.
将 RPO 设置为小于或等于 60 秒将帮助您保持最大可用性。这样做将确保在主源出现故障时，您不会丢失超过 60 秒的数据。

附录：《技术方案设计模板》

技术方案设计模板在每一章节的简单说明，用来帮助你理清每个章节大概要写什么内容

一，现状

现状，主要是用来描述当前这个业务(项目)的一些基本情况介绍和相关的背景。你的方案设计出来之后，是需要给你的 leader 或者团队其他成员进行评审或者查看，甚至是要给更高级别的人来评审。但是别人不可能都和你一样清楚你的项目，因此首先，你要把你项目的基本情况和背景都说清楚，让大家达成一个共识，站在同一个起点上，才能进行后面的方案评审和讨论。

业务背景

业务背景就是你这个业务（项目）的基本介绍，包括但不限于：

• 项目名称
• 业务描述

技术背景

技术背景就是你这个业务是基于什么样的技术背景下来构建的，我们的技术方案可能是从 0 到 1 来构建，也能是基于现有的方案来优化，但是不管是什么场景，一定都会存在相关的技术背景，因此包括但不限于：

• 现有技术积淀
• 现有架构描述
• 现有系统的整体容量

二，需求

需求，很重要！技术人员千万不要忽略需求，因为不管你的技术有多牛逼，都一定为需求服务的，不管这个需求是技术需求，还是业务需求，一定都是要为需求服务。而需求，就是你这个技术方案的起点，技术方案一切都是围绕需求来设计，当然，这个需求可以是当下的需求，也可以包含未来潜在的需求。

只有把需求介绍清楚之后，大家才能知道你方案设计里面的所有设计和对应的折中点是否可行，也才能比较好的去评审你的方案。

业务需求

业务需求就是你这个业务具体要做的事情，包括但不限于：

• 要改造的内容
• 要实现的新需求

业务痛点

• 涉及到的业务痛点有哪些

性能需求

我们做需求的时候，对于技术人员，不能只看业务需求，业务需求可能是项目管理人员，也可能是产品人员提出来的，他们只会重点关注业务的可行性，只会关注业务的逻辑。但是技术人员，要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点，比如我做一个秒杀活动，如果你不考虑性能，可能活动一上来，服务就挂掉了。性能需求包括但不限于：

• 预估系统平均容量
• 预估系统峰值容量
• 可伸缩性
• 其他的一些性能要求点，比如安全性等

三，方案描述

前面把现状和需求说清楚后，终于到了我们的重头戏，方案描述这里了。一般我们做方案，可能会有几个可选的方案，但是你不清楚哪个方案最合适，因此你需要把相关可能的方案都描述清楚，然后给出你认为的最合适的方案，然后让大家来评审和决策，看是否同意你的意见或者有其他更好的意见。

如果没有方案对比，那么可以省略掉这一章节

方案1

概述

一句话概括方案的亮点，比如说：高性能、可扩展、双写、主从分离、分库分表、扩容等。

详细说明

详细说明这里需要图文结合，包括但不限于架构图、流程图等。把你整个方案的架构和模块、细节流程都描述清楚

性能目标

性能一般来说可能包含以下部分：

• 日平均请求：一般来自产品人员的评估；
• 平均QPS：日平均请求除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；
• 峰值QPS：一般可以以QPS的2~4倍计算；

性能评估

给出方案的基准数据，并按性能需求评估需要使用的资源数量。

• 单机并发量
• 单机容量
• 按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)
• 伸缩方式

方案优缺点

列出方案的优缺点，优缺点要具有确定性，最好是通过量化的指标来说明

方案2

可选的另外一种方案，模板和上面一样。

方案对比

前面给出了多种可选的方案，那么这里就是进行一个简单的对比，然后给出你觉得最优的方案和原因，这就是你的决策。

有了你自己的决策（倾向）的方案后，接下来的设计就应该更多的偏向你倾向的方案去做设计和描述

四，线上方案

线上方案是对上面你更倾向的方案的更为细致的描述。

架构图

整体架构是如何，把架构图画上

关键设计点和设计折衷

把几个关键、重点的点的设计思想表述出来，用来确保你的方案的大体方向是 OK 的。

因为没有一个方案设计是最完美，方案设计都是逐步演进和优化的，方案设计是要最符合当前的背景的。因此，一定会有你设计的关键点和折衷点，这也就是前面为何要把项目的各种业务背景和技术背景都说清楚的原因。

业务流程

整体流程是如何，弄一个整体流程图、核心流程图出来，然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍

模块划分

有了业务流程，那么必然要针对这个业务流程的各个环节来划分模块，模块的划分需要考虑我们架构设计的一些原则，比如：架构分层、业务分模块、微服务化、高内聚低耦合等。然后把每个模块的功能点都说清楚

异常边界【重要】

异常边界是比较重要的，一般情况下，大部分人都能考虑到正常的处理流程，对于异常的边界考虑的比较少，但是线上出问题，大部分都是异常情况导致，因此这里非常重要！！！

我们可以通过一个 xmind 格式去整理相关的异常边界，这样有助于自己在实现的时候有足够的把控度，也便于别人去 review 你的方案和具体实现（如 coding）

异常边界需要考虑:

• 涉及到了哪些模块
• 涉及到了哪些流程
• 每个模块、流程出现了各种可能情况的处理是？
• 系统底层原因导致的异常的处理是？

统计、监控

线上运行的项目，一定需要有各种监控，除了公司内部的基建的监控外，我们可能还需要从业务内部实现自定义的一些业务监控和相关技术统计

灰度、回滚策略

• 如何灰度？
• 如何回滚？

容灾方案

容灾就是当出现 IDC 异常的情况下，怎么容灾，这个可以根据实际情况去考虑。

五，部署拓扑

线上部署拓扑如何，上下游是如何

六，风险评估

标识所选方案的风险，提出解决此风险发生时候的应对策略，比如：上线失败时的回滚策略。

潜在风险

• 相关的改动有哪些风险点
• 不兼容点？
• 当前设计方案目前存在哪些问题？
• 潜在有哪些问题

七，阶段规划【架构演进规划】

架构怎么演进

阶段如何规划

每个阶段该达成什么目标

第一阶段

第二阶段

第三阶段

八，工作量评估

工作量评估也是一个重要的环节，这里需要细化到每个模块、每个接口的设计分别需要多长时间，一定要同时包括开发时间、联调时间、测试时间。

参考阅读：技术方案模板。

三、应用服务层面

无状态和负载均衡设计

所谓的无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。

由于无状态应用，各实例之间不用考虑数据一致性问题，所以其高可用方案相对简单。主要手段是：

负载均衡
分布式 Session

1.负载均衡

负载均衡，顾名思义，主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上，以提高整体的负载处理能力。无状态应用的失效转移可以利用负载均衡来实现。

无状态的应用实现高可用架构十分简单，由于服务器不保存请求状态，那么所有服务器完全对等，在任意节点执行同样的请求，结果总是一致的。这种情况下，最简单的高可用方案就是使用负载均衡。

2.分布式 Session

应用服务器的高可用架构设计主要基于服务无状态这一特性。事实上，业务总是有状态的，如购物车记录用户的购买信息；用户的登录状态；最新发布的消息等等。

在分布式场景下，一个用户的 Session 如果只存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另一个服务器上，该服务器没有用户的 Session，就可能导致用户需要重新进行登录等操作。

为了解决分布式 Session 问题，常见的解决方案有：

粘性 session
应用服务器间的 session 复制共享
基于缓存的 session 共享 ✅

一般要做到系统的高可用，我们的应用服务的常规设计都是无状态的，这也就意味着，我们可以部署多个实例来提高我们系统的可用性，而这多个实例之间的流量分配，就需要依赖我们的负载均衡能力。无状态 + 负载均衡既可以让我们的系统提高并发能力，也可以提高我们系统的可用性。

如果我们的业务服务使用的是各种微服务框架来开发的，那么大概率在这个微服务框架里面就会包含了服务发现和负载均衡的能力。这是一整套流程，包括服务注册和发现、负载均衡、健康状态检查和自动剔除。当我们的任何一个服务实例出现故障后会被自动剔除掉，当我们有新增一个服务实例后会自动添加进来提供服务。

如果我们不是使用的微服务框架来开发的，那么就需要依赖负载均衡的代理服务，比如 LVS、Nginx 来帮我们实现负载均衡。

番外篇：软件系统架构设计中的无状态设计是什么？

Stateless design has a significant role in software system architecture design. It is a way to make systems simpler and easier to maintain by eliminating the need for the server to store information about each session[1]. Stateless design allows for easy horizontal scaling by adding more servers and load balancers[1]. This makes it easier to scale up or down as needed, without having to worry about maintaining state information.

无状态设计在软件系统架构设计中有着举足轻重的作用。这是一种通过消除服务器存储有关每个会话的信息的需要，来使系统更简单和更易于维护的方法[1]。无状态设计允许通过添加更多服务器和负载平衡器 [1] 轻松实现横向扩展。这使得按需扩展或缩减变得更容易，而不必担心维护状态信息。

Stateless design also eliminates the need for transactions to remember information from one request to another[1]. This means that each request is treated independently, without any context from previous requests. This makes it easier for systems to handle large numbers of requests simultaneously, as there is no need for the server to keep track of each individual request.

无状态设计还消除了事务记住从一个请求到另一个请求的信息的需要[1]。这意味着每个请求都是独立处理的，没有来自先前请求的任何上下文。这使得系统更容易同时处理大量请求，因为服务器不需要跟踪每个单独的请求。

Finally, stateless design also allows for pure functional programming, which is thread-safe and does not require any instance variables[1]. This makes it easier to create immutable objects that can be shared across multiple threads, improving performance.

最后，无状态设计还允许纯函数式编程，它是线程安全的并且不需要任何实例变量[1]。这使得创建可以跨多个线程共享的不可变对象变得更加容易，从而提高了性能。

The advantages of stateless design scalability include the ability to deploy services to any number of servers, less complexity due to no session synchronization logic, improved performance due to caching of service calls, seamless integration/implementation with HTTP protocols, and improved visibility as each request is its own resource[1][2].

无状态设计可扩展性的优点，包括能够将服务部署到任意数量的服务器、由于没有会话同步逻辑而降低了复杂性、由于服务调用的缓存而提高了性能、与 HTTP 协议的无缝集成/实现以及提高了每个请求的可见性是它自己的资源[1][2]。

Additionally, stateless applications are able to scale horizontally very easily compared to stateful applications due to the fact that infrastructure allows adding as many computing resources as needed[5]. Stateless applications also contain several microservices which can be easily scaled and decoupled from the infrastructure, reducing cost and boosting business productivity[5]. Dynamic and horizontal scaling are inbuilt features in stateless apps which ensure that the server doesn’t crash no matter how high the traffic spike gets on the app[5]. Therefore, stateless design scalability offers a variety of benefits for cloud-native applications that require an elastic and distributed environment[3][4][5].

此外，与有状态应用程序相比，无状态应用程序能够非常容易地水平扩展，因为基础设施允许根据需要添加尽可能多的计算资源[5]。无状态应用程序还包含多个微服务，这些微服务可以轻松扩展并与基础架构分离，从而降低成本并提高业务生产力 [5]。动态和水平缩放是无状态应用程序的内置功能，可确保无论应用程序的流量峰值有多高，服务器都不会崩溃 [5]。因此，无状态设计可扩展性为需要弹性和分布式环境的云原生应用程序提供了多种好处[3][4][5]。

弹性扩缩容设计

弹性扩缩容设计是应对突峰流量的非常有效的手段之一，同时也是保障我们服务可用性的必要手段。弹性扩缩容针对的是我们的无状态的应用服务而言的，因为服务是无状态的，因此可以随时根据请求量的大小来进行扩缩容，流量大就扩容来应对大量请求，流量小的时候就缩容减少资源占用。

怎么实现弹性扩缩容呢？现阶段都是云原生时代，大部分的公司都是采用容器化（K8s）部署，那么基于这个情况的话，弹性扩缩容就非常容易了，只需要配置好 K8s 的弹性条件就能自动根据 CPU 的使用率来实现。

如果不是容器化部署，是物理机部署的方式，那么要做到弹性扩缩容，必须要有一个公司内部的基础建设能力，能够在运营平台上针对服务的 CPU 或者 QPS 进行监控，如果超过一定的比例就自动扩缩容，和 K8s 的弹性原理是一样的，只是需要自行实现。

Perplexity AI：解释一下弹性扩缩容 K8s 部署的原理

Consise：

Elastic scaling is a method of autoscaling Kubernetes clusters to match current cluster utilization in order to manage costs[1]. This is done by dynamically scaling the number of nodes in the cluster. Kubernetes autoscaling helps optimize resource usage and costs by automatically scaling a cluster up and down in line with demand[2][3]. Best practices for making the most of an autoscaling strategy include using Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), and Cluster Autoscaler[4]. Additionally, there are 15 principles for designing and deploying cloud native applications on Kubernetes that can help with scalability, observability, and more[5].

弹性扩展是一种自动扩展 Kubernetes 集群以匹配当前集群利用率以管理成本的方法 [1]。这是通过动态扩展集群中的节点数量来完成的。Kubernetes 自动缩放通过根据需求自动缩放集群来帮助优化资源使用和成本[2][3]。充分利用自动缩放策略的最佳实践包括使用 Horizontal Pod Autoscaler (HPA)、Vertical Pod Autoscaler (VPA) 和 Cluster Autoscaler [4]。此外，还有 15 条原则可用于在 Kubernetes 上设计和部署云原生应用程序，这些原则有助于实现可扩展性、可观察性等[5]。

Detailed：

Elastic scaling is a process of automatically adjusting the number of resources allocated to an application or service in response to changes in demand. Kubernetes provides three methods for elastic scaling: Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), and Cluster Autoscaler[1][2][3].

弹性扩展是一种自动调整分配给应用程序或服务的资源数量以响应需求变化的过程。Kubernetes 提供了三种弹性伸缩方法：Horizontal Pod Autoscaler (HPA)、Vertical Pod Autoscaler (VPA) 和 Cluster Autoscaler[1][2][3]。

The Horizontal Pod Autoscaler (HPA) allows users to scale the number of running pods in a cluster based on metrics such as CPU utilization, memory usage, and custom metrics[1][2]. The Vertical Pod Autoscaler (VPA) adjusts the amount of resources allocated to each pod based on its current resource usage[2][3]. The Cluster Autoscaler dynamically adjusts the number of nodes in a cluster based on current utilization[1][2].

Horizontal Pod Autoscaler (HPA) 允许用户根据 CPU 利用率、内存使用率和自定义指标 [1][2] 等指标来扩展集群中正在运行的 Pod 的数量。Vertical Pod Autoscaler (VPA) 根据当前资源使用情况调整分配给每个 Pod 的资源量[2][3]。Cluster Autoscaler 根据当前利用率动态调整集群中的节点数 [1][2]。

Kubernetes deployment principles involve creating and managing deployments that are resilient, scalable, and secure. This can be achieved by using best practices such as setting up autoscaling, using rolling updates for deployments, and using namespaces for isolation[4]. Additionally, it is important to use appropriate strategies when deploying applications such as blue-green deployments or canary releases[4].

Kubernetes 部署原则涉及创建和管理具有弹性、可扩展性和安全性的部署。这可以通过使用最佳实践来实现，例如设置自动缩放、使用滚动更新进行部署以及使用命名空间进行隔离 [4]。此外，在部署应用程序时使用适当的策略很重要，例如蓝绿部署或金丝雀发布 [4]。

What is blue-green deployments 什么是蓝绿部署?

Blue-green deployments (also known as A/B deployments) are a change management strategy for releasing software code[3]. This approach involves having two identical environments, conventionally called blue and green, to do continuous, risk-free updates[1]. Kubernetes is an orchestration platform that is well-suited for blue-green deployments due to its ability to dynamically create the green environment[1].

蓝绿部署（也称为 A/B 部署）是一种用于发布软件代码的变更管理策略[3]。这种方法涉及两个相同的环境，通常称为蓝色和绿色，以进行连续、无风险的更新[1]。Kubernetes 是一个非常适合蓝绿部署的编排平台，因为它能够动态创建绿色环境[1]。

The process of blue-green deployment works by first deploying the new version of the application in the green environment and testing it for functionality and performance. Once the tests are successful, application traffic is routed from blue to green[3][4]. This allows organizations to deploy frequent updates while maintaining high quality and a smooth user experience[2].

蓝绿部署过程:

1.首先在绿色环境中部署新版本的应用程序并测试其功能和性能。

2.测试成功后，应用程序流量将从蓝色路由到绿色 [3][4]。

这使组织能够部署频繁的更新，同时保持高质量和流畅的用户体验[2]。

Blue-green deployments provide an easy way to roll back to a safe, working version in case something goes wrong. This reduces the risks inherent in experimenting in a production environment[2]. However, there are some challenges associated with this approach such as managing two deployments at once and managing the network[2][4]. To ensure successful blue-green deployments, it is important to follow best practices such as using containers for stand-alone environments and setting up services with selectors that route traffic between blue and green versions of applications[3][4].

蓝绿部署提供了一种简单的方法来回滚到安全、工作的版本，以防出现问题。这降低了在生产环境中进行试验的固有风险 [2]。但是，这种方法存在一些挑战，例如同时管理两个部署和管理网络 [2][4]。为确保成功的蓝绿部署，遵循最佳实践非常重要，例如在独立环境中使用容器，并使用选择器设置服务以在蓝绿版本的应用程序之间路由流量[3][4]。

What is Canary releases? 什么是金丝雀发布？

Canary releases are a software testing technique used to reduce the risk of introducing a new software version into production by gradually rolling out the change to a small subset of users before rolling it out to the entire platform/infrastructure[1][2][3]. This deployment method combines characteristics of other deployment options, creating an ideal modern release process[4][5].

金丝雀发布是一种软件测试技术，用于通过在将更改推广到整个平台/基础架构之前逐渐将更改推广到一小部分用户来降低将新软件版本引入生产的风险[1][2][3] ].这种部署方法结合了其他部署选项的特点，创建了理想的现代发布流程[4][5]。

异步解耦和削峰设计（消息队列）

要想我们的系统能够高可用，那么从架构层面来说，要做到分层、分模块来设计，而分层分模块之后，那么各个模块之间，还可以进行异步处理、解耦处理。目的是为了不相互影响，通过异步和解耦可以使我们的架构大大的提升可用性。

关于分层分模块的设计思想，可参考阅读：【软件架构思想系列】分层架构

架构层面的异步解耦的方式就是采用消息队列（比如常见的 Kafka），并且同时消息队列还有削峰的作用，这两者都可以提高我们的架构可用性：

• 异步解耦：采用消息队列之后，可以把同步的流程转换为异步的流程，消息生成者和消费者都只需要和消息队列进行交互，这样不仅做了异步处理，还讲消息生成者和消费者进行了隔离。异步处理的优势在于，不管消息的后续处理的业务服务是否 ok，只要消息队列还没满，那么就可以执行对外提供服务，而消费方则可以根据自身处理能力来消费消息后进行处理。解耦的优势在于，如果消费方异常，那么并不影响生产方，依然可以对外提供服务，消息消费者恢复后可以继续从消息队列里面消费数据后执行业务逻辑
• 削峰：采用消息队列之后，还可以做到削峰的作用，当并发较高的时候，甚至是流量突发的时候，只要消息生产者能够将消息写入到消息队列中，那么这个消息就不会丢，后续处理逻辑可以慢慢的去消息队列里面消费这些突发的流量数据。这样就不会因为有突发流量而把整个系统打垮。

Perplexity AI：what is message queue ? 什么是消息队列？

Message queue (MQ) software is used to handle asynchronous communication between different components of a system[3]. It provides a lightweight buffer which temporarily stores messages, and endpoints that allow software components to connect to the queue in order to send and receive messages[1][2].

消息队列（MQ）软件用于处理系统不同组件之间的异步通信[3]。它提供了一个临时存储消息的轻量级缓冲区，以及允许软件组件连接到队列以发送和接收消息的端点[1][2]。

The most popular open source message queue (MQ) software include IBM MQ, MuleSoft Anypoint Platform, IBM Cloud Pak for Integration, Apache Kafka, Azure Scheduler, Apache ActiveMQ, PubSub+ Event Broker, Amazon SQS and RabbitMQ[2][4]. These message queues provide features such as message priority, message queuing as a service on cloud servers or on-site networks, delivery acknowledgement and flexible routing to queues[3][5].

最流行的开源消息队列 (MQ) 软件包括 IBM MQ、MuleSoft Anypoint Platform、IBM Cloud Pak for Integration、Apache Kafka、Azure Scheduler、Apache ActiveMQ、PubSub+ Event Broker、Amazon SQS 和 RabbitMQ[2][4]。这些消息队列提供消息优先级、消息队列作为云服务器或现场网络上的服务、交付确认和灵活路由到队列等功能[3][5]。

Benefits of using message queue software include improved performance due to asynchronous communication between applications; simplified decoupling; scalability; reliability; and flexibility in terms of messaging protocols supported[3][5].

使用消息队列软件的好处包括由于应用程序之间的异步通信而提高了性能；简化解耦；可扩展性；可靠性;和支持的消息协议方面的灵活性[3][5]。

Message queue (MQ) architecture involves the configuration and use of multiple queue managers to enable application-to-application communication in microservice and serverless infrastructures[1][2][3].

消息队列 (MQ) 架构涉及多个队列管理器的配置和使用，以在微服务和无服务器基础架构中启用应用程序到应用程序的通信[1][2][3]。

The main parts of an MQ system include message queues, topics, and channels[4]. Testing messaging queues involves verifying that messages are transported correctly and that the messaging solution is compatible with enterprise architecture[5].

MQ 系统的主要部分包括消息队列、主题和通道[4]。测试消息队列涉及验证消息是否正确传输以及消息解决方案是否与企业架构兼容[5]。

故障和容错设计

任何服务，一定会存在失败的情况，不可能有 100% 的可用，服务在线上运行过程中，总会遇到各种各样意想不到的问题会让你的服务出现状况，因此业界来评价可用性 SLA 都是说多少个 9，比如 4 个 9(99.99%)的可用性。

为此，我们的设计建议遵循"design for failure"的设计原则，设计出一套可容错的系统，需要做到尽早返回、自动修复，细节如下

• 遵循 fail fast 原则，Fail fast 原则是说，当我们的主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，尽快返回错误，而不是等到出现负面影响才处理。
• 具备自我保护的能力。当我们依赖的其他服务出现问题的时候，要尽快的进行降级、兜底等各种异常保护措施，要避免出现连锁反应导致整个服务完全不可用。比如当我们依赖的数据存储出现问题，我们不能一直重试从而导致数据完全不可用。

Perplexity AI：怎样进行系统的故障和容错设计？

Fault tolerance is the property that enables a system to continue operating without interruption when one or more of its components fail[3]. Fault tolerant systems are designed to prevent disruptions arising from a single point of failure, ensuring high availability and business continuity[2].

容错是一种属性，当系统的一个或多个组件发生故障时，它能够使系统继续运行而不会中断 [3]。容错系统旨在防止单点故障引起的中断，确保高可用性和业务连续性 [2]。

There are various techniques for implementing fault tolerance in distributed systems, such as error detection, error recovery, and error masking[1]. To build a fault tolerant system, potential failures must be identified and counteractions designed[5]. Strategies such as using redundant nodes and fail-stop failures can help to achieve high reliability and resilience[5]. Additionally, load balancing and failover can be used to ensure that the system continues to operate even if one node fails[2].

在分布式系统中实现容错的技术有多种，例如错误检测、错误恢复和错误屏蔽[1]。要构建容错系统，必须识别潜在故障并设计应对措施[5]。使用冗余节点和 fail-stop 故障等策略可以帮助实现高可靠性和弹性 [5]。此外，负载平衡和故障转移可用于确保即使一个节点发生故障，系统也能继续运行[2]。

Fault tolerance is the property that enables a system to continue operating properly in the event of the failure of one or more faults within some of its components[1]. Fault tolerance techniques can be divided into three aspects: error detection, error recovery, and error masking[2]. Common fault tolerance techniques include acknowledgement, circuit breaker pattern, roll forward, roll back, active replication pattern, Byzantine fault tolerance, and error-tolerant design[2][3]. Replication based fault tolerance technique is often used for transient faults which disappear without any action taken to remedy them[3]. Fault tolerance systems are vital in distributed computing as they keep the system functioning even when there is a fault or failure[3].

容错性是使系统在其某些组件发生一个或多个故障时能够继续正常运行的属性[1]。容错技术可以分为三个方面：错误检测、错误恢复和错误屏蔽[2]。常见的容错技术包括确认、断路器模式、前滚、回滚、主动复制模式、拜占庭容错和容错设计[2][3]。基于复制的容错技术通常用于暂时性故障，这些故障在没有采取任何措施进行补救的情况下就消失了[3]。容错系统在分布式计算中至关重要，因为它们即使在出现故障时也能保持系统正常运行[3]。

过载保护设计（限流、熔断、降级）

系统无法高可用的一个重要原因就在于，我们的系统经常会有突发的流量过来，导致我们的服务超载运行。

这个时候，首先要做的当然是快速扩容，并且我们事先就要预留好一定的冗余。另外一个情况下，就算我们扩容了，但是还是会超载，比如超过了下游依赖的存储的最大容量、或者超过了下游依赖的三方服务的最大容量。

那么这个时候，我们就需要执行我们的过载保护策略了，主要包括限流、熔断、降级，过载保护是为了保证服务部分可用从而不至于整个服务完全不可用。

• 限流。限流是指对进入系统的请求进行限流处理，如果请求量超过了我们系统最大处理能力或者超过了我们指定的处理能力，那么直接拒绝请求，通过这种丢弃部分请求的方式可以保证整个系统有一定的可用性，从而不至于让整个系统完全不可用。怎么判别超过最大处理能力呢？一般就是针对 QPS 来判别，如果 QPS 超过阈值，那么就直接拒绝请求。
- • 限流有很多细节的策略，比如针对接口限流、针对服务限流、针对用户限流。
• 熔断。熔断，断路（开路）的价值在于限制故障影响范围。我们希望控制、减少或中断和故障系统之间的通信，从而降低故障系统的负载，有利于系统的恢复。一般我们的服务都会有很多下游依赖，如果下游依赖的服务出现问题，比如开始超时甚至响应非常慢的情况下，如果我们不做任何处理，那么会导致我们的整个请求都被卡住从而超时，那么我们的业务服务对外就无法提供任何正常的功能了。为此，熔断策略就可以解决这个问题，熔断就是当我们依赖的下游服务出现问题的时候，可以快速对其进行熔断（不发起请求），这样我们的业务服务至少可以提供部分功能。熔断的设计至少需要包括熔断请求判断机制算法、熔断恢复、熔断告警三部分。
• 降级。降级是指我们划分好系统的核心功能和非核心功能，然后当我们的系统超过最大处理能力之后，直接关闭掉非核心的功能，从而保障核心功能的可用。关闭掉非核心的功能后可以使我们的系统释放部分资源，从而可以有资源来处理核心功能。
• 熔断和降级这两个策略，看着比较像，字面的意思上来看都是要快速拒绝掉请求。但是他们是两个维度的设计，降级的目的是应对系统自身的故障，而熔断的目的是应对我们系统依赖的外部服务故障的情况。

Perplexity AI：怎样进行系统的过载保护设计？

System overload protection design is a safety mechanism intended to prevent or minimize damage that can occur from electrical malfunctions[1]. Overload protection is generally implemented using a fail-safe mechanism, or overload relay, which senses when something has gone wrong within the circuitry and cuts off power to an isolated section or the entire electrical system[1]. Thermal overload protection is also built into certain mechanical devices such as motors or engines to protect them from excessive current draw[1].

系统过载保护设计是一种安全机制，旨在防止或最大限度地减少电气故障可能造成的损害[1]。过载保护通常使用故障安全机制或过载继电器来实现，当电路出现问题时它会感应并切断隔离部分或整个电气系统的电源 [1]。某些机械设备（例如电动机或发动机）中也内置了热过载保护，以保护它们免受过大的电流消耗[1]。

Circuit breakers are commonly used for overload and overcurrent protection, and are rated in volts, amps, and interrupting capacity[2][3]. High-rupture capacity (HRC) fuses can interrupt currents up to 200,000 amps by using arc-quenching fillers such as silica sand[2]. Additionally, motor controllers are designed to safely start and stop a motor while providing overload protection[5].

断路器通常用于过载和过流保护，并以伏特、安培和中断容量为额定值[2][3]。高分断容量 (HRC) 保险丝可以通过使用硅砂等灭弧填料中断高达 200,000 安培的电流 [2]。此外，电机控制器旨在安全地启动和停止电机，同时提供过载保护[5]。

Perplexity AI：软件设计中的限流算法有哪些？

Rate limiting algorithms are used to limit the frequency of an operation from exceeding a defined limit in large-scale systems[1][3]. This is done to protect underlying services and resources, as well as to prevent users from brute forcing security intensive functionalities such as login and promo codes[1].

速率限制算法用于限制操作频率超过大型系统中定义的限制 [1] [3]。这样做是为了保护底层服务和资源，并防止用户暴力破解登录和促销代码等安全密集型功能[1]。

Common rate limiting algorithms include Leaky Bucket, Token Bucket, Fixed Window Counter, User Rate Limiting, and Server-based Rate Limiting[1]. These algorithms can be applied on parameters such as user or IP address[2].

常见的限速算法有漏桶、令牌桶、固定窗口计数器、用户限速和基于服务器的限速[1]。这些算法可以应用于用户或 IP 地址等参数 [2]。

When designing a rate limiter service, it is important to consider the use case and the criteria for rate limiting. For example, a rate limiter could be designed to limit API calls based on user[2][3]. Additionally, performance should be taken into account when designing a rate limiter service so that it does not add substantial latencies to the system[4].

在设计速率限制器服务时，重要的是要考虑用例和速率限制标准。例如，可以设计一个速率限制器来限制基于用户 [2][3] 的 API 调用。此外，在设计速率限制器服务时应考虑性能，以免给系统增加大量延迟[4]。

令牌桶算法 The token bucket algorithm

The token bucket algorithm is a technique used in packet-switched and telecommunications networks to check that data transmissions conform to defined limits on bandwidth and burstiness[1]. It works by adding tokens, which represent a unit of bytes or a single packet of predetermined size, to a fixed capacity bucket at a fixed rate[1]. When a packet arrives, the algorithm checks if there is any token in the bucket. If there is, one token is removed from the bucket and the packet is forwarded. If not, the packet is dropped[2][3].

令牌桶算法是一种用于分组交换和电信网络的技术，用于检查数据传输是否符合定义的带宽和突发性限制 [1]。它的工作原理是将表示字节单位或预定大小的单个数据包的令牌以固定速率添加到固定容量的桶中[1]。当数据包到达时，算法会检查桶中是否有令牌。如果存在，则从桶中移除一个令牌并转发数据包。否则，数据包将被丢弃 [2][3]。

The token bucket algorithm can be used for congestion control algorithms as it allows more traffic than the leaky bucket algorithm[2]. It can also be used for admission control by limiting the aggregate bandwidth of non-VoIP traffic entering a site, leaving some room for VoIP traffic[3]. The hierarchical token bucket algorithm can also be used to provide different levels of service to different groups of users[3][4].

令牌桶算法可用于拥塞控制算法，因为它比漏桶算法允许更多的流量[2]。它还可以通过限制进入站点的非 VoIP 流量的总带宽来用于准入控制，从而为 VoIP 流量留出一些空间 [3]。分层令牌桶算法也可以用来为不同的用户群提供不同级别的服务[3][4]。

高可用的服务总结

可复用的服务为业务产品提供基础公共服务，大型系统中这些服务通常都独立分布式部署，被具体应用远程调用。可复用的服务和应用一样，一般也是无状态的服务，因此，同样可以使用负载均衡的失效转移策略来实现高可用。

除此以外，还有以下手段来保证服务的高可用：

分级管理
超时重试
异步调用
过载保护
- 限流
- 降级
- 断路
幂等性设计

分级管理

将服务根据业务重要性进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。

在服务部署上进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至要部署在不同地域的数据中心。

超时重试

由于服务器宕机、线程死锁等原因，可能导致应用程序对服务端的调用失去响应。所以有必要引入超时机制，一旦调用超时，服务化框架抛出异常，应用程序根据服务调度策略，选择重试或请求转移到其他机器上。

Alibaba的《Java开发手册(黄山版)》：

【强制】调用远程操作必须有超时设置。

说明：类似于 HttpClient 的超时设置需要自己明确去设置 Timeout。根据经验表明，无数次的故障都是因为没有设置超时时间。

异步调用

对于需要即时响应的业务，应用在调用服务时可以通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。当然不是所有服务调用都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失；此外，对于那些必须确认服务调用才能继续下一步操作的应用也不适宜食用异步调用。

过载保护

过载保护的手段，一般有：限流、降级、熔断。

限流

降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。

常见的限流方式可以分为两类：基于请求限流和基于资源限流。

基于请求限流

基于请求限流指从外部访问的请求角度考虑限流，常见的方式有：限制总量、限制时间量。

限制总量的方式是限制某个指标的累积上限，常见的是限制当前系统服务的用户总量，例如某个直播间限制总用户数上限为 100 万，超过 100 万后新的用户无法进入；某个抢购活动商品数量只有 100 个，限制参与抢购的用户上限为 1 万个，1 万以后的用户直接拒绝。限制时间量指限制一段时间内某个指标的上限，例如，1 分钟内只允许 10000 个用户访问，每秒请求峰值最高为 10 万。

无论是限制总量还是限制时间量，共同的特点都是实现简单，但在实践中面临的主要问题是比较难以找到合适的阈值。

基于资源限流

基于请求限流是从系统外部考虑的，而基于资源限流是从系统内部考虑的，即：找到系统内部影响性能的关键资源，对其使用上限进行限制。常见的内部资源有：连接数、文件句柄、线程数、请求队列等。

基于资源限流相比基于请求限流能够更加有效地反映当前系统的压力，但实践中设计也面临两个主要的难点：如何确定关键资源，如何确定关键资源的阈值。

降级

降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。

在服务访问的高峰期，服务可能因为大量并发调用而性能下降，严重时可能会导致宕机。为了保证核心功能的正常运行，需要对服务进行降级。降级有两种手段：

拒绝服务 - 拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用。或者随机拒绝部分调用，节约资源，避免要死大家一起死的惨剧。

关闭服务 - 关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约资源。

熔断

熔断和降级是两个比较容易混淆的概念，因为单纯从名字上看好像都有禁止某个功能的意思，但其实内在含义是不同的，原因在于降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况。

熔断机制实现的关键是需要有一个统一的 API 调用层，由 API 调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了。

幂等性设计

服务调用失败后，调用方会将请求转发到其他服务器上，但是这个失败可能是虚假的失败。比如服务已经处理成功，但因为网络故障导致调用方没有收到应答，或等待超时。这种情况下，重新发起请求，可能会导致重复操作，如：向数据库写入两条记录。如果这个操作是比较敏感的交易操作，就会产生严重后果。

服务重复调用时无法避免的，但是只要能从业务实现上保证，重复调用和一次调用的处理结果一致，则业务就没有问题，这就是幂等性设计。

有些服务的业务天然具有幂等性，比如将用户性别设为男性，不管执行多少次，结果是一致的。但有些复杂的业务，要想保证幂等性，就需要根据全局性的 ID 去进行有效性验证，验证通过才能继续执行。

四、存储层面

在当前的互联网时代，应用服务基本都是无状态的，因此应用服务的高可用相对会比较简单，但是对于数据存储的高可用，相对来说，会复杂很多，因为数据是有状态的，那具体我们要怎么保障数据存储的高可用，我们来分析下。

存储层面的高可用方案的本质都是，通过通过数据冗余的方式来实现高可用，将数据复制到多个存储介质里面，可以有效的避免数据丢失，同时还可以提高并发能力，因为数据是有状态的，因此，这里会比服务的高可用要复杂很多，主要体现在如下几个方面

• 数据如何复制？
• 各个节点的职责是什么？
• 如何应对复制延迟？
• 如何应对复制中断？

常见的解决存储高可用的方案有两种：

集群存储和分布式存储。

业界大多是围绕这些来构建，或者是做相关衍生和扩展。

集群存储（集中式存储）

集群就是逻辑上处理同一任务的机器集合，可以属于同一机房，也可分属不同的机房。集群存储，就是把多台机器上的存储数据组合在一起对外形成一套统一的系统。集群存储适合业务存储量规模一般的场景，常规的业务数据存储一般都是集群存储方式就足够了。现在我们一般对于业务数据存储的使用，默认都是集群方式，比如 Redis、MySQL 等存储类型，一般中大型互联网公司，默认肯定都是集群存储的方式。

集群存储就是我们常说的 1 主多备或者 1 主多从的架构，写数据通过主机，读数据一般通过从机。集群存储主要需要考虑如下几个问题：

• 主机如何将数据复制给备机（从机）
- • 数据的写入都是通过主机，因此数据同步到备机（从机），就是要通过主机进行数据复制到备机（从机）。
- • 还需要考虑主备同步的时间延迟问题。
• 备机（从机）如何检测主机状态
• 主机故障后，备机（从机）怎么切换为主机
- • 主从架构中，如果主机故障，可直接将备机（从机）切换为主机

1，主备复制

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等。

主备架构中的“备机”主要还是起到一个备份作用，并不承担实际的业务读写操作，如果要把备机改为主机，需要人工操作。因此一般使用场景都是在一些内部的后台管理系统中使用。

2，主从复制

主从复制和主备复制虽然只有一字之差，但是两者是不一样的设计思路，“从”意思是“随从、仆从”，“备”的意思是备份。”从“ 的机制是要干活的，因此是承担数据的“读”操作的，一般就是主机负责读写操作，从机只负责读操作，不负责写操作。

3，主从切换

主备复制和主从复制方案存在两个共性的问题：

• 主机故障后，无法进行写操作。
• 如果主机无法恢复，需要人工指定新的主机角色。

主从切换（主备切换）就是为了解决这两个问题而产生的，具体的设计就是在原有方案的基础上增加“自动切换”的能力，当主机异常后，经过系统检测并且自动将备机或者从机切换为主机。这个是实际应用中比较多的一个方案之一，因为我们一定能够有机制保证主机异常后从机能够自动切换为主机。

4，主主复制

主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作，如果采取主主复制架构，必须保证数据能够双向复制。这个相对来说，要求较高。

分布式存储

集群指的是将几台服务器集中在一起，实现同一业务。而分布式是指将不同的业务分布在不同的地方，分布式中的每一个节点，都可以做集群。

分布式存储就是通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。分布式存储中的每台服务器都可以处理读写请求，因此不存在集中式存储中负责写的主机那样的角色。但在分布式存储中，必须有一个角色来负责执行数据分配算法，这个角色可以是独立的一台服务器，也可以是集群自己选举出的一台服务器。分布式存储适合非常大规模的数据存储，业务数据量巨大的场景可以采用这种方式。常见的分布式存储比如 Hadoop(HDFS)、HBase、Elasticsearch 等。

高可用的存储总结

对于绝大部分软件系统而言，数据都是最宝贵的虚拟资产，一旦丢失，可以说是毁灭性的打击。

保证存储高可用的主要手段是：数据备份和失效转移。

存储高可用架构的复杂性主要体现在：如何应对副本同步延迟和中断导致的数据一致性问题。

数据备份

数据备份是保证数据有多个副本，任意副本的丢失都不会导致数据的永久丢失。

冷备份 - 定期将数据复制到某种存储介质。
热备份
- 异步热备方式 - 异步热备方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作成功响应时，只写成功了一份，存储系统将会异步地写其他副本。
- 同步热备方式 - 同步热备方式是指多份数据副本的写入操作同步完成，即应用程序收到数据服务系统的写成功响应时，多份数据都已经写操作成功。但是当应用程序收到数据写操作失败的响应式，可能有部分副本或者全部副本都已经写入成功了（因为网络或者系统故障，无法返回操作成功的响应）。

失效转移

失效转移是保证任意一个副本不可访问时，可以快速切换访问其他副本，保证系统整体可用。

失效确认

判断服务器宕机的手段有两种：心跳检测和访问失败报告。

对于应用程序的访问失败报告，控制中心还需要再一次发送心跳检测进行确认，以免错误判断服务器宕机。因为一旦进行数据访问的失效转移，意味着数据存储多份副本不一致，需要进行后续一系列的复杂动作。

访问转移

确认某台数据服务器宕机后，就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器，当其中一台宕机后，应用程序根据配置直接切换到对等服务器上。如果存储不对等，就需要重新计算路由，选择存储服务器。

数据恢复

因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机时，就可能出现无法访问转移，数据永久丢失的情况。因此系统需要从健康的服务器复制数据，将数据副本数目恢复到设定值。

五、产品层面

产品层面的高可用架构解决方案，基本上就是指我们的兜底产品策略。降级/限流的策略，更多的是从后端的业务服务和架构上的设计来考虑相关解决方案。这里说的兜底策略，也可叫做柔性降级策略，更多则是通过产品层面上来考虑。

• 比如，当我们的页面获取不到数据的时候，或者无法访问的时候，要如何友好的告知用户，比如【稍后重试】之类的。
• 比如当我们的真实的页面无法访问的时候，那么需要产品提供一个默认页面，如果后端无法获取真实数据，那么直接渲染默认页面。
• 比如服务器需要停机维护，那么产品层面给一个停机页面，所有用户只会弹出这个停机页面，不会请求后端服务
• 比如抽奖商品给一个默认兜底商品
• ...

六、运维部署层面

开发阶段-灰度发布、接口测试设计

灰度发布、接口测试、接口拨测系列设计包括但不限于：

• 灰度发布，我们服务发布上线的时候，要有一个灰度的过程，先灰度 1-2 个服务实例，然后逐步放量观察，如果一切 ok，再逐步灰度，直到所有实例发布完毕
• 接口测试，每次服务发布上线的时候，服务提供的各种接口，都要有接口测试用例，接口测试用例跑过之后，服务才能发布上线，目的是为了查看我们对外提供的接口是否能够正常，避免服务发布上线后才发现有问题

灰度发布和接口测试，一般在大公司里面会有相关的 DevOps 流程来保证。

开发阶段-监控告警设计

监控告警的设计，在大公司来说，根本不是问题，因为一定会有比较专门一拨人去做这种基础能力的建设，会有对应的配套系统，业务开发的同学只需要配置或使用即可。那如果说公司内部没有相关基础建设，那么就需要自己分别来接入对应的系统了。

监控系统

一般在监控系统这方面的开源解决方案包括但不限于这些：

• ELK (Elasticsearch、Logstash、Kibana) 日志收集和分析
- • 我们的日志记录不能都本地存储，因为微服务化后，日志散落在很多机器上，因此必须要有一个远程日志记录的系统，ELK 是不二人选
• Prometheus 监控收集
- • 可以监控各种系统层面的指标，包括自定义的一些业务指标
• OpenTracing 分布式全链路追踪
- • 一个请求的上下游这么多服务，怎么能够把一个请求的上下游全部串起来，那么就要依靠 OpenTracing，可以把一个请求下的所有链路都串起来并且有详细的记录
• OpenTelemetry 可观测系统标准
- • 最新的标准，大一统，集合了跟踪数据（Traces），指标数据（Metrics），日志数据（Logs）来观测分布式系统状态的能力

我们会依托开源系统进行自建或者扩展，甚至直接使用都行，然后我们的监控的指标一般会包括：

• 基础设施层的监控：主要是针对网络、交换机、路由器等低层基础设备，这些设备如果出现问题，那么依托其运行的业务服务肯定就无法稳定的提供服务，我们常见的核心监控指标包括网络流量(入和出)、网络丢包情况、网络连接数等。
• 操作系统层的监控：这里需要包含物理机和容器。常见的核心指标监控包括 CPU 使用率、内存占用率、磁盘 IO 和网络带宽等。
• 应用服务层的监控：这里的指标会比较多，核心的比如主调请求量、被调请求量、接口成功率、接口失败率、响应时间（平均值、P99、P95 等）等。
• 业务内部的自定义监控：每个业务服务自己的一些自定义的监控指标。比如电商系统这里的：浏览、支付、发货等各种情况的业务指标
• 端用户层的监控：前面的监控更多的都是内部系统层面的，但是用户真正访问到页面，中间还有外网的情况，用户真正获取到数据的耗时、打开页面的耗时等这些信息也是非常重要的，但是这个一般就是需要客户端或者前端去进行统计了。

告警系统

这些系统接入完了之后，还只是做到监控和统计，当出现问题的时候，还需要进行实时告警，因此还要有一个实时告警系统，如果没有实时报警，系统运行异常后我们就无法快速感知，这样就无法快速处理，就会给我们的业务带来重大故障和灾难。告警设计需要包括：

• 实时性：实现秒级监控；
• 全面性：覆盖所有系统业务；
• 实用性：预警分为多个级别，监控人员可以方便实用地根据预警严重程度做出精确的决策；
• 多样性：预警方式提供推拉模式，包括短信，邮件，可视化界面，方便监控人员及时发现问题

开发阶段：安全性、防攻击设计

安全性、防攻击设计的目的是为了防刷、防黑产、防黑客，避免被外部恶意攻击，这个一般有几个策略：

• 在公司级别的流量入口做好统一的防刷和鉴权的能力，比如，在统一接入层做好封装
• 在业务服务内部，做好相关的业务鉴权，比如登录态信息、比如增加业务鉴权的逻辑

部署阶段：多机房部署（容灾设计）

一般的高可用策略，都是针对一个机房内来服务层面来设计的，但是如果整个机房都不可用了，比如地震、火灾、光纤挖断等。。。。那么这个情况怎么办？这就需要我们的服务和存储都能够进行容灾了，容灾的一个常见方案就是多机房部署了。

• 服务的多机房部署，这个比较容易，因为我们的服务都是无状态的，因此只要名字服务能够发现不同机房的服务，就可以实现调用，这里需要注意的是名字服务（或者说负载均衡服务）要能够有就近访问的能力。
• 存储的多机房部署，这个会比较难搞一点，因为存储是有状态的，部署在不同的机房就涉及到存储的同步和复制问题。

条件不允许的情况下，我们保证多机房部署业务服务就可以了。

线上运行阶段：故障演练（混沌实验）

故障演练在大公司是一个常见的手段；在业界，Netflix 早在 2010 年就构建了混沌实验工具 Chaos Monkey，混沌实验工程对于提升复杂分布式系统的健壮性和可靠性发挥了重要作用。

简单的故障演练就是模拟机房断电、断网、服务挂掉等场景，然后看我们的整个系统运行是否正常。系统的就要参考混沌实验工程来进行详细的规划和设计，这个是一个相对比较大的工程，效果挺好，但是需要有大量人力去开发这种基础建设。

线上运行阶段：接口拨测系列设计

接口拨测，和巡检类似，就是服务上线后，每隔一个固定时间（比如 5s）调用后端的各种接口，如果接口异常则进行告警

针对接口拨测，一般也会有相关配套设施来提供相关的能力去实现，如果没有提供，那么我们可以自己写一个接口拨测（巡检）的服务，定期去调用重要的接口。

高可用运维部署总结：

异地多活

异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、活跃的意思。

异地多活架构可以分为同城异区、跨城异地、跨国异地。

异地多活架构的代价：

系统复杂度会发生质的变化，需要设计复杂的异地多活架构。
成本会上升，毕竟要多在一个或者多个机房搭建独立的一套业务系统。

异地多活的设计原则：

保证核心业务的异地多活
保证核心数据最终一致性
采用多种手段同步数据
只保证绝大部分用户的异地多活

异地多活设计步骤：

业务分级 - 常见的分级标准有：
- 流量大的业务
- 核心业务
- 盈利业务
数据分类 - 常见的数据分析维度有：
- 数据量
- 唯一性
- 实时性
- 可丢实性
- 可恢复性
数据同步 - 常见的数据同步方案
- 存储系统同步
- 消息队列同步
- 重复生成
异常处理 - 常见异常处理措施：
- 多通道同步
- 同步和访问结合
- 日志记录
- 用户补偿

发布流程

高可用的软件质量保证的手段：

自动化测试
预发布验证
代码控制
自动化发布
灰度发布

系统监控

不允许没有监控的系统上线。

监控数据采集
- 服务端日志收集 - Apache、Nginx 等几乎所有 Web 服务器都具备日志记录功能，只要开启日志记录即可。如果是服务器比较多，需要集中采集日志，通常会使用 Elastic 来进行收集。
- 客户端日志收集 - 利用页面嵌入专门的 JavaScript 脚本可以收集用户真实的操作行为。
- 日志分析 - 可以利用 ElasticSearch 做语义分析及搜索；利用实时计算框架 Storm、Flink 等开发日志统计与分析工具。
- 用户行为日志收集
- 服务器性能监控 - 收集服务器性能指标，如系统负载、内存占用、CPU 占用、磁盘 IO、网络 IO 等。常用的监控工具有：Apache SkyWalking (opens new window)、Pinpoint (opens new window)等。
- 运行数据报告 - 应该监控一些与具体业务场景相关的技术和业务指标，如：缓存命中率、平均响应时延、TPS、QPS 等。
监控管理
- 优雅降级是为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分资源，以保证核心功能的优先访问。
- 系统在监控管理基础之上实现自动优雅降级，是柔性架构的理想状态。
- 系统报警 - 设置阈值。当达到阈值，及时触发告警（短信、邮件、通信工具均可），通过及时判断状况，防患于未然。
- 失效转移 - 监控系统可以在发现故障的情况下主动通知应用进行失效转移。
- 自动优雅降级