美团2面：5个9高可用99.999%，如何实现？

说在前面

在40岁老架构师尼恩的读者社区(50+)中，最近有小伙伴拿到了一线互联网企业如网易、有赞、希音、百度、网易、滴滴的面试资格，遇到一几个很重要的面试题：

问题1：你们系统，高可用怎么实现？

问题2： 4个9高可用99.99%，如何实现？

注意，最近一个小伙伴美团2面，又遇到了这个问题： 5个9高可用99.999%，如何实现？

尼恩提示，高可用的问题，是架构的核心知识，又是线上的重点难题。

所以，这里尼恩给大家做一下系统化、体系化的线程池梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的《尼恩Java面试宝典》V63版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

最新《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公号【技术自由圈】获取

文章目录

- 说在前面
- 架构设计的3高原则
- 3个9的架构--通用架构
- - 高可用SLB 组件介绍
  - 什么是多可用区？
  - 主备可用区列表
- 4个9的高可用架构—同城容灾
- 5个9的高可用架构—异地容灾
- - 虚拟专用网络（VPC）进行实现不同地域互通
  - 参考案例：阿里云关系型数据库RDS 高可用介绍
- 异地多活数据一致性：DTS组件
- 说在最后
- 参考文献
- 推荐阅读

架构设计的3高原则

现如今，开发一个软件系统，对其要求越来越高，如果你了解一些「架构设计」的要求，就知道一个好的软件架构应该遵循以下 3 个原则：

高性能
高并发
高可用

高性能意味着系统拥有更大流量的处理能力，更低的响应延迟。

例如 1 秒可处理 10W 并发请求，接口响应时间 5 ms 等等。

高并发表示系统在迭代新功能时，能以最小的代价去扩展，系统遇到流量压力时，可以在不改动代码的前提下，去扩容系统。

高可用通常用 2 个指标来衡量：

平均故障间隔 MTBF（Mean Time Between Failure）：表示两次故障的间隔时间，也就是系统「正常运行」的平均时间，这个时间越长，说明系统稳定性越高
故障恢复时间 MTTR（Mean Time To Repair）：表示系统发生故障后「恢复的时间」，这个值越小，故障对用户的影响越小

可用性与这两者的关系：

可用性（Availability）= MTBF / (MTBF + MTTR) * 100%

这个公式得出的结果是一个「比例」，通常我们会用「N 个 9」来描述一个系统的可用性。

从这张图你可以看到，要想达到 4 个 9 以上的可用性，一年的不可以时间为 52分钟，平均每天故障时间必须控制在 10 秒以内。

系统发生故障其实是不可避免的，尤其是规模越大的系统，发生问题的概率也越大。

3个9的架构–通用架构

在阿里云平台上，对于中小型企业，业务量不是特别大，对异地容灾要求不是特别强烈，

则可采用以下高可用方案（如下图：图六），

可以在同一地域下选择购买云产品。

建议在VPC网络环境下，选择同一可用区或者同地域不同可用区的云产品。

同时建议ECS服务器至少两台，避免单点故障，在前端购买SLB，提供负载功能，这样当后端ECS资源使用紧张时可以直接横向扩展，对业务无影响。

另外，数据库业务尽量不要和应用服务部署在同一台ECS上。

防止不同服务之间资源抢占，同时方便日常管理和后期扩容。数据库服务器推荐直接购买RDS产品，数据安全有保障，同时也不需要花太多精力去运维管理。

高可用SLB 组件介绍

阿里云SLB组件使用开源软件LVS＋keeplived实现4层的负载均衡。

7层采用淘宝的Tengine实现7层的负载均衡。

所有负载均衡均采用集群部署，集群之间实时会话同步，以消除服务器单点，提升冗余，保证服务稳定。在各个地域采用多物理机房部署，实现同城容灾。

SLB在整体设计上让其可用性高达99.99%。

且能够根据应用负载进行弹性扩容，在任意一台SLB故障或流量波动等情况下都能做到不中断对外服务。

什么是多可用区？

