导读：本文摘自于SkyWalking创始人吴晟撰写的《Apache SkyWalking实战》一书，详细讲述了SkyWalking的架构设计与优势。
吴晟：Apache基金会会员，Apache SkyWalking创始人、项目VP和PMC成员，Apache孵化器PMC成员，Apache ShardingSphere PMC成员，Apache APISIX (incubating) PPMC成员，Apache ECharts (incubating)和Apache DolphinScheduler (incubating)孵化器导师，Zipkin成员和贡献者，CNCF OpenTracing核心维护者。
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总体遵循以下三大设计原则：
- 面向协议设计
- 模块化设计
- 轻量化设计
面向协议设计
面向协议设计是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默认对外集成协议的范围，考虑到模块化设计，这些协议本身也是可以替换的，这里就不一一描述了。
模块化设计
模块化设计，旨在以开源项目为内核，为更多的企业内部定制服务、商业产品的二次包装及插拔机制提供插拨机制与扩展点。开源项目的一致性升级至关重要，模块化设计，明确接口边界，使得扩展很容易跟上开源版本升级的节奏。对于商业包装和开源产品的迭代发展，这是必不可少的一环。
大型的开源项目，无一不是由大量的商业公司/商业目的推进，不可能由个人凭兴趣在业余时间完成。虽然SkyWalking在早期的一到两年是个人基于兴趣在推进，但随着社区的壮大和商业价值的体现，开放、包容、具有扩展性的架构是必不可少的特性。Apache SkyWalking作为Apache顶级项目，基于商业友好的Apache 2.0开源协议，在设计上也充分考虑了定制化及二次开发的可能性。
SkyWalking根据探针和服务端的不同特性，使用了两种不同的模块化机制。
Java探针端，Java使用了较为紧凑的实现，主要使用SPI将核心服务隔离成替换状态，用户可以像开发plugin一样，只需将新的服务实现放在plugin目录中，即可实现自动替换。
后端（OAP Server）使用YML定义的模块化。SkyWalking将模块化定义为模块（Module）和实现（Provider）两部分。模块为抽象概念，提供对外服务方法的定义和声明；Provider需要实现这些服务方法，同时声明此实现依赖的其他模块。值得注意的是，模块本身不声明依赖，依赖由实现（Provider）声明。这种模式允许用户替换和新增所需的模块，并进行组织。
轻量化设计
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内核的稳定和高通用性。
