SkyWalking——SkyWalking架构设计

SkyWalking架构设计

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

　　探针（Tracing 和 Mestrices）：可以是语言探针，也可以是其他项目的协议。

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

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

　　面向协议设计

　　模块化设计

　　轻量级设计

 1.1 面向协议设计

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

　　1. 探针协议

　　探针协议分为四大类。

• • 语言探针上报协议。此协议包括语言探针的注册、Metrics 数据上报、Tracing 数据上报、命令下行，以及 Service Mesh 中使用的 Telemetry 协议。所有基于语言（Java、.NET、Node.js、PHP、Go 等）的探针都需要严格遵守此协议定义。此协议从 v6 版本开始全部以 gRPC 服务放肆对外提供。
  • 语言探针交互协议。因为分布式追踪，探针间需要借助 HTTP Header、MQ Header 等应用间通信管道进行交互。此协议都需要严格遵守此协议定义。此协议从 v2 开始执行与 v1 不同的编码方法，加入了强制 Base64 的要求。将从 SkyWalking 8 开始执行的全新 v3 协议，简化了编码，提供了更多特性，比如透传业务信息、探针交互能力等。
  • Service Mesh 协议。此协议是 SkyWalking 针对 Service Mesh 抽象的专有协议，任何 Mesh 类的服务都可以通过此协议直接上行 Telemetry 数据，用于计算服务 Metrics 和拓扑图。
  • 第三方协议。针对大型的第三方开源项目，尤其是 Service Mesh 核心平台 Istio 和 Envoy，提供核心协议适配，支持针对 Istio+Envoy 的 Service Mesh 进行无缝监控。

　　2. 查询协议

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

　　查询协议分为以下 6 类：

1. 1. 元数据查询：查询在 SkyWalking 注册的服务、服务实例、Endpoint等元数据信息。
   2. 拓扑关系查询：查询全局或者单个服务或 Endpoint 的拓扑图及依赖关系。
   3. Metrics 指标查询：线性指标查询。
   4. 聚合指标查询：区间范围均值查询及 TopN 查询等。
   5. Trace 查询：追踪明细查询。
   6. 告警查询。

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

 1.2 模块化设计

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

　　Apache SkyWalking 作为 Apache 定顶级项目，基于商业友好的 Apahce 2.0 开源协议，在设计上也充分考虑了定制化及二次开发的可能性。SkyWalking 根据探针和服务端的不同特性，使用了两种不同的模块化机制。

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

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

 1.3 轻量化设计

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

 1.4 SkyWalking 的优势

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

• • 传统分布式绞股与云原生的一致性支持
  • 易于维护
  • 高性能
  • 利于二次开发和继承