简述异地多活方案以及腾讯云实践

背景前言

为了保障系统可用性， 我们通常会为了应对故障将组件或数据做冗余。常见的类型包括: 变更故障、硬件故障、断电断网、自然灾害， 发生的频率一次降低。

部分系统对可用性要求极高， 为了应对上述即使可能性非常低的故障， 我们需要从容灾层面去考虑这些情况。

本文从常见的容灾方案和容灾架构入手介绍， 结合腾讯云多可用区容灾方案进行示例讲解。

系统与数据容灾架构

衡量容灾能力

评价容灾能力主要是RPO和RTO两个指标。

• RPO : 应发生故障时能忍受数据丢失的最大程度。系统越重要，要求 RPO 越小。 - 如果做数据备份，RPO越小意味着数据的备份频率更高，比如一般的系统可能一天备份一次，非常重要的系统可能一小时备份一次； - 如果做数据同步，RPO越小意味着要求数据同步链路的可靠性更高或延迟更低，对整个生产环境和网络的压力越大，需要的成本也更高。
• RTO: 应用从出现故障到故障恢复能接受的最大时间。系统越重要，要求 RTO 越小。

国家标准化管理委员会发布的容灾恢复RTO/RPO各等级对应关系如下:

我们可以看到最严格的6级标准 RPO 为0， 意味系统不允许丢失数据(很多大型项目也都有着这个要求)

容灾分层

image.png

相对接入层、应用层容灾而言，数据层的容灾相对比较复杂，实现起来难度大一些。 下面我们主要阐述的也是数据层的容灾。

主流容灾架构

同城灾备

同一个城市至少部署两个机房，仅主机房对外提供服务， 备机房平时不提供服务能力，主要作为主机房的备份，主备之间数据采用单向同步的形式。

undefined(https://iwiki.woa.com/tencent/api/attachments/s3/url?attachmentid=68288undefined(https://km.woa.com/gkm/api/img/cos-file-url?url=https%3A%2F%2Fkm-pro-1258638997.cos.ap-guangzhou.myqcloud.com%2Ffiles%2Fphotos%2Fpictures%2F202208%2F1661740963-7135-630c27a3ae350-387876.png&is_redirect=1

优点: 部署简单，将同一套架构完全复制到另外机房即可，数据做单向同步，对业务的改造极少。

缺点: 备数据中心存在资源浪费的情况；关键时刻不敢切流，容易出现版本、参数、操作系统不一致等情况

同城双活

两个机房同时对外提供服务。为了数据的一致性，所有写操作都会放在主数据中心，因此两个数据中心的距离要求小于50km，RT小于2ms~6ms。如果请求落在备数据中心，则涉及到跨机房写操作(备机房应用写主数据中心)。如果跨机房的 RT 非常大，数据请求在主、备数据中心的性能差异也会非常大，无法提供很好的用户体验。架构上数据采用单向同步方式。

image.png

优点： 解决了备数据中心资源浪费的问题，并且因为日常保持提供服务状态，出现故障时可以随时切换，切换前只需要做数据中心的主备切换， RTO为分钟级。

缺点: 灾备局限在同城区域内，距离受限， 城市级灾难容易不可用。 对于延时敏感的系统跨机房写会给用户带来不好的体验

伪异地双活(应用层双活)

这种架构与同城双活有很多相似之处，唯一的区别在于备数据中心的读写进行了分离，读操作直接读备数据中心，而写操作为了保证数据一致性，将打到主数据中心的数据库上。要求两个数据中心距离小于100km，RT小于6ms。如果两个机房的距离过远，请求在两个机房之间的性能表现差异会很大。此架构比较适合读多写少的系统。

image.png

优点: 具备了一定程度的地域级别容灾能力，虽然架构要求距离小于100km，但是对于大部分地级城市而言，100km已经能够覆盖两个地级城市，RTO 只需分钟级别。

缺点: 业务系统需要能够接受一定的跨机房网络延；业务需要进行一定程度的改造, 将操作分位读操作和写操作两类；容灾距离依然受到非常大的限制(主要受限于跨机房写)

异地双(多)活

异地双活可以接受两个机房之间的距离大于1000km，RT 超过 10ms。为了解决此前两个机房中的性能差异，我们使用了单元化的解决方案。单元化指请求落到某单元后，所有请求操作都在单元内闭环处理，避免涉及跨机房操作。因而不管请求打到哪个机房都能保证基本一致的处理效率，也能保证良好的用户体验。为了实现单元化，要求各个机房之间数据双向同步

image.png

优点: 容灾能力非常强，几乎不受限制， RTO为分钟级别。

缺点: 部署复杂，涉及到数据的双向同步(需要在同步过程中解决数据冲突的问题, 云厂商一般使用DTS工具进行同步)，还会涉及到比如 Redis 缓存、 Rocket MQ 、有状态中间件等；业务改造成本非常高，涉及到单元化和接入层等维度。

云上容灾架构分析

案例一腾讯云上云基础架构

云上基础容灾架构如下(数据层采取同城双活):

image.png

主要产品:

• CDN 加速
• WAF应用防火墙+DDOS防护
• CLB 负载均衡(多可用区)
• 多可用区云主机
• 数据库(多可用区主备+异地灾备)