Apache SkyWalking 在 Service Mesh 中的可观察性应用 | 线上直播回顾

Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不一样公司的嘉宾，从不一样角度展开了 Service Mesh 的应用实践分享，分享涵盖 Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh，来自陌陌和百度的 Service Mesh 生产实践。

本文根据5月7日晚，美国 Service Mesh 服务商 Tetrate 创始工程师高洪涛的主题分享《Apache SkyWalking 在 Service Mesh 中的可观察性应用》整理。文末包含本次分享的视频回顾连接以及 PPT 下载地址。

前言

本次演讲为你们分享的是 Apache SkyWalking 对 Service Mesh 可观测性方面的应用实践，共分为三个部分：

• 第一部分是 Apache SkyWalking 的相关背景；
• 第二部分是 Service Mesh 场景下 SkyWalking 所面临的挑战；
• 最后是针对 Service Mesh 场景方案的演化；

SkyWalking 的历史沿革及其特色

SkyWalking 项目的建设目的是为了解决在微服务环境下，如何快速的定位系统稳定性问题。创始团队于2016年启动项目，通过一年的努力完善了最初的版本。2017年，团队启动将项目捐献给 Apache 基金会的流程。在 Apache 基金会孵化器内，通过了多轮系统升级迭代，并得到近乎翻倍的贡献者和关注度，于2019年顺利毕业。通过经年的升级与维护，SkyWalking 从最开始专一于分布式追踪系统的单一平台，发展为包含多个门类并拥有丰富的功能的全领域 APM 系统。

SkyWalking 总体的系统架构包括有三个部分:

• 第一个是数据采集端，可使用语言探针对系统的监控指标进行采集，同时也提供了一套完整的数据采集协议。第三方系统可使用协议将相关的监控数据上报到分析平台。
• 第二部是分析平台，主要包括对监控指标数据的搜集，流式化处理，最终将数据写到存储引擎之中。存储引擎可以使用Elasticsearch，MySQL数据库等多种方案。
• 第三部分是 UI。UI 组件有丰富的数据展现功能，包含指标展板，调用拓扑图，跟踪数据查询，指标比较和告警等功能。

在此基础上，SkyWalking 自己组件具备丰富的定制功能，方便用户去进行二次开发以支持本身特有的场景。

SkyWalking 定义了三个维度用来绑定相关的监控指标数据。

• 服务(Service)：表示对请求提供相同行为的一系列或一组工做负载。在使用打点代理或 SDK 的时候, 你能够定义服务的名字。若是不定义的话，SkyWalking 将会使用你在平台上定义的名字, 如 Istio。
• 实例(Instance)：上述的一组工做负载中的每个工做负载称为一个实例。就像 Kubernetes 中的 Pod 同样, 服务实例未必就是操做系统上的一个进程。但当你在使用打点代理的时候，一个服务实例实际就是操做系统上的一个真实进程。
• 端点(Endpoint)：对于特定服务所接收的请求路径，如 HTTP 的 URL 路径和 gRPC 服务的类名 + 方法签名。

预约义的维度能够方便的进行数据预聚集操做，是 SkyWalking 分析引擎重要的组成部分。 虽然其相对的会有使用不够灵活的缺点，但在 APM 场景下，指标每每都是预先通过精心设计的，而性能才是关键因素。 故 SkyWalking 采用这种预约义维度模式来进行数据聚集操做。

Service Mesh 场景下 SkyWalking 面对的挑战

在描述 Service Mesh 的场景下所面临的挑战以前，须要去解释可观测性所包含的含义。可观测性通常包含有三个部分:

• 第一点，日志系统。由其能够构建出系统运行的实时状态。故日志成为很是方便的观测手段。
• 第二点，分布式追踪。这部分数据在微服务场景下具备强大的生命力，能够提供给用户分布式系统观测指标。
• 第三点，指标监控。相比于日志和分布式追踪，其具备消耗小，处理简便等特色，一般做为系统监测告警的重要数据来源。

如上所示是 Istio1.5 的架构图。重点看一下他对可观测性的支持。从图上看，全部的监控指标都汇聚到中间的 Mixer 组件，而后由 Mixer 再发送给他左右的 Adapter，经过 Adapter 再将这些指标发送给外围的监控平台，如 SkyWalking 后端分析平台。在监控数据流经 Mixer 的时候，Istio 的元数据会被附加到这些指标中。另外一种新的基于 Telemetry V2 观测体系是经过 Envoy 的 Proxy 直接将监控指标发送给分析平台，这种模式目前还处于快速的演进和开发中，可是它表明着将来的一种趋势。