云产品的可用区指的是一套独立的基础设施，不同的可用区之间基础设施（网络，电力和空调等）相互独立，即一个可用区出现基础设施故障不影响另外一个可用区。

为了向广大用户提供更加稳定可靠的负载均衡服务，阿里云负载均衡已在各地域（Region）部署了多可用区以实现同地域下的跨机房。

当主可用区的机房故障或不可用时，负载均衡仍然有能力在非常短的时间内（约30秒）切换到另外一个备可用区的机房并恢复服务的能力；当主可用区恢复时，负载均衡同样会自动切换到主可用区的机房提供服务。

关于负载均衡主备可用区，请注意：

SLB支持跨可用区挂载后端ECS，即只要ECS和SLB实例在同一个地域即可。SLB可以同时将流量分发至不同可用区的ECS上。
正常情况下，备可用区的SLB实例处于待机状态。您不可以手动切换SLB实例的主备工作状态，只有当阿里云检测到整个可用区不可用时如如机房整体断电、机房出口光缆中断等，负载均衡才会切换到备可用区。而并非某个实例出现故障，就切换到备可用区。
SLB和ECS是不同的集群。可用区A的SLB不可用时，ECS并不一定不可用，因此如果仅因为SLB集群故障导致的SLB主备倒换，备可用区的SLB依然可以将流量分发至不同可用区的ECS。但当整个可用区的所有集群断电或光缆中断时，那么可用区的所有服务（包括但不限于SLB、ECS等）就都无法正常工作了。

主备可用区列表

下表列举了阿里云各地域的主备可用区，您也可以通过DescribeZones接口查询可用的主备可用区。

下表列举了各地域的主备可用区，您也可以通过DescribeZones接口查询可用的主备可用区。

4个9的高可用架构—同城容灾

对中大型用户来说，希望业务系统要求具备同城容灾的能力，可以考虑在同城不同可用区之间对原有应用架构做一套完整的备份。

如果某个可以去出现像IDC机房断电或者火灾等故障时，可以通过前端切换DNS来及时恢复业务。

如下图：

5个9的高可用架构—异地容灾

对于一些大型企业在业务安全全性、服务可用性和数据可靠性方面既要求具备同城容灾又要求具备异地容灾时，可以采用这种容灾架构方式既可以解决单机房故障也可以应对像地震等灾难性故障。

不同地域之间可以采用阿里云的高速通道进行私网通信，保障数据库之间的数据实时同步，将数据传输延迟降到最低。

故障发生时可以通过前端DNS实现秒级切换，及时恢复业务。

如下图：

虚拟专用网络（VPC）进行实现不同地域互通

当ECS位于不同地域时，如何实现它们之间的内网互通呢？

首先，ECS之间的内网互通可以通过虚拟专用网络（VPC）进行实现。

VPC是阿里云提供的一种高度可定制化的网络隔离环境，用户可以在VPC内创建自己的私有网络，并通过VPC内网连接不同地域的ECS和RDS实例。

其次，用户可以通过VPC间对等连接方式实现地域之间的内网互通。通过创建对等连接，不同地域的VPC可以直接通信，从而使得位于不同地域的ECS和RDS实例能够通过内网进行互访。对等连接提供了低延迟、高带宽的网络通信，保障了数据的安全和速度。

除了VPC对等连接，用户还可以选择使用阿里云的内网专线接入（VBR）服务。通过VBR，用户可以自建专线连接不同地域的私有网络，实现ECS和RDS之间的内网互通。这种方式适用于需要大量数据传输或对网络可靠性有更高要求的场景。

另外，为了加强内网互通的安全性，用户可以使用安全组和访问控制列表（ACL）进行网络访问控制。

安全组可以定义入站和出站规则，控制对ECS和RDS的访问权限；ACL可以根据源和目标IP地址、协议及端口号等信息，精细控制子网和VPC之间的流量。

总的来说，ECS和RDS位于不同地域时，可以通过VPC的对等连接或者内网专线接入等方式实现内网互通。这些方法都提供了安全可靠的云上网络环境，满足了用户在分布式架构中对内网通信的需求。

