服务网格怎么实现

服务网格怎么实现？“服务网格( Service Mesh )”是时下最流行的应用微服务基础架构，它的核心功能是实现微服务实例之间的互联和互通。

Istio 是最著名的服务网格开源项目，它支持多集群Kubernetes ，但大多数部署与 Kubernetes 集群是一对一的关系，多个集群之间不可避免地存在着“网隔”。

VMware Tanzu Service Mesh(简称 TSM )与NSX的全局名称服务( GSLB )相结合，可以将多个云和应用程序联合以连接彼此隔离的服务集群。因此，不妨将 VMware 的 TSM 解释为“ Terminator of Seperated Mesh ——网隔终结者 ”。

微服务和服务网格

Linux 容器和来自 Kubernetes 的容器编排的出现，通过高度自动化方法，大大提高了部署速度。单个服务可以打包为在 Kubernetes Pod 中运行的容器，并带有各自的语言运行时，这就是“微”服务架构。

微服务架构，可以说是应用开发领域的“解耦合”革命，解耦之后的应用开发将更少受到特定基础环境和资源的限制，但更加依赖服务之间的标准化、自动化、安全化的连接。

因为“微型化”和“解耦合”不是目的，新的架构的终极目标还是要将这些分散开发和部署的“微组件”进行更快、更好、更强的组合，形成可以面向最终用户的应用和服务，并不断迭代以适应最终用户的新需求和新变化。

微服务是在以 Kubernetes 为基础架构的平台上发展并日益成熟的。Kubernetes 为复杂的分布式、多语言应用程序提供应用程序可用性、弹性和整体管理，提供基本的负载平衡，但不涉及在其 Pod 中运行的每个应用程序组件如何与其他组件连接和交互。

网络是将微服务结合在一起以交付应用程序的粘合剂。微服务必须通过网络进行大量通信——它是应用程序微服务之间的连接。Kubernetes 在网络、安全和负载均衡方面，一直依赖于外部组件提供的服务。

“服务网格”( Service Mesh )应运而生，来填补“微服务连接”这个空白区间。从某种意义上，可以将 Serive Mesh 称之为“连接即服务( Connection as a Service )”。

使用服务网格，我们可以将这些微服务之间所需的连接功能抽象为一个单独的实体，称为“代理”。“代理”位于每个微服务的前面，所有通信都通过它传递。“代理”负责连接详细信息、流量管理、错误和故障处理以及出于可观察性目的收集指标。

当“代理”与其他“代理”通信时，就会形成一个网格状逻辑拓扑，这就是这个架构被称为“服务网格”原因。在服务网格中，代理通过“ Sidecar ”来实现。容器在 Pod 中运行，其中的“ Sidecar ”充当主容器的“辅助容器”，主容器运行业务逻辑。

传统上，企业网络的设计和构建是为了提供冗余，但是微服务化的应用程序逻辑中增加了对网络的依赖，网络(以及应用程序)故障的可能性与应用程序所依赖的连接数量成正比。

图1 服务网格采用 Sidecar 代理微服务之间的连接

VMware Tanzu Service Mesh

VMware 的Tanzu Service Mesh (以下简称为“TSM”)建立在 Istio 和 Envoy 等认可度高开源产品基础之上。Istio 专注于服务，用户可以从开源基础中受益，并获得服务的发现、连接、可观察性和安全性等功能：

服务到服务通信

控制服务之间的流量和 API 调用

对服务通信实施授权和加密

服务的遥测数据(跟踪、指标、日志)以实现可观察性

除了 Istio 在单集群中提供的基础功能之外，TSM 有能力为单云和多云环境中的应用程序提供端到端的连接性、连续性、弹性、安全性和可观察性——为企业提供从应用程序最终用户到微服务和数据的可见性和策略控制。TSM 的适用场景包括但不限于：

应用程序连续性：通过与 NSX 软件定义的应用交付相集成，确保应用程序连续性，以支持多区域和多区域高可用性和灾难恢复

应用程序弹性：通过自动自动扩展策略确保应用程序弹性，以实现多云应用程序的服务级别目标( SLO )

应用程序安全性：通过定义基于属性的授权策略，来实现服务到服务的访问控制，从而保护应用程序和数据

API安全性：增强跨应用程序最终用户、微服务/ API 和敏感数据的 TSM 可见性和控制

图2 TSM 总体架构

全局命名空间GNS

TSM 通过称为全局命名空间(Global Namespace)的抽象层，使操作和集成工作负载变得更容易。该抽象层通过 TSM 与 NSX 的全局负载均衡( GSLB )功能相结合，允许企业跨云和工作负载连接、管理和保护应用程序。这提供了完整的服务和应用程序移动性。

全局命名空间 GNS 是 TSM 与其他服务网格产品的主要区别点之一。TSM 与 NSX GSLB 的结合，现在被称为“ VMware Modern Apps Connectivity ” 解决方案。应用程序需要在混合传统和微服务架构的多集群、多云环境中运行。在这种情况下，企业的平台、基础设施和运维团队面临着一系列多云环境下的需求和挑战，包括但不限于：

职责分离(服务由不同业务部门开发)

将无状态和有状态服务分配到不同的 Kubernetes 集群

服务消费(使用一个云中的数据服务和不同云中的应用服务)

业务连续性

减小扩散半径

使用 TSM 可以在 GNS 级别配置并启用应用策略，例如基于高可用性、安全目标和流量分配目标的策略。以下是将 GNS 与不同集群上的 TSM 联合使用的两个场景。

例1 云爆发

随着我们公共服务的流量增加(模拟数据达到峰值)，并且当本地站点(下图中的 On-Prem )上的集群资源耗尽或超过某个阈值时，用户现在可以触发应用程序在云站点(下图中的 Cloud )上的扩展部署(手动或由触发自动部署)。

而且，由于在我们的设置云站点集群是相同的全局域名服务的一部分，在这个域名下添加新的服务节点，会自动触发 TSM 更新 GSLB 配置，但新的服务节点指向到云上的集群，并根据 GSLB 配置的策略将流量转移到新端点。

图3 应用在云上的无缝扩展

例2 更具弹性的故障转移机制(增强型高可用性)

图4 应用的跨云故障倒换

如果一个集群或站点上的后端服务出现了故障，常见的 GSLB 会产生一个“黑洞”——由于 GSLB 的健康状况检查检测需要一些时间检测到到后端服务节点故障(这可能需要几十秒，取决于管理员设置的重试的次数)。

使用 TSM，在目标集群上运行的 Ingress 网关将首先检测到故障，并通过与 GSLB 联动，将流量转移到另一个集群。因此，使用此解决方案的最终丢包率最低。

总结

作为提供虚拟云网络的领导者，VMware 了解为现代应用程序连接和安全创建操作简单的模型所面临的挑战。 

Tanzu Service Mesh 和 NSX 高级负载均衡，通过使用一致的策略实现服务的连接，提供了实现企业现代化的最佳途径，不仅适用于跨混合和多云环境的现代应用程序，而且还扩展到包括在 VM 中运行的传统应用程序。

VMware 将在不断发布的 TSM 版本中添加更多功能，其功能不仅限于负载平衡和路由，还支持围绕公共服务的企业级安全性等附加功能。