这么多Apache顶级项目，SkyWalking为何一枝独秀？

吴晟

Apache基金会会员，Apache SkyWalking创始人、项目VP和PMC成员，Apache孵化器PMC成员，Apache ShardingSphere PMC成员，Apache APISIX (incubating) PPMC成员，Apache ECharts (incubating)和Apache DolphinScheduler (incubating)孵化器导师，Zipkin成员和贡献者，CNCF OpenTracing核心维护者。

导读： 本文摘自于SkyWalking创始人吴晟撰写的《Apache SkyWalking实战》一书，详细讲述了SkyWalking的架构设计与优势。

徐郡明 老师整理国内比较常见的 APM 如下：

APM 系统（Application Performance Management，即应用性能管理）

1. CAT ： 由国内美团点评开源的，基于 Java 语言开发，目前提供 Java、C/C++、Node.js、Python、Go 等语言的客户端，监控数据会全量统计。

2. Zipkin ： 由 Twitter 公司开发并开源，Java 语言实现。可以轻松与 Spring Cloud 进行集成，也是 Spring Cloud 推荐的 APM 系统。

3. Pinpoint ： 韩国团队开源的 APM 产品，运用了字节码增强技术，只需要在启动时添加启动参数即可实现 APM 功能，对代码无侵入。目前支持 Java 和 PHP 语言，底层采用 HBase 来存储数据，探针收集的数据粒度非常细，但性能损耗较大，因其出现的时间较长，完成度也很高，文档也较为丰富，应用的公司较多。

4. SkyWalking ： 国人开源的产品，2019 年 4 月 17 日 SkyWalking 从 Apache 基金会的孵化器毕业成为顶级项目。目前 SkyWalking 支持 Java、.Net、Node.js 等探针，数据存储支持MySQL、ElasticSearch等。SkyWalking 与 Pinpoint 相同，Java 探针采用字节码增强技术实现，对业务代码无侵入。探针采集数据粒度相较于 Pinpoint 来说略粗，但性能表现优秀。目前，SkyWalking 增长势头强劲，社区活跃，中文文档齐全，没有语言障碍，支持多语言探针，这些都是 SkyWalking 的优势所在，还有就是 SkyWalking 支持很多框架，包括很多国产框架，例如，Dubbo、gRPC、SOFARPC 等等，也有很多开发者正在不断向社区提供更多插件以支持更多组件无缝接入 SkyWalking。

还有很多不开源的 APM 系统，例如，淘宝鹰眼、Google Dapper 等等，不再展开介绍了。

1

SkyWalking 的架构设计

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

SkyWalking官方架构图

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

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

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

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

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

• 面向协议设计

• 模块化设计

• 轻量化设计

1.1

面向协议设计

面向协议设计是 SkyWalking 从 5.x 开始严格遵守的首要设计原则。SkyWalking 包含下列对外协议。

1) 探针协议

探针协议分为四大类。

• 语言探针上报协议。此协议包括语言探针的注册、Metrics数据上报、Tracing数据上报、命令下行，以及Service Mesh中使用的Telemetry协议。所有基于语言（Java、.NET、Node.js、PHP、Go等）的探针都需要严格遵守此协议定义。此协议从v6版本开始全部以gRPC服务方式对外提供。

• 语言探针交互协议。因为分布式追踪，探针间需要借助HTTP Header、MQ Header等应用间通信管道进行交互。此协议定义交互格式。所有基于语言（Java、.NET、Node.js、PHP、Go等）的探针都需要严格遵守此协议定义。此协议从v2开始执行与v1不同的编码方法，加入了强制Base64的要求。将从SkyWalking 8开始执行的全新v3协议，简化了编码，提供了更多特性，比如透传业务信息、探针交互能力等。

• Service Mesh协议。此协议是SkyWalking针对Service Mesh抽象的专有协议，任何Mesh类的服务都可以通过此协议直接上行Telemetry数据，用于计算服务Metrics和拓扑图。

• 第三方协议。针对大型的第三方开源项目，尤其是Service Mesh核心平台Istio和Envoy，提供核心协议适配，支持针对Istio+Envoy的Service Mesh进行无缝监控。

2) 查询协议

查询协议使用GraphQL格式定义的查询协议。多数读者可能更熟悉RESTful格式的查询，但SkyWalking考虑到更好的扩展性、更加灵活的组合查询模式，选择了由Facebook在2012年开源的GraphQL。GraphQL在开源和商业项目中已经得到了广泛运用。协议格式的预定义和多种查询组合使用提供了UI和第三方系统良好的集成能力。熟悉SkyWalking历史的读者会知道，SkyWalking在6.0.0-GA之后的版本，更换了全新的RocketBot UI作为默认UI，这个过程得益于GraphQL的灵活性，后端协议和实现可以完全不变。社区中已有大量公司基于此协议包装了云平台产品的UI。

查询协议分为以下6类。

• 元数据查询：查询在SkyWalking注册的服务、服务实例、Endpoint等元数据信息。

• 拓扑关系查询：查询全局或者单个服务或Endpoint的拓扑图及依赖关系。

• Metrics指标查询：线性指标查询。

• 聚合指标查询：区间范围均值查询及TopN查询等。

• Trace查询：追踪明细查询。

• 告警查询。

除了上述两大类协议外，部分模块也存在一些模块内协议，如导出的数据格式协议、告警协议、动态配置服务协议等。这些协议与执行模块的默认实现有关，属于SkyWalking默认对外集成协议的范围，考虑到模块化设计，这些协议本身也是可以替换的，这里就不一一描述了。

