分布式架构正在颠覆企业信息化建设的IT架构。不管是早期的SOA体系，还是当前正在流程的微服务和容器化等，都是从分布式架构角度提升整体系统的吞吐和容错能力。另一方面，分布式架构的发展也带来了监控难度加大。以往的基于日志、性能指标的传统部署架构的监控系统已难以跟上系统高速发展的步伐。

因此，在谈及微服务基础组件时，都会重点提及调用链追踪和监控组件。当前，常见的调用链组件包括Skywalking、Zipkin、Cat和Pinpoint等。

调用链跟踪系统的发展历程

分布式服务跟踪是在整个分布式系统中实现跟踪某用户请求的过程，包括对相关数据的采集、传输、存储、分析和可视化，完成捕获这部分跟踪让开发和运维构建用户交互过程的整个请求调用链的可视化视图，这是一个调试及监控微服务的核心工具。 2010年谷歌发表了其内部使用的分布式跟踪系统Dapper的论文（http://static.googleusercontent.com/media/research.google.com/zh-CN/archive/papers/dapper-2010-1.pdf，译文地址：http://bigbully.github.io/Dapper-translation/），讲述了Dapper在谷歌内部两年的演变和设计、运维经验。借助于Dapper 理念，开发者仅需把 Trace 组件嵌入基础通用库中，就可正常运行，而应用层开发人员则无需要关心具体 的Trace 组件实现和集成方式，达到了以应用层透明的方式嵌入至各个模块的目的。

调用链产品发展历程

当前开源流行的调用链系统的起源为两大类：eBay和Google。Cat发展的源头为eBay的CAL，其他的几个系统均源自2010年google Dapper论文，包括Twitter开源产品Zipkin、携程的CTrace、韩国Naver Pinpoint、UBer的Jaeger和华为Skywalking等。另外，淘宝的鹰眼、京东的Hydra，新浪的Watchman都是不错的链路跟踪和监控系统，但未开源。

调用链跟踪系统(一)：Zipkin介绍

把Zipkin放在最开始介绍，是因为当前Spring Cloud Sleth与Zipkin结合非常好，安装应用起来非常方便，甚至不需要单独进行安装，在Spring Cloud为Finchley版本时，如果只需要默认的实现，则不需要自己构建Zipkin Server了，只需要下载jar即可，当前许多公司都在选择使用Zipkin。

来自Zipkin网站的跟踪查看截图

来自Zipkin网站的依赖图截图

Zipkin 是一个由Twitter公司开发并开源的分布式的跟踪系统，每个服务向zipkin报告计时数据，zipkin会根据调用关系通过Zipkin UI生成依赖关系图。

架构概述

追踪器驻留在应用程序里，并记录发生操作的时间和元数据。这些经常装配在库上，所以对用户来说是透明的。例如，一个已被装配过的 Web 服务器，会在接收请求和发送响应时进行记录。收集的追踪数据叫做Span（跨度）。

生产环境中的装配器应该是安全并且低负载的。因此，带内（in-band）只传输ID，并告诉接收器仍有一个追踪在处理。完成的跨度在带外（out-of-band）汇报给 Zipkin，如同应用程序异步汇报指标。

举例，当追踪一个操作的时候，该操作对外发送了一个 HTTP 请求，那么，为了传输 ID 就会添加一些额外的头部信息。头部信息并不是用于发送像是操作明这样的详细信息的。

装配应用中用于向 Zipkin 发送数据的组件叫做 Reporter。Reporter 通过 Transport发送追踪数据到 Zipkin 的 Collector，Collector 持久化数据到 Storage 中。之后，API 从 Storage 把查询到的数据提供给 UI。

Zipkin流程架构

Zipkin框架

要理解这张图，需要了解一下Zipkin的几个核心概念：

• Reporter

在某个应用中安插的用于发送数据给Zipkin的组件称为Report，目的就是用于追踪数据收集

• Span

微服务中调用一个组件时，从发出请求开始到被响应的过程会持续一段时间，将这段跨度称为Span。Span是一个基本工作单元，如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID的唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)。

span在不断地启动和停止，同时记录了时间信息，当创建了一个span，必须在未来的某个时刻停止它。

• Trace

