面向分布式应用的全球服务网格

F5生态系统 | 2019年11月25日

本文是本系列博客的第2篇。本系列将介绍我们构建和运营SaaS服务所涉及的各个方面：

分布式Kubernetes PaaS的控制平面
面向分布式应用的全局服务网格
面向分布式基础设施、应用和数据的平台安全
分布式集群的应用和网络安全
覆盖全球分布式平台的可观测性
全球分布式平台的运维与SRE
面向分布式微服务的Golang服务框架

在之前的一篇博客文章中，我们介绍了促使我们构建新平台的需求背景。借助该平台，客户可以构建各种复杂的应用，例如智能制造、用于公共安全的视频取证、算法交易和电信5G网络。

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

本篇博客将从三个角度探讨如何应对连接和保护这些分布式应用集群所面临的挑战：应用到应用、用户或机器到应用，以及应用到公共互联网。我们将介绍全新且全面集成的L3-L7+数据路径、全球分布式控制平面，以及我们的高性能全球网络。这三者相结合，可在边缘、任意云VPC内或我们的全球网络PoP中提供一套全面的网络和安全服务。该方案已在35家以上客户的生产环境中运行超过1年。随着部署开始扩展，我们认为现在正是分享这段历程的好时机。

太长不看（摘要）

要为分布式应用集群提供高性能、可靠且安全的连接，我们需要构建一个全新的全球网络。虽然有许多服务提供商可为消费者与应用之间的连接（如Akamai、Cloudflare等）以及员工与应用之间的连接（如Zscaler、Netskope等）提供安全保障，但尚无服务提供商能够满足应用间连接和安全需求。
除了用于连接分布式应用的全球网络外，这些应用集群还需要采用一致配置和运维模式的网络、可靠性及安全服务，包括API路由、负载均衡、安全和网络路由。这些服务需要在多个云服务提供商的位置、资源受限的边缘位置和/或我们的全球网络中运行。
为提供这些网络和安全服务，我们决定构建一条全新且完全集成的L3-L7+网络数据路径。无论该数据路径运行在我们的网络、多个公有云还是边缘位置，都能提供一致的配置、策略和可观测性。由于其中许多数据路径可跨多个站点部署，我们还需要构建一个全球分布式控制平面来编排这些数据路径。
全球网络、新型网络数据路径与分布式控制平面的结合，为我们构建了一个“全球分布式应用网关”。该网关无需开放整个全球网络的网络访问权限，即可提供零信任安全、应用连接和集群可靠性。这一“全球服务网格”简化了安全与合规团队的工作。

线缆在哪里？我们为何构建全球网络？

客户正在构建相当复杂且任务关键型的应用，例如智能制造、用于公共安全的视频取证、算法交易和电信运营商5G转型。因此，我们需要为这些应用及其最终用户提供始终在线、互联且可靠的体验。其中一些应用需要在云内的多个集群之间运行数据管道，或跨云提供商备份数据，或将全球用户的请求可靠地传送至应用后端，或在其机器与集中式云中运行的后端之间建立高性能连接。

为满足这些需求，物理网络需要满足两项要求：

R1：云到云连接：为全球各地公有云或私有云中的应用提供高性能按需连接

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

我们本可以选择AT&T等网络服务提供商来满足R1和R2要求，但这些提供商无法为我们提供无缝的网络体验，也无法与我们的应用服务顺畅集成，包括基于API的配置、流式遥测、轻松添加我们或客户的IP前缀，以及基于API的网络服务等。此外，通过服务提供商实现全球覆盖非常困难，成本也可能高得难以承受。我们也可以选择两到三家不同的服务提供商来解决所有这些问题，但最终会面对一套混乱的异构系统：它们的行为方式、故障模式、SLA和支持系统各不相同，所提供的API也不一致，甚至根本没有API。

因此，我们最终需要构建自己的网络，而该网络需要具备以下三个特性：

要满足R1，我们需要构建一个横跨多个云提供商、覆盖全球的专用网络，以连接所有区域。适合的做法是在主要云区域与云提供商建立对等互连，同时结合使用主要托管设施中的直接连接链路。对等互连无法保证理想的服务级别协议（SLA），而直接连接链路可在云区域内提供SLA保障。
要为边缘位置的机器解决R2，就需要支持从每个边缘位置建立多条双活链路。这些链路可以是低成本的互联网链路（通过蜂窝网络或有线网络/光纤），也可以是成本较高的专用链路（通过光纤/以太网），或两者兼有。为实现所需的性能和可靠性，需要尽可能靠近边缘位置对流量进行负载均衡和终止，而不是通过不可靠的互联网进行长距离回传。按照行业术语，此功能也称为SD-WAN。
要为互联网用户和边缘应用解决R2问题，就需要在边缘终止TLS流量，并且终止位置应尽可能靠近用户。因此，我们需要构建与移动运营商和内容提供商密集对等互联的网络边缘站点，同时通过多家传输服务提供商引入流量，以优化路由。

