结论，可以直接拖到后面，如果看不明白，可以从头看起。
最近，公有云又出了些大故障，各大群和朋友圈又开始沸沸扬扬，但是整体看下来，声音无非两种：
- 单站点不靠谱，要有容灾，出现这种情况就得马上切，所以回去赶紧建设容灾站点;
- 鸡蛋不能放在一个篮子里，单云不靠谱，要多云。所以，多云就要选我们家的xx云，或者我们提供xx多云服务。
我在我的一个讨论群里就提出来，一种声音是有意识的建设，有这个意识很好，但是把这个事情想得太简单了。第二种声音，基本就是不动脑子的瞎BB，原因我下面讲。
转回正题来，既然上篇提到主备模式不靠谱，那到底怎么选?而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。
下面我就谈谈我的理解：
首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。
先讲相对简单的双活(简不简单，看后面就明白了)，其实就是两个站点，同时承载业务流量，可以根据用户ID、地域或者其他业务属性也决定怎么分担流量，当一个站点故障时，可以快速(分钟级)切换到另一个站点，理想情况下，对业务基本是无损或者非常小的。
这里就跟前面讲的主备不同了，主备的另一个站点完全是不承载任何流量的。
这里再往深里看一眼，同时承载流量，也要看承载到那一层，也就是流量在统一站点内闭环，所有调用都是本机房内完成，还是只有应用层这样的无状态组件双活，但是数据访问、异步消息这些有状态的部件还是回到主站点调用，这两种模式又是不一样的。
其实第二种，就比前面讲的主备模式要好一些，因为这样至少可以保证应用层随时可用，不过真出故障的时候，还是少不了数据层的切换，这个其实是非常耗时的。跟主备模式一样，基本无法演练，因为代价太高，数据会有损。(如果数据层没有这么复杂，只有几个数据库，那是没问题问题的，但是分布式的场景下，上百个，几百个实例切换，这个代价和成本还是很大的。)
所以，再往下推导，如果想要做到有效果的双活，就必须保证每个站点，都是独立运行，所有的调用都是本机房调用且闭环，底层做好数据同步即可。
只有做到这个程度，当一个站点发生故障不可用时，就可以从接入层把故障站点的流量切换到另一个站点，双活的效果也就有了。
不过，做到这个程度，就不是说我们想要做就能做到的，如果您做个类似的架构设计，你会知道这里有三个关键的技术点：
技术点一：本机房调用
也就是一个分布式请求不能跨机房调来调去，这个是不行的，必须要保证本机房调用闭环。所以从分布式服务的路由策略上，以及服务化框架上，必须得支持这也中调用模式，同理，数据访问层，以及消息组件也要支持这种特性。
技术点二：数据分片和一致性
为什么要做这个事情?我们知道一个系统中数据准确性、完整性和一致性是非常关键的，放到双活这个场景下，最关键的就是数据一致性，我们不能允许有同一个记录两边同时在变更，还要双向同步，比如用户交易和支付类的数据，同时变更的情况下，我们无法确认哪边是准确的。
前面提到，两个站点是同时承载不同的流量的，这就要根据一些业务属性来分配，比如用户ID、所属地域等等策略，这里为的就是能够在数据层面也要做好隔离，一个站点内只提供固定部分的用户访问。
这样就保证了单站点内同一分片的数据，不会在另外一个站点被变更，后续的同步也可以做到单向。
所以，这里的关键，就是数据要做分片，就要用到分布式的数据中间件，要做数据访问的路由设计，数据要同机房读写，还要做数据拆分这样的工作，技术门槛和工作量也不低。
这两点如果能够做到，其实就是我们经常说的“单元化”架构达成了，理论上，我们可以选择任何一个机房和地域，把系统搭建起来，就可以提供业务访问了。
但现实是更为复杂的，因为用户业务系统产生的数据，有可能会被其它系统用到，比如商品库存这样的系统，这就要涉及异步消息和数据的同步问题，而数据同步不仅仅是一个技术问题，而是个物理问题，我们接下来讲。
技术点三：数据同步。
其实单从同步角度而言，目前很多的同步工具和开源产品已经比较完善，所以这里的问题，其实不在技术层面，而是在物理层面。
准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。
既然要双活，必然会选择另一个跟当前机房有一定距离的机房(同城或异地)，而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。
距离一旦拉开，物理距离就出来了，即使是专线相连，中间也要经过很多网络设备，如果是云化的网络架构下，经过的软硬设备就更多，还有可能涉及协议转换，如果中途跨运营商，就更难保障，这样一来时延肯定是几倍、十几倍，甚至是上百倍的上涨，直接从0.x毫秒，上涨到秒级别。
对于同城来说，这个问题还好，但是一旦跨省就完全不可控，特别是机房如果不是自己的，根本无法控制。所以，想大公司自建机房，一定会在这个层面做大量的优化，尽可能降低时延。
就以淘宝、天猫为例，按照之前了解的情况，基本也是杭州和上海这两个城市为主做双活，再远时延这个问题就绕不开了。
数据同步及时性为什么这么重要，一个是业务体验，不能说库存都没了，其他用户看到的还是有货，这个是不会被接受的。
再就是故障时，如果同步不及时，极有可能造成几秒钟内的交易数据丢失，或者不一致，像淘宝这样每秒4位数订单量的系统，丢几秒钟数据，造成的损失也是巨大的。所以，这里就必须要建设有一整套的数据完整性和一致性保障措施，尽可能降低业务损失。
所以，数据同步所依赖的时延问题，其实就已经超出了绝大部分公司所能掌控的范畴，也不是单纯靠自身技术能解决的问题，要看天时和地利。
讲到这里，我想多活就不用讲了，时延这个问题解决不了，多活就是扯淡，至于同城和异地，我想看明白的读者，也知道怎么选择了，其实一样，还是取决于时延。
我们可以得出的几个结论：
不管怎么选择容灾方案，我们自己的业务系统，从自身架构上，一定要支持单元化，一定要支持数据同步才行，如果这都不支持，讲双活和多活，就是瞎扯。所以，打算搞双活，先从这里下手，当然牵出来就要涉及到分布式，还有很多大量细节技术问题。
一个合理的建设节奏应该是，同城双活—异地双活—两地三中心(同城双活+异地多活)，因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。
题目里这些个名词，不是孤立的，而是从不同维度看到的结论，但是如果你偏离自己的业务场景去看，孤立的去看，就一定会被带到沟里去，而且不知道该如何下手，所以，一定别偏离你的业务场景，然后把它们联系起来。
一切都是ROI，为了保证高可用，就一定会有成本，高可用程度越高，成本就一定越高，所以成本投入得到的收益到底划不划算，这个只能自家公司自家评判。
现实情况，比我写的要复杂的多的多，推荐大家看两个成功案例，一个是毕玄的异地多活数据中心，一个是饿了么异地多活，几个关键字google一下就有了，里面涉及到的场景化的细节对大家理解这件事情的复杂度会有更帮助。
写的有点多了，关于多云先不写了，就当问题吧，大家觉得是不是需要多云建设?你怎么看?可以在留言区发表下意见。