一系列spans组成的一个树状结构，如果正在执行一个分布式大数据工程，可能需要创建一个trace。从客户端（Client）发出请求到完成请求处理，中间会经历一个调用链，将这整个过程称为一个追踪（Trace）。一个Trace可能包含多个Span，反之每个Span都有一个上级的Trace。

• Transport

一种数据传输的方式，装配库发送的跨度必须由装配的服务传输到 Collector。 有三种主要的传输类型：HTTP、Scribe 和 Kafka。

Zipkin共有如下四个组件构成 ：

• collector
• storage
• search
• web UI

Zipkin Collector

一旦追踪数据抵达 Zipkin Collector 守护进程，Zipkin Collector 为了查询，会对其进行校验、存储和索引。

Storage

Zipkin 最初是构建在将数据存储在 Cassandra 中，因为 Cassandra 易跨站，支持灵活的 schema，并且在Twitter内部被大规模使用。在 Cassandra 之外，原生支持 ElasticSearch 和 MySQL。可作为第三方扩展提供给其它后端。

Zipkin 查询服务

一旦数据被存储索引，就需要一种方式提取它。查询守护进程提供了一个简单的 JSON API 查询和获取追踪数据的方法。API 的主要消费者就是 Web UI。

Web UI

创建了一个用户图形界面为追踪数据提供了一个漂亮的视图。Web UI 提供了基于服务、时间和标记（annotation）查看追踪数据的方法。注意：UI 没有内置的身份认证功能。

Spring cloud提供了spring-cloud-sleuth-zipkin来方便集成zipkin实现（指的是Zipkin Client，而不是Zipkin服务器），该jar包可以通过spring-cloud-starter-zipkin依赖来引入。

springcloud官方按照传输方式分成了三种启动服务端的方式：Sleuth with Zipkin via HTTP，Sleuth with Zipkin via Spring Cloud Stream，Spring Cloud Sleuth Stream Zipkin Collector。

由于采取HTTP的传输方式会存在如下弊端：一是每次发送的时候涉及到连接和发送过程；二是当Zipkin Server关闭或者重启过程中，因为客户端收集信息的发送采用http的方式会被丢失。这里可以在通信采用socket或者其他效率更高的通信方式，以及采用异步传输信息的方式在Zipkin Client和Server之间加入MQ来解决。

在信息传递中加入MQ

要将http方式改为通过MQ通信，需要将依赖的原来依赖的io.zipkin.java:zipkin-server换成spring-cloud-sleuth-zipkin-stream和spring-cloud-starter-stream-rabbit。

调用链跟踪系统(二)：Cat介绍

（1）概述

CAT（Central Application Tracking） 是基于 Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务。CAT的原型和理念来源于eBay的CAL系统，最初是吴其敏在大众点评工作期间设计开发的。他之前曾CAT不仅增强了CAL系统核心模型，还添加了更丰富的报表。CAT提供了 Java, C/C , Node.js, Python, Go 等多语言客户端，在中间件（MVC、RPC、数据库、缓存等）框架中得到广泛应用，为美团点评各业务线提供系统的性能指标、健康状况、监控告警等。自2014年开源以来，除了美团点评之外，CAT还在携程、陆金所、猎聘网、找钢网等多家互联网公司生产环境应用，项目的开源地址是https://github.com/dianping/cat/。

CAT 很大的优势是它是一个实时系统，CAT 大部分系统是分钟级统计，但是从数据生成到服务端处理结束是秒级别，秒级定义是48分钟40秒，基本上看到48分钟38秒数据，整体报表的统计粒度是分钟级；第二个优势，监控数据是全量统计，客户端预计算；链路数据是采样计算。CAT产品价值

• 减少故障发现时间
• 降低故障定位成本
• 辅助应用程序优化

CAT优势

• 实时处理：信息的价值会随时间锐减，尤其是事故处理过程中
• 全量数据：全量采集指标数据，便于深度分析故障案例
• 高可用：故障的还原与问题定位，需要高可用监控来支撑
• 故障容忍：故障不影响业务正常运转、对业务透明
• 高吞吐：海量监控数据的收集，需要高吞吐能力做保证
• 可扩展：支持分布式、跨 IDC 部署，横向扩展的监控系统

（2）CAT整体设计

主要分为三个模块：CAT-client、CAT-consumer、CAT-home。

• Cat-client 提供给业务以及中间层埋点的底层SDK。
• Cat-consumer 用于实时分析从客户端提供的数据。
• Cat-home 作为用户给用户提供展示的控制端。

