什么是服务网格？
在我们之前关于API 网关的文章中，我们讨论了服务如何处理外部客户端到服务（南北向）流量。
在处理服务间（东西向）流量时，通常会实现服务网格。
概述
服务网格是一个专用的基础设施层，用于处理服务之间的通信。它的目标是处理应用程序微服务之间的所有通信，而无需向客户端暴露配置细节。正如Tobias Kunze所说：
[服务网格] 是一个 API 代理网格，（微）服务可以插入其中，从而完全抽象化网络。
关键在于网络的抽象。服务网格的核心部分是：“服务如何相互发现？”
除了服务本身之外，服务网格还由两个主要部分组成：
在深入探讨您可能考虑使用服务网格的原因之前，让我们先来看看这些部分。
边车
大多数服务网格都实现了边车代理来处理所有服务间的通信。边车是与服务并行运行的适配器，它们就像部门之间的联络人或代表。服务之间并非直接通信，而是由边车负责路由和转换与服务之间的请求。
在Kubernetes这样的系统中，边车代理与应用容器安装在同一个 Pod 中，并以边车容器的形式存在。由于它们位于同一个 Pod 中，因此可以轻松通信，所有流量在到达应用之前都会先经过代理。这种共置方式也最大限度地减少了额外跳转带来的延迟。
所有服务的代理集合被称为数据平面。
控制平面
控制平面是数据平面的管理层。它负责创建新的服务实例、监控、管理服务间的安全性以及执行任何应用范围的策略。当需要更改网格中任何共享逻辑的运行方式时，控制平面会将必要的更新发送到边车服务。
控制平面通常采用可插拔系统实现，可以根据需要添加功能。这意味着，如果您需要为服务网格添加遥测功能，可以将其添加到现有的控制平面配置中。Istio就是一款流行的控制平面和服务网格管理解决方案，它正是以这种方式工作的。
服务网格的主要优势
随着服务网络规模的扩大，服务网格的优势会愈发凸显。它避免了重复编写相同或相似逻辑的麻烦。大多数服务网格实现都侧重于以下几个方面：
- 安全性：允许服务之间进行加密、相互认证和授权。网状架构允许您将这些逻辑与各个服务解耦。
- 可靠性：实施诸如健康检查、超时、断路器和重试等弹性模式。
- 可观测性：处理与微服务及其相互通信相关的所有遥测数据。这包括日志记录、监控和追踪等。如果没有网络网格，由于各个服务之间存在各种网络层（容器实例、虚拟机等），这将变得非常困难。
- 可配置性：由于网络本身与服务隔离，因此网格可以处理流量整形、负载均衡和 A/B 测试等功能。网格还可以跨服务应用共享策略和配置。
服务网格的缺点
虽然服务网格可以大幅减少现有的开销和配置，但对于您的团队来说，这是一个需要学习的新系统。尽管服务网格已经存在几年了，但其生态系统仍在快速发展，而且许多服务网格都与其构建所依赖的分布式平台（例如 Kubernetes）紧密相关。对于大型的现有应用程序或微服务较少的应用程序而言，最初投入的复杂性可能并不划算。
我们之前提到过，边车与服务的共置可以减少每次额外跳转的延迟，但应用程序和它们所依赖的服务之间仍然存在一个额外的层，即使这个层速度很快。
API网关在其中扮演什么角色？
API 网关与服务网格配合使用，负责将客户端流量路由到服务网格。服务之间的所有通信仍然在网格内部进行。随着服务网格技术的日趋成熟，它们开始借鉴 API 网关的许多特性。因此，一些实现方案现在能够处理客户端请求的外部路由以及所有相关的功能。
根据您选择的服务网格的功能集以及您的应用程序的要求，您可能会发现服务网格可以处理自身的角色以及 API 网关的角色。
服务网格架构适合您吗？
到目前为止，我们已经有所提及，但值得一提的是：服务网格与“云原生”应用模型的概念紧密相关。具体来说，它与微服务、容器化和编排层的结合密切相关。
这种应用模式带来的管理和复杂性，使得服务网格之类的解决方案显得尤为必要。如果你的应用只依赖几个微服务，那么服务网格就显得有些多余。只有当微服务数量超过几十个时，服务网格才真正发挥作用。一旦这些微服务之间开始通信，管理复杂性就会上升到一定程度，此时服务网格对你的事业来说才有意义。
总结
服务网格的未来在于普及和功能扩展。许多服务网格产品开始吸收API网关的部分功能。
如果你的应用是基于“云原生”应用模型构建的，那么你绝对可以考虑采用这种方式。否则，不妨看看其他解决方案，例如Bearer.sh，它可以帮助你的应用和服务更好地与外部和内部 API 通信。
Bearer.sh 的工作原理是集成了日志记录、实时通知、自动重试等功能，无需更改代码或进行复杂的配置。几分钟即可上手🚀。
📢什么是服务网格？这篇文章最初发表在 Bearer 博客上。
