TSB 架构

本节重点介绍组成 TSB 的架构及其含义。你将获得以下方面的知识:

  • 我们的可靠部署理念是 TSB 架构背后的驱动力
  • 数据平面,由 Envoy 提供支持
  • 由 Istio 提供支持的本地控制平面
  • Tetrate Service Bridge 的全局控制平面
  • Tetrate Service Bridge 的管理平面
  • 拥有管理平面的重要性
  • Tetrate Service Bridge 中的 Envoy 扩展

读完本节后,你应该清楚地了解 TSB 架构的每个元素以及它们如何协同工作以帮助你管理环境。

部署理念

TSB 的架构基于以故障域为中心的强大部署理念。此方法涉及识别和隔离关键系统发生故障时受影响的基础设施部分。这些故障域分为三类:

  • 物理故障:包括主机故障、机架故障、硬盘驱动器故障和资源短缺。
  • 逻辑故障:逻辑故障包括错误配置、安全漏洞以及与依赖项和数据相关的问题。
  • 数据故障:这些涉及数据库问题、错误更新、复制失败和备份问题。

为了创建可靠的系统,这些故障域被分组到孤岛中并作为独立实例进行复制。所得系统的可靠性取决于最小化副本之间的相互依赖性。

物理故障域

在现代云环境中,需要考虑的一组物理故障域已被浓缩为一个简单的概念,称为可用区(Zone)。然而,我们必须记住,可用性区域并不总是彼此完全隔离,正如云提供商中断所证明的那样。

为了解决这个问题,云提供商将多个可用区域组织到一个称为区域的更高级别的故障域中。虽然同一区域中的多个可用区发生故障的情况并不罕见,但多个区域发生故障的可能性很小。

因此,在考虑可用区和区域(Region)作为物理故障域的同时,还必须考虑逻辑故障域。

逻辑故障

逻辑故障很大程度上取决于我们自己的应用程序架构,并且往往更难以推理。作为应用程序开发人员,要考虑的关键要素是应用程序的部署、配置、数据、依赖项以及它的公开方式(负载平衡、DNS 等)

在典型的微服务架构中,我们设计应用程序来使用云提供商数据库,使用单个区域中跨可用区的云提供商原语运行它(使用 Kubernetes、VM 自动缩放组、容器 aaS 产品等),并尽可能与部署在同一区域的依赖进行通信。当这不可能时,我们依赖于 DNS 等全局负载平衡层。这是我们的故障域孤岛,我们将其复制到其他区域以实现可用性,以某种方式处理数据复制(这是一个难题,也是影响所有孤岛的常见故障域)。

保持本地化

创建没有耦合故障域的隔离孤岛的最简单方法之一是在每个孤岛中运行关键服务的独立副本。我们可以说这些副本对于筒仓来说是“本地”的,因为它们共享相同的故障域,包括物理故障域,这意味着它们位于附近。

在 Tetrate Service Bridge,我们遵循这种“保持本地化”模式,在运行应用程序的每个计算集群中运行 Istio 控制平面的实例。换句话说,我们部署 Istio,使其物理故障域与你的应用程序保持一致。此外,我们确保这些实例是松散耦合的,不需要彼此直接通信,从而最大限度地减少它们需要在孤岛之外进行的任何通信。

这意味着你运行的每个集群都是一座孤岛,其中一个集群的故障不会导致其他集群的故障。此外,由于控制平面位于集群本地,因此它了解正在发生的情况。当发生故障时,它可以继续保持其网格部分在其本地上下文中尽可能表现最佳。

有了这个基本原语,我们就可以通过简单地跨孤岛进行整体故障转移来开始构建更可靠的系统。如果孤岛中出现任何问题,我们可以将所有流量发送到不同的孤岛,直到解决问题为止。

但为了将其提升到一个新的水平,我们想要做的是在部分发生故障时促进跨孤岛的通信,而不是对整个事情进行故障转移。为此,我们需要跨部门进行沟通。

促进跨孤岛通信

保持本地化为我们提供了一组可用但不互连的孤岛。这会导致浪费并使故障转移操作变得痛苦。

更新从 K8s 流向 TSB,然后返回远程集群中的 TSB 组件的框图。
更新从 K8s 流向 TSB,然后返回远程集群中的 TSB 组件的框图。