在实际开发和部署中，Cat-consumer和Cat-home是部署在一个JVM内部，每个CAT服务端都可以作为consumer也可以作为home，这样既能减少整个层级结构，也可以增加系统稳定性。

在实际开发和部署中，cat-consumer和cat-home是部署在一个jvm内部，每个CAT服务端都可以作为consumer也可以作为home，这样既能减少整个CAT层级结构，也可以增加整个系统稳定性。

上图是CAT目前多机房的整体结构图：

• 路由中心是根据应用所在机房信息来决定客户端上报的CAT服务端地址
• 每个机房内部都有的独立的原始信息存储集群HDFS
• cat-home可以部署在一个机房也可以部署在多个机房，在做报表展示的时候，cat-home会从cat-consumer中进行跨机房的调用，将所有的数据合并展示给用户
• 实际过程中，cat-consumer、cat-home以及路由中心都是部署在一起，每个服务端节点都可以充当任何一个角色

（3）CAT客户端设计

客户端设计是CAT系统设计中最为核心的一个环节，客户端要求是做到API简单、高可靠性能、无论在任何场景下客户端都不能影响各业务服务的性能（监控只是公司核心业务流程一个旁路环节）。以下客户端设计以及细节均以java客户端为例子。

设计架构

CAT客户端是java，客户端在收集端数据方面使用ThreadLocal，是线程本地变量，也可以称之为线程本地存储。线程局部变量(ThreadLocal)其实的功用非常简单，就是为每一个使用该变量的线程都提供一个变量值的副本，是Java中一种较为特殊的线程绑定机制，是每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。

在监控场景下，为用户提供服务都是web容器，web容器比如Tomcat或者Jetty，后端的rpc服务端比如dubbo或者点评自研的服务框架pigeon，也都是基于线程池来实现的。业务方在处理业务逻辑时基本都是在一个线程内部调用后端服务，数据库，缓存等，将这些数据拿回来在进行业务逻辑逻辑封装，最后将结果展示给用户。所以将所有的监控请求作为一个监控上下文存入于线程变量就非常合适。

如上图业务执行业务逻辑的时候，就会把此次请求对应的监控存放于线程上下文中，存于上下文的其实是一个监控树的结构。在最后业务线程执行结束时，将监控对象存入一个异步内存队列中，CAT有个消费线程将队列内的数据异步发送到CAT服务端。

API设计

当设计者对监控以及性能分析有足够深度的理解下，才能定义好监控的API，监控和性能分析所针对的场景有如下几种

• 一段代码的执行时间，一段代码可以是URL执行耗时，也可以是SQL的执行耗时
• 一段代码的执行次数，比如程序抛出异常记录次数，或者一段逻辑的执行次数
• 定期执行某段代码，比如定期上报一些核心指标，jvm内存、gc等指标
• 关键的业务监控指标，比如监控订单数、交易额、支付成功率等

在如上的领域模型的基础上，CAT设计自己核心的几个监控对象 Transaction、Event、Heartbeat、Metric

一段监控API的代码示例如下

序列化和通信

序列化和通信是整个客户端包括服务端性能里面很关键的一个环节

• CAT序列化协议是自定义序列化协议，自定义序列化协议相比通用序列化协议要高效很多，这个在大规模数据实时处理场景下还是非常有必要的。
• CAT通信是基于Netty来实现的NIO的数据传输，Netty是一个非常好的NIO开发框架，在这边就不详细介绍。

客户端埋点

日志埋点是监控活动的最重要环节之一，日志质量决定着监控质量和效率。CAT的埋点目标是以问题为中心，像程序抛出exception就是典型问题。我个人对问题的定义是：不符合预期的就可以算问题。比如请求未完成，响应时间快了慢了，请求TPS多了少了，时间分布不均匀等等。

在互联网环境中，典型的突出的容易出问题的场景，包括跨模块调用，跨公司调用等。比如

• HTTP/REST、RPC/SOA、MQ、Job、Cache、DAL;
• 搜索/查询引擎、业务应用、外包系统、遗留系统;
• 第三方网关/银行, 合作伙伴/供应商之间；
• 各类业务指标，如用户登录、订单数、支付状态、销售额。

（4）服务端设计

