聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

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

2021-08-10 18:49 浏览: 3149336 次 我要评论(0 条) 字号:


本文内容节选自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内完成闭环处理,需要数据同步或者双向同步甚至多向同步的挑战。


对比上面几种方案,在腾讯云原生同城双活方案推出之前,我们发现投入资源的成本从上到下逐渐增加,业务的改造成本、运维的成本也是逐渐增加,对应的是故障的恢复时长从上至下不断降低。


我们再来看看腾讯云原生同城双活方案,其资源成本投入中等,部分数据层服务做了双活之后,成本也是零增加。多数业务场景下不需要业务做任何改造,零业务改造可以升级成同城双活的架构,运维成本比较低,所有数据层的服务和接入层都是通过腾讯云云原生的产品做故障自动的切换,包括故障后的数据以及环境的自动恢复。故障的恢复时长比较短,趋近于零,因为这种AZ级的故障为了保障判断的准确性,一般会在分钟级去完成故障的切换和恢复。

这个方案是基于腾讯云云原生的产品,支持业务轻松实现同城双活,主要包括接入层、应用层及数据层,每层云产品都提供了对应双活的能力。接入层双活能力支持腾讯云负载均衡CLB,主备架构实现跨数据中心容灾;支持故障自动切换,保持VIP不变。应用层双活能力支持容器服务TKE,支持跨数据中心容灾。数据层双活能力支持数据库主备架构,故障后VIP保持不变;Kafka/ES/COS单集群跨可用区多副本。此外,还有腾讯云WAF/API网关/TDMQ/TDSQL等更多产品,支持跨数据中心容灾;腾讯云网络原生支持就近访问的能力。

关于腾讯云原生同城双活的方案,下面我为大家分享一个案例:


上图是国内领先的电商SaaS平台,致力于为零售商家们提供多渠道的电商解决方案。它的业务全量部署在公有云单个可用区,一旦可用区故障服务中断,将影响数百万商家和上亿买家,所以他们希望实现单可用区故障不影响业务连续性。但他们业务资源数量多,热备成本浪费严重;众多数据服务,业务改造代价大;跨可用区数据同步方案难度高。

所以,我们给客户推荐了腾讯云原生同城双活的解决方案,前面也介绍了,它有几个优势:资源可以有效利用、具备业务零改造代价、数据可靠性高、运维代价低、故障恢复速度快的优势。

客户将在线同城双活架构升级之后,我们和客户一起,开始在非核心业务,逐渐去到他们的核心业务做在线容灾的演练。经过演练,效果还是比较理想的。


在上述方案中,常用的组件是如何实现跨数据中心容灾的呢?


上图是腾讯云负载均衡CLB容灾方案,其实现原理是当主可用区出现故障或不可用时,负载均衡有能力在非常短的时间内(约30秒)切换到备可用区并恢复服务;当主可用区恢复时,负载均衡同样会自动切换到主可用区提供服务。优点是CLB主可用区不可用,自动切换到备可用区并恢复服务,无需人工操作,故障恢复时间短。要补充说明的是CLB的主备可用区是可用区级别的容灾。只有当主可用区整体不可用时,如机房整体断电、机房出口光缆中断等,负载均衡才会切换到备可用区,而并非某个实例出现故障,就切换到备可用区。


上图是腾讯云数据库MySQL容灾方案腾讯云MySQL数据库实现了金融级数据的一致性,上图只画了两个可用区,实际备库可以加到第三个可用区,这个数据在另外一个数据中心有完整一致的数据。故障之后,MySQL的IP完全不需要变更,故障之后应用层IP不需要做任何配置的变更。访问请求就近的接入访问本可用区的从库,提升业务访问性能。

最后是数据的高可靠,可以通过强同步的方式来实现。即使用户选择了只部署在两个可用区,后台还是会在第三个可用区部署HA管控的系统,其实在不可见的地方也部署了管控平台,这就是为了保障我们在切换的时候,避免出现只有两个可用区的情况,发生网络分割导致的脑裂问题,我们默认在第三可用区部署管控节点,真正故障的时候可以准确的把故障实例剔除掉。


上图是腾讯云数据Redis容灾方案Redis一般用于缓存服务,对性能要求比较高,故障切换的时候,IP不变和前面MySQL一致。这里做了Redis内核的加强,因为有些客户希望故障切换之后Redis的主库可以优先切到本可用区的从库,社区版是不支持的。数据中心的故障是低概率的事件,更多的可能是单台机器发生故障,所以我们也做了策略,增强内核参数,制定从库权重,故障时可以优先把主库切换到本可用区的从库。Redis也是一样,管控的HA节点在第三个可用区做了部署,避免网络出现分割的时候脑裂的情况出现,保证切换时可以做正确的选主操作。


关于Redis容灾和Failback的特性,例如,它初始的主可用区在第二可用区,为了保障集群可以快速恢复最原始的状态,Redis产品做了Failback的特性,可以一键恢复最初一百个分片或者两百个分片最初始的状态。这是推荐部署的方式,如果我们对可用性有要求,只部署前面讲的两个可用区,只有两个节点,一个节点故障,另外一个可用区也是单点,推荐的部署方式是可以达到极致可用1+1+1的模式,当一个节点故障之后另外两个数据中心的节点将提供数据和服务。


再为大家介绍一下Redis就近接入的特性,上图是一个测试数据,同区是指应用层应用的服务去访问Redis,跨区是跨可用区的访问Redis的服务,当我们的并发足够高的时候,Redis写入还是读取吞吐基本都是一致的。上面的数据,相当于串行请求,因为有跨可用区网络延时的问题,跨区的时候明显不如同区写入性能高,这是预期当中的。开启就近接入之后,两个可用区QPS都是一致的。