我们经常想要找到一个健康的依赖实例,即使它不在我们的本地孤岛中,并将请求路由到它。例如,如果我们在一个集群中的后端服务部署不当,我们希望前端能够故障转移到第二个集群中的现有部署。TSB 促进了应用程序的跨孤岛通信,同时最大限度地减少了 Istio 控制平面实例与其全局控制平面之间所需的配置同步。它将网格中每个集群的入口点地址以及该集群中可用的服务集发布到 TSB 管理的每个 Istio 实例。当服务在本地发生故障,或者本地服务需要与远程依赖项进行通信时,我们可以将该流量定向到具有我们所需服务的远程集群,而应用程序本身无需担心依赖项所在的位置。

与互联网比较

我们经常使用互联网作为例子来解释我们的方法。你完全了解本地网络,并且要连接到其他网络上的主机,你可以使用 BGP 发布的路由。这些路由提供有关使用哪个本地网关来转发流量以到达远程地址的信息。在我们的设置中,Istio 控制平面的每个实例都完全了解其自己的本地集群。全局控制平面的功能类似于 BGP,发布“第 7 层路由”,指示 Istio 使用哪些远程网关(网格中的其他 Istio 集群)来转发流量以到达远程服务。

架构概述

Tetrate Service Bridge 的架构由四层组成:数据平面、本地控制平面、全局控制平面和管理平面。

具有本地控制平面、全局控制平面和管理平面的 Tetrate Service Brdige 架构
具有本地控制平面、全局控制平面和管理平面的 Tetrate Service Brdige 架构

  • 数据平面:数据平面负责入站和出站流量,确保使用 Envoy 代理强制执行流量和安全策略。
  • 本地控制平面:本地控制平面部署在集群内并管理服务网格功能,例如提供服务身份、加密和流量路由。
  • 全局控制平面:全局控制平面链接本地控制平面,方便跨集群的配置传播、服务发现和灾难恢复。
  • 管理平面:管理平面是可以管理工作区、组和服务的用户的主要访问点。这提供了对环境的有效管理和控制。

数据平面

Istio 使用 Envoy 代理的扩展版本作为数据平面。Envoy 是一种高性能边缘/中间/服务代理,旨在调解服务网格中所有服务的所有入站和出站流量。当作为 sidecar 部署到应用程序时,Envoy 代理可以通过流量管理、安全性和可观测性功能来增强这些应用程序。

将 Envoy 部署为 sidecar 会自动配置所有入站和出站流量通过 Envoy。这允许在不需要重新架构或重写应用程序的情况下增加服务。

现代 API 网关、Web 应用程序防火墙和其他“边缘”功能

利用 Envoy 作为一致的数据平面,我们可以提供传统上仅限于应用程序流量平台中任何位置的边缘或 DMZ 的功能。TSB 将 Envoy 的一系列功能组合到一个易于使用的包中,支持 API 网关功能,例如令牌验证、速率限制和基于 OpenAPI 规范的配置。它还为 sidecar、入口网关和边缘负载均衡器带来了 WAF 功能。最重要的是,TSB 允许你编写单个策略并将其应用于任何地方的流量:外部客户端和你的服务之间、网络中的集群或数据中心之间、甚至同一集群上运行的服务之间。

扩展

TSB 在数据平面的扩展点是 WebAssembly。Envoy 有多个扩展点,但正常的 Envoy 扩展需要重建和链接 Envoy 二进制文件。WebAssembly 是一种沙盒技术,从 Istio 1.6 开始可用于动态扩展 Envoy。

Istio 文档提供了 WebAssembly 扩展的概述。在 TSB 中,通过 WASM 扩展和 Istio 的 WasmPlugin 资源提供了对 WebAssembly 扩展的更好支持。这有助于开发人员构建和测试 Envoy 扩展,并与 TSB 集成以促进扩展部署。

本地控制平面

TSB 使用 Istio 作为每个集群内的本地控制平面,通过多个 Istio 实例提供隔离的故障域,并从 TSB 管理平面进行简单、标准化的管理。

作为用户,你可以从管理平面访问和控制它们,这意味着你不会与本地控制平面进行直接交互。此外,你只需推送一个配置即可更新所有配置。

本地控制平面负责:

  • 智能本地负载均衡
  • 在集群内实施零信任
  • 在本地级别实施身份验证和授权