注意跨地域的延迟

异地多活面临的主要挑战是网络延迟，以北京到上海 1468 公里，即使是光速传输，一个来回也需要接近10ms，在实际测试的过程中，发现上海到北京的网络延迟，一般是 30 ms。

参考案例：阿里云关系型数据库RDS 高可用介绍

阿里云关系型数据库（简称RDS）：是一种稳定可靠、可弹性伸缩的在线数据库服务。

RDS默认采用主备架构（备用实例正常情况下对用户不可见），两个实例位于不同服务器，自动同步数据。主实例不可用时，系统会自动将数据库连接切换至备用实例。切换是分钟级别，而且不需要人工介入，全部由系统自动完成，应用系统也无需任何变更。这种架构足以满足90% 用户的高可用需求。

如下图：

用户如果对系统可用性有更高的要求，希望可以做到机房容灾，

阿里云RDS可以选择购买多可用区RDS，多可用区是在单可用区的级别上，将同一地域的多个单可用区组合成的物理区域。

相对于单可用区RDS实例，多可用区RDS例可以承受更高级别的灾难，如下图：

RDS同城容灾架构

图四：RDS同城容灾架构

除了同城容灾之外，对于数据可靠性有强需求用户，比如是有监管需求的金融业务场景，RDS提供异地灾备实例，帮助用户提升数据可靠性。

RDS通过数据传输服务（DTS）实现主实例和异地灾备实例之间的实时同步。

主实例和灾备实例均搭建主备高可用架构，当主实例所在区域发生突发性自然灾害等状况，主节点（Master）和备节点（Slave）均无法连接时，可将异地灾备实例切换为主实例，在应用端修改数据库链接地址后，即可快速恢复应用的业务访问。

如下图：

图：RDS异地容灾架构

异地多活数据一致性：DTS组件

异地多活架构中，为了支持业务流量在各个地域之间的灵活切换，必须解决各个业务中心之间的数据同步问题。

阿里云数据传输服务DTS支持RDS实例之间的双向同步，实现业务中心之间的数据同步，保证数据全局一致，从而实现异地多活技术架构的快速复制。

数据传输服务DTS从2013年起，已连续4年平稳支撑了阿里巴巴异地多活(3个业务中心)底层的全局数据同步。

自2014年在阿里云为用户提供服务以来，DTS已经为上万用户提供可靠、稳定的数据流服务。

DTS支持异地多活架构中数据层之间的数据同步，实现数据全局一致。下面是一个简单的异地多活业务架构图：

如上图所示，业务按照某个维度将流量切分到各个业务中心(亦称单元)。

切分维度的选择要遵循如下原则：

(1) 拆分后，需要实现业务的单点写。例如按照会员切分，那么同一个会员的访问只能在某个业务中心单点写。

(2) 拆分维度要能够尽量保证业务在单元内封闭，即所有的业务请求都能够在单元内完成，以减少跨地域的访问调用。

对于用户分布比较广的业务，可以根据用户分布进行业务中心部署区域的选择。

例如国际化业务，可以选择中国、欧洲、北美等多点进行业务中心的部署，区域附近的用户的业务请求直接落在就近区域，以最大程度降低用户访问延迟，从而有效提升用户体验。

当流量切分到各个单元后，各个单元的数据层均会有数据写入，通过DTS进行数据层的数据双向同步，实现数据全局一致。当某个业务中心(单元)出现故障时，可以修改流量切分规则将流量秒级切换到其他单元，从而有效得保证了业务的持续可用，完美得避免了故障造成的经济损失及对公司品牌的影响。

说在最后

高可用相关面试题，是非常常见的面试题。以上的内容，如果大家能对答如流，如数家珍，基本上面试官会被你震惊到、吸引到。

最终，让面试官爱到 “不能自已、口水直流”。offer，也就来了。

学习过程中，如果有啥问题，大家可以来找 40岁老架构师尼恩交流。

参考文献

https://zhuanlan.zhihu.com/p/549472160

https://zhuanlan.zhihu.com/p/96917394