分布式applications的全局服务网格

本博客是系列博客中的第二篇，涵盖了我们构建和运营SaaS服务的各个方面：

1. 分布式 Kubernetes PaaS 的控制平面
2. 分布式应用的全局服务网格
3. 分布式基础设施、应用程序和数据的平台安全
4. 分布式集群application及网络安全
5. 跨全球分布式平台的可观察性
6. 全球分布式平台的运营和 SRE
7. 面向分布式微服务的Golang服务框架

在之前的博客中，我们提供了一些促使我们构建新平台的需求背景。 利用这个平台，我们帮助客户构建一套复杂而多样的应用——比如智能制造、公共安全视频取证、算法交易、电信 5G 网络。

本系列的第一篇博客介绍了一个分布式控制平面，用于在公共云、我们的私有网络 PoP 和边缘站点中交付多个基于 Kubernetes 的多租户应用集群。

本博客将从三个角度探讨连接和保护这些分布式应用集群的挑战——应用到应用、用户/机器到应用以及应用到公共互联网。 我们将推出全新的、完全集成的 L3-L7+ 数据路径、全球分布式控制平面和我们的高性能全球网络。 这三者结合在一起，在边缘、任何云 VPC 或我们的全球网络PoP 中提供了一套全面的网络和安全服务。 与 35 多个客户一起运行生产超过 1 年之后，我们已经开始扩大部署规模，并觉得现在是分享我们历程的好时机。

TL;DR（摘要）

• 为分布式应用集群提供高性能、可靠和安全的连接需要我们构建一个新的全球网络。 虽然有许多服务提供商负责连接和保护消费者与应用（Akamai、Cloudflare 等）以及员工与应用（例如 Zscaler、Netskope 等），但没有一个服务提供商能够满足应用到应用的连接和安全性需求。
   
• 除了连接分布式应用的全球网络之外，这些应用集群还需要具有一致配置和操作模型的网络、可靠性和安全服务（API 路由、负载均衡、安全性和网络路由）。 这些服务需要在多个云提供商位置、资源受限的边缘位置和/或我们的全球网络中运行。
   
• 为了提供这些网络和安全服务，我们决定构建一个新的、完全集成的 L3-L7+ 网络数据路径，无论它在我们的网络中、在许多公共云中还是边缘位置运行，都具有一致的配置、策略和可观察性。 由于许多这些数据路径可以部署在多个站点，因此还要求我们构建一个全局分布的控制平面来协调这些数据路径。
   
• 全球网络、新网络数据路径和分布式控制平面的结合为我们提供了“全球分布式应用网关”，可提供零信任安全性、应用连接性和集群可靠性，而无需通过该全球网络提供网络访问——“全球服务网格”为我们的安全和合规团队提供了简化。

电缆在哪儿？ 我们为什么要建立全球网络？

由于我们的客户正在构建相当复杂和关键任务的应用——例如智能制造、公共安全的视频取证、算法交易、电信 5G 转型——我们需要为这些应用应用最终用户提供始终在线、连接且可靠的体验。 其中一些应用在云中的跨集群运行数据管道，或者需要跨云提供商备份数据，或者需要将来自全球用户群的请求可靠地传递到应用程序后端，或者需要从其机器到在集中式云中运行的后端的高性能连接。

为了满足这些需求，对物理网络有两个要求：

R1 — 云到云— 跨全球公共或私有云位置实现应用的高性能和按需连接

R2 — 互联网到云端— 为了让边缘位置的设备和机器可靠地连接到应用后端，我们需要提供多条冗余路径，并终止尽可能靠近这些用户的连接，而不是使用互联网将流量一直回传到后端。

我们可以通过联系 AT&T 这样的网络服务提供商来解决需求 R1 和 R2，但他们无法为我们提供无缝的网络体验和与我们的应用服务的集成——基于 API 的配置、流式遥测、轻松添加我们自己或我们客户的 IP 前缀的能力、基于 API 的网络服务等。 此外，从服务提供商处获得全球覆盖非常困难或成本过高。 我们本可以与两到三个不同的服务提供商一起解决所有这些问题，但最终我们会得到一堆混乱的系统，这些系统行为各异，故障模式不同，SLA 不同，支持系统不同，API 也不同（甚至没有）。