服务端主要的问题是大数据的实时处理，截止2017年6月后端CAT的计算集群大约100台物理机，存储集群大约50台物理机，每天处理了约200TB的数据量。下面是CAT服务端一些设计细节:

架构设计

服务端单机cat-consumer的整体架构如下：

如上图，CAT服务端在整个实时处理中，基本上实现了全异步化处理。

• 消息接收是基于Netty的NIO实现
• 消息接收到服务端就存放内存队列，然后程序开启一个线程会消费这个消息做消息分发
• 每个消息都会有一批线程并发消费各自队列的数据，以做到消息处理的隔离
• 消息存储是先存入本地磁盘，然后异步上传到hdfs文件，这也避免了强依赖hdfs

当某个报表处理器处理来不及时候，比如Transaction报表处理比较慢，可以通过配置支持开启多个Transaction处理线程，并发消费消息。

实时分析

实时分析CAT服务端实时报表分析是整个监控系统的核心，CAT中客户端采集的是是原始的Logview，目前一天大约有3000亿的消息，所以需要在这些消息基础上实现丰富报表，以支持业务问题以及性能分析的需要。

CAT根据日志消息的特点(比如只读特性)和问题场景，量身定做的。CAT将所有的报表按消息的创建时间，一小时为单位分片，那么每小时就产生一个报表。当前小时报表的所有计算都是基于内存的，用户每次请求即时报表得到的都是最新的实时结果。对于历史报表，因为它是不变的，所以就实时不实时也就无所谓了。

CAT基本上所有的报表模型都可以增量计算，它可以分为：计数、计时和关系处理三种。计数又可以分为两类：算术计数和集合计数。典型的算术计数如：总个数（count），总和（sum），均值（avg），最大/最小（max/min)，吞吐（tps）和标准差（std）等，其他都比较直观，标准差稍微复杂一点，大家自己可以推演一下怎么做增量计算。那集合运算，比如95线（表示95%请求的完成时间），999线（表示99.9%请求的完成时间），则稍微复杂一些，系统开销也更大一点。

报表建模

CAT每个报表往往有多个维度，以transaction报表为例，它有5个维度，分别是应用、机器、Type、Name和分钟级分布情况。如果全维度建模，虽然灵活，但开销将会非常之大。CAT选择固定维度建模，可以理解成将这5个维度组织成深度为5的树，访问时总是从根开始，逐层往下进行。

CAT服务端为每个报表单独分配一个线程，所以不会有锁的问题，所有报表模型都是非线程安全的，其数据是可变的。这样带来的好处是简单且低开销。

CAT报表建模是使用自研的maven plugin自动生成的。所有报表是可合并和裁剪的，可以轻易地将2个或多个报表合并成一个报表。在报表处理代码中，CAT大量使用访问者模式（visitor pattern）。

性能分析报表

故障发现报表

• 实时业务指标监控 ：核心业务都会定义自己的业务指标，这不需要太多，主要用于24小时值班监控，实时发现业务指标问题，图中一个是当前的实际值，一个是基准值，基准值是根据历史趋势计算的预测值。如下图就是当时出故障，直观看到支付业务出问题的故障。

• 系统报错大盘
• 实时数据库大盘、服务大盘、缓存大盘等

存储设计

CAT系统的存储主要有两块

• CAT的报表的存储
• CAT原始logview的存储

报表是根据logview实时运算出来的给业务分析用的报表，默认报表有小时模式，天模式，周模式以及月模式。CAT实时处理报表都是产生小时级别统计，小时级报表中会带有最低分钟级别粒度的统计。天、周、月等报表都是在小时级别报表合并的结果报表。

原始logview存储一天大约300TB的数据量，因为数据量比较大所以存储必须要要压缩，原始logview需要根据messageId读取。在这样的情况下，存储整体要求就是批量压缩以及随机读。在当时场景下，并没有特别合适成熟的系统以支持这样的特性，所以我们开发了一种基于文件的存储以支持CAT的场景，在存储上一直是最难的问题，我们一直在这块持续的改进和优化。

消息ID的设计

CAT每个消息都有一个唯一的ID，这个ID在客户端生成，后续CAT都通过这个ID在进行消息内容的查找。比如在分布式调用里面，RPC消息需要串起来，比如A调用B的时候，在A这端生成一个MessageId，在A调用B的过程中，将MessageId作为调用传递到B端，在B执行过程中，B用context传递的MessageId作为当前监控消息的MessageId。

