公众号：大猪蹄子程序员

昨天科技圈最火的新闻应该是“AWS中国区光缆被挖，导致三星、小米等众多企业服务不可用”。 又是光缆被挖，咦！？为什么是又，让我们来一起回到过去：

• 2019.6.02：亚马逊光缆被挖断,国内部分地区网络出现异常
• 2019.3.23：施工队挖断腾讯光纤,致腾讯旗下100多款游戏受影响,损失大了
• 2015.5.27：由于杭州市萧山区某地光纤被挖断，造成目前少部分用户无法使用支付宝

我这里只是列出来了几家大公司所涉及到的光缆被挖事故，其余还包括什么广电光缆被挖，社保局光缆被挖就不列了，感兴趣的自己去百度。

好，我们发现“公司再大，也怕施工队”，那么这种事故能怪施工队吗？个人觉得不能把责任都推给施工队，当然我们这里不讨论这些，我们做为大公司，我们以后怎么预防这种现象呢？ 这个我们可以来看下支付宝的解决办法，毕竟它老人家在2015年就经历过这种惨况了。

2018年9月20日，杭州云栖大会ATEC主论坛现场上演了一场特别的技术秀。蚂蚁金服副CTO胡喜现场模拟挖断支付宝近一半服务器的光缆。结果只过了26秒，模拟环境中的支付宝就完全恢复了正常。

这种解决办法就是“三地五中心”，这是一种机房架构，即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，依靠技术可以将故障城市的流量全部切换到运行正常的机房。 那么在“三地五中心”之前还存在很多其他架构，我们一一来看一下他们的特点。

灾难演进

最初，我们把应用(一个非常简单的只读应用，比如一个显示Hello World的网页，不考虑数据存储)只放在一个机器上，那么当这个服务器down机了，我们的应用便不可用了。 所以，我们考虑把我们的应用放在多个机器上，在公司单独开辟一个机房来放置这些机器，这样单独某一个台机器down机了并不影响我们的应用。 但是，如果你们公司某一天停电了呢？这个时候我们就考虑在这座城市的另外一个地方在放置一个机房，这是应用就被部署在了同城的两个机房（这个叫同城双活） 但是，如果你们城市某一天经历了海啸、台风、地震等自然灾害，两个机房都不能使用了，这个时候我们就会考虑在另外一个城市再搭建一个机房来部署我们的应用，这样我们应用的可用性就更高了（这个叫异地多活）。 好，到此为止不管出现什么样的状况，我们的应用基本上都可用（除非地球毁灭...）

那么我们上面考虑的应用是一个非常简单的只读应用，所以各个地方的应用是可以同时对外提供服务的，那么如果我们的应用涉及到数据存储，这个时候各个地方的应用就不能同时对外提供写入数据的服务了，因为很有可能会出现数据冲突，那么我们暂且规定只有公司内部机房里的服务器（后文我们叫主机房）可以提供写数据服务，而同城的另外一个机房以及异地的另外一个机房只能从主机房同步数据，这样这两个地方的机房的功能就叫灾备，因为数据会同步，所以就算主机房停电了，另外两个机房还是可以临时来对外提供服务的。所以现在的架构可以如下：

当主机房停电后，用户会去请求北京备份机房，当北京备份机房也停电后，用户会去请求上海备份机房。 好，对于这个架构，我们刚刚说只有主机房能对外提供服务，另外两个机房都只是作为容灾的备份，那么也就是说备份机房利用率不高，因为毕竟正常请求下主机房不可能老停电，所以对于备份机房能不能提高它的利用率呢？当然可以，我们可以让北京的备份机房也去接收部分业务请求，只是这些请求可以没那么重要，比如一些读请求，而上海的备份机房不去接收请求，还是单纯作为容灾备份机器，因为如果谁都不能保证当备份机房接收业务请求会不会出现其他不可预知的问题，那么现在三个机房的角色实际上已经有些不同了：

这个就叫两地三中心。

那么两地三中心这种架构是目前很多银行或大型企业正在使用的一种架构，因为国家针对银行的灾备能力做过要求，资产超过多少多少的一定要做两地三中心架构，以保证银行系统的稳定。

那么这种架构有没有它的缺点呢？我们来考虑一下它的可用性高不高？可用性的意思就是这个架构处理用户请求时够不够快？ 我们发现这种架构，中心之间是需要数据备份的，那么对于数据备份只有两种方式，要么异步，要么同步。

• 最大性能模式：如果是异步，表示用户一个写数据请求，只要在生产数据中心存储完数据后就会直接返回结果给用户，同时异步去备份数据，但是，如果正准备去异步备份数据的时候生产数据中心停电了~，那么这个时候还能将灾备服务器暴露出去给用户提供服务吗？不能了，因为很有可能灾备中心的数据是过时的数据。
• 最大保护模式：如果是同步，表示用户一个写数据请求，不仅要等待生产数据中心存储完数据，还需要等其他灾备中心备份完数据后才能返回，而且仅仅当灾备中心出现问题时，因为不能完成数据的备份，所以整个架构也不能对外提供服务，这种可用性是很低的。
• 最大可用模式：这是普遍采用的方案，正常情况下使用最大保护模式，同时生产数据中心监控灾备数据中心，一旦发现某一灾备中心出现了问题，那么则会改为最大性能模式，这样就保证了生产数据中心不受其他灾备中心影响。
• 三写两同步：这是阿里之前的架构模式，意思是同城三个中心，数据备份不是发生在数据库层面，而是应用层，当应用向数据库去写数据时，会同时向三个中心去写数据，只要有两个中心返回成功即可，这样就算三个中心有一个中心停电了，那么并不影响整个架构的高可用，这个思路和我们前面三种是不一样的，性能肯定会高很多。

好，我们介绍了一下两地三中心，总结一下它的缺点：

1. 灾备中心利用率不高
2. 生产数据中心停止运行后，灾备中心中不一定有100%一模一样的数据
3. 成本高，但又无法真正实现期望的高可用能力

那么为了解决这个问题，就出现了三地五中心，虽然名字和两地三中心类似，但提供的功能完全不同。

三地五中心是指三个城市，5个中心，三地五中心基于的概念是单元化，还得花很大篇幅来讲，下一篇继续吧。

相信大家不喜欢在小小的手机屏幕上还看到一大块的代码，阅读体验不好，所以我写作的风格会文字偏多一点。如果觉得有所收获就给个小小的赞吧。