因此我们最终需要建立自己的网络，这意味着网络需要具备三个属性：

1. 解决 R1 意味着我们需要构建一个跨多个云提供商和全球的私有网络来连接所有地区——而实现此目的的最佳方法是与主要云区域的云提供商对等，并在主要主机托管设施中使用多种直接连接链路。 对等连接不能保证最佳的 SLA，而直接连接链接确实在云区域内提供了 SLA 保证。
    
2. 解决边缘位置机器的 R2 意味着我们需要从每个边缘位置支持多个主动-主动链接，其中链接可以是低成本的互联网链接（通过蜂窝或电缆/光纤）和/或高成本的专用链接（通过光纤/以太网）。 为了获得性能和可靠性，流量需要进行负载平衡并尽可能靠近边缘位置终止，而不是通过不可靠的互联网进行传输。 在行业术语中，此功能也称为 SD-WAN。
    
3. 为互联网用户和边缘应用解决 R2 问题意味着我们需要执行 TLS 流量的边缘终止，并且这也需要尽可能靠近用户进行。 这意味着我们需要与移动运营商、内容提供商构建密集对等的网络边缘位置，并使用多个中转提供商承载流量以确保最优路由。

为了满足这三个特性，我们需要做很多事情。 然而，我们将重点介绍五大项目：

1. 使用我们的网络设备建立全球网络PoP — 我们最终不得不在主要大都市市场建立多个网络 PoP — 在平台构建的早期，我们从欧洲的多个城市开始，包括巴黎、伦敦、阿姆斯特丹、卢森堡，以及美国的纽约一个 PoP，然后扩展到西雅图、圣何塞、阿什本、法兰克福、新加坡和东京 — 因为这给了我们全球覆盖，而且我们与所有主要的云提供商都很接近。 我们选择 Equinix 作为我们的全球合作伙伴，并在 Equinix 不是最佳选择的地区与 Interxion、Telehouse/KDDI 和 Westin 进行了合作。 因为我们相信自动化，所以我们最终选择了瞻博网络用于交换/路由设备，并选择了 Adva 用于 400G 和 100G 链路的城域光纤互连。
2. 私有主干网— 为了以高性能和高可靠性连接所有这些 PoP，我们决定不在多个传输提供商之上构建覆盖网络，而是选择使用来自 Zayo、Centurylink、EuNetworks 等提供商的多个 100G 波的组合来构建全球私有主干网。 虽然许多 CDN（例如 Cloudflare、Fastly）和安全提供商（例如 Zscaler）在服务下行流量时完全依赖 Transit 和 Peering 连接，但我们认为，在处理东西向应用到应用流量时，有充分的理由使用私有主干网和中转网的组合。 这并不是我们独有的——所有主要的云提供商都拥有连接其云位置的全球私有主干网。
3. 互联网对等和中转提供商——为了增加多样性并实现最佳性能以接触用户和内容或 SaaS 提供商，理想的解决方案是直接与尽可能多的运营商和内容提供商对等。 我们对等多个交易所，如 PeeringDB（ PeeringDB 中的 ASN-35280 ）中所述。 并非所有流量都可以通过对等连接来提供服务，这时传输连接就可以发挥作用。 需要非常仔细地监控传输链路和对等端口以保持质量——我们最终选择了最好的一级供应商，例如 NTT、CenturyLink 和 Telia，在全球各个地点为我们提供服务。
4. 云对等和互连- 我们最近开始直接与云提供商进行对等，但他们不保证这些连接的任何 SLA - 例如，在我们位于西雅图（威斯汀设施）的对等连接中，我们能够直接联系所有三大云提供商。 尽管这些连接比仅仅通过中转提供商要好，但我们还是开始通过与这些云提供商的直接连接（称为 AWS Direct Connect、Azure Express Route 和 GCP Dedicated Interconnect）来增强我们的网络，因为这些连接带有 SLA 和附加功能。 虽然这些链接价格昂贵且仅允许访问内部 VPC/VNET 子网，但它们提供了最佳的连接。
5. 软件网关——在未直接连接到我们的 PoP 位置的云端或边缘位置，我们安装了软件网关。 我们将在本博客的后面部分介绍这些网关提供的高级功能，但与传输层相关的功能之一是，这些网关会自动创建到多个网络 PoP 的安全 VPN（IPsec 或 SSL）隧道，以实现冗余并对 PoP 的流量进行负载平衡。 此外，在云部署中，这些网关会通过云提供商 NAT 网关创建到我们最近的 PoP 的出站连接，并创建到我们全球专用网络的入口 - 无需遍历公共网络和/或使用公共 IP 地址跨云位置连接应用集群。

