从0开始学微服务
胡忠想
微博技术专家
立即订阅
16281 人已学习
课程目录
已完结 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开始学微服务
登录|注册

08 | 如何追踪微服务调用?

胡忠想 2018-09-08
在微服务架构下,由于进行了服务拆分,一次请求往往需要涉及多个服务,每个服务可能是由不同的团队开发,使用了不同的编程语言,还有可能部署在不同的机器上,分布在不同的数据中心。
下面这张图描述了用户访问微博首页,一次请求所涉及的服务(这张图仅作为示意,实际上可能远远比这张图还要复杂),你可以想象如果这次请求失败了,要想查清楚到底是哪个应用导致,会是多么复杂的一件事情。
如果有一个系统,可以跟踪记录一次用户请求都发起了哪些调用,经过哪些服务处理,并且记录每一次调用所涉及的服务的详细信息,这时候如果发生调用失败,你就可以通过这个日志快速定位是在哪个环节出了问题,这个系统就是今天我要讲解的服务追踪系统

服务追踪的作用

在介绍追踪原理与实现之前,我们先来看看服务追踪的作用。除了刚才说的能够快速定位请求失败的原因以外,我这里再列出四点,它们可以帮你在微服务改造过程中解决不少问题。
第一,优化系统瓶颈。
通过记录调用经过的每一条链路上的耗时,我们能快速定位整个系统的瓶颈点在哪里。比如你访问微博首页发现很慢,肯定是由于某种原因造成的,有可能是运营商网络延迟,有可能是网关系统异常,有可能是某个服务异常,还有可能是缓存或者数据库异常。通过服务追踪,可以从全局视角上去观察,找出整个系统的瓶颈点所在,然后做出针对性的优化。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(30)

  • Realm
    1 监控是若干个局部,单独采集、分析、展示;追踪是全局视角,有链的上下游传递的概念,通过某个id串联相关的监控;
    2 诊断故障一般从链上分析出现问题的点,然后定位到点上的监控数据,看具体原因;

    作者回复: 嗯

    2018-09-08
    14
  • topsion
    胡老师,微博个人主页刷半天才能出来?为啥现在还没修复?
    2018-09-15
    9
  • 要是结合docker,不用侵入式的追踪系统就完美了

    作者回复: mesh思路可以

    2018-09-08
    7
  • 拉欧
    两者的维度不同:服务追踪系统关心的是单次调用的性能,这其中可能跨越多个服务;服务监控系统关心的是单个服务的性能,主要包括服务质量,甚至机器性能等指标;
    两者是互为补充的关系,服务监控系统可以及时发现服务内部出现的问题,但是所有服务运行正常,不代表跨服务调用一定正常,因为网络本身就是不可靠的,所以需要服务追踪系统发现服务之间可能出现的问题,这样对于系统的监控才算完备
    2018-09-08
    7
  • Liam
    一般排查bug都是从整体到局部,分布式链路追踪就是从整体把握业务执行的的过程,定位问题的区域后再具体分析,监控系统会收集每个节点的数据,包括日志,性能,资源,异常等,根据这些数据进一步定位问题的原因
    2018-09-08
    6
  • 何磊
    日志上报的阶段是不是在rpc的四个过程中都应该上报?比如在ss阶段,由于服务端挂了,没有响应数据。那么这次rpc调用就无法查询了?
    2018-09-09
    4
  • andyXH
    相同:
    1.整个流程一致。


    不同:
    数据采集维度不一样。监控采集单个服务或整个业务详细业务数据,而追踪系统采集是调用链路过程中调用埋点数据即非业务数据。

    作者回复: 对的

    2018-09-10
    3
  • 弥朵
    请问什么是埋点呀
    2018-09-09
    3
  • 云中漫步
    一直不太懂,微服务怎么把一个交易组装起来,怎么编排,调用哪些服务。希望能得到这方面的知识。^_^
    2018-09-08
    3
  • kane
    我们团队当前也有这个痛点,我们的解决办法是:1.在调用链的源头生成TraceID,每个微服务在处理请求的时候将相关信息打印到日志文件2.通过ELK进行日志收集,可以在elk里进行traceid的检索。这样每次检索就把一次调用处理的所有日志都显示出来,提高问题定位的效率。对于老师讲的内容主要有两个问题,1.日志主动上报,会不会对微服务的资源有比较大的消耗呢?特别是比较频繁的调用处理。2.服务调用的耗时怎么计算的,没太看懂。

    作者回复: 主动上报采用udp方式对性能影响可以接受,另外服务调用的耗时也可以靠上报调用耗时来统计

    2018-10-30
    1
  • 波波安


    相同之处有系统的搭建都需要数据采集,数据处理,数据存储和数据展示这些步骤

    不同之处是服务监控系统主要监控局部的业务数据和日志,服务状况等。服务追踪系统是全局链路的一个调用跟踪。一般与业务无关

    2018-10-13
    1
  • 回复何磊“日志上报的阶段是不是在rpc的四个过程中都应该上报?比如在ss阶段,由于服务端挂了,没有响应数据。那么这次rpc调用就无法查询了?”
    服务端挂了,客户端会收到异常,还是可以在cr阶段上报

    作者回复: 对,客户端等到超时或者异常,就会记录下错误上报

    2018-09-10
    1
  • asdf100
    1.在每个请求涉及的四个点都要收集数据并上报,这样在原始业务代码里写上报代码是不是耦合性太强了?
    2.假如其中一个调用超市未返回数据,导致多次调用都无法收到服务端的返回信息,如何处理?
    2018-09-10
    1
  • 铂金小猪
    链路不是http呢?

    作者回复: 也可以的,就是埋点采集的代码不同

    2018-09-08
    1
  • 钟杰
    服务追踪主要是发现故障点,服务监控数据用于找出什么原因导致这个故障点发生故障
    2019-10-24
  • 杨恒连
    容器现在已经很厉害,所有的追踪都在容器化这一层做了处理
    2019-07-22
  • godtrue
    好东西呀😄
    我们好像没有这个,有调用链的追踪也是进程内的,而且使用起来也不太方便。

    正如其他同学回答的,监控系统的关注点在局部,凡人视角。追踪系统的关注点在全局,上帝视角。

    关注局部是为了了解更多的个体信息,关注整体一般是为了定位瓶颈看谁最慢。

    单机性能压测时通过监控系统能了解单机的最佳性能,以及机器的各种性能指标,可以针对单机的性能瓶颈进行优化。

    全链路压测时,如果有分布式的性能追踪系统,那定位性能瓶颈就方便多啦!
    2019-05-22
  • gongxt
    老师列举的似乎都是侵入性太强的工具,有没有其它方法呢?
    2019-03-14
  • gongxt
    相同点:
    1、都有采集端(agent)进行独立上报
    2、服务端收到数据都会对数据进行聚合计算,原始值的存储。这里不同的存储服务有不同的实现
    不同点:
    1、业务不一样,链接追踪主要针对请求链路进行处理,监控主要是针对服务内的业务指标包括不限于指标,日志等
    2、实现方式不一样,监控是时间序列数据库(基于lsm),而trace就不是了(应该是基于树)
    2019-03-14
  • 饭粒
    监控是对某种对象(功能,接口,硬件资源)的特定性能指标的监测,数据采集的过程可以不侵入业务代码。
    追踪是对服务整个RPC调用关系链的追踪,采集数据一般要通过在业务代码埋点获取。
    2019-03-11
收起评论
30
返回
顶部