云原生趋势下的容灾架构演进之路
业务发展，“稳”字先行！
当今，数字化转型已经驶入快车道，同时受到疫情常态化的影响，企业构建IT系统容灾能力，既是保障自身业务发展的需要，也是承担社会责任实际要求。
容灾方案发展阶段
回顾企业容灾方案的发展，通常有这样四个阶段：
1、数据冷备：实现简单，无需业务改造；
2、在线热备：因为冷备只备了数据，故障恢复时需把应用服务部署起来，恢复时间较久；常态下热备服务不提供在线访问，导致资源大量浪费，且可靠性难保障；
3、同城双活：相比于异地多活，实现起来较为简单，业务改动较少，可提供在线服务，让资源有效利用，故障恢复时间比较短；
4、异地多活：多活实现比较复杂，需要业务做Set化的改造，同时运维也较为复杂，但优势明显——故障恢复时间非常短。
那么，有没有一种方案，可以避免投入过多资源，减少业务改造，并且维持较低的运维成本，同时缩小故障恢复时间呢？
腾讯云通过分析众多客户实践与案例发现，同城双活已经能够满足绝大多数客户容灾的需求。结合内外部不同阶段用户的容灾架构落地经验， 腾讯云总结提炼了一套以低成本为核心的云原生容灾解决方案，解决了不同行业、不同阶段客户的容灾场景，如同城双活、两地三中心、跨云多活、跨云灾备、混合云等。
详解腾讯云原生同城双活方案
在2022年1月7日举办的TOP100Summit上，腾讯云泛互联网行业首席解决方案架构师邱浩，详细介绍了腾讯云原生同城双活方案。
在接入层，腾讯云负载均衡CLB产品在跨可用区做主备部署，单可用区出现故障的时候，流量不受影响，外网流量引入到备可用区。负载均衡器在非常短的时间（约30秒）内，即可切换到备可用区恢复服务。主可用区恢复之后，CLB能够探测到并自动把流量恢复到主可用区。整个切换不需要人工操作，故障恢复时间比较短，一般分钟级就能够恢复。
值得注意的是，负载均衡器只有主可用区不可用的时候，才会切换到备可用区，而不是出现一个故障就会整体切换，因为整体可用区的切换会对业务带来较大的影响。
在数据层，保障数据一致性和可靠性至关重要。邱浩详细介绍了腾讯云数据库MySQL容灾方案的最佳实践。在数据一致性方面，通过强同步策略，保证数据一致性；同时，通过内核修改和优化，提升TPS的吞吐能力。在高可靠方面，腾讯云数据库实现了整条链路的可靠性保障，即使用户选择了第一和第二个可用区来部署数据库的实例，云数据库会在不可见的第三个可用区也部署探测节点，实时探测MySQL主节点与备节点运行状况，真正做到在一个可用区或者网络分区，把故障剔除掉，保证数据库可靠性。在低成本方面，一般来说核心数据库高可用是一主两备、部署在同一个可用区，在升级为跨可用区部署的时候，在后台可以把两个备库其中的一个移到备可用区，这样对于成本来说是零增加。此外，发生故障之后，云数据库MySQL读写访问的IP完全不需做变更，应用层不需重新发版，也毋需通过中间件修改访问IP，整个故障切换和恢复都由云数据库后台自动完成，免去用户手工恢复环境的代价。
接下来，邱浩还详细介绍了云上缓存数据库Redis是如何实现故障还原、高可用性。一般来说，业务对于缓存数据库Redis的访问性能要求比较高，比如一次请求只有0.1毫秒，但是跨可用区访问的网络延时大约需要1毫秒，于是读取大量缓存的时候就会有性能损耗。通过腾讯云网络就近接入能力，使应用层感知到本可用区Redis部署在哪里，在读取的时候优先就近访问本可用区的副本节点，这样无论是从哪个可用区读取时，都是在访问本可用区的副本。这样就提供了一种本地访问体验，并且降低了请求的耗时。此外，云上产品还将Redis内核需求化，切换时能够指定从库权重。
如果是自建Redis，就需要应用每一台应用客户端，实现就近感知的能力。由每一台客户端探测Redis所有的副本时延情况，选择一个最低网络时延副本分发流量。而云上，通过网络、网关，路由器可以自动学习，感知到它的网络就近路由信息，不需要应用程序再做额外探测。
对于极致可用性的场景，可以把数据库副本分散在三个可用区。当一个可用区主节点发生故障时，还有两个可用区有容灾能力。这样的好处是增强了可用区能力，缺点则是需要更多的资源投入。
接下来，邱浩详细介绍了腾讯云数据库MongoDB容灾方案、腾讯云消息列队Kafka容灾方案、Elastic Search容灾方案、COS容灾方案。其中， 腾讯云数据库MongoDB 能够实现自动选主协议。云产品实现逻辑与社区版本类似，但是进一步优化了内核锁粒度。 Mongo一定要部署到三个可用区，避免单个可用区出现故障的情况。同时，Mongo在云上也有就近接入的特性。
腾讯云原生同城双活案例
之后，邱浩通过一个案例详细介绍了腾讯云如何实现单可用区升级为双可用区双活架构：国内某领先电商SaaS平台，其业务需求全部部署在公有云单可用区。一旦出现可用区故障，发生服务中断，就会影响其上百万商家与上亿买家。由于此电商平台业务资源数量众多，如果使用热备方案，成本浪费比较严重。同时，由于该平台使用了大量的数据层或中间件服务，如果完全依靠自身做改造，需要投入非常大的精力；另外，数据同步与环境管理的代价也比较高。
平台使用腾讯云云原生同城双活方案之后，由于双可用区都是百分之百承接流量，资源有效利用，业务毋需改造，运维代价大大降低，故障恢复时间也降为分钟级。
解决架构升级的挑战
在架构升级时会遇到一些挑战：老的业务会面临流量二次穿越问题，这就造成了两个可用区之间的网络延时；经过多次二级流量穿越之后，就会导致访问时延在极端情况下放大十数倍，影响业务性能。 通过智能流量调度方案，可以实现http和rpc流量就近访问本可用区。
除了这些基础保障，更加重要的是如何保障整个双活容灾可靠性。以数据库容灾为例，如果是主库故障，管控就会探测到数据实例故障，然后触发HA切换，更新数据库路由信息；网络管控获取路由存放的数据库地址，更新正确的数据库路由信息。更新之后会下发到对应可用区的备库实例上，对应的可用区路由信息更新，将VIP旧的路由信息擦除掉，使路由信息指向新的主库，完成整个切换。 如图所示，每层组件都在不同可用区做了多副本，真正实现整个链路的可靠性与容灾能力。 
在完成双活部署或验证之后，还要做真实的多轮容灾演练，以确保核心业务整体架构具备真正的容灾能力。 在经过多轮演练之后，效果符合预期，验证完成。以上就是将单可用区的架构，升级为多可用区的全过程。
腾讯云两地三中心案例
接着邱浩为大家带来双活架构之后的演进介绍：如何实现两地三中心架构。
如图所示，依据上面的阐述，左侧广州六区和四区可以实现同城双活。如果跨地域的话，需要做一个接入跟应用的热备部署，平时不承载流量。数据层做一个灾备同步，部署在跨地域，这样便可以实现两地三中心的架构。
传统方案中，异地灾备最难的就是网络抖动问题，尤其是redis跨地域复制，是落地的一大卡点。这是因为Redis原生代码在跨地域复制的场景中无法保证目的端实例服务的可用性，在写入量过大或者长时间断开复制的情况下，Master节点的backlog可能无法满足断点复制日志的续传，导致目标节点必须进行全量复制。在全量复制数据同步的过程中，目标节点不能提供访问，因此无法保障服务的可用性，详情可参考redis官方文档。
腾讯云Redis支持全球复制功能，能够完全兼容Redis4.0和5.0，全球复制版本在保障性能前提下优化了复制的日志数据，使得Redis可以进行跨地域复制。断点续传避免跨地域网络抖动导致的同步问题，消除两地三中心落地的卡点。
分布式云TDCC
解决多云及混合云趋势下的容灾挑战
多云环境下，如何在充分利用云上弹性伸缩能力？如何避免业务被单一云厂商绑定？如何治理多云及混合云环境下的应用？如何低成本实现跨云或混合云双活？
腾讯云分布式云TDCC可以解决这些难题。如图所示，跨云双活案例：客户的业务接入层和应用层服务独立部署在腾讯云和其他云上，数据通过专线实时同步。借助腾讯云TDCC产品，统一管理不同云上的容器应用集群。不同容器集群注册到TDCC，管理人员通过K8S API或TDCC控制台，统一发布应用到两朵云，实现跨云双活部署，无需改造现有业务发布流程，又充分利用云上资源弹性，避免技术绑定。 TDCC可以管理多云、多IDC的容器应用集群，实现一次发布全球运行。
容灾注意事项
最后，邱浩对容灾过程中需要注意的事项进行了总结。包括明确容灾目标、容易忽略的问题、定期演练等。
容灾是个复杂的话题，业务在不同发展阶段组合多种技术栈，进一步增加了容灾的复杂度。在传统容灾方案下，需要研发人员投入大量人力和资源实现容灾。现在，借助云原生技术，可以低成本的实现高可靠的容灾架构，既能满足业务的容灾需求，又能兼顾技术的发展趋势。