我的天，你们公司的“微服务”简直就是反人类…(9)

表字段说明：

id：自增 id

span_id：唯一 id

pspan_id：父级 span_id

service_name：服务名称

api：api 路径

stage：阶段/状态

timestamp：插入数据时的时间戳

上表中的 stage 中的状态解释为：

CS(Client Sent 客户端发送)：客户端发送一个请求，表示 Span 的开始。

SR(Server Received 服务端接收)：服务端接收请求并开始处理它。(SR - CS)等于网络的延迟。

SS(Server Sent 服务端发送)：服务端处理请求完成，开始返回结束给服务端。(SR - SS)表示服务端处理请求的时间。

CR(Client Received 客户端接收)：客户端完成接受返回结果，此时 Span 结束。(CR - CS)表示客户端接收服务端数据的时间。

根据这个表我们就能很快的分析上面提到的两个问题：

如果以上任何一步有问题，那么当前调用就不是完整的，我们必然能追踪出来。

通过每一步的调用时间进行分析，我们也必然知道阻塞在哪一步，从而对调用慢的地方进行优化。

现有的分布式 Trace 基本都是采用了 Google 的 Dapper 标准。

Dapper 的思想很简单，就是在每一次调用栈中，使用同一个 TraceId 将不同的 Server 联系起来。

一次单独的调用链也可以称为一个 Span，Dapper 记录的是 Span 的名称，以及每个 Span 的 ID 和父 ID，以重建在一次追踪过程中不同 Span 之间的关系。

对于一个特定的 Span，记录从 Start 到 End，首先经历了客户端发送数据，然后 Server 接收数据，然后 Server 执行内部逻辑，这中间可能去访问另一个应用。执行完了 Server 将数据返回，然后客户端接收到数据。

在整个过程中，TraceId 和 ParentId 的生成至关重要。首先解释下 TraceId 和 ParentId。

TraceId 是标识这个调用链的 Id，整个调用链，从浏览器开始放完，到 A 到 B 到 C，一直到调用结束，所有应用在这次调用中拥有同一个 TraceId，所以才能把这次调用链在一起。

既然知道了这次调用链的整个 Id，那么每次查找问题的时候，只要知道某一个调用的 TraceId，就能把所有这个 Id 的调用全部查找出来，能够清楚的知道本地调用链经过了哪些应用，产生了哪些调用。但是还缺一点，那就是链。

基于这种需求，目前各大厂商都做出了自己的分布式追踪系统：

目前国内开源的有：阿里的鹰眼，美团的 CAT，京东的 Hydra，还有广为人知的个人开源 Apache 顶级项目 SkyWalking。

国外的有：Zipkin，Pinpoint。

Spring Cloud Sleuth+Zipkin：Spring Cloud Sleuth 实现了一种分布式的服务链路跟踪解决方案，通过使用 Sleuth 可以让我们快速定位某个服务的问题。

简单来说，Sleuth 相当于调用链监控工具的客户端，集成在各个微服务上，负责产生调用链监控数据。

通过 Sleuth 产生的调用链监控信息，让我们可以得知微服务之间的调用链路，但是监控信息只输出到控制台始终不太方便查看。

所以我们需要一个图形化的工具，这时候就轮到 Zipkin 出场了。Zipkin 是 Twitter 开源的分布式跟踪系统，主要用来收集系统的时序数据，从而追踪系统的调用问题。

Spring Cloud Slueth 聚焦在链路追踪和分析，将信息发送到 Zipkin，利用 Zipkin 的存储来存储信息。

当然，Zipkin 也可以使用 ELK 来记录日志和展示，再通过收集服务器性能的脚本把数据存储到 ELK，则可以展示服务器状况信息。

Pinpoint：数据分析非常完备。提供代码级别的可见性以便轻松定位失败点和瓶颈，对于执行的 SQL 语句，都进行了记录。

还可以配置报警规则等，设置每个应用对应的负责人，根据配置的规则报警，支持的中间件和框架也比较完备。

Pinpoint 是一个完整的性能监控解决方案：有从探针、收集器、存储到 Web 界面等全套体系。

Pinpoint 提供有 Java Agent 探针，通过字节码注入的方式实现调用拦截和数据收集，可以做到真正的代码无侵入，只需要在启动服务器的时候添加一些参数，就可以完成探针的部署。

对于这一点，Zipkin 使用修改过的类库和它自己的容器(Finagle)来提供分布式事务跟踪的功能。

但是，它要求在需要时修改代码。Pinpoint 是基于字节码增强的方式，开发人员不需要修改代码，并且可以收集到更多精确的数据因为有字节码中的更多信息。

相对来说，Pinpoint 界面显示的更加丰富，具体到调用的 DB 名，Zipkin 的拓扑局限于服务于服务之间。

SkyWalking：和 Pinpoint 有一种既生瑜何生亮的感叹。

SkyWalking 逻辑上分为四部分：

探针(SkyWalking-agent)

平台后端(oap-server)

存储(es)

用户界面(apm-webapp)

探针基于不同的来源可能是不一样的(原生代理，SDK 以及 Zipkin，Jaeger 和 OpenCensus )，但作用都是收集数据、将数据格式化为 SkyWalking 适用的格式。

平台后端是一个支持集群模式运行的后台、用于数据聚合、数据分析以及驱动数据流从探针到用户界面的流程。

平台后端还提供了各种可插拔的能力，如不同来源数据(如来自 Zipkin)格式化、不同存储系统以及集群管理，你甚至还可以使用观测分析语言来进行自定义聚合分析。

存储是开放式的，你可以选择一个既有的存储系统，如 ElasticSearch，H2 或 MySQL 集群(Sharding-Sphere 管理)、也可以选择自己实现一个存储系统。

用户界面对于 SkyWalking 的最终用户来说非常炫酷且强大、同样它也是可定制以匹配你已存在的后端的。

总结

以上是微服务全链路过程中需要经历的阶段，当然还不包括发布系统的搭建，底层数据治理能力。

所以提倡微服务可以，但是真的做起来不是所有公司都能做得到。小公司能做到服务拆分但是相应的配套设施不一定能跟上，大公司有人有钱有时间，才能提供这些基础设施。

（编辑：ASP站长网）