1.2

模块化设计

模块化设计，旨在以开源项目为内核，为更多的企业内部定制服务、商业产品的二次包装及插拔机制提供插拨机制与扩展点。开源项目的一致性升级至关重要，模块化设计，明确接口边界，使得扩展很容易跟上开源版本升级的节奏。对于商业包装和开源产品的迭代发展，这是必不可少的一环。

大型的开源项目，无一不是由大量的商业公司/商业目的推进，不可能由个人凭兴趣在业余时间完成。虽然SkyWalking在早期的一到两年是个人基于兴趣在推进，但随着社区的壮大和商业价值的体现，开放、包容、具有扩展性的架构是必不可少的特性。Apache SkyWalking作为Apache顶级项目，基于商业友好的Apache 2.0开源协议，在设计上也充分考虑了定制化及二次开发的可能性。

SkyWalking根据探针和服务端的不同特性，使用了两种不同的模块化机制。

Java探针端，Java使用了较为紧凑的实现，主要使用SPI将核心服务隔离成替换状态，用户可以像开发plugin一样，只需将新的服务实现放在plugin目录中，即可实现自动替换。

后端（OAP Server）使用YML定义的模块化。SkyWalking将模块化定义为模块（Module）和实现（Provider）两部分。模块为抽象概念，提供对外服务方法的定义和声明；Provider需要实现这些服务方法，同时声明此实现依赖的其他模块。值得注意的是，模块本身不声明依赖，依赖由实现（Provider）声明。这种模式允许用户替换和新增所需的模块，并进行组织。

1.3

轻量化设计

SkyWalking在设计之初就提出了轻量化的设计理念。APM虽然是运维端的核心系统，但放在整套业务架构下，属于二线支撑系统，不承担系统主要业务功能。而绝大多数的分析系统要求大数据作为其核心技术，但是技术团队应该都了解，大数据天然具有维护难度大和门槛高的问题。基于此背景，SkyWalking核心要求能够在非大数据架构下，使用最轻量级的jar包模式，形成强大的分析能力、扩展能力和模块化能力。

2

SkyWalking 的优势

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

2.1

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

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

同时，从2018年起，由Google、Lyft和CNCF的Istio与Envoy组成的Service Mesh方案开始流行，提供了在Kubernetes上创新的分布式服务管理、监控和安全管理能力。SkyWalking项目团队也一直关注这一动向，在Istio 1.0.4发布的同时发布了SkyWalking 6的测试版本，并在3个月后开始发布SkyWalking 6稳定版本。在6.x版本中，SkyWalking针对Istio和Envoy组成的Service Mesh方案提供了核心适配能力。用户可以认为Service Mesh构成了SkyWalking的一种新的语言无关的探针形式。利用SkyWalking的后端OAP平台以及UI，可以对Service Mesh管理中的服务提供同样的依赖拓扑、服务性能指标、告警等能力。90%以上的配置与使用其他语言探针（如Java探针）时完全一致。

这也是首个在开源软件中实现语言探针和Service Mesh一致性解决方案的项目。为不同公司的技术栈提供统一的监控能力，更有利于公司在未来系统架构升级中保持监控系统的一致性。这个一致性不单单指SkyWalking的使用，更是对于用户在SkyWalking构建的生态系统，如告警平台、AIOps、指标基线计算系统、弹性计算等，保持一致性。

2.2

易于维护

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

2.3

高性能

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

SkyWalking在永辉超市的典型公开案例中，使用15台OAP节点和20台Elasticsearch节点，就支撑了250多个服务每天高达3TB的监控数据，数据流量超过百亿。在6.x中，SkyWalking性能从6.0-GA到6.4，每个版本都得到了明显提升。

2.4

利于二次开发和集成

SkyWalking的二次开发和集成的便利性主要分为两方面。

面向协议和模块化的设计。面向协议保证其他的探针接入，只需要学习协议就可以轻松完成对接。而模块化给予用户深度定制的能力，模块实现的可切换使用户可以对分布式计算过程、集群管理与协调模式、存储、告警引擎、可视化页面等进行个性化定制。

大量的SkyWalking内置实现提供了第三方网络接口，HTTP或gRPC接口。用户可以使用第三方程序进行对接，而非进行程序改造。这样能保证SkyWalking版本升级时周边生态的稳定。而且在容器化大行其道的今天，网络接口集成的方式也更为友好。

SkyWalking的几百家公开用户大量使用了这些扩展方式，定制了丰富的内部系统，也保证了SkyWalking内核的稳定和高通用性。

关于SkyWalking的实战内容推荐阅读《Apache SkyWalking实战》一书，本文经出版社授权发布。

3

福利时间

dotnet跨平台 联合机械工业华章图书给大家带来福利时间。

送书规则 ：截止 2020年7月31日13:30前 在留言区，分享你在SkyWalking方面的心得与踩坑经验、或者对新技术的更新、迭代有何独特的个人见解， 精选留言点赞前8名各送出此书一本。

注：获得赠书资格的读者须于8小时内联系小编发送详细收货信息，逾期则视为主动放弃。

推荐语：《Apache SkyWalking实战》从功能使用、项目设计、核心模块、工作原理、扩展实践5个维度全面讲解SkyWalking，由SkyWalking的创始人吴晟与核心开发团队撰写，得到了来自华为、百度、蚂蚁金服、京东数科、Tetrate.io的5位资深技术专家的联袂推荐。