从0开始学微服务
胡忠想
微博技术专家
立即订阅
16289 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务,从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务?
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务?
05 | 如何注册和发现服务?
06 | 如何实现RPC远程服务调用?
07 | 如何监控微服务调用?
08 | 如何追踪微服务调用?
09 | 微服务治理的手段有哪些?
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地?
13 | 开源服务注册中心如何选型?
14 | 开源RPC框架如何选型?
15 | 如何搭建一个可靠的监控系统?
16 | 如何搭建一套适合你的服务追踪系统?
17 | 如何识别服务节点是否存活?
18 | 如何使用负载均衡算法?
19 | 如何使用服务路由?
20 | 服务端出现故障时该如何应对?
21 | 服务调用失败时有哪些处理手段?
22 | 如何管理服务配置?
23 | 如何搭建微服务治理平台?
24 | 微服务架构该如何落地?
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化?
26 | 微服务容器化运维:镜像仓库和资源调度
27 | 微服务容器化运维:容器调度和服务编排
28 | 微服务容器化运维:微博容器运维平台DCP
29 | 微服务如何实现DevOps?
30 | 如何做好微服务容量规划?
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio:Service Mesh的代表产品
35 | 微博Service Mesh实践之路(上)
36 | 微博Service Mesh实践之路(下)
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密(上) | 微博信息流是如何实现的?
微博技术解密(下)| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务,从入门到精通
从0开始学微服务
登录|注册

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

胡忠想 2018-11-01
专栏前面我在讲服务治理时提到过,为了实现高可用性,微服务一般要部署在多个机房,保证有一个机房因为各种不可抗力因素导致不可用时,可以把流量切换到其他可用机房来避免故障。但是,是不是只要部署到多个机房就万事大吉了呢?你有没有想过这几个问题呢?
一切正常时用户请求该访问哪个机房?
多个机房之间的数据如何同步?
多个机房之间的数据如何确保持一致性?
你看多机房部署并非看似那么轻松,里面还有不少门道。接下来,我就以微博业务实践为例,跟你聊聊微服务实际进行多机房部署时是如何解决这些关键问题的

多机房负载均衡

