结论，可以直接拖到后面，不懂的可以从头讲起。最近公有云出现了一些重大故障，各个群和朋友圈又开始火了，但总体来说，有两种声音：单个站点不可靠，如果有容灾，必须立即切割。于是回去赶紧搭建灾备站点；鸡蛋不能放在一个篮子里，一朵云也不靠谱，一定要有多朵云。所以，如果是多云，一定要选择我们的xx云，或者我们提供xx多云服务。我在我的一个讨论组中指出，声音是一种有意识的建构。有这个意识固然好，但把这件事想的太简单了。第二个声音基本就是个不用脑子的瞎BB，原因我下面会解释。言归正传，既然上一篇文章提到了主备模式不可靠，那么如何选择呢？而且整天看各种技术文章，要么双活，要么多活，要么同城，要么异地，现在阴天了，好复杂。下面说说我的理解：首先，这么多名词的意思是什么，你得弄清楚，再看适不适合。先说比较简单的双活（不简单，后面你就明白了），其实就是两个站点同时承载业务流量，可以根据用户ID，地域来决定如何分流，或其他业务属性。当一个站点发生故障时，可以快速（分钟）切换到另一个站点，理想情况下，对业务基本没有损失或损害很小。这和上面说的主备不同。主备的另一站点根本不承载任何流量。让我们仔细看看这里。同时承载流量，承载到哪一层也取决于承载到哪一层，即流量在统一站点闭环。所有调用都在本地机房完成，或者只有应用层等无状态组件双活，但是数据访问、异步消息等有状态组件还是会回调到主站，两种模式是不一样的。其实第二种模式比上面说的主备模式要好，因为它至少可以保证应用层随时可用，但是当出现故障时，数据层的切换还是必不可少的，这其实很费时间。就像主备模式一样，基本没法钻，因为成本太高，数据会丢失。（如果数据层没有那么复杂，数据库就那么几个，那是没有问题的。但是在分布式场景下，成百上千个实例切换，代价和成本还是很高的。）所以，再进一步推导，如果要实现有效的双活，必须保证每个站点独立运行，所有调用都在本地机房进行闭环，底层可以做数据同步。只有这样，当一个站点出现故障不可用时，故障站点的流量才能从接入层切换到另一个站点，实现双活的效果。但是，达到这个水平，并不代表我们想做就可以做。如果你做过类似的架构设计，就会知道这里有三个关键的技术点：技术点1：本地机房调用是一个分布式请求，不能跨机房传递。这不可能。需要保证本地机房调用闭环。因此，从分布式服务的路由策略和服务框架来说，支持这种调用方式是很有必要的。同样，数据访问层和消息组件也必须支持此功能。技术要点2：数据分片和一致性为什么要这样做？我们知道数据的准确性、完整性和一致性在系统中非常关键。在双活场景下，最关键的是数据的一致性，不能让同一条记录的两边同时发生变化，需要双向同步，比如用户交易数据和支付数据。在同时变化的情况下，我们无法确认哪一方是准确的。前面提到，两个站点同时承载不同的流量，需要根据一些业务属性进行分配，比如用户ID、地域等策略。这里的目的是隔离数据级别。仅向网站的固定部分提供用户访问权限。这样可以保证单个站点中同一个分片的数据在另一个站点中不会被更改，后续同步也可以是单向的。所以，这里的关键是数据一定要分片，一定要使用分布式数据中间件，一定要做好数据访问的路由设计，一定要在同一个机房??读写数据，一定要做好数据拆分。门槛和工作量也不低。如果能做到这两点，其实我们常说的“单元化”架构就已经实现了。理论上，我们可以选择任意机房和区域，搭建系统，提供业务接入。但实际情况更复杂，因为用户业务系统产生的数据可能会被其他系统使用，比如商品库存等系统，这就涉及到异步消息和数据的同步，而数据同步不仅仅是一个技术上的问题，而是物理上的问题，这个我们接下来会讲到。技术点三：数据同步。其实单从同步的角度来看，目前很多同步工具和开源产品都比较完善，所以这里的问题不在技术层面，而是在物理层面。准确的说是物理距离上的时延问题。无论是双活、多活，还是同城异地，这都是一个无法回避的痛苦问题。由于需要双活，所以必须在距离当前机房一定距离的地方选择另一个机房（同城或异地），距离要拉远才有意义。如果都在同一个校区，就没有容灾意义。距离一拉开，物理距离就出来了。即使是专线连接，中间也会有很多网络设备。更难保证运算符被中途越过。这样一来，延迟肯定要提高几倍，十倍，甚至上百倍，直接从0.x毫秒提升到秒级。对于同一个城市来说，这个问题还好，但是一旦跨省，就完全不可控了，尤其是机房不是自己的，就完全不可控了。所以大公司如果要自建机房，肯定会在这个层面做很多优化，尽可能的降低延迟。以淘宝和天猫为例。根据我们之前的了解，杭州和上海基本上是做双活的两个城市。无论相距多远，延误的问题都无法避免。为什么数据同步的及时性如此重要？一是业务经验。不能说库存没了，其他用户看到还有货。这将不被接受。此外，当出现故障时，如果同步不及时，很可能导致几秒内的交易数据丢失或不一致。对于淘宝这种每秒4位数订单量的系统，如果数据丢失几秒，损失将是巨大的。的。因此，有必要构建一套完整的数据完整性和一致性保障措施，尽可能减少业务损失。所以，数据同步所依赖的延迟问题，其实是大部分公司无法控制的，不是单纯靠自己的技术就能解决的问题。这取决于时间和地点。说到这里，活多了就不用多说了。时间延迟的问题无法解决。延迟。我们可以得出几个结论：无论我们如何选择容灾方案，我们自己的业务系统都必须在自身的架构上支持单元化和数据同步。如果这个不支持，谈主动和多活就是废话。因此，如果您打算从事双活活动，请先从这里开始。当然会涉及到分发，还有很多细节性的技术问题。一个合理的建设节奏应该是：双住同城-双住异地-两地三中心（双住同城+多住异地），因为问题的复杂性和难度你需要解决的也在逐渐增加，不可能一蹴而就。题目中的这些名词并不是孤立的，而是从不同维度看到的结论，但是如果脱离自己的业务场景来看，肯定会被带入沟里，不知所措。如何开始，所以，一定不要偏离你的业务场景，然后把它们联系起来。一切都是投资回报率。为了确保高可用性，必须有成本。高可用程度越高，成本越高。因此，成本投资所获得的收益是否值得，只能由企业自己判断。现实比我写的要复杂得多。推荐大家看两个成功的案例，一个是必选的异地多活，一个是饿了么的异地多活。几个关键词google一下就可以了，里面涉及到的场景化的细节会更有利于大家理解这件事情的复杂性。写的有点多了，多云先不写了，就当做一道题吧。您认为多云建设有必要吗？你怎么认为？您可以在留言区发表您的看法。
