文章采集调用(设为“星标”，好文章不错过！(组图))

　　文章采集调用(设为“星标”，好文章不错过！(组图))

　　设置为“star”，所以文章不要错过！

　　

　　1 服务跟踪系统的意义

　　

　　1.1 快速定位请求失败的原因

　　

　　在微服务架构下，有很多服务。如果上游请求失败，要找出是哪个应用程序导致它是一场噩梦！

　　

　　如果有系统，它可以跟踪记录用户请求发起了哪些调用，处理了哪些服务，并记录了每次调用所涉及的服务的详细信息。如果调用失败，可以通过日志快速定位问题！

　　1.2 优化系统瓶颈

　　

　　通过记录调用经过的每个环节的耗时，可以快速定位整个系统的瓶颈点。比如你访问xxx网站的首页，发现速度很慢，可能是运营商网络延迟、网关系统异常、服务异常、缓存或者DB异常。通过服务跟踪，可以从上帝视角看到整个系统的瓶颈点，然后针对性的优化。

　　1.3 优化链接调用

　　

　　分析调用经过的路径，评估是否合理，每个依赖是否必要，是否可以通过业务优化减少服务依赖。

　　一般情况下，服务部署在多个数据中心，实现异地容灾。此时服务A经常调用另一个数据中心的服务B，而不会调用同一个数据中心的服务B。

　　跨数据中心的呼叫会根据距离有一定的网络延迟，这对于某些业务来说是无法接受的。通过分析调用链，可以识别和优化跨数据中心的服务调用。

　　1.4 生成网络拓扑

　　

　　通过记录的链路信息，可以生成系统的网络调用拓扑图，可以反映系统依赖哪些服务，服务之间的调用关系是什么，一目了然。

　　服务调用的详细信息也可以标注在网络拓扑图上，也可以起到服务监控的作用。

　　1.5 数据透传

　　

　　业务中经常有需求，期望从调用开始就可以传递一些用户数据，让系统中的每个服务都能获取到这些信息。比如一个业务要做一些A/B测试，想把A/B测试的切换逻辑一路向下通过服务跟踪系统，经过的每一层服务都可以得到切换值，从而可以统一A/B测试。.

　　

　　2 服务跟踪系统原理

　　

　　服务跟踪系统的鼻祖：Google 的论文 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 详细解释了服务跟踪系统的实现原理。

　　2.1 核心概念

　　

　　

　　

　　跟踪标识

　　

　　全局唯一的 64 位整数，用于标识特定的请求 ID。

　　它在 RPC 调用的网络链路中不断传输，将一个请求在系统中经过的所有路径串联起来。

　　

　　跨度ID

　　

　　它用于标识一个RPC调用在分布式请求中的位置，以及区分系统中不同服务之间的调用顺序。

　　当用户的请求进入系统时，在RPC调用网络第一层A时spanId初始值为0，进入下一层RPC调用B时spanId为0.1，并继续进入下一层RPC调用在C中，spanId为0.1.1，与B同层的RPC调用E的spanId为0.2，这样某个RPC请求就可以通过spanId在系统中定位到调用中的位置，以及它的上下游依赖是谁。这类似于霍夫曼编码。

　　

　　注解

　　

　　用于自定义业务的嵌入点数据。可以是业务感兴趣并想上传到后端的数据，比如一个请求的用户UID。

　　商家自定义一些自己感兴趣的数据，除了上传traceId、spanId等基本信息外，添加一些自己感兴趣的信息。

　　

　　3 服务跟踪系统的实施

　　

　　服务跟踪系统可分为三层：

　　3.1 个数据采集图层

　　

　　在系统的不同模块中嵌入点，采集数据并上报给数据处理层进行处理。

　　那么如何掩埋数据呢？结合下图来了解数据嵌入的过程。

　　

　　以红框圈出的A调用B的过程为例，一个RPC请求可以分为四个阶段。

　　CS（Client Send）阶段：客户端发起请求并生成调用的上下文

　　SR（Server Recieve）阶段：服务器接收请求并生成上下文

　　SS（Server Send）阶段：服务器返回请求。在此阶段，将报告服务器上下文数据。下图显示上报数据为：traceId=123456, spanId=0.1, a*敏*感*词*ey=B, method=B.method, start=103, duration=38

　　CR（Client Recieve）阶段：客户端接收返回的结果。此阶段将报告客户端上下文数据。上报数据为：traceid=123456，spanId=0.1，a*敏*感*词*ey=A，method=B.method，start=103，duration=38。

　　

　　3.2 数据处理层

　　

　　按需计算data采集层上报的数据，然后存储在地面上供查询使用。

　　据我所知，数据处理需求一般分为两类，一类是实时计算需求，一类是离线计算需求。

　　实时计算要求需要较高的计算效率。一般要求采集到的链路数据可以秒级聚合，实时查询。但是，离线计算的需求并不需要那么高的计算效率。一般可以在小时级别完成链路数据的聚合计算，一般用于数据汇总统计。对于这两类不同的数据处理需求，所使用的计算方式和存储也是不同的。

　　3.3 数据表示层

　　

　　数据展示层的作用是将处理后的链接信息以图形方式展示给用户。

　　主要使用以下两个图形：

　　

　　调用链接图

　　

　　从这张图中可以看出：

　　在实际项目中，调用链路图主要用于故障定位。例如，如果用户调用失败，可以通过调用链路图查询用户调用经过了哪些链路，以及调用失败的层级。造成的。

　　

　　呼叫拓扑

　　

　　呼叫拓扑图是全局视图图。在实际项目中，主要用于全局监控，以发现系统中的异常点并快速做出决策。比如某个服务突然出现异常，在调用链路拓扑图中可以看出该服务的调用时间增加了，可以用红*敏*感*词*案标注，用于监控和告警。

　　参考

　　过去推荐

　　厂家如何解决数值精度/舍入/溢出问题

　　大厂数据库事务实践——事务生效后能否正确回滚？

　　在线问题事迹（一)数据库事务没有生效？