服务网格：架构、概念和4大框架常用工具

什么是服务网格？

服务网格提供了使应用程序更加安全、可靠和可观察的功能。这些功能是在平台层提供的，而不是应用层。

服务网格通常以sidecar模式实现为一系列网络代理，并使用应用程序代码来管理它们的行为。代理管理微服务之间的通信，并为引入服务网格功能提供入口点。总的来说，代理形成了服务网格的数据平面，该数据平面作为控制平面的可扩展单元进行控制。

由于云原生应用程序的广泛采用，服务网格越来越受欢迎。云原生应用程序可以包含数百个服务和数千个服务实例。这些实例通常由Kubernetes管理，在物理节点上动态调度，其状态不断变化。这使得服务到服务的通信变得极其复杂，并直接影响应用程序的运行时行为。

服务网格技术使得管理这种复杂的服务间通信成为可能，以确保可靠性、安全性和端到端性能。

服务网格可以解决管理服务之间通信的一些主要挑战，但它们也有其缺点。服务网格的优点包括：

服务网格的一些缺点是：

服务网格的功能和组件有一个独特的术语：

容器编排框架——服务网格架构通常与Kubernetes或Nomad等容器编排器一起运行。
Sidecar代理——它们与每个Pod或实例一起运行，并相互通信以在它们运行的容器之间路由流量。它们通过编排框架进行管理。
服务和实例——实例（或Pod）正在运行微服务的副本。客户端通常通过服务访问实例，服务是实例的可扩展、容错副本。
服务发现——实例需要发现它们需要与之交互的服务的可用实例。这通常涉及DNS查找。
负载均衡——编排框架通常为传输层（第4层）提供负载均衡，但服务网格也可以为应用层（第7层）提供负载均衡。
加密——服务网格可以加密请求和响应，然后解密它们。他们优先考虑重用已建立的连接，从而最大限度地减少创建新连接的需要并提高性能。通常，流量使用双向TLS进行加密，公钥基础设施生成密钥、证书以及sidecar代理使用的密钥。
认证和授权。服务网格可以授权和验证应用程序外部和内部发出的请求，仅向实例发送经过验证的请求。
断路器模式——这涉及隔离不健康的实例并在需要时将它们逐渐恢复。
数据平面是服务网格的一部分，用于管理实例之间的网络流量。控制平面生成并部署控制数据平面的配置。它通常包括（或可以连接到）命令行界面、API和图形用户界面。

服务网格不会向应用程序的运行时环境引入新功能。对于任何架构，应用程序都需要规则来定义请求的通信方式。服务网格的不同之处在于，它们将管理服务间通信的逻辑抽象到基础设施层（而不是单个服务）。

这是通过将服务网格作为一组网络代理构建到应用程序中来实现的。

代理通常用于从企业设备访问网站。通常，对网页的请求首先由公司的Web代理接收，该代理会检查这些请求是否存在安全问题，然后才将请求发送到主机服务器。来自页面的响应也会发送到代理进行安全检查，然后再返回给用户。

服务网格中的代理也称为边车，因为它们与微服务一起运行，而不是在微服务内部运行。它们在各自基础设施层的微服务之间路由请求。这些代理共同形成一个称为网格的网络。

如果您没有服务网格，则需要使用管理服务之间通信的逻辑对每个微服务需求进行编码。这不仅极大地浪费了您的时间，而且还使诊断通信故障变得更加困难，因为管理服务间通信的逻辑隐藏在服务内部。

安全性是云原生应用程序的一个关键问题。许多组织正在采用零信任方法，这种方法特别适合云原生环境。零信任安全模型假设不存在网络边界。它不信任任何实体，即使它位于网络“内部”，并且需要对应用程序组件之间的任何通信以及外部通信进行持续的身份验证和验证。

以下是服务网格可以帮助实现零信任安全的几种方法：

服务网格可以帮助减轻以下类型的攻击：

转载请注明出处：https://www.cloudnative-tech.com/uncategorized/6006.html