从架构图中咱们能够看到，这里面的第一个挑战就是 Service Mesh 场景下，对于可观测性的技术体系的支持是很是多变的。

Istio 自己就包括两种不融合的体系，第一种是基于 Mixer 的场景，第二种是 Mixerless 场景。

Mixer 是基于访问日志进行指标生成的，也就是说服务与服务之间的访问日志通过 Mixer 增长相关的原数据后再发给外围分析系统。其特色是这个模式很是的成熟、稳定，可是性能会很是的低。它的低效源于两个方面，第一点是他的数据发送通道很长，中间节点过多。能够看到数据须要到从 Proxy 发送到 Mixer 节点，再发送给外围的 Adapter 节点。另外一个效能低下的缘由主要是体如今它发送的是原始访问日志，其数据量是很是大的，会消耗过多的带宽，这对总体的数据搜集与分析提出了很是大的挑战。

另外一种模式是 Mixerless，它彻底是基于 Metrics 指标的。经过可观测性包含的技术及其特色分析可知，它是一种消耗比较小的技术，对带宽以及分析后台都是很是友好的。可是它同时也有本身的问题，第一个问题就是他须要的技术门槛是比较高的（使用 WASM 插件来实现），而且对于 Proxy 端的性能消耗也是比较大的。同时因为是新的技术，稳定性较差，相关接口与规范并不完整。

第二个挑战就是无 Tracing 数据。SkyWalking 最先是为了收集处理跟踪数据（Tracing）而设计的一套系统，可是咱们能够从右边的图发现，对于 Service Mesh 上报的数据实际上是基于调用的，也就是说它不存在一条完整的跟踪链路。这样就对后台的分析模型有比较大的挑战，如何才能同时支持好这两种模式成为后端分析系统所要处理的棘手问题。

第三个挑战就是维度匹配的问题。咱们从前一章能够看到 SkyWalking 是包括三个维度的，其中对于实例和端点，在 Service Mesh 场景下都是有比较好的支持。这里多说一句，不只仅是对 Mesh 场景，对于大部分场景均可以很好的去匹配它们。可是对于服务的匹配是有至关大难度的，由于 SkyWalking 只有服务这一层的概念，而在 Istio 中有好几个概念能够称之为“服务”。如何才能进行相关的维度匹配，特别是对于服务级别的维度匹配，成为了 Service Mesh 是如何与 SkyWalking 结合的另外一个关键点。

应用方案及其演化

与 Istio 的集成

咱们从 Istio 的架构图中可见，除了网络流量控制服务之外，Istio 同时提供了对 Telemetry 数据集成的功能。Telemetry 组件主要经过 Mixer 进行集成，而这偏偏就是 SkyWalking 首先与 Istio 集成的点。早期 Istio 能够进行进程内的集成，即将集成代码添加到其源码进行变异，以达到最高性能。后来 Istio 为了下降系统的集成复杂性，将该功能演变为进程外的适配器。目前 SkyWalking 就是采用这种进程外适配器进行集成的。

安装模式有两种：

• 若是从 Helm Chart 安装 SkyWalking，能够在 values.yml 文件中将如图的参数设置为 true。然后 Helm 会自动安装 SkyWalking 分析后台，并将它以进程外适配器的模式集成到 Istio 中；
• 若是 SkyWalking 与 Istio 已经安装，可使用右图中所示的 cr 文件来配置 Istio，使其将观测数据发送到 SkyWalking 中；

安装完毕后，使用 BookInfo 示例程序进行测试。能够看到维度匹配为：

• 服务 Service ：<ReplicaSet>.<Namespace>；
• 实例 Instance: kubernetes://<Pod> ；
• 端点 Endpoint：http url；

能够发现 Service 包含了 Namespace。 故在不一样 Namespace 下，必定是两个不一样的服务。

拓扑图中除了示例中的服务和 Ingress 外，还包含有 istio-telemetry 组件。这反映了实际的数据流量，但有些用户会以为这稍显冗余，然后的方案你们会看到此处略有不一样。

除了进行 Mixer 的集成之外，SkyWalking 同时能够与 Envoy 的 access log service 进行相关的系统集成，以达到 Mixer 相似的效果。与 Envoy 集成的优点在于能够很是高效的将访问日志发送给 SkyWalking 的接收器，这样延迟最小。但缺点是目前的 access log service 发送数据很是多，会潜在影响 SkyWalking 的处理性能和网络带宽。同时全部的分析模块都依赖于较为底层的访问日志，一些 Istio 的相关特性不能被识别。好比这种模式下只能现实 Envoy 的元数据，Istio 的虚拟服务等概念没法有效的现实。

