程序要一定要明白的架构-三地五中心（1）

昨天科技圈最火的新闻应该是“AWS中国区光缆被挖，导致三星、小米等众多企业服务不可用”。

又是光缆被挖，咦！？为什么是又，让我们来一起回到过去：

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

好，我们发现“公司再大，也怕施工队”，那么这种事故能怪施工队吗？个人觉得不能把责任都推给施工队，当然我们这里不讨论这些，我们做为大公司，我们以后怎么预防这种现象呢？

这个我们可以来看下支付宝的解决办法，毕竟它老人家在2015年就经历过这种惨况了。

这种解决办法就是“三地五中心”，这是一种机房架构，即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，依靠技术可以将故障城市的流量全部切换到运行正常的机房。

那么在“三地五中心”之前还存在很多其他架构，我们一一来看一下他们的特点。

最初，我们把应用(一个非常简单的只读应用，比如一个显示Hello World的网页，不考虑数据存储)只放在一个机器上，那么当这个服务器down机了，我们的应用便不可用了。

所以，我们考虑把我们的应用放在多个机器上，在公司单独开辟一个机房来放置这些机器，这样单独某一个台机器down机了并不影响我们的应用。

但是，如果你们公司某一天停电了呢？这个时候我们就考虑在这座城市的另外一个地方在放置一个机房，这是应用就被部署在了同城的两个机房（这个叫 同城双活 ）

但是，如果你们城市某一天经历了海啸、台风、地震等自然灾害，两个机房都不能使用了，这个时候我们就会考虑在另外一个城市再搭建一个机房来部署我们的应用，这样我们应用的可用性就更高了（这个叫 异地多活 ）。

好，到此为止不管出现什么样的状况，我们的应用基本上都可用（除非地球毁灭）

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

这个就叫 两地三中心 。

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

那么这种架构有没有它的缺点呢？我们来考虑一下它的可用性高不高？可用性的意思就是这个架构处理用户请求时够不够快？

我们发现这种架构，中心之间是需要数据备份的，那么对于数据备份只有两种方式，要么异步，要么同步。

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

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

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

不管什么原因，可以先把手机重启一下试试看。原因及解决办法如下：