CAT消息的MessageId格式ShopWeb-0a010680-375030-2，CAT消息一共分为四段

• 第一段是应用名shop-web
• 第二段是当前这台机器的ip的16进制格式，01010680表示10.1.6.108
• 第三段的375030，是系统当前时间除以小时得到的整点数
• 第四段的2，是表示当前这个客户端在当前小时的顺序递增号

存储数据的设计

消息存储是CAT最有挑战的部分。关键问题是消息数量多且大，目前美团点评每天处理消息3000亿左右，大小大约300TB，单物理机每秒要处理200MB左右的流量。CAT服务端基于此流量做实时计算，还需要将这些数据压缩后写入磁盘。

整体存储结构如下图

CAT数据文件分为两种，一类是index文件，一类是Data文件

• data文件是分段GZIP压缩，每个分段大小小于64K，这样可以用16bits可以表示一个最大分段地址
• 一个MessageId都用需要48bits的空间大小来存索引，索引根据MessageId的第四段来确定索引的位置，比如消息MessageId为ShopWeb-0a010680-375030-2，这条消息ID对应的索引位置为2*48bits的位置
• 48bits前面32bits存数据文件的块偏移地址，后面16bits存数据文件解压之后的块内地址偏移
• CAT读取消息的时候，首先根据MessageId的前面三段确定唯一的索引文件，在根据MessageId第四段确定此MessageId索引位置，根据索引文件的48bits读取数据文件的内容，然后将数据文件进行GZIP解压，在根据块内偏移地址读取出真正的消息内容。

服务端设计总结

CAT在分布式实时方面，主要归结于以下几点因素：

• 去中心化，数据分区处理
• 基于日志只读特性，以一个小时为时间窗口，实时报表基于内存建模和分析，历史报表通过聚合完成
• 基于内存队列，全面异步化，单线程化，无锁设计
• 全局消息ID，数据本地化生产，集中式存储
• 组件化、服务化理念

以上的内容主要来源于CAT网站，详细内容可去网站上了解。

调用链跟踪系统(三)：Skywalking介绍

Skywalking是由国内开源爱好者吴晟（原OneAPM工程师，目前在华为）开源并提交到Apache孵化器的产品，它同时吸收了Zipkin/Pinpoint/CAT的设计思路，支持非侵入式埋点。是一款基于分布式跟踪的应用程序性能监控系统。另外社区还发展出了一个叫OpenTracing的组织，旨在推进调用链监控的一些规范和标准工作。

SkyWalking项目的建立和发展，在前期具有很大的偶然性。SkyWalking3.2之前的版本与后面的5.x、6.x有巨大的技术栈和设计差异，其原因即在于此。在2015年建立并开源时，SkyWalking是一套针对分布式系统的培训类系统，用于辅助公司的新员工学习分布式的复杂性以及如何建立监控系统。SkyWalking3.2.x是第一个里程碑版本，它建立了以轻量级架构为核心的设计理念，彻底放弃了HBase等大数据存储技术。SkyWalking多语言探针协议1.0也是在那时建立的，并且一直被SkyWalking所支持。

2017年12月，SkyWalking成为国内首个进入Apache孵化器的个人项目，充分反映了Apache对于项目社区和项目未来的认可。

2018年是项目高速发展的一年，项目团队在2018年发布了SkyWalking5，并得到华为、阿里巴巴等大厂的支持，初步开始被较为广泛地运用。2018年年底，SkyWalking社区迎来第一个生态子项目——SkyWalking的.NETCore探针，这标志着SkyWalkingTracing和Header协议正式被大家接受，并开始围绕此协议进行社区生态建设。

2019年，为了迎合ServiceMesh这个下一代分布式网络架构，SkyWalking项目发布了新一代内核，版本升级为SkyWalking6。SkyWalking6总结了前三年开源社区发展的经验、需求和对未来的规划，通过大量的顶层设计，把面向协议、轻量化、模块化作为核心思想，为传统探针监控和ServiceMesh提供了一致性的解决方案。

2020年，SkyWalking6的大量特性和设计得到延续，社区推出了SkyWalking7，在特定技术方向上做出了进一步的强化。

