服务网格可以做从服务发现到零信任安全、负载均衡、多云连接、自动化和南北流量的所有事情。
即使服务网格的采用持续增长，一些组织仍在尝试全面了解服务网格可以做什么和不能做什么。
他们可能没有意识到服务网格不仅是一种单一用途的工具，而且可以满足各种网络需求。服务网格实际上可能有助于整合多个现有工具，以帮助减少管理工作和成本。
看看这两种多云网络架构：
哪个看起来不那么复杂？
如果您选择的服务网格与云无关，则可以大大简化多云架构。不仅如此，许多服务网格产品还包括服务发现、安全的服务到服务通信、负载均衡功能以及包含渐进式交付模式的 L7 和 L4 网络管理功能。
其他一些服务网格产品进一步扩展以提供多云/多运行时连接、网络基础设施自动化和南北流量控制。让我们看一下与云无关的服务网格的功能，以及它在跨环境整合现有工具以减少开支方面的潜力。
服务发现
服务发现允许开发人员编目和跟踪其网络上所有已注册服务的网络位置和健康状况。在服务不断扩大和缩小的动态环境中，这是一项重要的能力。这通常是服务网格采用之旅的第一步。
有很多方法可以获得服务发现能力。但 Kubernetes、Amazon EKS、Azure AKS、Google GKE 或 AWS 云地图和配置管理数据库 (CMDB) 等服务发现工具中内置的常用功能通常特定于它们所运行的平台或云。他们可以发现的服务范围仅限于其特定平台或云的边界。然而，今天，大多数组织跨多个平台或云环境运行应用程序，这意味着他们需要学习、安装和管理多个服务发现解决方案。
更好的方法是可以跨越多个运行时的与云无关的服务网格。例如，HashiCorp Consul是一个不可知的服务网格，包括对 Kubernetes、虚拟机、Amazon ECS 和 HashiCorp Nomad 的支持，允许组织跨多个异构环境集中全局服务发现。
通过将服务发现整合到服务网格中，平台团队可以将服务发现作为全局共享服务提供，与依靠单个团队在没有任何监督的情况下运行和管理自己的服务发现工具相比，这可以降低成本、提高合规性并简化管理。
零信任网络
组织不再仅仅依赖于保护网络边界的传统方法，而是越来越多地寻求零信任网络来保护他们的网络和基础设施。
与依赖于防御现代云环境中可能不存在的边界的传统城堡和护城河安全方法不同，零信任安全认为任何服务（无论是在边界内部还是外部）都不应被授予访问权限，直到它被授权和身份验证，所有通信都经过加密。
应用身份验证、授权和加密的零信任网络原则是服务网格的主要功能。服务网格通过代理（通常是Envoy）自动重定向服务之间的入口和出口流量。这允许将授权、身份验证和加密职责转移到代理上。
服务网格使用服务身份而不是 IP 地址作为允许或拒绝授权的单位，极大地简化了服务到服务通信的管理。
管理员可以配置一个单一的拒绝所有策略，该策略将由代理强制执行，以阻止所有服务到服务的通信。开发人员可以添加更精细的策略来授权特定服务根据需要进行通信。
服务网格代理还将确保所有服务到服务的通信都自动进行身份验证和加密。在进行任何服务通信之前，代理会确保交换 TLS 证书并加密网络上的所有流量。这导致网络更加安全，即使在发生网络破坏后也能防止服务之间的横向移动。
最后，服务网格通过为管理员和开发人员提供在开发周期早期授权、验证和加密其网络服务的能力，从本质上帮助组织左移，通过左移，组织可以在投入生产之前降低由于不可预见的安全漏洞而导致的最后一分钟延误的风险。此外，使用服务网格向左移动使网络管理员可以专注于保护网络边界，而不是管理单个 IP 地址。
服务网格是网络管理员的力量倍增器和抽象层，允许开发人员专注于他们的应用程序而不是安全逻辑，并避免管理和轮换证书和密钥的麻烦。
负载均衡
由于服务网格上的数据流量流经代理，服务网格还可以控制流量整形等功能。一个简单的例子是服务的多个实例之间的负载均衡。服务网格允许自定义流量模式直接在实例之间分布，而不是通过单独的负载均衡设备进行额外的网络跃点。即使实例向上或向下扩展，服务网格也可以动态调整流量分布。使用服务网格可以大大降低跨多个不同环境和云管理多个不同负载均衡设备的成本和复杂性。
这是一个传统的负载均衡拓扑，在服务 A 与服务 B 对话之前，负载均衡器有一个额外的网络跃点：
在像 Consul 这样的服务网格中，没有额外的跃点，因为 sidecar 代理直接通信并且 Consul 集中管理每个代理之间的流量平衡：
多云连接
许多组织拥有分散在给定云的不同网络和区域中的不同团队和服务。许多还跨多个云环境部署服务。跨不同云网络安全地连接这些服务是一项非常理想的功能，通常需要网络团队付出大量努力。此外，要求子网之间不重叠的无类域间路由 (CIDR) 范围的限制可能会阻止虚拟私有云 (VPC) 和虚拟网络 (VNET) 之间的网络连接。服务网格产品可以安全地连接在不同云网络上运行的服务，而无需付出同样的努力。
例如，HashiCorp Consul 支持多数据中心拓扑，该拓扑使用网状网关在跨云的不同网络中运行的多个 Consul 部署之间建立安全连接。团队 A 可以在 EKS 上部署 Consul 集群。团队 B 可以在 AKS 上部署一个独立的 Consul 集群。团队 C 可以在私有的内部数据中心的虚拟机上部署 Consul 集群。可以在三个 Consul 集群之间建立多数据中心配置，允许在 EKS、AKS 和虚拟机之间运行的服务进行安全连接，而无需额外的网络配置(如 vpn、Direct Connects 或 ExpressRoutes)。Consul 网状网关允许将多个 Consul 部署集群化，即使 IP 范围在网络中重叠。
自动化
自动化在动态环境中尤其有利。波动的需求要求运营商扩展服务实例的数量，这是一项相当微不足道的任务。但是，可能需要更新网络防火墙、负载均衡器或其他网络基础设施，才能访问新实例。类似地，新的应用程序服务可能需要更新网络设备，然后客户端才能访问它们。
由于大多数组织都有独立的网络和安全团队，因此这些工作流程通常涉及网络设备更新的手动工单请求，这可能需要数小时甚至数天才能完成。缩减或停用服务可能会导致额外的问题。这是因为网络团队从网络设备中删除 IP 地址的请求很容易被忽视，从而导致潜在的安全漏洞。
为了应对这些挑战，一些服务网格与 HashiCorp Terraform 等基础设施供应工具建立了独特的集成。Consul 与 Terraform 具有独特的集成，可以自动触发网络设备更新和重新配置。运营商可以配置Consul-Terraform-Sync (CTS)以根据 Consul 目录中服务的更改自动更新防火墙和负载均衡器等设备。自动化这些任务减少了对手动票务系统的依赖，提高了工作流程效率，并加强了组织的安全状况。
南北交通管制
除了在组织网络内的服务之间调整和路由流量外，还需要从外部客户端提供对这些服务的访问。AWS API Gateway、Azure API Management 和 Google Cloud API Gateway 等云原生选项对于不打算扩展到单一云的组织来说可能是不错的选择。然而，对于在多个云上运行的组织而言，在单个通用平台上进行标准化是有价值的。
一些不可知的服务网格，包括 Consul，有一个内置的API 网关，可以提供与云原生选项类似的功能。这使组织可以使用一个一致的管理平面来管理服务网格流量（东西向）以及来自外部客户端（南北向）的流量，从而无需在不同环境中部署多个不同的 API 网关。
谁从服务网格的工具整合中受益？
如果服务网格可以帮助整合不同运行时之间的许多不同工具，那么每个组织都应该将服务网格整合到他们的基础设施中吗？这取决于：
对于81% 已经使用或计划使用多云的组织而言，服务网格绝对可以帮助遏制工具的蔓延。
即使是致力于单一云提供商的组织也可能要处理由不同开发团队选择的不同运行时。对服务网格进行标准化以提供全局服务发现、零信任网络和负载均衡也可以帮助这些组织减少工具蔓延。像 Consul 这样的服务网格可以通过内置特性提供进一步的工具整合，以连接云之间的服务、自动化网络设备更新以及控制外部客户端对服务的访问。
虽然一些较小的组织可能看不到工具的显着整合，但至少他们仍然可以通过采用服务网格来改善他们的整体安全状况，而不会给开发人员、平台工程师或网络工程师带来额外的负担。
译自：https://www.hashicorp.com/blog/what-can-a-service-mesh-do
译者：#公众号：进击云原生