HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

Apache SkyWalking 在 Service Mesh 中的可观察性应用

  • 2020-06-06
  • 本文字数:4904 字

    阅读完需:约 16 分钟

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。


以上就是此次分享的全部内容,感谢大家的关注与支持!


回顾视频以及 PPT 下载地址



作者介绍


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


本文转载自公众号金融级分布式架构(ID:Antfin_SOFA)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247486207&idx=1&sn=70878ef28825f3bd20b1a0ed5e625295&chksm=faa0e525cdd76c3350e46caaee7ec9fd35cdb58ee17dcd996c6c12b8b40b80272c5103c31b1a&scene=27#wechat_redirect


2020-06-06 14:063832

评论

发布
暂无评论
发现更多内容

【SpringBoot】6、自动配置原理【狂神篇

爱好编程进阶

Java 程序员 后端开发

《英雄联盟》首部成人动画全球爆火

爱好编程进阶

程序员 后端开发

一起学Java——html

爱好编程进阶

Java 程序员 后端开发

刚出炉热腾腾的定时任务可视化管理系统

爱好编程进阶

Java 程序员 后端开发

去中心化云存储技术 | CESS 的多层网络架构详解

One Block Community

区块链 去中心化存储 CESS 波卡生态

LockSupport与Condition

急需上岸的小谢

5月月更

一个三线程序员的2020年,CSDN 10 万粉里程碑达成

爱好编程进阶

Java 程序员 后端开发

【并发编程】

爱好编程进阶

Java 程序员 后端开发

亦直问JVM?凡不凡啊?记住这篇就不怕

爱好编程进阶

Java 程序员 后端开发

你真的知道Java同步锁何时释放?

爱好编程进阶

Java 程序员 后端开发

是能力更是文化,谈谈IT系统的安全发布

Samson

技术管理 SRE 系统稳定性 安全生产 5月月更

AI简报-图像质量评价指标-LPIPS

AIWeker

人工智能 深度学习 5月月更

AuthTalk | 全面拆解多租户解决方案

Authing

SaaS 多租户 Idaas

利用Java反射实现两个具有相同属性bean赋值

爱好编程进阶

程序员 后端开发

C语言_链表总结

DS小龙哥

5月月更

全链路压测(十二):生产压测必不可少的环节

老张

性能测试 全链路压测 稳定性保障

全靠这份阿里大厂Java面试真题手册,让我成功拿下12家大厂offer

爱好编程进阶

Java 程序员 后端开发

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

爱好编程进阶

程序员 后端开发

一个${}引发的惨案

爱好编程进阶

Java 程序员 后端开发

使用cobbler 安装工具批量安装服务器

爱好编程进阶

Java 程序员 后端开发

全栈开发之后端脚手架:SpringBoot集成MybatisPlus代码生成,分页

爱好编程进阶

Java 程序员 后端开发

关于扑克牌的一些讨论——《Fluent Python 2》读书笔记

codists

Python

Spring Boot MyBatis配置Druid多数据源

爱好编程进阶

Java 程序员 后端开发

SpringBoot之:SpringBoot中使用HATEOAS

程序那些事

Java Spring Boot 程序那些事 5月月更

Tomcat与JDK版本对应关系,Tomcat各版本特性

爱好编程进阶

Java 程序员 后端开发

困扰程序员的7个噩梦,只要遇上一个,都是崩溃的瞬间

爱好编程进阶

Java 程序员 后端开发

在职场,光有技术是不行的,18年老程序员职场宝贵经验分享

爱好编程进阶

Java 程序员 后端开发

首届波卡黑客松项目「Manta Network」的进击之路

One Block Community

区块链 隐私安全 黑客马拉松 波卡生态

SpringMVC快速入门(3)默认组件加载

爱好编程进阶

Java 程序员 后端开发

到了2020年,技术水平到底需要达到怎样的程度才能成为顶级的阿里P8架构师

爱好编程进阶

Java 程序员 后端开发

“三高”程序员谈:Mysql的“三高”集群架

爱好编程进阶

程序员 后端开发

Apache SkyWalking 在 Service Mesh 中的可观察性应用_架构_高洪涛_InfoQ精选文章