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

胡忠想



该思维导图由 AI 生成，仅供参考

专栏前面我在讲服务治理时提到过，为了实现高可用性，微服务一般要部署在多个机房，保证有一个机房因为各种不可抗力因素导致不可用时，可以把流量切换到其他可用机房来避免故障。但是，是不是只要部署到多个机房就万事大吉了呢？你有没有想过这几个问题呢？
一切正常时用户请求该访问哪个机房？
多个机房之间的数据如何同步？
多个机房之间的数据如何确保持一致性？
你看多机房部署并非看似那么轻松，里面还有不少门道。接下来，我就以微博业务实践为例，跟你聊聊微服务实际进行多机房部署时是如何解决这些关键问题的。
多机房负载均衡当服务部署在多个机房时，最简单的就是遵循用户就近访问的原则，比如北方用户访问联通机房，南方用户访问电信机房。微博的服务也是同时部署在联通和电信机房，你可以看下面这张图，访问时根据用户访问的 IP，通过 DNS 解析到不同的机房，如果是北方用户就访问联通机房，南方用户就访问电信机房。并且为了实现负载均衡，还会在每个机房分别部署四层负载均衡器 VIP 以及七层负载均衡器 Nginx。比如来自北方用户的请求通过 DNS 解析到联通机房下任意一个 VIP，然后通过 VIP 把请求转发给联通机房下任意一个 Nginx，Nginx 再把请求转发给联通机房下任意一个 Tomcat 容器，通过这种方式来实现各个机房内高并发访问下的负载均衡。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入探讨了微服务多机房部署的关键问题和解决方案。首先，文章提出了在多机房部署中需要解决的问题，包括负载均衡、数据同步和数据一致性。针对负载均衡，介绍了根据用户就近访问原则进行流量调配的方法，并探讨了实际部署中可能遇到的情况。在数据同步方面，详细介绍了主从机房架构和独立机房架构两种数据同步方案，并重点讲解了WMB消息同步组件的实现原理。最后，讨论了多机房数据一致性的保证方法，重点介绍了通过消息对账机制来实现数据的最终一致性。整体而言，本文对于需要实践经验的技术人员具有一定的参考价值，尤其对于微服务多机房部署的关键问题和解决方案有着深入浅出的介绍。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学微服务》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(22)

最新
精选

每天晒白牙
看完有几个疑惑点 1.独立机房部署的情况，虽然通过WMB在两个机房之间进行数据同步，但都只更新缓存，更新数据库还是由主库更新，然后通过binlog同步给从库，如果主库有问题，从库并未写数据库只是写了缓存，数据库中数据就不会更新了，只剩下缓存来扛流量。新的写请求只会写缓存不会写数据库，如果这时候来的请求数据恰好在缓存中失效了，就查不到数据了。 2.关于数据一致性问题，文中给的方案是通过定时任务扫描es，通过比较不同机房相同requestid对应的处理状态，如果相同数据一致不做处理。如果不一致，进行重拾操作，达到一致。这种方案觉得是最终一致性，而不是准实时一致。阿忠伯有啥准实时一致方案推荐吗？ 3.这种多机房部署和业界说的那种异地多活是同一种概念吗？ ps 留言了好几次了，阿忠伯回复我一次吧😂
作者回复: 第一个问题确实存在如果从库同步延迟，只有缓存更新成功了，穿透访问数据库就会数据不一致，所以要保证数据库同步的及时性。第二个问题看你理解的准实时有多实时，如果是秒级别的话目前里看还是强一致性的方案靠谱，但是这种方案比较复杂，需要付出一定的性能代价，对微博的业务场景来说目前没有这个强一致性的需求。第三个问题异地多活就是靠多机房部署才能实现。
2018-11-01

25
拉欧
同步一般有三种方式:应用层同步，缓存层同步，存储层同步，复杂度上也是由高到低排列，一般应用的话，存储层同步就够了
作者回复: 说的很对👍
2018-11-01

12
asdf100
如果有的机房某一阶段处理失败，则可以根据日志信息重试该阶段直到成功，从而保证数据的最终一致性。 --------------- 这时再重试会不会导致数据不一致的？假如失败后，数据被后面的请求进行了修改，如果再重试原来失败的请求，数据不是不一致了吗？
作者回复: 重试的前提是要满足服务的幂等
2018-11-03

8
李俊
文章里没写如何保证强一致性？
作者回复: 目前微博业务要求的是最终一致性，强一致性还没达到
2018-11-17

5
每天晒白牙
越到后面文章越好看
作者回复: 后面就全是实践了，希望你能有所收获，哈哈
2018-11-01

3
风轨
如何做到缓存与数据库一致呢，缓存数据库不一致如何处理呢，写操作如果只写成功了缓存，数据以谁为呢？
作者回复: 一般都是先写数据库再写缓存，以数据库的操作为准
2018-11-02

2
每天晒白牙
看完有两个疑惑点 1.独立机房部署的情况，虽然通过WMB在两个机房之间就行数据同步，但都只更新缓存，更新数据库还是由主库更新，然后通过binlog同步给从库，如果主库有问题，从库并未写数据库只是写了缓存，数据库中数据就不会更新了，只有缓存来扛。 2.关于一致性问题，文章给出的方案是通过定时任务每分钟在es中扫描requestid相同机房不同的处理状态信息，判断是否一致，不一致的进行充实直到一直，这种也是最终一致性，阿忠伯有啥准实时同步的方案吗？我都留了好多言了，阿忠伯从不回复我😂
作者回复: 1.确实有这个问题，在异常情况下要靠缓存来扛。 2.实时同步只能是靠强一致性的解决方案，这样业务性能肯定会有一定影响，代码复杂度也会增加不少，阿里和腾讯都有自己的成熟方案，可以去看看。
2018-11-01

2
明天更美好
胡老师，请教个问题，我们对性能有要求，所以数据全量缓存分布式缓存中，通过消息异步更新库，数据库是分布式的。需要携带分片键。所以性能一搬。故而全量缓存。但是数据有差异，怎么做到最终一致性呢
作者回复: 我上面说得通过对账机制就是一种方案
2018-11-01
2
1
秋天的透明雨🌧️
有些术语缩写不是很懂，网上搜了一下，不知道对不对，请老师指正。WMB=Weibo Message Broker，MCQ=MemCache Queue(SimpleQueue Service Over Memcache)
2020-06-28

4
xylsh
写操作可能是有先后顺序的，比如a b c 3个写操作需要按照顺序写入，a c成功，b失败，定时线程重试b的时候，会导致c操作好的结果不正确，这种情况怎么处理的？
2019-07-20

3

收起评论