译者 | 布加迪
审校 | 孙淑娟
下面看看这两种多云网络架构。实现网络服务和安全相关功能自动化，并将这些功能卸载到与云无关的服务网格上，就有助于简化多云环境的管理。
针对特定云供应商的网络解决方案的多云架构：
图1
与云无关的服务网格：
图2
许多服务网格产品包括服务发现、零信任网络和负载均衡功能，其他一些服务网格产品甚至更进一步，提供多云/多运行时环境连接、网络自动化和南北流量控制。不妨看一下与云无关的服务网格的功能，及其跨环境整合现有工具以帮助减少管理工作和成本的潜力。
服务发现
服务发现让开发人员可以登记和跟踪其网络上所有已注册服务的网络位置和健康状况。在服务不断增加或减少的动态环境中，这是一项重要的功能。这常常是向采用服务网格迈出的第一步。
有很多方法可以获得服务发现功能。但Kubernetes、Amazon EKS、Azure AKS、Google GKE或服务发现工具（比如AWS Cloud Map和配置管理数据库即CMDB）中内置的常用功能通常是它们在其中运行的平台或云所特有的。它们可以发现的服务范围局限于其特定平台或云的边界。然而，如今大多数组织在多个平台或云环境上运行应用程序，这意味着它们需要学习、安装和管理多个服务发现解决方案。
更好的方法是可以跨越多个运行时环境的与云无关的服务网格。比如说，HashiCorp Consul是一种中立的服务网格，支持Kubernetes、虚拟机、Amazon ECS和HashiCorp Nomad，允许组织跨多个异构环境集中处理全球服务发现。
如果将服务发现整合到服务网格中，平台团队可以将服务发现作为全球共享服务来提供，与依靠各个团队在没有任何监督的情况下运行和管理各自的服务发现工具相比，可以降低成本、改进合规并简化管理。
零信任网络
组织不再仅仅依赖保护网络边界的传统方法，而是日益寻求零信任网络来保护其网络和基础设施。
不像传统的城堡和护城河安全方法有赖于防护现代云环境中可能不存在的边界，零信任安全认为，任何服务（无论在边界内部还是外部）都不应被授予访问权限，除非它获得授权和身份验证，所有通信都经过加密。
运用零信任网络的几个原则：身份验证、授权和加密是服务网格的主要功能。服务网格通过代理（通常是Envoy）自动重定向服务之间的进出流量。这可以将授权、身份验证和加密等任务扔给代理。
服务网格使用服务身份而不是IP地址作为允许或拒绝授权的单位，极大地简化了管理服务到服务通信的工作。
管理员可以配置将由代理强制执行的一概拒绝的单一策略，以阻止所有服务到服务的通信。开发人员可以添加更精细化的策略，根据需要授权特定服务进行通信。
服务网格代理还将确保所有服务到服务的通信都自动进行身份验证和加密。在进行任何服务通信之前，代理确保交换TLS证书，并加密网络上的所有流量。这带来了更安全的网络，即使在发生网络安全事件后也能防止服务之间的横向移动。
最后，服务网格让管理员和开发人员能够在开发周期早期授权、验证和加密其网络服务，天生帮助组织向左移（shift left）。通过向左移，组织可以降低在部署到生产环境之前因不可预见的安全漏洞而导致最后一刻钟延误的风险。此外，使用服务网格向左移使网络管理员可以专注于保护网络边界，而不是管理单个IP地址。
服务网格是网络管理员的力量倍增器，也是抽象层，好让开发人员专注于其应用程序、而不是安全逻辑，并避免管理和轮换证书和密钥带来的麻烦。
负载均衡
由于服务网格上的数据流量流经代理，服务网格还可以控制流量整形等功能。一个简单的例子是服务的多个实例之间的负载均衡。服务网格允许自定义流量模式直接在实例之间分布，而不是通过不同的负载均衡设备完成额外的网络跳跃（hop）。即使实例增加或减少，服务网格也可以动态调整流量分布。使用服务网格可以大大降低跨多个不同环境和云管理多个不同负载均衡设备的成本和复杂性。
图3
对比：
图4
多云连接
许多组织的不同团队和服务分散在不同网络和某个云的多个区域。许多组织的服务还部署在多个云环境上。跨不同云网络安全地连接这些服务是一项大受欢迎的功能，通常需要网络团队花很大的精力。此外，要求子网之间无类域间路由（CIDR）范围不重叠的限制可能会阻止虚拟专用云（VPC）和虚拟网络（VNET）之间的网络连接。服务网格产品可以安全地连接在不同云网络上运行的服务，无需花一样大的精力。
比如说，HashiCorp Consul支持多数据中心拓扑结构，该拓扑结构使用网状网关在跨云的不同网络中运行的多个Consul部署环境之间建立安全连接。A团队可以在EKS上部署Consul集群。B团队可以在AKS上部署单独的Consul集群。C团队可以在专有本地数据中心的虚拟机上部署Consul集群。可以在这三个Consul集群之间建立多数据中心配置，从而为在EKS、AKS和虚拟机之间运行的服务提供安全连接，无需额外的网络配置，比如VPN、Direct Connect或ExpressRoute。即使IP范围在网络之间出现重叠，Consul网状网关也允许对多个Consul部署环境进行集群。
自动化
自动化在动态环境中尤其有利。波动的需求要求操作人员扩展服务实例的数量，这是比较简单的任务。然而，可能需要更新网络防火墙、负载均衡系统或其他网络基础设施，才能访问新实例。同样，新的应用程序服务可能需要更新网络设备，然后客户端才能访问它们。
由于大多数组织都有独立的网络团队和安全团队，这种工作流程常常需要手动提交工单，请求更新网络设备，这可能需要数小时甚至数天才能完成。缩减或停用服务可能导致另外的问题。这是由于很容易忽视要求网络团队从网络设备中删除IP地址的请求，从而导致潜在的安全漏洞。
为了应对这些挑战，一些服务网格与HashiCorp Terraform等基础设施配置工具建立了独特的集成。Consul与Terraform有独特的集成，可以自动触发网络设备更新和重新配置。操作人员可以配置Consul-Terraform-Sync（CTS），根据Consul目录中的服务出现的更改，自动更新防火墙和负载均衡系统等设备。自动处理这些任务减少了对手动工单系统的依赖，提高了工作流程效率，并加强了组织的安全状况。
南北流量控制
除了在组织网络内的服务之间整形和路由流量外，还需要确保可以从外部客户端访问这些服务。如果组织不打算扩展到单一云之外的云环境，AWS API Gateway、Azure API Management和Google Cloud API Gateway等云原生方案可能是不错的选择。对于在多个云上运行的组织而言，统一使用单个通用平台有其价值。
一些与云无关的服务网格（包括Consul）有内置的API网关，可以提供与云原生方案相似的功能。这让组织可以使用一个统一的管理平面来管理服务网格内部的流量（东西向）以及来自外部客户端的流量（南北向），因而不需要在不同环境上部署多个不同的API网关。
谁从服务网格的工具整合中受益？
既然服务网格有助于整合不同运行时环境之间的许多不同工具，是不是每家组织都应该将服务网格整合到基础设施中？这要看情况。
对于86%的已经使用或计划使用多个云的组织而言，服务网格绝对有助于遏制工具散乱现象。
就连致力于单一云提供商的组织也可能在处理不同的开发团队选择的不同运行时环境。统一使用服务网格以提供全球服务发现、零信任网络和负载均衡等功能，也能帮助这些组织缓解工具散乱现象。Consul等与云无关的服务网格可以通过内置功能提供进一步的工具整合，以连接云之间的服务、自动实现网络设备更新以及控制来自外部客户端的服务访问。
虽然一些小组织可能看不到整合工具的显著意义，但至少可以得益于采用服务网格作为力量倍增器，从而改善整体安全状况，不需要开发人员、平台工程师或网络工程师花另外的精力。
原文标题：All the Things a Service Mesh Can Do，作者：Van Phan
