什么是服务网格？

在上一篇有关API网关的文章中，我们讨论了服务如何处理外部客户端到服务 （南北）流量。

在处理服务到服务 （东西方）流量时，通常会实现服务网格。

总览

服务网格是处理服务之间的通信的专用基础结构层。 它旨在处理应用程序微服务之间的所有通信，而无需向客户端公开配置详细信息。 正如Tobias Kunze所说：

[服务网格]是API代理的网格，微服务可以插入这些API网格以完全抽象网络。

这里的关键是网络的抽象。 服务网格的核心部分是：“服务如何相互找到？”

除了服务本身之外，服务网格还包括两个主要部分：每个服务的边车和控制平面。 在深入探讨为什么考虑使用服务网格的原因之前，让我们看一下这些部分。

边车

大多数服务网格都实现了sidecar代理来处理所有服务间通信 。 边车是与服务并排放置的适配器。 他们就像部门之间的联络员或代表。 边车不是将服务直接彼此通信，而是路由和转换与服务之间的请求并进行转换。

在像Kubernetes这样的系统中，sidecar代理与sidecar容器安装在同一容器中，与应用程序容器并排放置。 由于它们都在同一个Pod中，因此它们可以轻松进行通信，所有流量在到达应用程序之前都要通过代理。 这种共置也使附加跃点的附加等待时间最小。

我们所有服务的代理集合称为数据平面 。

控制平面

控制平面是数据平面的管理层。 它负责创建服务的新实例，监视，管理服务之间的安全性以及实施任何应用程序范围的策略。 当需要更改任何共享逻辑在网格上的工作方式时，控制平面会将必要的更新发送到边车。

控制平面通常被实现为可插拔系统，其中可以根据需要添加功能。 这意味着，如果需要为服务网格添加遥测，则可以将其添加到现有控制平面配置中。 Istio是一种流行的控制平面和服务网格管理解决方案，可以通过这种方式工作。

服务网格的主要优势

随着服务网络的增长，服务网格的好处开始变得越来越重要。 这样可以避免一遍又一遍地重写相同或相似的逻辑。 大多数服务网格实现都集中在：

• 安全性 ：允许服务之间进行加密以及相互认证和授权。 网格使您可以将此逻辑与各个服务分离。
• 可靠性 ：实现弹性模式，例如运行状况检查，超时， 断路器和重试。
• 可观察性 ：处理与微服务及其相互之间的通信有关的所有遥测数据。 这包括日志记录，监视和跟踪。 如果没有网状网络，由于位于每个服务之间的网络的各个层次（容器实例，VM等），这可能会很困难。
• 可配置性 ：由于网络是从服务本身中抽象出来的，因此网格处理诸如流量整形，负载平衡和A / B测试之类的功能。 网格还跨服务应用共享策略和配置。

服务网格的缺点

虽然服务网格可以消除大量的现有开销和配置，但它是团队学习的新系统。 尽管它们已经存在了几年，但生态系统仍在不断发展，许多生态系统与其所构建的分布平台（例如Kubernetes）紧密相关。 对于大型，既存的应用程序或微服务很少的应用程序，最初的复杂性投资可能没有意义。

前面我们曾提到，边车与服务的并置可以减少每增加一跳的等待时间，但是应用程序和它们所依赖的服务之间仍然存在一个附加层，即使这是一个快速的层。

API网关从哪里进入？

API网关一起使用，可处理从客户端到服务网格的流量路由。 网格内仍会发生任何服务间通信。 随着服务网格变得越来越成熟，它们开始采用API网关的许多功能。 结果，一些实现现在可以处理客户端请求的外部路由以及接任该角色所需的所有功能。

根据所选服务网格的功能集以及应用程序的要求，您可能会发现服务网格可以处理自己的角色以及API网关的角色。

服务网格适合您吗？

到目前为止，我们已经提到了这一点，但是值得一提：服务网格与“云原生”应用程序模型紧密相关。 特别是微服务，容器化和业务流程层的混合。

这种应用程序样式带来的管理和复杂性增加了对诸如服务网格之类的解决方案的需求。 如果您的应用程序仅依赖于一些微服务，那么服务网格就显得过大了。 直到您超过数十个微服务级别。 一旦它们彼此通信，该管理复杂性将上升到服务网格对您的业务有意义的水平。

包起来

服务网格的未来是采用和功能扩展。 许多服务网格产品开始吸收API网关的某些功能。

服务网格可以帮助您管理堆栈中服务器到服务的通信，而Bearer我们正在构建解决方案，通过结合日志记录，实时通知，自动重试等功能，帮助您的应用和服务更好地与第三方API进行通信。 ，以及更多无需更改代码或配置复杂的内容。 立即尝试Bearer 。

post本文最初由 Mark Michon 在 Bearer Blog 上 撰写

From: https://hackernoon.com/what-is-a-service-mesh-582a36q9