微服务多机房部署实践.pdfVIP

31|微服务多机房部署实践

2018-11-01想

31|微服务多机房部署实践

朗读人：想09′55′′|4.55M

专栏前面我在讲服务治理时提到过，为了实现高可用性，微服务一般要部署在多个机房，保证有一

个机房因为各种不可抗力因素导致不可用时，可以把流量切换到其他可用机房来避免故障。但是，

是不是只要部署到多个机房就万事大吉了呢？你有没有想过这几个问题呢？

一切正常时用户请求该哪个机房？

多个机房之间的数据如何同步？

多个机房之间的数据如何确保持一致性？

你看多机房部署并非看似那么轻松，里面还有不少门道。接下来，我就以业务实践为例，跟你

聊聊微服务实际进行多机房部署时是如何解决这些关键问题的。

多机房负载均衡

当署在多个机房时，最简单的就是遵循用户就近的原则，比如北方用户机房，

南方用户电信机房。的服务也是同时部署在和电信机房，你可以看下面这，

时根据用户的IP，通过DNS解析到不同的机房，如果是北方用户就机房，南方用户

就电信机房。并且为了实现负载均衡，还会在每个机房分别部署四层负载均衡器以及七层

负载均衡器Nginx。比如来自北方用户的请求通过DNS解析到机房下任意一个，然后通过

把请求转发给机房下任意一个Nginx，Nginx再把请求转发给机房下任意一个Tomcat

容器，通过这种方式来实现各个机房内高并发下的负载均衡。

当然这是最理想的情况，在实际部署时经常会遇到下面的情况：

某个机房的流量比较大，但是该机房的服务器规模有限并不足以支撑线上流量。

某个机房服务有问题，需要切一部分流量到另外一个机房。

因此在实际部署时，有时候并不能完全遵循就近的原则，根据需要调配流量，达到各个

机房流量均衡的目的。在实践中可以通过两种方法来切换流量：一种是在DNS解析时，把一部分

北方用户的请求解析到电信机房的或者把一部分南方用户的请求解析到机房的；另一

种是在Nginx转发请求时，把一部分电信机房的Tomcat容器配置到机房的Nginx的upstream

里或者把一部分机房的Tomcat容器配置到电信机房的Nginx的upstream里。这两种方法的示

意你可以看下面这。

多机房数据同步

想要实现署到多机房供用户是有前提的，这个前提是每个机房的数据都是一样的，用户

哪个机房都可以获取到一样的数据，这就要求多个机房之间的数据必须保持同步。对于这

种高并发的服务来说，数据通常都会有两层即缓存层和数据库层，就像下图所展示的。缓

存层是为了用户经常的数据，尤其是在高并发下可以用缓存cache住绝大多数用户请

求，减少对数据库层的，这是因为数据库层要直接磁盘，相比缓存层直接内存来说，

响应要慢得多。

如此一来，要保证多个机房的数据一致，不仅要保证数据库层的数据一致，还需要保证缓存层的数

据一致，应该如何实现呢？

1.主从机房架构

主从机房数据同步方案如下图所示。主从机房架构是以一个机房为主机房，所有的写请求都只发给

主机房的处理机，由主机房的处理机来更新本机房的缓存和数据库，其他机房的缓存也通过主机房

的处理机来更新，而数据库则通过MySQL的binlog同步机制的方式实现数据同步。

上面这种架构把所有的写请求都发给主机房，由主机房来负责写所有机房的缓存和本机房的数据

库，而其他机房的数据库则通过MySQL的binlog