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

09 | 微服务治理的手段有哪些?

胡忠想 2018-09-11
上一期我给你讲述了服务追踪的基本原理,有了分布式服务追踪系统,在服务出现问题的时候,我们就可以定位服务哪里出现了问题。一般单体应用改造成微服务架构后,还会增加哪些问题呢?又该如何应对呢?
前面我讲到单体应用改造为微服务架构后,服务调用由本地调用变成远程调用,服务消费者 A 需要通过注册中心去查询服务提供者 B 的地址,然后发起调用,这个看似简单的过程就可能会遇到下面几种情况,比如:
注册中心宕机;
服务提供者 B 有节点宕机;
服务消费者 A 和注册中心之间的网络不通;
服务提供者 B 和注册中心之间的网络不通;
服务消费者 A 和服务提供者 B 之间的网络不通;
服务提供者 B 有些节点性能变慢;
服务提供者 B 短时间内出现问题。
可见,一次服务调用,服务提供者、注册中心、网络这三者都可能会有问题,此时服务消费者应该如何处理才能确保调用成功呢?这就是服务治理要解决的问题。
接下来我们一起来看看常用的服务治理手段

节点管理

根据我的经验,服务调用失败一般是由两类原因引起的,一类是服务提供者自身出现问题,如服务器宕机、进程意外退出等;一类是网络问题,如服务提供者、注册中心、服务消费者这三者任意两者之间的网络出现问题。
无论是服务提供者自身出现问题还是网络发生问题,都有两种节点管理手段。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(29)

  • 白鹿
    最少活跃调用法,理想情况下,每个服务提供者的连接数一样多,为什么最适合性能参差不齐的情况?难道不是性能好的连接多,差的连接少,比较好吗?

    作者回复: 性能好的话,连接也释放得快

    2018-09-11
    14
  • Geek_sky
    消费者从内存中摘除此问题用户服务者,那么注册中心是否同步摘除?注册中心不摘除问题服务者的话,是否会又同步给了消费者?这块是怎么处理的呢?
    2018-09-21
    4
  • Geek_c909b6
    注册中心摘除机制说的是不是有问题 应该是把当前时间和最近一次收到心跳的时间做对比吧 超过一定时间 就摘除吧

    作者回复: 是的,这个说法更严谨一些,感谢指正。

    2018-12-08
    3
  • 叽歪
    最少活跃方式,按这个来的话,请求都打到性能不好的机器了?不会压死性能不会的机器吗

    作者回复: 正常情况下,性能不好的机器因为处理慢,所以活跃连接数要比性能好的要多,所以按照最少活跃负载均衡算法的话,请求会更少

    2018-09-25
    3
  • 幻想
    作者果然是老司机,还没见过列举的这么全的,点个赞。
    2018-09-12
    3
  • 海洋
    如果是注册中心宕机,有什么机制来保障调用成功率呢?

    作者回复: 后面专栏有细讲

    2018-09-12
    1
  • ASCE1885
    路由规则应该是存在配置中心而不是注册中心吧?

    作者回复: 看情况,注册中心也可以存配置,两者可以分开部署也可以部署在一起

    2018-09-11
    1
  • hello
    服务消费者摘除机制这里没听懂,消费者的列表不是注册中心给的吗?这里说的是消费者从自己的内存中的服务列表中摘除请求失败的服务吗?
    2019-09-20
  • 时间
    一致性hash是根据请求的IP吧
    2019-06-29
  • godtrue
    赞👍,干货满满
    没有开发过微服务框架不熟悉,原理能听明白,知道是怎么回事!
    2019-05-23
  • 学习
    文中说:如果后端服务节点的配置没有差异,同等调用量下性能也没有差异的话,选择随机或者轮询算法比较合适;如果后端服务节点存在比较明显的配置和性能差异,选择最少活跃调用算法比较合适。
    前者是否应选择随机或者最少活跃调用算法,后者是否应选择轮询算法?
    2019-05-04
    1
  • 江南豆沙包
    胡老师,你好。初探微服务那一篇,服务治理这块说到了自动扩缩容,本文没有说到,这块一般怎么弄?
    2019-03-14
  • 探索无止境
    老师你好,最少活跃调用算法,这个是有消费端实现的吗?我感觉应该是服务端来统计会更准确一些,因为连接服务端可以有多个客户端,那么这个比如在A客户端看来是连接数少了,比如2,但可能B客户端连接数很多,比如200,所以应该看所有客户端加起来的总连接数更准确些,不知道分析得是否正确?还请老师指点!
    2019-03-08
  • 木木木
    由于目前是手机游戏项目,
    负载均衡应用在逻辑和战斗服务的分配上,
    服务路由:根据网络延时分配战斗服
    节点管理: 通过统一的注册中心,其他服务和注册中心进行心跳检查,并且订阅服务状态相关的消息,一旦对应服务挂了,消费者可以知道。不过可能会有延时
    服务容错:现在所有的接口基本都是failfast,直接失败,打印日志处理。
    2019-02-11
  • 何何何何何少侠
    应该是对于幂等的场景才需要查询服务状态吧?
    非幂等等服务请求直接重试就好了啊。
    2019-02-03
  • 西兹兹
    阿忠老师好,请问本章节的服务治理 和 断路器里的服务的降级和限流 之间是什么样的关系呢?
    2019-01-06
  • Bobo
    最小活跃数,消费者维护的仅仅是自己与各个提供者的连接数,并不能得知服务提供者的总消费情况,这样子不能均衡吧

    作者回复: 是的,只知道自身的情况,大部分情况下可以反馈整体的情况

    2018-11-29
  • 看不到de颜色
    关于失败节点摘除有点疑惑。如果靠消费者在调用失败后才摘除异常节点的话,那么岂不会降低系统的稳定性。是否应当是注册中心和消费端一起配合进行服务端状态判断呢?

    作者回复: 对于大流量业务来说,调用失败的次数可以忽略,并且灵敏度要高于使用注册中心

    2018-11-18
  • 王维
    .net 有什么好的微服务框架?.net core 算不算

    作者回复: 不太清楚,.net语言基本没接触过

    2018-11-07
  • 波波安
    请问下,dubbo的节点管理采用的是什么方式?
    2018-10-13
收起评论
29
返回
顶部