我们在发展初期就意识到，建立和运营一个全球网络需要时间和技能，我们需要具备这些专业知识。 经过与 Acorus Networks（总部位于法国巴黎的安全提供商）创始人数月的讨论，我们最终将 Acorus 与 Volterra 合并。 这帮助我们解决了全球基础设施和网络部署的问题。 Acorus 已经建立了一个优秀的网络和一个运营团队，该团队使用 Ansible 完全自动化了物理网络配置，并构建了可供我们的软件团队使用的遥测和配置外部 API。

现在我们已经有一个团队专注于构建高可靠性和性能的全球专用网络，我们可以轻松解决跨边缘或云位置的应用到应用以及用户/机器到应用的流量问题，如图 1 所示。 此外，我们网络 PoP 中的计算和存储基础设施还允许我们向我们的网络添加 API 终止、应用程序安全和工作负载卸载（从边缘或云端）。 这将使我们能够在未来很长一段时间内继续发展我们的能力，并根据需求轻松扩展我们的网络覆盖范围和服务目录。

applications的网络服务——多云、私有、边缘？

一旦我们拥有了正常运转的全球网络，我们就需要开始添加应用集群和工作负载。 这些工作负载需要自己的一套应用程序级连接和安全服务。

正如我们在之前的博客中所解释的那样，我们使用该平台的目标是提高生产力并降低管理跨多个环境（云、边缘和我们的网络 PoP）运行的工作负载的团队的复杂性。

每个云提供商都需要配置、管理和监控许多不同的云资源，以实现与应用集群的安全连接。 例如，在 Google Cloud 中，要为应用集群配置端到端网络服务，就需要我们管理许多不同的服务集：

广域网 (WAN) 服务

• 虚拟专用网络 (VPN)和/或互连
• DNS 服务器
• DDoS 和 WAFS

application网络服务

• application负载均衡器、网络负载均衡器（公共 API）
• application负载均衡器、网络负载均衡器（内部）
• 服务网格（应用到应用）

网络路由和隔离服务

• 虚拟私有云网络（VPC网络）
• 子网、 IP 范围、路由
• NAT 网关、防火墙规则

太好了，虽然这是一个巨大的挑战，但我们本可以决定通过构建配置和操作层来协调每个云提供商来解决这个问题。 然而，我们知道这并不能解决我们的问题，因为云提供商的服务不能满足我们所有的需求（例如，CSP 缺乏执行应用和 API 安全性的能力），它们不是最好的，并且在不断变化。

此外，我们的网络 PoP 和边缘站点怎么样？ 我们必须从硬件或软件供应商那里获得类似的功能，并将它们集成在一起 — — 例如 Cisco/Juniper 用于路由+nat+vpn，F5 用于负载均衡和防火墙，等等。 在边缘位置，问题更加复杂，因为云提供商和大型网络供应商都无法解决资源受限环境的网络服务问题。 边缘的另一个潜在选择可能是将所有应用连接、安全性和网络服务转移到我们的全球网络- 但很明显这行不通，因为同一边缘站点内的应用程序到应用程序流量也需要其中一些服务。

经过大量讨论和调查情况后，我们意识到跨许多服务提供商和供应商进行集成（配置、遥测、监控、警报）并跟上他们的路线图和 API 变化与我们追求简单和速度的目标背道而驰。

我们需要在整个平台上解决的另一个问题是多租户——这对于 WAN 服务和网络路由来说比较容易，但对于应用网络服务来说却很有挑战性，因为市场上大多数负载均衡器对多租户的支持都没有或者非常有限。

