共计 9491 个字符，预计需要花费 24 分钟才能阅读完成。
【转载起源】https://cloud.tencent.com/dev…
前言
谈到 Service Mesh，人们总是想起微服务和服务治理，从 Dubbo 到 Spring Cloud (2016 开始进入国内研发的视线，2017 年凋敝)再到 Service Mesh (2018 年开始被大家所相熟)，正所谓长江后浪推前浪，作为后浪，Service Mesh 别无选择，而 Spring Cloud 对 Service Mesh 满怀艳羡，微服务架构的呈现与凋敝，是互联网时代架构模式的微小冲破。Service Mesh 具备肯定的学习老本，实际上在国内的落地案例不多，大多是云商与头部企业，随着性能与生态的欠缺以及各大社区推动容器化场景的落地，Service Mesh 也开始在大小公司生根发芽，补救容器层与 Kubernetes 在服务治理方面的短缺之处。本次将以一个选型调研者的视角，来看看 Service Mesh 中的可观测性支流实际计划。
可观测性的哲学
可观测性（Observability）不是一个新名词，它在很久之前就曾经诞生了，然而它在 IT 畛域却是一个新兴事物。可察看性在维基百科中原文是这样定义的：“In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.”。云原生畛域第一次呈现这个词，是在云原生理念方兴未艾的 2017 年，在云原生的思潮之下，使用传统的形容形式曾经不足以概括这个时代的监控诉求，而 Observability 就显得贴切许多。
回忆一下传统的监控形式，除去运维层面的主机监控、JVM 监控、音讯队列监控之外，有多少监控是当时就想好怎么做的？很少！其实很多时候，咱们做的事件就是在故障产生之后，对故障复盘的过程中，除了 bug 重现与修复，也会去定制加一些监控，以冀望下次产生同样的状况时有一个实时的告警。研发人员收到告警之后得以疾速地解决问题，尽可能地缩小损失。所以，传统的监控模式大多都是在做亡羊补牢的事件，短少一个主动性。
在云原生时代的容器化体系当中就不一样了，容器和服务的生命周期是紧密联系在一起的，加上容器完满的隔离个性，再加上 Kubernetes 的容器管理层，应用服务跑在容器当中就显得更加地黑盒化，相较在传统物理主机或者虚拟机当中，排查问题的时候显得十分不便。所以在云原生时代强调的是可观测性，这样的监控永远都是兵马未动而粮草先行的，须要提前想好咱们要如何观测容器内的服务以及服务之间的拓扑信息、各式指标的收集等，这些监测能力相当重要。
对于可观测性在云原生畛域是何时开始流行起来的，没有一个很明确的工夫。业界认为可观测性最早是由 Cindy Sridharan 提出的，其实一位德国柏林的工程师 Peter Bourgon 早在 2017 年 2 月就曾经有文章在探讨可观测性了，Peter 算是业界最早探讨可观测性的开发者，他写的驰名的博文《Metrics, Tracing, and Logging》被翻译成了多种语言。真正可观测性成为一种规范，是来自 Pivotal 公司的 Matt Stine 定义的云原生规范，可观测性位列其中，由此可观测性就成为了云原生时代一个规范主题。
Peter Bourgon 提出的可观测性三大支柱围绕 Metrics、Tracing 和 Logging 开展，这三个维度简直涵盖了应用程序的各种表征行为，开发人员通过收集并查看这三个维度的数据就能够做各种各样的事件，时刻把握应用程序的运行状况，对于三大支柱的了解如下：
Metrics：Metrics 是一种聚合态的数据模式，日常中常常会接触到的 QPS、TP99、TP95 等等都属于 Metrics 的领域，它和统计学的关系最为亲密，往往须要应用统计学的原理来做一些设计；
Tracing：Tracing 这个概念简直是由 SOA 时代带来的复杂性弥补，服务化带来的长调用链，仅仅依附日志是很难去定位问题的，因而它的表现形式比 Metrics 更简单，好在业界涌现进去了多个协定以撑持 Tracing 维度的对立实现；
Logging：Logging 是由申请或者事件触发，应用程序当中用以记录状态快照信息的一种模式，简略说就是日志，但这个日志不仅仅是打印进去这么简略，它的对立收集、存储以及解析都是一个有挑战的事件，比方结构化 (Structured) 与非结构化 (Unstructed) 的日志解决，往往须要一个高性能的解析器与缓冲器；
此外，Peter Bourgon 在博文中还提到了三大支柱结合态的一些现实输入模式，以及对存储的依赖，Metrics、Tracing、Logging 因为聚合水平的不同，对存储依赖由低到高。更多细节，感兴趣的同学能够查看文末的原文链接。
Peter Bourgon 对于可观测性三大支柱的思考不止于此，他还在 2018 年的 GopherCon EU 的分享下面再次探讨了 Metrics、Tracing 和 Logging 在工业生产当中的深层次意义，这次他探讨了 4 个维度。
CapEx：示意指标初始收集老本，很显著日志的老本最低，埋点即可；其次是 Metrics，最难是 Tracing 数据，在有了协定撑持的状况下，仍然要定义许多数据点，以实现链路追踪必须的元数据定义收集；
OpEx：示意运维老本，个别指存储老本，这个之前曾经探讨过；
Reaction：示意异常情况的响应灵敏度，显然聚合之后的数据能够呈现出稳定状况，因而 Metrics 是对异常情况最灵活的；Logging 次之，也能够从 Logging 荡涤之中发现异常量；而 Tracing 在响应灵敏度下面仿佛沾不上边，最多还是用在排障定位的场景；
Investigation：规范故障定位能力，这个维度是 Tracing 的强项，能够直观看出链路当中的故障，精确定位；Logging 次之；Metrics 维度只能反馈稳定，对定位故障帮忙不大；
在 CNCF Landscape 当中，有一块区域专门用作展现云原生场景下的可观测性解决方案，外面又分为好几个维度，图中是截至 2020 年 5 月 14 日的最新幅员，将来还会有更多优良的解决方案涌现进去。CNCF 目前毕业的 10 个我的项目库当中，有 3 个是和可观测性无关的，可见 CNCF 对可观测性的器重水平。
谈到这里，很多同学兴许对于可观测性相干的协定比拟感兴趣。目前比拟火的有好几个，OpenTracing、OpenCensus、OpenTelemetry、OpenMetrics 等等，目前比拟火的是前三个。OpenMetrics 这个我的项目曾经不保护了。
OpenTracing 能够说是目前应用最广的分布式链路追踪协定了，赫赫有名的 SkyWalking 就是基于它实现的，它定义了与厂商无关，与语言无关的链路追踪协定 API，使得构建跨平台的链路追踪成为一件比拟轻松的事件，目前它在 CNCF 的孵化器当中茁壮成长。
OpenCensus 是谷歌提出的一个针对 Tracing 和 Metrics 场景的协定，背靠 Dapper 的加持与历史背景，就连微软也非常拥戴，目前在商用畛域非常风行。
其余的协定比方 W3C Trace Context，呼声也很高，它甚至对数据在头部进行了压缩，与实现层无关。兴许 CNCF 意识到各种协定又在层出不穷，当前各成气候，群雄逐鹿，每一个中间件都要做许多兼容，这对整个技术生态自身不利，因而 OpenTelemetry 横空出世。从字面意思就晓得，CNCF 会将可观测性的“遥测”进行到底，它交融了 OpenTracing 和 OpenCensus 的协定内容，旨在进步云原生时代可观测性指标的对立收集与解决，目前 OpenTelemetry 曾经进入 beta 版本，其中令人欣慰的是，Java 版本的 SDK 曾经有一个相似 SkyWalking 的基于 byte-buddy 框架的无侵入式探针。目前曾经能够从 47 种 Java 库当中主动探测获取遥测数据，另外推出了可供使用的 Erlang、Go、Java、JavaScript、Python 的 API 和 SDK。此外，数据收集器 OpenTelemetry Collector 也能够应用了，能够用它接管 OpenTelemetry client 发射过去的数据，对立收集解决。目前 CNCF 对 Logging 相干的协定制订暂缓，然而有一个工作小组也在做这方面标准的事件。
Service Mesh 与可观测性
要说 Service Mesh 与可观测性的关系，那就是可观测性是 Service Mesh 的性能子集。Service Mesh 是当今最为火爆的技术理念之一，它致力于为云原生时代运行在容器当中的大规模服务提供对立的服务发现、边缘路由、平安、流量管制、可观测性等能力，它是对 Kubernetes 服务治理能力的补充强化。能够说，Service Mesh 是云原生容器化时代的必然产物，它将对云上服务架构产生深远的影响。Service Mesh 的架构理念是将容器服务运行单元当成一个个网格，在每组运行单元中劫持流量，而后由一个对立的控制面板做对立解决，所有网格与控制面板维持肯定的分割，这样，控制面板就得以作为可观测性解决方案与容器环境之间的桥梁。
市面上最为常见的 Service Mesh 技术有 Linkerd、Istio、Conduit 等，然而要在生产环境落地必须要禁受住严苛的性能、正当的架构、社区活跃度的评估。
Linkerd 是由 Buoyant 开发保护，算是 Service Mesh 畛域第一代的产品，Linkerd1.x 基于 Scala 编写，可基于主机运行，大家都晓得 Scala 运行环境依赖 JDK，因而对资源的耗费绝对较大。随后官网进行了整改，推出了新一代的数据立体组件 Conduit，基于 Rust 和 Go 编写，与 Linkerd 双剑合璧，成为 Linkerd2.x。总体来说，Linkerd2.x 性能有了较大的晋升，也有可视化界面供操作，然而在国内就是不愠不火的，社区始终倒退不起来。
转头看 2017 年呈现的 Istio，也算是含着金汤匙出世的，由谷歌、IBM、Lyft 发动，尽管晚了 Linkerd 一年，然而一经推出，就受到宽泛的关注与追捧。Istio 基于 Golang 编写，完满符合 Kubernetes 环境，数据立体整合 Envoy，在服务治理方面职责明显，国内落地案例相较 Linkerd 更加宽泛。
Istio 目前总体还算是一个年老的开源中间件，大版本之间的组件架构有比拟大的区别，比方 1.0 引入了 Galley（如图左），1.5 去掉了 Mixer，并且管制立体整合成单体，减少了 WASM 扩大机制（如图右）。总体的架构模式没有太大变动，数据面还是关注流量的劫持与转发策略的执行，管制面仍然做遥测收集、策略下发、平安的工作。目前国内业界对于 Istio 的应用上，云商与头部公司处于当先地位，比方蚂蚁金服自研了本人基于 Golang 的数据立体 MOSN，兼容 Istio，做了许多优化工作，对 Istio 在国内落地做出了表率，更多的信息能够深刻理解，看如何打造更适宜国内互联网的 Service Mesh 架构。
尽管在 1.5 版本当中 Mixer 曾经根本被废除掉，进入维护阶段直到 1.7 版本，默认状况下 Mixer 齐全敞开，然而目前少数落地计划还是基于 1.0-1.4 这个版本区间，所以在没有整体降级的状况下，以及 WASM 性能不明朗的仿佛还，始终还是离不开 Mixer 的。后面说到 Service Mesh 是云原生容器环境与可观测性之间的桥梁，Mixer 的 Adapter 能够算得上是这个桥梁的钢架主体了，并且具备良好的可扩展性。Mixer Adapter 除了为流量做 Check 之外，更重要的是在预检阶段和报告阶段收集遥测数据，遥测数据通过 Adapter 裸露或发射数据到各种观测端，观测端基于数据绘制丰盛的流量轨迹与事件快照。罕用的用于可观测性的 Adapter 有对各种商用计划的适配，比方 Datadog、New Relic 等，开源计划 Apache SKyWalking、Zipkin、Fluentd、Prometheus 等，相干内容会在下文开展。
数据立体比方 Envoy 会向 Mixer 上报日志信息（Log）、链路数据（Trace），监控指标（Metric）等数据，Envoy 上报的原始数据都是一些属性信息（Attributes），属性信息是名称和类型的元数据，用来形容入口和进口流量和流量产生时的环境信息，而后 Mixer 会按照 LogEntry、Metric 或者 TraceSpan 模板配置的格局对属性进行格式化，最初再交给 Mixer Adapter 做进一步解决，当然对于数据量宏大的 Log 信息和 Trace 信息能够抉择间接上报解决端，Envoy 也原生反对一些特定组件。不同的 Adapter 须要不同的 Attributes，模板定义了 Attributes 到 Adapter 输出数据映射的 schema，一个 Adapter 能够反对多个模板。Mixer 当中又能够形象出三种配置模型：
Handler：示意一个配置好的 Adapter 实例；
Instance：定义 Attributes 信息的映射规定；
Rule：为 Handler 调配 Instance 以及触发规定；
下图是 Metric 模板与 LogEntry 模板，在映射关系之上还能够设定默认值，更多的设定能够查看官网文档。
下图是 TraceSpan 模板，相熟 OpenTracing 的同学可能对映射内容比拟相熟，很多信息都是 OpenTracing 协定的标准值，比方 Span 的各种形容信息以及 http.method、http.status_code 等等，感兴趣的同学也能够去看看 OpenTracing 的规范定义。另外在 Service Mesh 中对于链路追踪广泛有一个问题，就是无论你在数据立体如何做流量劫持，如何透传信息，以及如何生成或者继承 Span，入口流量和进口流量都有一个无奈串联的问题，这个问题要解决还是须要服务主容器来埋点透传，将链路信息透传到下一次申请当中去，这个问题是无奈防止的，而 OpenTelemetry 的后续推广，能够解决这方面的标准化问题。
Istio 可观测性实际
在 Istio Mixer Adapter 当中咱们能够获知，Istio 反对 Apache SKyWalking、Zipkin、Jaeger 的链路追踪，这三个中间件都反对 OpenTracing 协定，所以应用 TraceSpan 模板同时接入也没有什么问题。三者稍有不同的中央是：
Zipkin 算是老牌的链路追踪中间件了，我的项目发动工夫是 2012 年，新版的性能也比拟好用；
Jaeger 是 2016 年发动的新兴我的项目，应用 Go 编写，然而因为云原生的加持，致力于解决云原生时代的链路追踪问题，所以倒退很快，它在 Istio 中集成极为繁难，也是 Istio 官网举荐的计划
SkyWalking 是 2015 年开始开源，目前正在蓬勃发展的一个我的项目，然而稍有不同的是，目前它与 Istio 的联合是通过过程外适配的形式，接入损耗略微大一些，在最新的 8.0 版本（还未公布）当中有相应的解决方案；
另外一个在云原生链路追踪畛域收到宽泛应用的是中间件是 Jaeger，它是由 Uber 开源，被 CNCF 接收，目前曾经是一个毕业我的项目。它原生反对 OpenTracing 协定，与市面上的其余中间件也具备互通性，反对多种后端存储以及具备灵便的扩展性。在 Envoy 中原生反对 Jaeger，当申请达到 Envoy 的时候，Envoy 会抉择创立 Span 或继承 Span，以保障链路的连贯性，它反对 Zipkin 的 B3 系列 Header 透传，以及 Jaeger 与 LightStep 的 Header。下图是 Jaeger 当中对链路的展现，能够通过 TraceId 精确定位某一次申请。
传统的日志解决方案，ELK 能够说是妇孺皆知的，从 Spring Cloud 流行开始，它便是日志解决方案的低劣抉择。随着技术的倒退，近几年又呈现了 EFK 这种解决方案，存储组件 ElasticSearch 和界面 Kibana 倒是没有什么特地大的变动，然而在严苛的线上环境与容器环境中，以及各种对资源敏感的场景下，对于日志采集组件的要求也越来越高，目前比拟风行的计划是应用 Fluentd 或者 Filebeat 代替 Logstash，上面是它们三者的一些介绍：
Logstash：Java 编写，资源耗费大，当初个别不主张用作日志采集；
Fluentd：主体由 C 编写，插件由 Ruby 编写，2019 年 4 月从 CNCF 毕业，资源耗费十分小，通常占用内存在 30MB 左右，能够将日志发射到多个缓冲器，也就是多个接收端，目前在容器内比拟罕用的组件；
Filebeat：Go 编写，然而线上呈现过拉高底层资源 load average 的问题以及资源耗费较大，是 Fluentd 的 10 倍左右，在 Fluentd 呈现之前，其被宽泛使用在虚拟机当中；
对于 Istio 中的日志解决方案，只管 Mixer 当中有提供 Fluentd Adapter，然而日志的量级大家也晓得，这种形式并不好，所以从 Envoy 去拿到原始的属性日志再进行加工发射到存储端对利用是比拟敌对的，能够节俭出很大一部分资源。
在日志维度中，如果要定位问题，最好与申请绑定起来，而绑定申请与日志，须要一个特定的标识，能够是 TransactionId 或者是 TraceId，所以链路追踪与日志交融是一个势在必行的行业诉求，因而在抉择链路追踪中间件的时候，肯定要思考到如何更好地获取 TraceId 并与日志联合起来。
那么 Fluentd 就是最好的日志收集和发射解决方案了吗？
不是。Fluentd 的研发团队又推出了更加轻量级的 Fluent Bit，它是应用纯 C 编写的，占用资源更加少，从 Fluentd 的 MB 级别间接降为 KB 级别，更加适宜作为日志收集器。而 Fluentd 插件品种十分繁多，目前共有靠近上千种的插件了，所以它更适宜作为日志的聚合处理器，在日志收集之后的加工与传输中应用。在理论利用中，应用 Fluent Bit 可能会遇到一些问题，应用比拟晚期的版本可能会有配置动静加载的问题，解决办法就是另起一个过程管制 Fluent Bit 的启停，同时监听配置的变动，有变动则 reload。
对于上图中的 Loki，它的核心思想正如我的项目介绍，“Like Prometheus, but for logs”，相似于 prometheus 的聚合日志解决方案，2018 年 12 月开源，短短两年，却已有靠近 1 万个 Star 了！它由 Grafana 团队开发，由此能够看出 Grafana 对于一统云原生可察看性的目标。
在云原生时代，像以前那样用低廉的全文索引，如 ES，或者列式存储，如 HBase，将大量的原始日志间接存储到低廉的存储介质之中的做法，仿佛曾经不太得当。因为原始日志 99% 是不会被查问到的，所以日志也是须要做一些归并，归并之后压缩成 gzip，并且打上各式标签，这样可能会更加合乎云原生时代精细化运作的准则。
而 Loki 能够将大量的日志存储于便宜的对象存储中，并且它为日志打标归并成日志流的这种形式得以让咱们疾速地检索到对应的日志条目。然而留神一点，想要应用 Loki 代替 EFK 是不明智的，它们针对的场景不一样，对数据的完整性保障和检索能力也有差异。
自从 Prometheus 呈现以来，就牢牢占据着监控指标的次要位置。Prometheus 应该是以后利用最广的开源系统监控和报警平台了，随着以 Kubernetes 为外围的容器技术的倒退，Prometheus 弱小的多维度数据模型、高效的数据采集能力、灵便的查问语法，以及可扩大、不便集成的特点，尤其是和云原生生态的联合，使其取得了越来越宽泛的利用。
Prometheus 于 2015 年正式公布，于 2016 年退出 CNCF，并于 2018 年成为第 2 个从 CNCF 毕业的我的项目（第一个是 Kubernetes，其影响力可见一斑）。目前 Envoy 反对 TCP 和 UDP statsd 协定，首先让 Envoy 推送指标到 statsd，而后能够应用 Prometheus 从 statsd 拉取指标，以供 Grafana 可视化展现。另外咱们也能够提供 Mixer Adapter，接管解决遥测数据供 Prometheus 采集。
在 Prometheus 的理论应用当中可能会存在一些问题，比方 pod 被杀掉须要另外启一个，导致 Prometheus 数据失落，这就须要一个 Prometheus 的数据可长久化的高可用计划。CNCF 的沙箱我的项目外面有一个我的项目叫做 Thanos，它的核心思想相当于是在 Prometheus 之上做了一个相似数据库 sharding 的计划，它有两种架构模式：Sidecar 与 Receiver。目前官网的架构图用的 Sidecar 计划，Receiver 是一个临时还没有齐全公布的组件，Sidecar 计划绝对成熟一些，更加高效也更容易扩大。
Service Mesh 解决方案当中的 Linkerd 和 Conduit 都有可视化界面。Istio 相对来说比拟黑盒，始终被诟病，不过 Istio 社区联结 Kiali，独特推出了一个可视化计划，提供如下性能：
Topology：服务拓扑图；
Health：可视化健康检查；
Metrics：指标可视化；
Tracing：分布式链路追踪可视化；
Validations：配置校验；
Wizards：路由配置；
Configuration：CRD 资源的可视化与编辑；
上面是 Kiali 的架构，能够比较清楚地看出，其自身是一个前后端拆散的架构，并且能够从 Prometheus 或者集群特定 API 获取指标数据，另外也囊括了 Jaeger 链路追踪界面与 Grafana 展现界面，不过它们并非开箱即用，Kiali 依赖的三方组件须要独自部署。
总结
在许多的中小型公司外部，其实 Service Mesh 还是处于一个预研阶段，理论落地的时候须要思考的因素繁多，如何能力取得较好的的投入产出效力比，是每一个做选型的人员都必须要经验的。其实不论落地状况，鉴于云原生的可察看性哲学来说，在落地的同时做好可察看性，能够同步解决很多问题，防止消耗过多的资源在无意义的事件下面，综合可察看性的三大支柱以及 Service Mesh 中对可察看性的反对来说，总结如下：
Metrics：正当使用 Prometheus，并且做好长久化与高可用工作是要害；
Tracing：抉择适合的链路追踪中间件，关键在于集成符合度、整合 Logging、存储、展现来考量；
Logging：什么场景应用原始日志，什么场景应用摘要日志，要明确；
观测云——疾速实现零碎可观测
以后，云计算市场对系统的可观测性需求宏大，但真正具备可观测性的对立实时监测产品却寥寥无几。作为国内首批一体化零碎可观测平台——观测云，能疾速实现零碎可观测，对立满足您云、云原生、利用及业务上的监测需要。
观测云是新一代一体化数据平台，与传统计划齐全不同。反对全场景监测，全面数据驱动，用数字化伎俩全力保障我的项目团队计划，保障系统可靠性、稳定性。
观测云自问世以来，始终广受业内高度关注和市场好评，沉闷用户数继续飞速增长。2022 年 4 月，观测云首批通过中国信通院《可观测性平台技术能力》“先进级”评估（最高级），升级为国内可观测性 SaaS 服务赛道内领军品牌。4 月 28 日，“2022 观测云产品发布会”上，观测云强调会加大投入到 SRE 理念在国内的流传与实际，及对新一代可观测性技术的推广遍及。社区版的公布，是观测云践行承诺的重要动作之一，继观测云 SaaS 版之后，部署版也凋谢收费体验。