为了满足这三个特性，我们需要开展多项工作。下面重点介绍其中五大类：

采用自有网络设备的全球网络PoP为了满足需求，我们最终需要在主要大都市市场建设多个网络PoP。平台建设初期，我们先在欧洲的巴黎、伦敦、阿姆斯特丹和卢森堡等多个城市部署，并在美国纽约市部署了一个PoP；随后扩展到西雅图、圣何塞、阿什本、法兰克福、新加坡和东京，从而实现全球覆盖，并靠近所有主要云服务提供商。我们选择Equinix作为全球合作伙伴；在Equinix并非更合适选择的地点，则以Interxion、Telehouse/KDDI和Westin作为补充。基于对自动化的重视，我们最终选择Juniper Networks提供交换和路由设备，并选择Adva为400G和100G链路提供城域光纤互联。
专用骨干网：为了以高性能、高可靠性连接所有这些PoP，我们决定不在多家传输服务提供商的网络之上构建覆盖网络，而是采用Zayo、Centurylink、EuNetworks等提供商的多条100G波长链路，构建全球专用骨干网。许多CDN提供商（例如Cloudflare、Fastly）和安全服务提供商（例如Zscaler）主要处理下行流量，因此完全依赖传输和对等互联；而我们处理的是应用间的东西向流量，因此认为将专用骨干网与传输服务结合使用有充分理由。这种做法并非我们独有，主要云服务提供商也都通过全球专用骨干网连接各自的云节点。
互联网对等互联和传输服务提供商：为提高连接多样性，并优化用户及内容或SaaS提供商的访问性能，理想的解决方案是与尽可能多的运营商和内容提供商直接建立对等互联。我们按照PeeringDB中的信息，在多个互联网交换中心建立了对等互联（PeeringDB中的ASN-35280）。并非所有流量都能通过对等互联连接传输，此时就需要使用传输连接。为保持服务质量，需要密切监控传输链路和对等互联端口。我们最终选择了NTT、CenturyLink和Telia等优质Tier-1提供商，为全球多个地点提供服务。
云对等互联和互连我们最近开始与云提供商直接建立对等互联，但云提供商不为这些连接提供任何服务级别协议（SLA）保证。例如，通过位于西雅图（Westin设施）的对等互联连接，我们可以直接连接三大云提供商。尽管这些连接优于仅通过传输提供商连接，但我们仍开始通过直连服务（即AWS Direct Connect、Azure Express Route和GCP Dedicated Interconnect）连接这些云提供商，以增强网络，因为这些服务提供SLA和其他功能。虽然这些链路成本高昂，并且只能访问内部VPC/VNET子网，但可以提供更优的连接质量。
软件网关：对于未与我们的PoP直接连接的云端或边缘位置，我们会部署软件网关。本文稍后将介绍这些网关提供的高级功能。其中一项与传输层相关的功能是，网关会自动与多个网络PoP建立安全的VPN（IPsec或SSL）隧道，以实现冗余，并在各PoP之间对流量进行负载均衡。此外，在云部署中，这些网关会通过云提供商的NAT网关与距离最近的PoP建立出站连接，并接入我们的全球专用网络，无需经过公共网络，也无需使用公共IP地址连接不同云位置的应用集群。

在开发初期，我们就意识到，构建和运营全球网络需要投入时间并具备专业技能，因此需要引入这方面的专业能力。经过数月与Acorus Networks（一家总部位于法国巴黎的安全服务提供商）创始人的讨论，我们最终将Acorus与Volterra合并。这帮助我们解决了全球基础设施建设和网络部署方面的问题。Acorus已从零开始搭建了一套出色的网络，并组建了一支运营团队。该团队使用Ansible实现了物理网络配置的全面自动化，还构建了供我们软件团队使用的遥测和配置外部API。

图1：通过我们的全球网络传输的应用间流量或用户/机器到应用的流量

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

面向应用的网络服务：多云、私有环境还是边缘环境？