MongoDB也是类似,故障之后IP不用做任何变更,访问延时也是就近访问本可用区的Mongo的从副本。Mongo默认部署到三个可用区内,通过它自主原生选择逻辑实现高可用。就近接入,跨可用区之后,并发场景的同区和跨区基本一致,就近接入之后访问的吞吐也是基本一致。


上图是云原生就近接入的Mongos 3.6版本,开启的nearest访问模式。Mongo的特性是就近对于3.6及以下的版本有一个Mongos在前面,MongoDB节点和Mongo之间的时延只要在15毫秒以内都认为是就近访问,所以需要注意的是,这里对原生的访问都是默认把从Mongos发到下面每个MongoDB的节点。


Kafka同集群做跨可用区多副本,切换后访问的VIP保持不变,也不需要业务做任何的变更。针对成本问题,Kafka原来的topic只有两个副本,变为将两个副本中的一个副本挪到另外一个AZ部署,这样成本便是零增加。

从单个AZ到双AZ的升级都是后台管控平台自动进行升级,不需要人工搬数据、部署环境。即使用户选择两个可用区,后台的ZK还是布到三个可用区,这样可以保证在故障选取的时候,避免出现脑列情况。


ElasticSearch跟Kafka差不多,都是同集群跨可用区多副本,切换后VIP保持不变。ElasticSearch原来两个副本,把其中一个副本迁到跨可用区内,可以保障ES在两个数据中心有完整的数据,保证整个数据故障在另一个数据中心有完整的容灾,并且是成本零增加。

ES切换依赖专用主节点,我们也会在三个可用区部署专用的主节点,即使数据只分布在两个可用区,专用主节点保障一个数据中心故障之后真正被感知到做正确的选主切换。ES在云上的升级也是完全自动的,不需要手动再部环境,去挪数据,通过滚动模式自动升级到同城跨可用区的架构。


COS是腾讯云的对象存储,这里对比一下,如果是非原生的多AZ架构,跨数据中心要建两个,数据要通过异步复制。这样数据可能会有RPO,没办法做到0,故障的时候还需要有切换,同时只有一半的服务在提供请求,资源也会浪费。

COS在设计之初就已经是这种原生多AZ的架构来支持整个数据在多AZ的部署。其实COS是进行分层设计的,绿色模块是接入层,接入层无状态,负责处理用户的请求和路由。蓝色的模块是数据存储的模块,包括用户写入的数据和容灾的副本。用户的请求到接入层之后,把数据通过算法把数据写入到不同的AZ里面,保证数据是完整的。当其中一个AZ故障之后,COS还可以只做简单的降级操作,不访问故障数据中心的节点,就可以实现整个故障的快速恢复。


如果,我们现在的业务不是重新搭建的,可能有些业务已经在云上或者因为有耦合,有服务间的调用。这样可能会导致跨可用区的问题,所以我们也有Private DNS服务。它能够去通过DNS view的配置实现Http流量智能调度,同可用区的请求通过view优先访问同区IP服务上,然后来实现http就近的访问。

用dubbo的分布式服务,也可以简单的扩展dubbo路由的规则,实现流量优先访问本可用区的实例。


接下来,为大家分享一个容灾切换的简单例子。上图中CDB的主库从第一个AZ故障之后切到第二个AZ,其实它背后依赖几十个组件,为了方便大家理解我只画了ABC三种组件。CDB的管控,IP不变,网络管控,跟CDB互为依赖,相互依赖会有冲突的问题,导致故障不能用,这里引入第三个模块,所以我们简单以这个为例来看一下故障时是怎么样的。

当CDB主库发生故障,我们探测到主库不可用就触发到HA的切换,通过网络管控去更新VIP路由,把原来指向AZ1的实例指向到AZ2,网络管控为了解耦避免网络和CDB相互依赖,故障时候相互调,这里引入了内部的name server的模块,帮助网络管控找到对应db的地址。找到db的地址更新到对应路由的信息,更新完路由信息之后再去通过cdb的管控设置cdb背后新的主库,然后将路由指向新的主库上。这里看起来比较复杂,其实都是为了将cdb一个主库节点故障时候依赖的所有模块在不同的可用区甚至不同的地域都有对应容灾或者高可用的能力,而不是简单的只依赖一个cdb的管控就把所有事情覆盖住,后面还有几十个组件没有显示,我们定期对组件整个容灾能力做演练来验证我们的功能可靠性。

最后我们真正实操的时候有些注意事项,首先要明确容灾的目标:
1、单可用网络异常超过10分钟,
2、单可用区遭受重大损害且无法在10分钟内恢复,3、单可用区整体访问异常占比超过25%,且持续10分钟且无法定位故障;

容易忽略的问题:
1、双区部署标准化(如容器化,默认跨区部署),
2、运维组件容灾(如堡垒机、中控、监控、定时任务等),
3、在线升级的影响(如后台原地升级,避免影响业务访问);

定期演练:
1、数十上百个组件/业务,任意一个都可能造成切换失败,
2、架构在不断变化,需持续验证方案的有效性。


上图是腾讯云原生产品的特性,这里列的,并不是只有MySQL切换后IP不变,Mongo和Kafka等产品切换之后IP都是不变,包括多可用区部署其他产品也有这个能力。总结来说这些产品组合起来可以实现灾备、同城双活、两地三中心甚至全球多活,可以根据实际业务场景的选用。

最后,邱浩为大家分享了腾讯云原生同城双活的Demo,它基于腾讯云原生产品实现(接入层CLB、应用层TKE容器、数据层CDB等产品)。

参考阅读:


技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。


高可用架构
改变互联网的构建方式




网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复