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

公众号：大猪蹄子程序员

上篇文章咱们总结了一下同城双活、异地多活、两地三中心等一些部署架构，那么这篇文章我来发表一下我对三地五中心的理解。

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

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

上篇文章说了，灾备中心它主要的功能是做为生产数据中心的一个备份，因此它并无如同生产数据中心同样不停的在对外提供服务，那么就有问题了，灾备至关于一个新人，一个一直在模仿大哥的一个新人，如今大哥受伤了，按道理是应该小弟顶上，可是小弟仍是个新人，硬顶上去是否是颇有可能会出错？也就是说：

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

因此基于上面的分析，并非说灾备中心必定不能顶上，只是在顶上以前可能还要作不少其余的检查和准备，这个时间是不肯定的，至少不会很快...。

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

首先对于上面列出来的两点中的第一点，若是咱们可以让灾备中心再也不仅仅只能用来作灾备，还能和生产数据中心同样正常的对外提供服务呢？以下图：

能够看到上面的架构图：

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

好，首先咱们无论这种架构能不能实现，至少它的好处是很是明显的：

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

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

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

固然思路很是简单，可是实现起来确定是很是麻烦的，可是思路确定是能够的，阿里也用实践证实了，咱们先把上面的架构稍微完善一下：

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

因此，咱们如今能够：

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

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

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

这就叫三地五中心。

市面上浅显的讲述三地五中心的文章很少，但愿这篇文章能给你帮助，固然我也是参考了其余文章有了本身的理解，若是错误的地方欢迎你们指正。

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

公众号：大猪蹄子程序员

参考：

• www.infoq.cn/article/int…
• tech.antfin.com/community/a…