常用的数据中心部署架构

说起数据中心，相信大家并不陌生。随着互联网行业的蓬勃发展，大数据时代的快速到来，数据中心同我们的生活紧密联系，息息相关。我们日常生活中的各种数据几乎都存储在数据中心里，例如：手机照片的云端备份、放入电商网站购物车的物品、各种好玩的在线游戏等等。可想而知，一旦数据中心出现故障，会导致应用中断，给大家的生活带来不便。

那么，如何提高数据中心的可靠性成为企业关注的焦点。除了数据中心提高自身的电力、网络的SLA水平，我们还可通过不同的数据中心解决方案，提高数据中心的可靠性，保障业务的连续性。

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

我这里只是列出来了几家大公司所涉及到的光缆被挖事故，其余还包括什么广电光缆被挖，社保局光缆被挖等。

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

这个我们可以来看下支付宝的解决办法。

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

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

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

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

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

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

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

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

当主机房停电后，用户会去请求北京备份机房，当北京备份机房也停电后，用户会去请求上海备份机房。

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

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

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

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

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

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

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

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

我们上篇文章讲过两地三中心这个架构，如下图：

这种架构具备容灾能力，比如生产数据中心停电了，那么可以把所有流量都切到同城灾备中心或异地灾备中心，那么现在的问题是假如真到了停电的那一天，你敢把所有的流量都切到灾备中心去吗？

上篇文章说了，灾备中心它主要的功能是作为生产数据中心的一个备份，所以它并没有如同生产数据中心一样不停的在对外提供服务，那么就有问题了，灾备相当于一个新人，一个一直在模仿大哥的一个新人，现在大哥受伤了，按道理是应该小弟顶上，但是小弟还是个新人，硬顶上去是不是很有可能会出错？也就是说：

第一，不能保证灾备中心有能力接管线上所有的用户流量，可能刚已接收灾备中心被压垮，或者出现其他各种各样预估不到的错误；
第二，如果生产数据中心接收了用户的写请求，还没来得及同步到灾备中心，这个时候停电了，这种情况下，也不能直接把用户流量切到灾备中心。

所以基于上面的分析，并不是说灾备中心一定不能顶上，只是在顶上之前可能还要做很多其他的检查和准备，这个时间是不确定的，至少不会很快...。

那么问题来了，该怎么办？

首先对于上面列出来的两点中的第一点，如果我们能够让灾备中心不再仅仅只能用来做灾备，还能和生产数据中心一样正常的对外提供服务呢？如下图：

可以看到上面的架构图：

不再区分生产数据中心和灾备数据中心，只有数据中心，而且数据中心之间相互备份数据，保证每个数据中心都是全量数据。
用户可以在任意一个数据中心上进行读写操作。

好，首先我们不管这种架构能不能实现，至少它的好处是非常明显的：

每个数据中心一直在对外提供服务（不是一个新手），所以当一个数据中心停电后，直接把用户流量切到另外一个数据中心也是问题不大的。
用户可以就近访问数据中心，这样用户的体验更好，并且整个架构的流量也比较平均。

优点很明显，如果能实现就再好不过了，那么这种架构实现起来最重要的一点就是：用户同时向不同数据中心写入数据，数据中心双向同步数据时，如果出现冲突该如何解决？

那么这个问题，目前阿里和蚂蚁金服的解决办法是：将用户按某一个规则进行分组，每组用户写入数据时只能写入到指定的数据中心，相当于用户与数据中心绑定在一起了，这样保证了数据中心在双向同步之前数据是不会冲突的，因为按用户分组了，不同用户的数据不会冲突。

当然思路非常简单，但是实现起来肯定是非常麻烦的，但是思路肯定是可以的，阿里也用实践证明了，我们先把上面的架构稍微完善一下：

用户使用网站时，由运营商网络或CDN选择最近的机房，机房内部署一个负载均衡，由这个负载均衡最终判断用户属于机房（前文中的数据中心），也就是可能出现，用户在注册时在北京，那么他的uid就和北京某个机房绑定了，那么当这个用户在上海使用时，会由上海的负载均衡按照用户分组规则将请求转发到北京绑定的那个机房去（当然并不是所有请求，比如读请求肯定可以直接在上海机房进行读取，所以具体的实现都要看业务怎么实现了，以及负载均衡具体的配置，这里只是把最简单易懂的思路说一下）。

所以，我们现在可以

假设北京机房1应用程序或数据库对应的机器停电了，那么我们可以调整负载均衡是原本属于这个机房的用户流量转移到机房2去，注意这里不要有疑问，将用户进行分组是为了防止用户同时写两个数据库发生冲突，那么现在机房1里其实已经不能写入数据了，所以将流量迁移到机房2是没有问题的。
假设北京机房1整个停电了，那么可以通过运营商网络或CDN将流量迁移到北京机房2。
假设北京停电了，那么一样可以将流量迁移到上海。

这个架构中最重要的其实就是用户分组，所以包括我们的应用程序、数据库负载均衡、数据库分表等等都需要按用户进行分组，我们要保证针对同一个用户的请求与操作都在同一个机房内，不去跨机房，这样才是最快的，这就是单元化。

那么上面这个架构实际上就是一个高级版的“两地三中心”，只是这种单元化架构我们可以任意去扩展（只要你足够有钱，因为搭一套全配置的数据中心是需要很高成本的），比如你在上海在增加一个数据中心，在杭州也增加一个，那么就如下图：