控制平面是 TSB 推送配置、挖掘数据并根据集群活动做出智能决策的本地接入点。

全局控制平面

全局控制平面 (XCP) 是管理平面的一部分,作为用户,你无法直接访问全局控制平面的 API。全局控制平面负责:

  • 集群间的服务发现
  • 从本地控制平面和数据平面收集的遥测数据
  • 网关中断或集群故障时的灾难恢复和故障转移
  • 用户以及应用程序之间的身份验证和授权
  • 出口控制以确定什么可以离开网络。

在 us-east 中创建的 bar.com 服务会传播到 TSB,然后通过 XCP 传播到集群。
在 us-east 中创建的 bar.com 服务会传播到 TSB,然后通过 XCP 传播到集群。

全局控制平面使集群能够相互通信并通告可用服务。

全局控制平面由两个应用程序组成:XCP Central 和 XCP Edge。XCP Central 部署在 TSB 管理平面中,负责将配置传播到 XCP Edge 应用程序。XCP Edge 应用程序部署在每个运行用户应用程序的载入集群中,以便将 TSB 配置本地转换为 Istio API。

多集群方法比较

与使用 Istio 跨多个集群构建网格的其他方法(例如将每个集群的每个服务的 Pod 或 VM IP 地址更改发布到所有其他 Istio 实例)相比,TSB 的方法需要的数据更改率非常低传播,数据本身非常小,并且不需要跨集群进行 n 方通信,这意味着保持最新和准确要容易得多,并且整体系统更简单。越简单总是更容易运行并且更可靠。TSB 促进跨孤岛通信的方法可实现非常稳健且可靠的运行时部署。

Tetrate Service Bridge 管理平面

TSB 管理平面是网格管理环境中所有内容的主要访问点。

管理平面将你的基础架构划分为称为工作区、组和服务的逻辑分组,从而简化管理环境的过程,从而轻松管理你的环境。

影响网格管理环境的所有更改均由管理平面处理,包括流量管理、服务发现、服务间通信和入口/出口控制等运行时操作,以及管理用户访问等管理操作(IAM)、安全控制和审计。

了解管理平面

在上一篇服务网格架构中,我们介绍了数据平面和控制平面的概念。上面,我们介绍了故障域的概念以及为什么我们要部署本地控制平面的许多实例。拥有许多本地控制平面自然意味着我们需要一些东西来帮助它们作为一个整体运行,因此全局控制平面会出现问题。但为什么要在管理平面之上添加另一层呢?

与控制平面不同,控制平面的主要工作是可用、低延迟并尽快服务数据平面配置(它以机器的速度变化),管理平面的主要工作是促进用户与系统的交互,他们之间的工作流程。

管理平面是将运行时系统连接到组织中的用户和团队的层。它允许你在具有许多用户和团队、具有许多不同策略和兴趣的复杂组织中安全地管理同一物理基础设施上的分布式系统。它使用 Envoy、Istio 和 SkyWalking 创建一个工具,可在企业中自信地实施监管要求的控制,在同一基础设施上维护许多不相关的团队,而不会造成共同的命运中断,并让团队按照他们想要的速度快速行动它将是安全可靠的。

我们将在概念部分的其余部分讨论你可以使用 Tetrate Service Bridge 管理平面做什么,从授权应用程序开发人员管理流量到应用全局策略和使用 TSB 的 IAM 系统管理用户访问,再到了解你的整个基础设施单块玻璃。但乍一看,它可以让你:

  • 无论应用程序或其依赖项部署在何处,都可以在一处控制流量
  • 使用高级权限系统管理谁可以更改什么(防止应用程序开发人员更改安全设置;防止安全团队导致应用程序中断)
  • 审核系统中的每一个变更
  • 了解和控制系统中的流量:内部流量、入口和出口
  • 管理整个基础设施的控制平面生命周期

详细的数据流

Tetrate Service Bridge 组件和数据流的详细、幕后视图可以帮助你了解构成运行时系统的各个部分以及数据在它们之间的流动方式。

TSB 组件之间的数据流的详细图表。
TSB 组件之间的数据流的详细图表。

有关每个组件的详细说明,请参阅 TSB 组件。有关每个组件使用的端口的完整列表,请转到组件端口