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