服务网格如何简化微服务可观察性

服务网格和可观察性是微服务社区中的热门话题。在本趋势报告中，我们将详细探讨服务网格以及良好的可观察性堆栈如何帮助我们克服使用微服务时面临的一些最紧迫的挑战。 

常见的微服务挑战

采用微服务很难。调试并确保它们继续运行更加困难。微服务以第 2 天操作的形式引入了大量开销。让我们深入探讨使使用微服务变得困难的几个方面。 

在分布式系统中调试错误是一场噩梦

微服务的分布式特性使得调试错误变得困难。在单体应用中，只需查看日志和堆栈跟踪就足以确定错误的根本原因。当涉及到微服务时，事情就不是那么简单了。在出现错误的情况下，挖掘微服务的日志可能无法直接指出确切的问题。相反，它可以简单地提及从依赖微服务收到的请求和/或响应中存在的错误。 

换句话说，我们必须跟踪整个网络跟踪以确定哪个微服务是问题的根本原因。这是一个非常耗时的过程。 

识别系统中的瓶颈并不容易

在单体应用中，识别性能瓶颈就像分析我们的应用程序一样容易。分析通常足以确定代码库中哪些方法最耗时。这有助于您将优化工作集中在一小段代码上。不幸的是，找出导致整个系统变慢的微服务是一项挑战。 

单独测试时，每个微服务似乎都表现出色。但在现实世界的场景中，每项服务的负载可能会有很大差异。可能存在一些其他微服务所依赖的核心微服务。在孤立的测试环境中复制此类场景非常困难。 

维护微服务依赖树很困难

微服务的全部意义在于我们可以发布新软件的敏捷性。话虽如此，重要的是要注意发布微服务时可能会产生多种下游影响。某些经常破坏功能的事件是： 

• 在上游依赖之前释放依赖的微服务
• 删除遗留系统仍然依赖的已弃用 API
• 发布破坏 API 兼容性的微服务

当微服务之间没有明确的依赖树时，这些事件变得难以避免。依赖树可以更轻松地通知适当的团队并更好地计划发布。 

可观察性：微服务问题的解决方案

我上面提到的所有问题都可以通过可观察性来解决。根据 Jay Livens 的说法，可观察性是一种根据系统生成的指标和日志捕获系统当前状态的做法。它是一个系统，可以帮助我们监控应用程序的健康状况，生成故障警报，并在问题发生时捕获足够的信息来调试问题。 

任何可观察性堆栈都将具有以下组件： 

• 指标/日志的来源——我们用来生成数据的代理或库
• Metric/log shipper——将数据传输到存储引擎的代理；通常嵌入在度量源中
• 收集器/存储- 负责存储生成的数据的有状态服务
• 仪表板——精美的图表，使我们易于解释和消化数据
• 警报管理器——负责触发通知的服务

对我们来说幸运的是，有一些强大的开源工具可以帮助简化设置可观察性堆栈的过程。 

介绍服务网格

可观察性的一个主要方面是捕获网络遥测，拥有良好的网络洞察力可以帮助我们解决我们最初谈到的许多问题。通常，生成此遥测数据的任务由开发人员来实现。这是一个极其繁琐且容易出错的过程，并不会真正以遥测结束。开发人员还负责实施安全功能并使通信能够抵御故障。 

理想情况下，我们希望我们的开发人员编写应用程序代码，而不是别的。微服务网络的复杂性需要下推到底层平台。实现这种解耦的更好方法是使用服务网格，如Istio、Linkerd或Consul Connect。 

服务网格是一种用于控制和监控微服务网络和通信的架构模式。 

服务网格有两个主要组件：数据平面和控制平面。数据平面负责管理我们的微服务将产生的所有网络流量。为了实现这一点，服务网格会在我们的每个微服务旁边注入一个 sidecar 代理。这个 sidecar，通常是 Envoy，负责透明地拦截流过服务的所有流量。另一方面，控制平面仅负责配置代理。没有应用程序流量到达控制平面。 

如图 2 所示，服务网格架构可帮助您抽象出我们之前谈到的所有复杂性。最好的部分是我们可以开始使用服务网格，而无需编写任何代码。服务网格帮助我们管理基于微服务的架构的多个方面。一些显着的优势包括：

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

全面了解流量如何流动

在图 3 中，应用 A 正在向应用 B 发出请求。由于位于每个应用旁边的 Envoy 代理正在拦截请求，因此它们对流经这两个微服务的流量具有完全的可见性。代理可以检查此流量以收集信息，例如发出的请求数和每个请求的响应状态代码。 

换句话说，服务网格可以帮助我们回答以下问题： 

• 哪个服务正在与哪个对话？ 
• 每个微服务观察到的请求吞吐量是多少？ 
• 每个 API 的错误率是多少？ 

控制网络

服务网格不仅仅是一个沉默的旁观者。它可以积极参与塑造所有网络流量。用作 sidecar 的 Envoy 代理是 HTTP 感知的，并且由于所有请求都流经这些代理，因此可以配置它们以实现一些有用的功能，例如： 

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

它并没有在这里结束。代理还可以根据一定的权重分割流量。例如，我们可以将代理配置为将 95% 的传入流量发送到服务的稳定版本，而其余的可以重定向到金丝雀版本。这可以通过支持金丝雀部署等高级实践来帮助我们简化发布管理流程。 

保护微服务通信

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

服务网格还可以通过选择性地允许哪个服务与哪个服务进行通信来协助访问控制。所有这些都可以帮助我们彻底消除诸如中间人攻击等一整套安全漏洞。 

服务网格如何帮助提高可观察性？

我们刚刚看到了服务网格如何捕获遥测数据。让我们更深入地了解这些数据可以支持什么样的用例。 

分布式跟踪

我们已经讨论了调试微服务有多么困难。解决这个可调试性问题的一种方法是通过分布式跟踪——捕获请求生命周期的过程。仅一张图表就可以更容易找出问题的根本原因。 

大多数服务网格会自动收集网络跟踪并将其发送到 Jaeger 等工具。您需要做的就是在应用程序代码中转发一些 HTTP 标头。而已！ 

流量指标

服务网格可以帮助我们收集必须监控的四个黄金信号中的三个，以确定服务的健康状况： 

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

服务网格收集的指标还有很多，但这些是迄今为止最重要的指标。这些指标可用于支持几个有趣的用例。其中一些包括： 

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

网络拓扑结构

服务网格可以帮助我们自动构建网络拓扑，可以通过将跟踪数据与流量指标相结合来构建。如果你问我，这是一个真正的救星。网络拓扑可以帮助我们一目了然地可视化整个微服务依赖树。此外，它还可以突出我们集群的网络健康状况。这对于识别我们的应用程序中的瓶颈非常有用。