从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开始学微服务
登录|注册

阿忠伯的特别放送 | 答疑解惑02

胡忠想 2018-12-18
你好,我是胡忠想。今天我继续来给同学们做答疑,第二期答疑主要涉及微服务架构、注册中心和负载均衡算法,需要一定的基础,如果对这些内容不了解,可以先返回专栏第 14 期第 17 期第 18 期复习一下。
专栏里我主要讲的是基于 RPC 通信的微服务架构,除此之外还有一种微服务架构是基于 MQ 消息队列通信的,下面我就从这两种架构不同的适用场景来给你讲讲它们的区别。
基于 RPC 通信的微服务架构,其特点是一个服务依赖于其他服务返回的结果,只有依赖服务执行成功并返回后,这个服务才算调用成功。这种架构适用于用户请求是读请求的情况,就像下图所描述的那样,比如微博用户的一次 Feed API 请求,会调用 Feed RPC 获取关注人微博,调用 Card RPC 获取微博中的视频、文章等多媒体卡片信息,还会调用 User RPC 获取关注人的昵称和粉丝数等个人详细信息,只有在这些信息都获取成功后,这次用户的 Feed API 请求才算调用成功。
而基于 MQ 消息队列通信的架构,其特点是服务之间的交互是通过消息发布与订阅的方式来完成的,一个服务往 MQ 消息队列发布消息,其他服务从 MQ 消息队列订阅消息并处理,发布消息的服务并不等待订阅消息服务处理的结果,而是直接返回调用成功。这种架构适用于用户请求是写请求的情况,就像下图所描述的那样,比如用户的写请求,无论是发博、评论还是赞都会首先调用 Feed API,然后 Feed API 将用户的写请求消息发布到 MQ 中,然后就返回给用户请求成功。如果是发博请求,发博服务就会从 MQ 中订阅到这条消息,然后更新用户发博列表的缓存和数据库;如果是评论请求,评论服务就会从 MQ 中订阅到这条消息,然后更新用户发出评论的缓存和数据库,以及评论对象收到评论的缓存和数据库;如果是赞请求,赞服务就会从 MQ 中订阅到这条消息,然后更新用户发出赞的缓存和数据库,以及赞对象收到的赞的缓存和数据库。这样设计的话,就把写请求的返回与具体执行请求的服务进行解耦,给用户的体验是写请求已经执行成功,不需要等待具体业务逻辑执行完成。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 老师你好,对于MQ的架构方案有一些疑问。

           以您说的“如果是赞请求,赞服务就会从 MQ 中订阅到这条消息,然后更新用户发出赞的缓存和数据库,以及赞对象收到的赞的缓存和数据库”为例,如果是这种异步的方式,当用户在点赞的时候,恰巧碰到作者删除了文章。用户认为点赞成功(发送完请求就显示成功),但其实"点赞服务"是执行失败的。对于写请求引入MQ的方案又会带来补偿、回滚的问题,该如何权衡?

    实际方案中,对于写请求,采用接口同步调用是否真的会带来很大的性能影响。


    2019-03-01
    1
    1
  • arebya
    自适应最优选择算法就是所谓的WeightedResponseTimeRule
    2018-12-26
    1
  • Jarvis
    最后一个问题,最少连接算法里面,客户端是只根据自己和服务端的连接数来算的吧?不需要知道服务端同所有客户端的连接数
    2019-09-14
  • godtrue
    嗯,赞👍
    2019-06-16
收起评论
4
返回
顶部