做容灾，双活、多活、同城、异地、多云

，不是同城，就是异地，现在又出来个多云，好复杂。

下面我就谈谈我的理解：

首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。

先讲相对简单的双活(简不简单，看后面就明白了)，其实就是两个站点，同时承载业务流量，可以根据用户ID、地域或者其他业务属性也决定怎么分担流量，当一个站点故障时，可以快速(分钟级)切换到另一个站点，理想情况下，对业务基本是无损或者非常小的。

这里就跟前面讲的主备不同了，主备的另一个站点完全是不承载任何流量的。

这里再往深里看一眼，同时承载流量，也要看承载到那一层，也就是流量在统一站点内闭环，所有调用都是本机房内完成，还是只有应用层这样的无状态组件双活，但是数据访问、异步消息这些有状态的部件还是回到主站点调用，这两种模式又是不一样的。

其实第二种，就比前面讲的主备模式要好一些，因为这样至少可以保证应用层随时可用，不过真出故障的时候，还是少不了数据层的切换，这个其实是非常耗时的。跟主备模式一样，基本无法演练，因为代价太高，数据会有损。(如果数据层没有这么复杂，只有几个数据库，那是没问题问题的，但是分布式的场景下，上百个，几百个实例切换，这个代价和成本还是很大的。)

所以，再往下推导，如果想要做到有效果的双活，就必须保证每个站点，都是独立运行，所有的调用都是本机房调用且闭环，底层做好数据同步即可。

只有做到这个程度，当一个站点发生故障不可用时，就可以从接入层把故障站点的流量切换到另一个站点，双活的效果也就有了。

不过，做到这个程度，就不是说我们想要做就能做到的，如果您做个类似的架构设计，你会知道这里有三个关键的技术点：

技术点一：本机房调用

也就是一个分布式请求不能跨机房调来调去，这个是不行的，必须要保证本机房调用闭环。所以从分布式服务的路由策略上，以及服务化框架上，必须得支持这也中调用模式，同理，数据访问层，以及消息组件也要支持这种特性。

技术点二：数据分片和一致性

为什么要做这个事情?我们知道一个系统中数据准确性、完整性和一致性是非常关键的，放到双活这个场景下，最关键的就是数据一致性，我们不能允许有同一个记录两边同时在变更，还要双向同步，比如用户交易和支付类的数据，同时变更的情况下，我们无法确认哪边是准确的。

前面提到，两个站点是同时承载不同的流量的，这就要根据一些业务属性来分配，比如用户ID、所属地域等等策略，这里为的就是能够在数据层面也要做好隔离，一个站点内只提供固定部分的用户访问。

这样就保证了单站点内同一分片的数据，不会在另外一个站点被变更，后续的同步也可以做到单向。

所以，这里的关键，就是数据要做分片，就要用到分布式的数据中间件，要做数据访问的路由设计，数据要同机房读写，还要做数据拆分这样的工作，技术门槛和工作量也不低。

这两点如果能够做到，其实就是我们经常说的“单元化”架构达成了，理论上，我们可以选择任何一个机房和地域，把系统搭建起来，就可以提供业务访

（编辑：黄山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!