当服务部署在多个机房时,最简单的就是遵循用户就近访问的原则,比如北方用户访问联通机房,南方用户访问电信机房。微博的服务也是同时部署在联通和电信机房,你可以看下面这张图,访问时根据用户访问的 IP,通过 DNS 解析到不同的机房,如果是北方用户就访问联通机房,南方用户就访问电信机房。并且为了实现负载均衡,还会在每个机房分别部署四层负载均衡器 VIP 以及七层负载均衡器 Nginx。比如来自北方用户的请求通过 DNS 解析到联通机房下任意一个 VIP,然后通过 VIP 把请求转发给联通机房下任意一个 Nginx,Nginx 再把请求转发给联通机房下任意一个 Tomcat 容器,通过这种方式来实现各个机房内高并发访问下的负载均衡。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • 每天晒白牙
    看完有几个疑惑点
    1.独立机房部署的情况,虽然通过WMB在两个机房之间进行数据同步,但都只更新缓存,更新数据库还是由主库更新,然后通过binlog同步给从库,如果主库有问题,从库并未写数据库只是写了缓存,数据库中数据就不会更新了,只剩下缓存来扛流量。新的写请求只会写缓存不会写数据库,如果这时候来的请求数据恰好在缓存中失效了,就查不到数据了。
    2.关于数据一致性问题,文中给的方案是通过定时任务扫描es,通过比较不同机房相同requestid对应的处理状态,如果相同数据一致不做处理。如果不一致,进行重拾操作,达到一致。这种方案觉得是最终一致性,而不是准实时一致。阿忠伯有啥准实时一致方案推荐吗?
    3.这种多机房部署和业界说的那种异地多活是同一种概念吗?
    ps 留言了好几次了,阿忠伯回复我一次吧😂

    作者回复: 第一个问题确实存在 如果从库同步延迟,只有缓存更新成功了,穿透访问数据库就会数据不一致,所以要保证数据库同步的及时性。
    第二个问题看你理解的准实时有多实时,如果是秒级别的话目前里看还是强一致性的方案靠谱,但是这种方案比较复杂,需要付出一定的性能代价,对微博的业务场景来说目前没有这个强一致性的需求。
    第三个问题异地多活就是靠多机房部署才能实现。

    2018-11-01
    17
  • 拉欧
    同步一般有三种方式:应用层同步,缓存层同步,存储层同步,复杂度上也是由高到低排列,一般应用的话,存储层同步就够了

    作者回复: 说的很对👍

    2018-11-01
    4
  • 李俊
    文章里没写如何保证强一致性?

    作者回复: 目前微博业务要求的是最终一致性,强一致性还没达到

    2018-11-17
    3
  • asdf100
    如果有的机房某一阶段处理失败,则可以根据日志信息重试该阶段直到成功,从而保证数据的最终一致性。
    ---------------
    这时再重试会不会导致数据不一致的?假如失败后,数据被后面的请求进行了修改,如果再重试原来失败的请求,数据不是不一致了吗?

    作者回复: 重试的前提是要满足服务的幂等

    2018-11-03
    3
  • xylsh
    写操作可能是有先后顺序的,比如a b c 3个写操作需要按照顺序写入,a c成功,b失败,定时线程重试b的时候,会导致c操作好的结果不正确,这种情况怎么处理的?
    2019-07-20
    2
  • 西兹兹
    如果光缆被挖断了,在修复光缆之前,如何在电信机房写入数据库呢。 方案二
    2019-01-07
    1
  • 波波安
    对于redis我们在两个机房采取的策略是主从复制保持数据一致。保证A机房中的主节点在B机房中有从节点,反过来也是。
    2018-11-18
    1
  • 风轨
    如何做到缓存与数据库一致呢,缓存数据库不一致如何处理呢,写操作如果只写成功了缓存,数据以谁为呢?

    作者回复: 一般都是先写数据库再写缓存,以数据库的操作为准

    2018-11-02
    1
  • 每天晒白牙
    越到后面文章越好看

    作者回复: 后面就全是实践了,希望你能有所收获,哈哈

    2018-11-01
    1
  • 衣申人
    数据同步还涉及消息顺序问题,rpc方式如何确保顺序同步?
    2019-09-10
  • godtrue
    看结构图是强依赖缓存的,如果电信的缓存挂了,对应的服务是否就不可用了?还是此时能切到联通去?
    分布式系统的数据一致性是个难题,做到强一致更加复杂。
    赶集思路就是这两种啦:
    1:单写
    2:多写+同步
           同步可以日志、MQ、RPC
    2019-06-16
  • Enjoystudy
    多机房部署有个很重要的原则就是通过路由策略保证同一个用户的请求(至少写请求)打到同一个机房,尽量避免多个机房同时写数据导致的各种问题,在入口处和RPC的时候都需要做路由
    2019-03-22
  • 饭粒
    请问下,独立机房架构下,不同机房的数据库都是可写的吗,数据库是主-主模式?还是说固定一个机房的数据库写?
    2019-03-13
  • Mangosteen
    2. 独立机房架构
    既然两机房处理机得到的数据时一致的,为什么电信机房不能直接从处理机写入数据库而要用联通的binlog
    2019-03-12
  • 梦朝思夕
    这样的实践方式的确很折中,机房缓存的同步起码是秒级以上,
    2019-03-04
  • 西兹兹
    独立机房方案,如果联通机房挂了,那如何写电信机房的数据库呀?
    2019-01-07
  • 明天更美好
    胡老师,请教个问题,我们对性能有要求,所以数据全量缓存分布式缓存中,通过消息异步更新库,数据库是分布式的。需要携带分片键。所以性能一搬。故而全量缓存。但是数据有差异,怎么做到最终一致性呢

    作者回复: 我上面说得通过对账机制就是一种方案

    2018-11-01
  • 每天晒白牙
    看完有两个疑惑点
    1.独立机房部署的情况,虽然通过WMB在两个机房之间就行数据同步,但都只更新缓存,更新数据库还是由主库更新,然后通过binlog同步给从库,如果主库有问题,从库并未写数据库只是写了缓存,数据库中数据就不会更新了,只有缓存来扛。
    2.关于一致性问题,文章给出的方案是通过定时任务每分钟在es中扫描requestid相同机房不同的处理状态信息,判断是否一致,不一致的进行充实直到一直,这种也是最终一致性,阿忠伯有啥准实时同步的方案吗?
    我都留了好多言了,阿忠伯从不回复我😂

    作者回复: 1.确实有这个问题,在异常情况下要靠缓存来扛。
    2.实时同步只能是靠强一致性的解决方案,这样业务性能肯定会有一定影响,代码复杂度也会增加不少,阿里和腾讯都有自己的成熟方案,可以去看看。

    2018-11-01
收起评论
18
返回
顶部