服务网格如何简化微服务的可观测性？

大家好，欢迎来到IT知识分享网。

译者 | 陈峻

最近一段时间，服务网格和可观测性已是微服务社区中的热门话题。在此，我们将详细地探讨服务网格以及可观测性技术栈，如何协助我们克服在使用微服务过程中的各种挑战。

常见的微服务挑战

通常，微服务会给应用上线的运维工作引入大量的开销。我们在调试和确保其持续运行的过程中，往往会面临如下方面的挑战：

难以在分布式系统中调试错误

在单体应用（monolith）时代中，我们只需查看日志和进行栈跟踪，即可确定错误的根本原因。而在微服务中，由于其本身的分布式特性，在出现错误时，挖掘微服务的日志可能仍无法直接获悉确切的问题。相反，它只能简短地报告那些从具有依赖性的微服务处，收到的请求和/或响应中存在的错误。换句话说，我们必须跟踪整个网络，以确定哪个微服务是导致问题的根本原因。而且，这是一个非常耗时的过程。

难以识别系统中的瓶颈

在单体应用中，识别性能瓶颈就像分析应用本身一样容易。通过基本分析，我们往往能够准确定位到代码库中，哪些方法最为耗时，以便将后续的优化工作集中在这一小段代码上。不过，定位导致整个系统变慢的微服务则是一项极具挑战的工作。尽管在各项单独的测试中，每个微服务似乎都能表现出色。但在现实的应用场景中，每项服务所面对的负载可能存在着巨大的差异。毕竟其中的一些可能会成为其他微服务所依赖的核心微服务。这是在孤立的测试环境中很难复现的状况。

难以维护微服务的依赖树（Dependency Tree）

微服务的主要优势在于我们可以敏捷地发布新的软件与服务。不过，在真实场景中，我们往往会因为如下事件，造成新发布的微服务会对其下游功能性产生多种影响：

• 在上游的依赖性的基础上，发布新的具有依赖性的微服务
• 删除了某个老旧系统里的仍然存在着依赖性、但已弃用的API
• 发布了一个会破坏现有API兼容性的微服务

当微服务之间没有明确的“依赖树”时，上述情况会变得难以避免。而依赖树则可以将各个组件之间的关系，更便捷地通知给适当的团队，以指定更好的发布计划。

微服务的可观测性

其实，上面提到的各种问题都可以由可观测性来解决。此处的可观测性是一种根据系统生成的指标和日志，来捕获系统当前状态的做法。作为一个系统，它可以帮助我们监控应用程序的健康状况，生成故障警报，并在问题发生时，捕获足够的信息，以便后续的问题调试。

图 1：具有开源示例的可观测性技术栈组件

如上图所示，可观测性技术栈通常包含如下组件：

• 指标/日志源——用来生成数据的代理或库
• 指标/日志搬运器——将数据传输到存储引擎的代理，通常被嵌入在指标源中
• 收集器/存储——负责存储已生成数据的有状态服务
• 仪表板——通过全面的图表，满足数据的解释和摘要
• 警报管理器——负责触发通知的服务

我们可以通过各种强大的开源工具，来简化设置整个可观测性技术栈的过程。

服务网格（Service Meshes）介绍

从原理上说，可观测性主要是通过捕获网络中的遥测数据（telemetry），运用良好的网络洞察力，来协助开发者解决前文提到的各种问题。当然，生成遥测数据的任务是一个极其繁琐且易错的过程。开发人员不但要保证在功能上的安全实现，而且要让数据通信能够抵御可能发生的故障。为此，我们可以通过诸如：Istio、Linkerd或Consul Connect之类的服务网格，以解耦的方式，将微服务网络的复杂性下放到底层平台。下面，让我们以Istio为例，来了解一下服务网格是工作原理。

图 2：典型的服务网格架构图片来源–https://istio.io/latest/docs/ops/deployment/architecture

如上图所示，服务网格有两个主要组件：数据平面（data plane）和控制平面（control plane）。其中，数据平面负责管理由微服务产生的所有网络流量。为此，服务网格会在每个微服务旁注入一个sidecar代理。我们可以采用Envoy作为sidecar，负责透明地拦截流过服务的所有流量。而控制平面仅负责配置代理。也就是说，没有任何应用流量会到达控制平面。

如图 2 所示，服务网格架构可协助我们抽象出所有的复杂性，且无需编写任何代码。同时，服务网格可以运用如下三大优势，帮助我们管理基于微服务的应用架构的各个方面：

