全链路日志中间件对比

 技术选型

在进行技术选型时，可以对照表9-1中的全链路日志中间件对比。

表9-1 全链路日志中间件对比

从表9-1中可以看出，可供选择的中间件很多，那么该如何选择呢？项目组讨论后，最终梳理出了以下原则。

◆ 日志数据结构支持OpenTracing

平时日志行都是独立记录的，只能通过线程ID把它们关联起来。因此需要一个数据结构把每个请求在全部服务中的相关日志关联起来。目前已经有一种比较通用的全链路数据格式——OpenTracing，它的标准和API是由一个开源组织Cloud Native Computing Foundation（云原生计算基金会）进行维护的，这个开源组织也包含了一些全链路日志系统的维护者，如图9-2所示。

• 图9-2 OpenTracing协议维护者

OpenTracing通过提供一个与平台/厂商无关的API，使得开发人员能够更方便地添加（或更换）追踪系统，这样即使之前引入的全链路日志不好用，以后想换掉也是非常方便的。

接下来解释一下OpenTracing标准，它主要包含两个概念：一个是Trace，一个是Span。

先来看看下面的例子，如图9-3所示。

• 图9-3 请求调用示意图

从图9-3中可以看到一个客户端调用Order API的请求时经历的整个流程（①~⑩），即一个Trace；Order API调用了Produc Service的整个过程（②~⑤），这就是一个Span。每个Span代表Trace中被命名且被计时的连续性执行片段。

通过图9-3还能发现，Span中又包含了一个子Span，比如调用ProductService的过程中，Product Service会访问一次数据库（③④），这也是一个Span。因此可以得出，一个Span可以包含多个子Span，而Span与Span之间的关系就叫Reference。

在技术选型时，项目组都认可：必须保证系统的可替代性，尽量不要束缚于一项开源技术上。因为以前有过一次教训，当时强依赖了一个框架，结果那个框架不维护了，之后维护相关代码的人就非常痛苦，但是如果全部迁移，代价又太大且工作量也很大，付出与产出比不足以说服领导进行决策；如果不迁移，就只能一直用着过时的技术。所以这次选型使用了基于OpenTracing的日志系统。

◆ 9支持Elasticsearch作为存储系统

诚然，因为流量大的原因，导致记录的日志数据量也很大，这就要求存储这些日志的系统必须支持海量数据且保证查询高效。

最终，因为公司运维人员对Elasticsearch比较熟悉，所以提出可以使用Elasticsearch对日志进行存储。

保证日志的收集对性能无影响

当服务在记录日志时，需要确保日志的记录与收集对服务器的性能不会产生影响。

比如之前调研过Pinpoint，当服务在记录日志时，Pinpoint的并发数达到一定数量时整体吞吐量少了一半，对服务器的性能影响很大，这是不能接受的。

◆ 查询统计功能的丰富程度

一般来说，查询统计功能越丰富越好，但必须首先满足一个基础功能：支持每个请求树状结构的全链路日志（如图9-4和图9-5所示），比如SkyWalking的功能就非常适用。

查询统计系统除了满足基本功能以外，也要实现监控报警、指标统计等功能，以此帮助减轻二次开发的工作量。

如何以最小的业务代码侵入性引入这些功能？

• 图9-4 请求日志列表示意图

• 图9-5 请求日志树状示意图

项目组希望日志数据的收集过程对写业务代码的人保持透明，因此，一种比较理想的解决方案是使用Java的探针，通过字节码加强的方式进行埋点。不过，这种方式对系统性能也会产生一定影响。

而且在实际业务中，公司都会把访问数据库、Redis、MQ的代码进行封装，无法通过字节码加强的方式实现埋点，就只能尝试在封装的代码中实现，这样对开发业务代码的人来说同样透明。

◆ 使用案例

技术选型时，往往还需要了解哪些知名公司使用了这个技术，因为大公司的业务场景相对复杂些，经历的陷阱较多，一个技术如果被很多公司用过，那使用起来也就会稳定很多。

以上就是技术选型的几个判断标准。

◆ 最终选择

根据以上问题剖析及性能测试结果分析，可以发现SkyWalking比较符合需求。

项目组做性能测试时发现，对于500线程压力以下的服务，是否使用SkyWalking对其吞吐量影响不大，一般相差不超过10%。

SkyWalking官方测试报告中也提到：假如有500个并发用户，每个用户的每次请求间隔是10毫秒，TPS基本没什么变化，如图9-6所示。

• 图9-6 SkyWalking压测性能影响

另外，技术选型时不仅要关注需求本身，还需要考虑组织或个人主观上的因素。

最后，根据笔者的实践经验，随着国内技术环境的改善和中国互联网的崛起，如今国产的很多开源框架并不比国外差，反而更贴近实际需求，比如VUE、Dubbo，这也是项目组选择SkyWalking的原因之一。