AWS光缆被挖后对架构设计的一点总结（一）

公众号：大猪蹄子程序员

昨天科技圈最火的新闻应该是“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个中心，三地五中心基于的概念是单元化，还得花很大篇幅来说，下一篇继续吧。

相信你们不喜欢在小小的手机屏幕上还看到一大块的代码，阅读体验很差，因此我写做的风格会文字偏多一点。若是以为有所收获就给个小小的赞吧。