全球网络正常运行后，我们需要开始添加应用集群和工作负载。这些工作负载需要一套专属的应用级连接和安全服务。

正如我们在之前的博客文章中所述，我们构建该平台的目标是提高团队的工作效率并降低复杂性，帮助他们管理跨多个环境（云、边缘和我们的网络PoP）运行的工作负载。

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

广域网（WAN）服务

应用网络服务

网络路由与隔离服务

当然，尽管这将是一项艰巨的挑战，我们原本可以选择构建一个配置和运维层，以协调各云提供商之间的差异。然而，我们知道这并不能解决问题，因为云提供商的服务无法满足我们的所有需求（例如，CSP缺少应用和API安全防护能力），这些服务并非同类产品中的优选方案，而且还在不断变化。

此外，我们的网络PoP和边缘站点又该如何处理？我们必须从硬件或软件供应商处获取类似功能，并将其全部集成起来，例如使用Cisco/Juniper提供路由、NAT和VPN功能，使用F5提供负载均衡和防火墙功能等。在边缘位置，问题更加复杂，因为无论是云提供商还是大型网络供应商，都无法解决资源受限环境中的网络服务问题。边缘环境的另一个潜在方案，是将所有应用连接、安全和网络服务迁移到我们的全球网络。但显然，这种方案行不通，因为同一边缘站点内的应用间流量也需要其中一些服务。

经过大量讨论和市场调研，我们意识到，要在众多服务提供商和供应商之间集成配置、遥测、监控和告警等功能，并持续跟进其路线图和API变更，这与我们追求简单高效的目标背道而驰。

我们需要在整个平台上解决的另一个问题是多租户。WAN服务和网络路由较容易实现多租户，但应用网络服务则面临挑战，因为市面上大多数负载均衡器不支持或仅提供非常有限的多租户支持。

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

因此，我们决定迎接这一挑战，构建一条高性能网络数据路径，不仅提供网络路由服务，还提供应用、安全和广域网服务。这样，我们就能在混合云和分布式云环境中统一服务组合，并最大限度减少对公有云原生服务的依赖。

鉴于团队拥有丰富的网络经验，并且我们此前在Contrail/Juniper也处理过此类问题，因此我们认为，解决这一问题的合适途径是从零开始，构建全新的网络解决方案，将L3至L7+服务集成到单一数据路径中。该数据路径可在任何云或边缘环境中运行，并由我们的平台集中管理。

我们选择了合适的项目作为新数据路径的设计起点：一是已投入6年开发的OpenContrail vRouter（用于L3-L4），二是拥有广泛社区支持、用于L7的Envoy。不过，为构建全新的统一L3-L7+数据路径，我们必须进行多项改造并增加多种功能，包括Envoy多租户支持、Envoy dpdk支持、用户空间dpdk TCP栈、网络策略、SSL/IPSec VPN、http connect、动态反向代理、透明正向代理、API网关、可编程应用策略、用于DDoS防护的高速ACL、PKI身份集成、Chrome v8引擎、应用和网络安全等。

图 2：网络数据路径

此数据路径（如图 2所示）可部署为应用集群的入口/出口网关、边缘软件网关，用于在单个集群内或多个集群之间提供服务网格功能，或通过全球PoP提供网络服务。

为满足平台的多租户需求（上一篇博客中已介绍），我们还需要让此网络数据路径全面支持多租户。由于vRouter已支持VRF，因此路由层的改造相对简单。不过，我们必须修改Envoy，使其支持多租户。由于未使用内核TCP协议栈，我们修改了Envoy的TCP套接字接口，并使其能够感知VRF。

该数据路径还需要提供API安全、应用防火墙和网络安全功能。为此，我们结合使用了算法技术和机器推理，并将在后续博文中介绍这一主题。

构建这条网络数据路径带来了诸多优势：

完整的L3-L7+能力，以及统一的配置、控制和可观测性

支持在单个集群内横向扩展，使我们能够覆盖从占用空间极小、性能较低的边缘设备，到部署在自有网络或公有云位置、容量达100 Gbps以上的设备。

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

适用于各种环境的通用解决方案，具有相似的故障和性能特征，这对我们的运维团队非常重要。

借助这一新的网络数据路径，我们可以部署多个应用集群，因此构建一个全球分布式控制平面来配置、控制和监控这些集群至关重要。

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