这种模式须要在安装 SkyWalking 与 Istio 时进行配置。首先在 SkyWalking 的 Helm 里将“envoy.als.enabled”设置为 true。然后安装 Istio 时，须要设置"values.global.proxy.envoyAccessLogService"为如图中的值。

从拓扑图中看，与 Mixer 模式最明显的区别为没有 istio-telemetry 组件。这是因为该组件并无 Envoy Sidecar 来路由流量，故也不会产生访问日志。也就是，此种模式彻底反应了实际的工做负载状况。

除了上述两种模式，目前社区正在开发基于 Istio 最新的 TelemetryV2 协议的观测模型。此种模式是基于 Metrics 监控而不是基于访问日志。这种模式将对外暴露两种 Metrics：

• service level: 这种 Metrics 描述的是服务之间的关系指标，用来生成拓扑图和服务级别的指标；
• proxy level: 这种 Metrics 描述的 Proxy 进程的相关指标，用来生成实例级别的指标；

此种模式为标椎的 Mixerless，其优势是对分析平台友好，网络带宽消耗小。 缺点为须要消耗 Envoy 的资源，特别是对内存消耗大。 可是相信通过外来多轮优化，能够很好的解决这些问题。

但此种模式还有另外的缺点，即不能生成端点 Endpoint 的监控指标。若是用户但愿能包含此种指标，还须要使用基于 ALS 访问日志的模式。

Tracing 与 Metric 混合支持

在 SkyWalking8.0 以前，若是开启 Service Mesh 模式，那么传统的 Tracing 模式是不能使用的。缘由是他们共享了一个分析流水线。若是同时开启会形成计算指标重复的问题。

在 SkyWalking8.0 中，引入的 MeterSystem 能够避免此种问题的产生。并且计划将 Tracing 调整为能够配置是否生成监控指标，这样最终将会达到的效果是：指标面板与拓扑图的数据来源于 Envoy 的 Metrics，跟踪数据来源于 Tracing 分析，从而达到支持 Istio 的 Telemetry 在控制面中的全部功能。

另外，Envoy 和 Istio 自己不支持 Skywalking 的远程 Tracing 协议。目前社区已经尝试进行 nginx 和 MOSN 等Mesh 环境中经常使用的 Proxy 的协议支持，后续也会尝试将 Skywalking 协议添加到 Envoy 中（使用 WASM 插件）。

维度匹配

从安装过程能够发现，服务 Service 在 Mixer 和 ALS 中的规则为 ReplicaSet+Namespace 的形式。其很难反映 Istio 实际的维度状况。后续在 TelemetryV2 中将会得到真实的 Istio 服务间映射。同时也会尝试增长以下的命名规则以区分跨Cluster的状况：“Version|App|Namespace|Cluster”。

总结

结 本次分享简要的介绍了 Apache SkyWalking 在 Service Mesh 场景下的应用方案。 主要是基于 Istio 作了详细的介绍，经过三种主要的挑战而引出的解决方案，将帮助你们更好的理解和使用 SkyWalking 的 Mesh 功能。 但愿你们有兴趣去尝试使用 SkyWalking 去观测 Istio。

以上就是这次分享的所有内容，感谢你们的关注与支持！

嘉宾介绍

高洪涛，FoundingEngineer 美国 Service Mesh 服务商 Tetrate 创始工程师。原华为软件开发云技术专家，对云原生产品有丰富的设计，研发与实施经验。对分布式数据库、容器调度、微服务、Servic Mesh 等技术有深刻的了解。目前为 Apache ShardingSphere 和 Apache SkyWalking 核心贡献者，参与该开源项目在软件开发云的商业化进程。前当当网系统架构师，开源达人，曾参与 Elastic-Job 等知名开源项目。

回顾视频以及 PPT 下载地址

• 视频回顾：https://www.bilibili.com/video/BV1qp4y197zU

• PPT 下载：https://github.com/servicemesher/meetup-slides/tree/master/2020/05/virtual

相关阅读

• Service Mesh 高可用在企业级生产中的实践 | 线上直播回顾
  
• 陌陌的 Service Mesh 探索与实践 | 线上直播回顾
  
• Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题
  

本文归档在 sofastack.tech。

🎉 奖励支持 SOFAStack 的你~

* 关注“Service Mesh”的点个“ 在看 ”

* 到公众号对话框发送“ T 恤 ”，试试手气~

* 本期互动奖品“ SOFAStack  T 恤 ”

本文分享自微信公众号 - 金融级分布式架构（Antfin_SOFA）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。