新的 L3-L7+ 网络数据路径

因此，我们决定接受这一挑战，构建一条高性能网络数据路径，不仅提供网络路由服务，还提供应用、安全和广域服务。 这将使我们能够在混合和分布式云环境中统一服务组合，并要求我们依赖公共云中最少的一组本机服务。

鉴于团队具有良好的网络经验，并且我们之前在使用 Contrail / Juniper 时已经处理过此类问题，我们认为解决此问题的最佳方法是从头开始，构建一个全新的网络解决方案，将 L3 到 L7 + 服务集成到单个数据路径中，该数据路径可以在任何云或边缘中运行，同时由我们的平台集中管理。

我们选择了最好的项目来开始设计这个新的数据路径 - OpenContrail vRouter（用于 L3-L4），我们已经花了 6 年的时间来开发它，而 Envoy 用于 L7，因为它拥有庞大的社区支持。 也就是说，我们必须进行一些更改和添加才能构建一个新的统一的 L3-L7+ 数据路径 - Envoy 的多租户、Envoy 的 dpdk、用户空间 dpdk TCP 堆栈、网络策略、SSL/IPSec VPN、http 连接、动态反向代理、透明正向代理、API 网关、可编程应用策略、用于 DDoS 保护的快速 ACL、PKI 身份集成、Chrome v8 引擎、应用和网络安全等。

该数据路径（如图 2所示）部署为我们的应用集群的入口/出口网关、边缘的软件网关，在集群内或跨多个集群提供服务网格功能，或从我们的全球 PoP 提供网络服务。

为了满足我们对平台多租户的需求（在之前的博客中介绍过），我们还需要为该网络数据路径提供完整的多租户。 对于路由层来说，这相对简单，因为 vRouter 已经支持VRF ，但是，我们必须在 Envoy 中进行更改以使其成为多租户。 由于我们没有使用内核 TCP 堆栈，我们更改了 Envoy 的 TCP 套接字接口并添加了 VRF 感知。

该数据路径还需要执行 API 安全、应用防火墙和网络安全——我们为此使用了算法技术和机器推理的组合，并将在即将发布的博客文章中介绍这个主题。

通过构建这个网络数据路径，我们获得了很多好处：

完整的 L3-L7+ 功能，具有统一的配置、控制和可观察性

支持单个集群内的横向扩展，使我们能够在网络或公共云位置支持从占用空间非常小、性能较低的边缘设备到容量高达 100Gbps 或更高的设备

无需依赖任何网络供应商和/或云提供商即可快速向网络数据路径添加新功能

在任何环境中具有类似故障和性能特征的通用解决方案——对我们的运营团队来说非常重要。

现在我们可以使用这个新的网络数据路径部署多个应用程序集群，构建一个全局分布式控制平面来配置、控制和监控它们至关重要。

为分布式网络构建的控制平面

在构建分布式控制平面以管理大量分布式数据路径处理节点的过程中，我们的平台团队必须解决多个问题。 由于我们构建了新的数据路径，因此没有可以利用的现成的控制平面，因此我们必须自己编写： 本地控制平面用于管理单个集群（云、边缘或网络 PoP）内运行的多个数据路径。 这些数据路径节点需要一个本地控制平面来管理配置更改、路由更新、执行健康检查、执行服务发现、使用 BGP 等协议与其他网络设备对等、聚合指标和访问日志等。 分布式控制平面用于管理多个本地控制平面——我们的全球网络PoP 中运行一个分布式控制平面（图 3 ），该控制平面负责本地控制平面的配置管理、每个本地控制平面之间的运行状态分发以及从每个节点收集数据。 为了分发操作状态——我们决定使用 BGP，因为它最终是一致且强大的。 由于我们已经在 OpenContrail 中构建了非常高规模和多线程的 BGP 实现，我们利用它并添加了负载均衡的扩展 - 健康检查分发、http / api 端点、策略传播等。

此外，还有一个集中管理平面运行在两个云区域（AWS 和 Azure）中，与分布式控制平面一起使用来提供多租户功能，如图 4所示。 我们的 SRE 团队可以创建多个租户，并且每个租户都与我们全球网络中的其他租户完全隔离。 它们只能使用“公共网络”相互路由。 在租户内，跨命名空间的服务可以基于 http/api/network 路由和安全规则相互通信。

