一个云原生双活架构方案

互联网业务对于业务的连续性有非常高的要求，当业务发展到一定规模之后，容灾就是一个不得不面对的问题，如何实现一个RPO趋于0的同城双活架构是一个挑战。

四种容灾架构

容灾架构经历过四个发展阶段：

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

2. 在线热备：冷备只是做了数据备份，故障恢复的时候需要把服务热起来，恢复的时间会比较久，于是就有了在线热备方案，但热备常态下备份不提供在线服务，导致资源大量浪费，且可靠性难保证；

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

4. 异地多活：多活实现起来比较复杂，需要做业务维度的set化，运维也比较复杂，优势是故障恢复时间短；

冷备VS热备

如下图，冷备只是把数据备份到IDC机房，故障时需要临时部署应用服务；热备方案相当于两个数据中心1：1的应用于环境，故障的时候可以切换到热备环境下。

但热备环境下常态下无流量，故障时切过去不能确定服务是否正常访问，考虑到成本，使用的较少。

同城双活

互联网应用使用较多的容灾方案是同城双活。应用服务双活，数据层单写、多读，故障恢复时间短，业务改造成本低，主备可用区常态承载流量，可用性高。

要求数据服务支持实时增量同步，接入层、应用层无状态，应用层可以接受跨区访问数据层增加的网络、数据延迟。

需要实现中间件层面的流量自动调度，以及数据层的故障HA自动切换，本可用区无跨区访问，或优先访问本区可用实例。

异地多活

异地多活一般是跨地域的多活方案，首先业务需要进行SET化改造，每个地域或数据中心可以同时接入写流量，用户请求与数据在