SkyWalking是一个为微服务、容器化和分布式系统而生的高度组件化的APM项目。早在2010年SOA开始兴起时，应用系统开发人员就注意到，系统的调试过程越来越复杂，在线运行程序出现故障时，面临的问题定位已经很难使用传统日志进行排查。之后随着微服务的兴起，去IOE及分布式架构的广泛采用，程序性能的监控和问题定位需求也越来越急迫。这正是SkyWalking项目诞生的出发点，SkyWalking受GoogleDapper论文启发，整合多位初创成员在APM和互联网公司的工作经验，设立了基于分布式追踪的应用性能监控解决方案。同时，针对中国业务流量大和系统研发团队的特点，SkyWalking首先提出在生产大流量环境下支持100%追踪采样。SkyWalking也是目前唯一一个提出此支持的APM系统。

（1）Skywalking适用场景

SkyWalking不是一个单纯的追踪系统

SkyWalking首先是一个应用性能监控工具，它的目标是应用性能。很多人把SkyWalking和Zipkin、Jaeger作为开源界的竞争对手，而实际上这三个社区的核心成员都不这么看。SkyWalking在语言探针的场景下，具有自动化分布式追踪（distributedtracing）的能力，但这个能力是为应用性能监控服务的。它提供了高性能、自动探针解决方案，支持轻量级分析拓扑图、应用性能指标等功能。而Zipkin和Jaeger都专注于追踪本身，得到尽可能细致的调用链，并建议在高流量时开启采样。大家深入使用后会发现，双方系统提供的追踪结构有较大差别。

SkyWalking不是一个以大数据为基础的APM系统

提到APM，就不得不提早在2012年由韩国Naver公司开源的APM项目Pinpoint。Pinpoint曾经是GitHubstar数最多的APM项目，直到2019年被SkyWalking超过。初看Pinpoint和SkyWalking，大家会感觉功能有些类似，毕竟都是在APM领域，但是两者采用的技术栈反映了其本质差别：Pinpoint立足于HBase；SkyWalking使用包括Elasticsearch在内的多种存储，却不支持任何一种大数据技术。

SkyWalking在3之后的版本中就完全放弃了大数据技术栈，根本原因是，作为Ops的核心系统之一，轻量级和灵活性被放在首要位置上。SkyWalking以监控千亿级流量为基础要求，自己不能反而成为整个大型分布式系统的部署和运维难点，而大数据技术却适得其反，会大幅增加运维和部署难度。

同时，SkyWalking在超过5000TPS下超级优良的性能，也是其与Pinpoint的较大区别。无论是官方测试还是网上大量的性能对比都能反映出巨大差异。SkyWalking在设计之初，也是要保证探针能够在单进程1万TPS级别系统中，提供稳定的100%采样，以及合理的性能消耗（小于10%增幅）。高起点也要求SkyWalking必须能够完全控制自己的技术栈和运算模型，使其完全符合APM计算的要求。

除了类似的项目比较，还有一些比较核心的运用场景，可以帮助大家了解SkyWalking。

SkyWalking不是方法诊断系统

首先，从技术角度上说，方法级别追踪是SkyWalking技术栈能够做到的技术，但是官方并不推荐这样使用，特别是在生产环境中。方法级别

当然，SkyWalking考虑到不同团队的使用场景，在可选插件中提供了对Spring托管的类进行方法级别追踪。作为APM系统，SkyWalking不建议做常规性新加span的方法诊断，而提供了更为高效合理的方式——性能剖析，用于生产环境的性能诊断。

SkyWalking能够追踪方法参数

参数追踪和方法追踪类似，即使是针对HTTP请求的方法参数追踪，也会对应用系统和APM造成较大的压力。虽然目前SkyWalking的部分插件（如MySQL）支持用户手动开启参数追踪，但依然提醒用户，要注意考虑性能消耗。此外，SkyWalking7新推出了性能诊断功能，方法参数会被自动捕捉。

（2）Skywalking架构设计

SkyWalking官方架构图对SkyWalking的整体架构进行了非常直观的描述。SkyWalking由以下4个核心部分构成。

• 探针。探针（对应图1-1中Tracing和Mestrics部分）可以是语言探针，也可以是其他项目的协议。

• OAP平台（ObservabilityAnalysisPlatform），或称OAPServer。它是一个高度组件化的轻量级分析程序，由兼容各种探针的Receiver、流式分析内核和查询内核三部分构成。

• 存储实现（StorageImplementors）。SkyWalking的OAPServer支持多种存储实现，并且提供了标准接口，可以实现其他存储。

