为什么要使用服务网格?

要想说明为什么要使用服务网格,那就要从微服务架构说起,可以说服务网格很大程度上是一种新一代的微服务架构,它解决了微服务中网络层操控性、弹性、可视性的问题。

微服务架构

开发人员经常将云原生应用程序分解为多个执行特定动作的服务。你可能有一个只处理客户的服务和另一个处理订单或付款的服务。所有这些服务都通过网络相互沟通。如果一个新的付款需要被处理,请求会被发送到付款服务。如果客户数据需要更新,请求会被发送到客户服务,等等。

微服务架构
微服务架构

这种类型的架构被称为微服务架构。这种架构有几个好处。你可以有多个较小的团队从事个别服务。这些团队可以灵活地选择他们的技术栈和语言,并且通常有独立部署和发布服务的自主权。这种机制得以运作得益于在其背后通信的网络。随着服务数量的增加,它们之间的通信和网络通信也在增加。服务和团队的数量使得监控和管理通信逻辑变得相当复杂。由于我们也知道网络是不可靠的,它们会失败,所有这些的结合使得微服务的管理和监控相当复杂。

服务网格概述

服务网格被定义为一个专门的基础设施层,用于管理服务与服务之间的通信,使其可管理、可见、可控制。在某些版本的定义中,你可能还会听到服务网格如何使服务间的通信安全和可靠。如果我必须用一个更直接的句子来描述服务网格,我会说,服务网格是关于服务之间的通信。

但是,服务网格是如何帮助通信的呢?让我们思考一下通信逻辑和它通常所在的地方。在大多数情况下,开发人员将这种逻辑作为服务的一部分来构建。通信逻辑是处理入站或出站请求的任何代码,重试逻辑,超时,甚至可能是流量路由。因此,无论何时服务 A 调用服务 B,请求都要经过这个通信代码逻辑,这个逻辑决定如何处理这个请求。

通信逻辑
通信逻辑

我们提到,如果我们采用微服务的方法,最终可能会有大量的服务。我们如何处理所有这些服务的通信逻辑呢?我们可以创建一个包含这种逻辑的共享库,并在多个地方重用它。假设我们对所有的服务都使用相同的堆栈或编程语言,共享库的方法可能会很有效。如果我们不这样做,我们将不得不重新实现这个库,这会带来巨大的工作量而且效率低下。你也可能使用自己本身不拥有代码库的服务。在这种情况下,我们无法控制通信逻辑或监控。

第二个问题是配置。除了配置你的应用程序外,我们还必须维护通信逻辑配置。如果我们需要同时调整或更新多个服务,我们将不得不为每个服务单独进行调整。

服务网格所做的是,它将这种通信逻辑、重试、超时等从单个服务中分离出来,并将其移到一个单独的基础设施层。在服务网格的情况下,基础设施层是一个网络代理的阵列。这些网络代理的集合(每个服务实例旁边都有一个)处理你的服务之间的所有通信逻辑。我们称这些代理为 sideecar,因为它们与每个服务并存。

Sidecar 代理
Sidecar 代理

以前,我们让 Customer 服务直接与 Payment 服务通信,现在我们有一个 Customer 服务旁边的代理与 Payment 服务旁边的代理通信。服务网格控制平面以这样一种方式配置代理,即它们透明地拦截所有入站和出站请求。这些代理的集合(基础设施层)形成了一个网络网格,称为服务网格。

将通信逻辑从业务和应用逻辑中分离出来,可以使开发人员专注于业务逻辑,而服务网格运维人员则专注于服务网格配置。

服务网格的功能

服务网格为我们提供了一种一致的方式来连接、保护和观察微服务。网格内的代理捕获了网格内所有通信的请求和指标。每一次失败、每一次成功的调用、重试或超时都可以被捕获、可视化,并发出警报。此外,可以根据请求属性做出决定。例如,我们可以检查入站(或出站)请求并编写规则,将所有具有特定头值的请求路由到不同的服务版本。

所有这些信息和收集到的指标使得一些场景可以合理地直接实现。开发人员和运营商可以配置和执行以下方案,而不需要对服务进行任何代码修改。

  • mTLS 和自动证书轮换
  • 使用指标识别性能和可靠性问题
  • 在 Grafana 等工具中实现指标的可视化
  • 使用 Jaeger 或 Zipkin(需要对代码进行小的修改,以便在服务之间传播跟踪头信息) 对服务进行调试和追踪
  • 基于权重和请求的流量路由,金丝雀部署,A/B 测试
  • 流量镜像
  • 通过超时和重试提高服务的弹性
  • 通过在服务之间注入故障和延迟来进行混沌测试
  • 检测和弹出不健康的服务实例的断路器