控制平面作为 Kubernetes 工作负载在单独的租户和隔离的命名空间中运行，仅受我们的 SRE 团队的控制。 因此，没有开发人员和/或客户可以中断此服务。 此外，由于控制平面是分布式的，因此一个位置的控制平面中断不会影响整体服务。

全球分布式application网关？

一旦我们弄清楚了全球网络的需求并定义了应用程序集群的 L3-L7 + 网络服务要求（新的数据路径和分布式控制平面），我们的产品团队就会提出更多要求，让我们的生活更加精彩。 基本上，他们希望我们提供具有以下功能的全局跨集群服务网格：

1. 在全球网络上提供应用连接（路由、控制和可观察性），但不提供网络连接（至少默认情况下不是）——原因很简单，连接网络会产生各种安全漏洞，只有通过创建复杂的防火墙规则才能解决，这使得执行变更管理变得更加困难。
    
2. 通过端点健康和可靠性改进网络 PoP 中的边缘负载均衡器 - 目前，边缘负载均衡器（例如 AWS 全局加速器或 Akamai 全局负载均衡器），从边缘位置到后端的路由决策基于原始服务器的健康状况（在大多数情况下，原始服务器是另一个负载均衡器而不是实际的服务端点）。 我们的团队希望每个边缘负载均衡器都能够根据所有集群中所有端点的健康状况来管理流量，而不仅仅是原始负载均衡器的健康状况。
    
3. 改进边缘站点（网络 PoP）选择作为 GSLB 决策的一部分 - 当前，任播或 GSLB 会将用户/客户端路由到最近的边缘站点进行入口。 然而，由于各种原因（主干网和/或中转提供商的负载），将用户发送到不同的入口边缘站点可能会更好。

对于要求 #2 和 #3，目标是提高客户端到服务器连接的响应时间和性能，这对于应用到应用通信或大型 SaaS应用来说确实至关重要。 为了满足要求2和3，显然最好的方法是构建一个分布式代理（图5） - 一个基于应用寻址而不是网络寻址的入口代理和出口代理和路由。 此外，我们决定利用分布式控制平面和 BGP 扩展（如前所述）来分发服务端点（或服务器）的健康状况。 分布式代理的实现如下图所示。

由于它成为了具有完整 L3-L7+ 网络堆栈的分布式代理，我们将其称为全局分布式应用网关。 我们网络数据路径中可用的所有功能现在都可以在我们的全球网络中使用——例如，基于 HTTP 或 API 的负载均衡和路由、边缘的策略实施、API 转换、更靠近用户的 TLS 终止等。

分布式application网关带来的好处

通过实施全球分布式应用网关，团队能够实现多项收益。 这些收益体现在运营改进、安全性、性能和 TCO 方面：

1. 安全性与合规性——无需网络访问即可跨站点提供应用访问，显著提高了边缘或云位置的应用集群之间的安全性与合规性。 这也减少了对复杂防火墙配置管理的需求，因为没有跨站点的网络访问，并且应用集群可以连接但完全位于每个站点的 NAT 之后。
    
2. 运营开销- 我们网络 PoP 和边缘/云站点之间的通用网络服务集消除了我们的 SRE 或 DevOps 在不同服务集之间进行配置和可观察性集成的需要。
    
3. 性能和可靠性改进——由于我们从网络 PoP 路由到最优、最健康的端点而不是最优的负载均衡器，该平台能够为应用到应用或用户到应用的流量提供比市场上任何其他解决方案更高的性能。
    
4. TCO 收益——对于大型 SaaS应用，通常会有来自全球多个数据中心的数百个服务副本。 为了有效地做到这一点，SaaS 提供商必须构建复杂的功能，这些功能现在可以通过此分布式应用网关供所有客户使用。

待续…

本系列博客将涵盖我们构建和运营全球分布式 SaaS 服务的各个方面，其中包括公共云、私有网络 PoP 和边缘站点中的许多应用集群。 接下来是平台和数据安全……