• 全面了解流量是如何流动的
• 控制网络流量
• 保护微服务通信

全面了解流量是如何流动的

在下面的图 3 中，应用A正在向应用B发出请求。由于位于每个应用旁边的Envoy代理正在拦截请求，因此它们对于流经这两个微服务的流量具有完全的可见性。例如，Envoy代理可以通过检查流量，以收集到诸如：发出的请求数和每个请求的响应状态代码等信息。具体而言，服务网格可以帮助我们回答以下问题：

• 哪两个服务正在通信？
• 被每个微服务观察到的请求的吞吐量有多少？
• 每个API的错误率是多少？

图 3：服务网格可以协助收集指标

控制网络流量

服务网格并非在一旁作壁上观，它会积极地参与塑造所有网络流量的工作。例如，被用作sidecar的Envoy代理不但具有HTTP感知能力，并且可以被配置为实现如下功能：

• 自动尝试——在遇到网络错误时重放某个请求
• 断路——将已停止响应的上游微服务的副本列入黑名单
• 请求重写——在满足某些条件时，设置标头或修改请求的URL

图 4：服务网格可以控制网络流量

此外，代理还可以根据一定的权重去分割流量。例如，我们可以通过支持金丝雀（Canary）部署等高级方式，将代理配置为将95%的传入流量，发送到服务的稳定版本；而将其余的流浪重定向到金丝雀版本处，以简化发布管理的流程。

保护微服务通信

使用服务网格的另一个优势便是安全性。我们的sidecar代理可以被配置为使用双向TLS，以确保所有的网络流量在传输过程中，都得到自动加密。其中，mTLS所需的证书管理和置换任务，都可以由服务网格的控制平面来自动化实现。

服务网格还可以通过选择性地允许哪些服务相互进行通信，来协助访问控制。据此，我们可以有效地消除诸如中间人（man-in-the-middle）攻击等安全漏洞。

图 5：服务网格可以保护网络流量

​服务网格如何协助提高可观测性？

下面，让我们继续深入了解由服务网格捕获的遥测数据可以支持哪些用例。

分布式跟踪

针对上文提到的有关调试微服务的挑战，我们可以通过分布式跟踪，来捕获请求的生命周期全过程。据此，我们可以仅通过一张图表，就能够轻松地找出问题的根本原因。

通常，大多数服务网格都会自动收集网络行踪，并发送到Jaeger等工具处。因此，只需要在应用程序的代码中，转发相关的HTTP标头即可。

流量指标

服务网格也可以帮助我们收集如下值得关注的三大“黄金监控信号”，以确定服务的健康状况：

• 请求吞吐量——被某个微服务正在服务的请求数。
• 响应错误率——失败请求的百分比。
• 响应延迟——微服务响应所需的时间。它往往是一个直方图，可以从中提取n个百分位的延迟。

当然，服务网格还能收集到许多其他类型的指标。这些指标可用于支持各种丰富的用例。例如：

• 根据请求的吞吐量等高级参数启用扩展
• 启用诸如：速率限制和断路等高级流量控制功能
• 执行自动化的金丝雀部署和A/B测试

网络拓扑结构

服务网格也可以通过将跟踪数据与流量指标相结合，来协助我们构建自动化的网络拓扑。通过网络拓扑，我们便可以一目了然地可视化整个微服务的依赖树。此外，服务网格还可以突出显示集群的网络健康状况，以帮助我们有效地识别应用程序中的瓶颈。

​总结

综上所述，服务网格主要能够在如下方面提高微服务的可观测性：

• 通过生成分布式的跟踪数据，来简化调试
• 通过捕获微服务的黄金监控信号，来担任关键指标的来源
• 生成网络拓扑

可见，服务网格非常实用，而且无需编写任何代码。如果您对其感兴趣的话目前，还可以通过如下指南与链接，去深入了解服务网格在微服务可观测性方面已经有了不少的各种实践，相关Istio、LinkerD、Kuma、Prometheus、Grafana的应用细节和案例都可以从官网上得到，不失为一种可观测性利器。

译者介绍

陈峻 （Julian Chen），51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验；持续以博文、专题和译文等形式，分享前沿技术与新知；经常以线上、线下等方式，开展信息安全类培训与授课。

原文链接：

https://dzone.com/articles/how-a-service-mesh-simplifies-microservice-observa

来源： 51CTO技术栈