在构建分布式控制平面以管理大量分布式数据路径处理节点时，我们的平台团队需要解决多个问题。由于我们构建了新的数据路径，没有可直接使用的现成控制平面，因此必须自行开发：本地控制平面，用于管理单个集群（云、边缘或网络PoP）内运行的多个数据路径。这些数据路径节点需要本地控制平面来管理配置变更和路由更新、执行运行状况检查和服务发现、通过BGP等协议与其他网络设备建立对等连接，以及汇总指标和访问日志等。分布式控制平面用于管理多个本地控制平面。我们的全球网络PoP中运行着一个分布式控制平面（图3），负责管理本地控制平面的配置、在各本地控制平面之间分发运行状态，以及从各节点收集数据。为分发运行状态，我们决定使用BGP，因为它具有最终一致性且稳健可靠。我们曾在OpenContrail中构建了可支持超大规模的多线程BGP实现，因此在此基础上增加了负载均衡扩展，包括运行状况检查分发、http/api端点和策略传播等。

图 3：分布式控制平面和本地控制平面

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

图4：网络中的多租户

控制平面以Kubernetes工作负载的形式运行在独立租户和隔离的命名空间中，仅由我们的SRE团队管理。因此，开发人员和客户均无法中断此服务。此外，由于控制平面采用分布式架构，某一位置的控制平面发生中断不会影响整体服务。

全球分布式应用网关？

在明确全球网络的需求，并定义应用集群所需的L3-L7+网络服务要求（包括新的数据路径和分布式控制平面）后，产品团队又提出了更多要求，让我们的工作更具挑战性。简而言之，他们希望我们交付一个具备以下功能的全球跨集群服务网格：

在全球网络中提供应用连接（路由、控制和可观测性），而不是网络连接（至少默认情况下不提供）。原因很简单：连接网络会产生各种安全漏洞，而解决这些漏洞需要创建复杂的防火墙规则，这会增加变更管理的难度。
利用端点健康状况和可靠性改进网络PoP中的边缘负载均衡器。目前，边缘负载均衡器（例如AWS Global Accelerator或Akamai全局负载均衡器）从边缘位置到后端的路由决策基于源站服务器的健康状况（大多数情况下，源站服务器是另一个负载均衡器，而非实际提供服务的端点）。我们的团队希望每个边缘负载均衡器都能根据所有集群中全部端点的健康状况管理流量，而不只是依据源站负载均衡器的健康状况。
改进GSLB决策中的边缘站点（网络PoP）选择：目前，任播或GSLB会将用户或客户端路由到距离最近的边缘站点进行流量接入。但出于多种原因（例如骨干网和/或中转服务提供商的负载），将用户转发到其他接入边缘站点可能更合适。

针对要求#2和#3，我们的目标是缩短客户端到服务器连接的响应时间并提升其性能，这对于应用间通信或大规模SaaS应用至关重要。为满足要求#2和#3，合适的方案是构建分布式代理（图5），包括入口代理和出口代理，并基于应用寻址而非网络寻址进行路由。此外，我们决定利用分布式控制平面和BGP扩展（如前文所述），分发服务端点（或服务器）的运行状况信息。下图展示了该分布式代理的实现方式。

图5：分布式应用网关

由于它已成为具备完整L3-L7+网络堆栈的分布式代理，我们将其称为全球分布式应用网关。网络数据路径中的所有功能现已覆盖整个全球网络，例如基于HTTP或API的负载均衡和路由、边缘策略执行、API转换，以及在更靠近用户的位置终止TLS连接等。

Distributed Application Gateway带来的收益

通过实施全球分布式应用网关，团队在运营改进、安全性、性能和总拥有成本（TCO）等方面取得了多项收益：

安全与合规：无需开放站点间的网络访问即可提供跨站点应用访问，这项能力显著提升了边缘或云端位置中各应用集群的安全性与合规性。由于站点之间无需开放网络访问，且应用集群可相互连接，同时完全位于各站点的NAT之后，因此也减少了复杂防火墙配置管理的需求。
运维开销：我们的网络PoP和边缘及云站点采用一套通用网络服务，因此SRE或DevOps无需再对不同服务集的配置和可观测性进行集成。
性能和可靠性提升：由于我们从网络PoP将流量路由到状态良好的适宜端点，而不是适宜的负载均衡器，因此该平台可为应用间流量或用户到应用的流量提供优于市场上其他解决方案的性能。
TCO效益。对于大型SaaS应用，通常需要通过全球多个数据中心提供数百个服务副本。为有效实现这一点，SaaS提供商必须构建复杂的功能。如今，借助此分布式应用网关，所有客户均可使用这些功能。