揭开腾讯云原生同城双活的秘密

本文内容节选自7月30-31日，由msup和高可用社区联合主办的第七届GIAC全球互联网架构大会，腾讯高级解决方案架构师邱浩分享的《腾讯云原生同城双活解决方案》案例实录。

分享者邱浩，腾讯高级解决方案架构师。2019年加入腾讯，专注于云上架构设计与方案咨询，已为电商、出行、社交等多个行业客户提供深度定制的业务架构优化方案。曾在百度有近十年的存储架构设计经验，主导过广告、计费、财务等多个千亿级数据库架构优化。

大多数互联网公司对于业务的连续性要求非常高，尤其业务发展到一定规模之后，容灾是我们一定会面临的问题。不管是物理故障还是灾难级故障，都是低概率发生事件，但一旦发生对公司的业务或整个用户口碑都是致命的影响。尤其是腾讯云越来越多的客户均提出了容灾需求，希望更简单、便捷的去实现RPO、RTO趋近于0的同城双活架构。

容灾发展主要经历了四个阶段：

1、数据冷备：实现简单，无需业务改造

2、在线热备：因为冷备只备了数据，故障恢复的时候需要把业务布起来，恢复的时间比较久，所以出现了在线的热备，但是热备常态下备份不提供在线服务，导致资源大量浪费，且可靠性难保障

3、同城双活：相比于异地多活实现起来较简单，业务改动较少，可以提供在线服务，让资源有效利用，故障恢复时间比较短

4、异地多活：多活实现比较复杂，需要业务去做Set化的改造，同时运维也比较复杂，但它的优势是故障恢复时间非常短。

容灾发展的四个阶段相对应的方案：

左图是数据冷备，冷备是只把数据备到IDC机房，故障的时候需要临时再部署应用服务；右图是在线热备方案，热备相当于两个数据中心有1：1的应用和环境，故障的时候切换到热备环境下，但是热备环境常态下无流量，故障的时候切过去不能确定服务是否能够正常访问，所以在互联网环境下，因为考虑成本问题，使用的比较少。

互联网行业应用比较多的是同城双活，其设计思想是：

1、应用服务双活，数据层单写、多读；

2、故障恢复时间较短，业务改造代价低；

3、主备可用区常态承载流量，可靠性高；

前置条件是：

1、数据服务支持实时增量同步，

2、接入层/应用层无状态，

3、应用层可接受跨区访问数据层增加的网络/数据延迟；

改造代价是：

1、中间件实现自动流量调度，以及数据层故障HA自动切换，

2、本可用区应用无跨区访问，或优先访问本可用区实例。

最后一种是异地多活，一般是跨地域的多活。首先要业务做Set化的改造，每个地域或者每个数据中心都会同时接入写入流量，用户的请求或者访问在单个数据中心去实现交易的闭环。这种方案改造代价比较高，落地案例可能少一些，下面我们一起来看看用户的请求过来之后是如何处理的。

首先，用户的请求通过互联网进入外网网关，如果用户的请求是首次，不带用户信息的请求就会随机选一个数据中心接入。第二次之后，因为用户有自己的身份信息，访问会把用户信息带到网关。网关这里有一个小的处理脚本，可以通过路由中心访问到用户所属Set，比如天津Set的用户把流量发到天津的数据中心，上海的用户发到上海的数据中心，同时用户下单的请求都在上海的数据中心内部完成应用的逻辑处理以及下单的订单操作，最后每个数据中心都会有完整的数据。当天津地域发生故障的时候，我们从入口处把网关的流量切到上海，因为上海地域都有完整的天津的数据，相当于天津的用户就会录入到上海的数据中心处理，完成整个故障的恢复。这种方案最大的挑战是业务需要在本Set内完成闭环处理，需要数据同步或者双向同步甚至多向同步的挑战。