• UI模块（SkyWalking）。通过标准的GraphQL协议进行统计数据查询和展现。

从设计角度而言，SkyWalking总体遵循以下三大设计原则：

• 面向协议设计
• 模块化设计
• 轻量化设计

（3）Skywalking的优势

SkyWalking的优势在于它紧跟当前的技术发展趋势，保证同一套APM系统适用于传统架构和云原生架构。另外，在技术设计理念上，SkyWalking提供了较大的包容性和扩展性，适用于不同的用户场景和定制需求。

传统分布式架构与云原生的一致性支持

随着近十年服务化和微服务化的进程，以RPC和HTTP服务为通信技术核心，以注册中心作为服务注册与服务发现的架构，已经成为国内成熟的微服务“传统”架构。主流技术有SpringCloud、ApacheDubbo等。SkyWalking从2015年项目诞生之初，就把这种传统的分布式架构及自动探针作为最为核心的功能。SkyWalking可以无缝支持已经稳定的分布式服务架构，方便替换传统的监控手段，而无须增加运维团队和开发团队的工作量。

同时，从2018年起，由Google、Lyft和CNCF的Istio与Envoy组成的ServiceMesh方案开始流行，提供了在Kubernetes上创新的分布式服务管理、监控和安全管理能力。SkyWalking项目团队也一直这一动向，在Istio1.0.4发布的同时发布了SkyWalking6的测试版本，并在3个月后开始发布SkyWalking6稳定版本。在6.x版本中，SkyWalking针对Istio和Envoy组成的ServiceMesh方案提供了核心适配能力。用户可以认为ServiceMesh构成了SkyWalking的一种新的语言无关的探针形式。利用SkyWalking的后端OAP平台以及UI，可以对ServiceMesh管理中的服务提供同样的依赖拓扑、服务性能指标、告警等能力。90%以上的配置与使用其他语言探针（如Java探针）时完全一致。这也是首个在开源软件中实现语言探针和ServiceMesh一致性解决方案的项目。为不同公司的技术栈提供统一的监控能力，更有利于公司在未来系统架构升级中保持监控系统的一致性。

这个一致性不单单指SkyWalking的使用，更是对于用户在SkyWalking构建的生态系统，如告警平台、AIOps、指标基线计算系统、弹性计算等，保持一致性。

易于维护

SkyWalking一直坚持以易于维护为核心需求，不引入过多的技术栈，以免成为一个过于复杂的监控系统。这其中的深层逻辑在于，监控系统作为二线甚至三线系统，应该利用有限的环境资源，提供尽可能大的监控价值，同时尽可能降低对于运维的要求。在SkyWalking集群模式下，大量公司每日需要采集超过百亿级别的监控数据及明细，SkyWalking不要求使用复杂的大数据平台，以减少系统的入门难度和维护负担。同时SkyWalking的构建集群架构比较简单，用户只要针对自己的数据量，对于不同的存储平台（如MySQL、TiDB或Elasticsearch等）具备基本的集群运维能力，就可以轻松监控百亿级的流量系统。

高性能

SkyWalking并不会因为追求简单、易于维护而降低对性能的要求。SkyWalking内置一套针对分布式监控专门设计的可扩展流计算框架，该计算框架针对监控数据特别设计了特定的流程，并利用字节码技术来兼顾扩展性和系统性能。

调用链跟踪系统比较

分布式调用链追踪系统一般有以下五个目标：

• 低消耗（low-overhead）调用链追踪埋点不能占用链路上太长的时间，也不应消耗太多的机器资源。
• 低侵入（low-invasiveness）作为非业务组件，应当尽可能少侵入或者不侵入其他业务系统，保持对使用方的透明性，减少开发人员的负担和接入门槛。
• 可扩展（scalability）整个调用链追踪通路都应该可扩展，以应对不断接入的服务和公司未来的发展。
• 时效性（time-efficient）从追踪数据采集，分析处理，查询，展示的整个通路都要尽量快速。
• 决策支持（decision-support）需要为业务定位问题，分析服务，提供丰富清晰的报表。

三类产品比较如下表所示：

从上表可以看出，三个产品都是比较优秀的调用链跟踪系统，综合各方面情况，如公司、项目团队开始选择一款产品作为系统的调用链跟踪监控，Skywalking是一个不错的选择。