目标是为精通云计算但不精通网络的开发人员提供一种创建多云连接并使用熟悉的工具管理它们的方法。
译自How We Made Fast Cloud-to-Cloud Connections Possible，作者 Brandon Wright; David Marquis。
传统上，要实现不同云中托管的事物之间的通信，需要从托管云“入口”（到云网络的专用连接）的托管服务提供商处订购物理交叉连接（一根实际的电缆）来连接它们。
近年来，出现了各种软件定义的替代方案。有些本质上做的是同样的事情，但虚拟化了；而另一些，例如典型的SD-WAN，则依赖于IPsec或其他加密协议来保护穿越互联网的连接。
还有一些不太成熟的方法，包括一些云提供商自己的云间连接服务。而且，始终可以选择通过公共互联网发送您的云到云API请求，并寄希望于一切顺利。
传统方法往往成本高昂且设置复杂，需要专业的网络知识。一年多前，我们决定构建一个更易于使用的云到云专用连接服务。目标是为精通云但并非精通网络的开发人员提供一种创建多云连接并使用熟悉的工具（如Terraform或Pulumi）管理它们的方法，而无需在我们自己的数据中心托管任何基础设施。
这是一个有趣的挑战，尤其是在架构方面。我们将重点介绍我们在构建该服务时做出的一些关键架构决策，并解释其背后的原因。
抽象网络配置
该服务，Fabric Cloud Router(FCR)，以Equinix Fabric命名，我们的软件定义网络自动化了我们数据中心（云提供商、网络运营商、ISP、企业和其他机构）中托管的网络节点之间的专用连接。Fabric和FCR都运行在相同的运营商级硬件路由器上，这是一个深思熟虑的架构决策，我们将在介绍其他几个决策后再次讨论。
我们希望FCR用户体验以及我们自己随着时间的推移构建和改进该体验的过程都能快速灵活。我们通过将构成用户界面产品的微服务集合与底层网络配置管理分离来实现这两个目标，为微服务创建了一个抽象层来进行交互，而不是直接与网络基础设施交互。
这样，负责该产品的开发团队就无需了解（也无需了解）运营商级边界网关协议（BGP）堆栈中那些底层配置的具体细节。团队可以专注于产品，而无需担心其决策对网络级别功能的影响。
这也使我们能够将用户请求和配置连接的过程与配置这些连接的过程分离，从而使该过程更快、更灵活。关键在于，在从用户收集所有必要详细信息之前，不要在网络中应用任何配置。他们订购FCR，选择要连接到的端点，选择连接带宽和冗余，并设置其路由协议。在这些步骤之后，无需等待网络级别发生任何操作。不会发送和使用不必要的事件，从而避免了使用尚未需要的配置消息污染我们的网络。
这与传统上配置网络连接的缓慢过程大相径庭，在传统过程中，每个配置步骤都必须在网络中实现，然后才能执行下一个步骤。
事件驱动架构
虽然构成FCR产品层的基于Java的微服务通过REST API相互通信，但产品层使用异步事件驱动架构与网络抽象层通信。服务将事件发布到Apache Kafka，其他服务在那里查找和使用与其相关的事件。（Fabric微服务也同时使用REST API和Kafka事件）。
例如，名为云路由管理器 (Cloud Router Manager) 的微服务负责处理围绕创建、更新和检索客户 FCR 及其连接相关数据的所有操作。另一个名为连接管理器 (Connection Manager) 的微服务负责处理连接请求，收集来自下游服务的更多网络信息。路由协议管理器 (Routing Protocol Manager) 将用户的路由协议存储在数据库中。这只是构成该解决方案的数十个微服务中的一小部分示例。
无需额外硬件，无需虚拟机
让我们回到在 Fabric 运行的同一硬件路由器上运行 FCR 的决定。首先，无需部署更多硬件或虚拟机（传统的但延迟更高的虚拟网络功能托管方式）本身就是一个优势。此外，将来在任何启动 Fabric 的新站点都可以立即支持 FCR。
单个 FCR 是一个虚拟路由功能，分布在服务可用区域内每个地铁中的多个 Equinix 数据中心的物理路由器上。Fabric 内可访问的任何端点都可访问在该地铁中创建的任何 FCR。您可以使用边界网关协议 (BGP) 来路由端点之间的流量，这些端点与您的 FCR 对等。
来自云世界的最接近 FCR 的结构是虚拟私有云。您可以在包含多个子网的云可用性区域中创建 VPC，每个子网都在该区域中的单独可用区（其自己的数据中心）中运行。您可以为不同的工作负载创建另一个 VPC，并使这两个 VPC 完全相互隔离或配置为连接和交换数据。同样，您可以为不同的目的创建多个 FCR。
FCR 与 VPC 的一个不同之处在于它将各个数据中心从用户那里抽象出来。他们在地铁内启动 FCR 并选择要连接的端点（例如 Azure 入口）。然后使用现有的网络到网络接口 (NNI) 在 Azure 和 Fabric 之间配置第 2 层连接。此时，用户可以配置其通过 BGP 与 Azure 的第 3 层连接。
当用户想要连接到地铁中的另一个节点（例如 AWS 入口）时，他们会进行所有必要的选择，并且他们的配置会自动通过我们的 MPLS 网络分发，以将其 FCR 连接到该入口托管的任何地铁位置。
由于地铁内数据中心之间的 Fabric 延迟非常低——例如，Ashburn（我们的华盛顿特区地铁）中 FCR 连接到 AWS 和 Azure 在其各自的美国东部云区域中的延迟小于 2 毫秒——端点的物理位置不会影响性能。
我们在这里只提供了一些 FCR 架构的主要亮点。我们没有涵盖产品层中的所有其他微服务，也没有涵盖我们如何抽象网络配置。我们也没有涉及它的其他功能，例如连接混合云环境、地铁之间路由或高级 BGP 管理工具（如 AS 路径追加和 MED 属性）。
从不是网络专家但需要构建或维护跨越多个平台的环境的用户角度来思考多云连接应该是什么样子，这令人欣慰。如果您对 FCR 感兴趣，AWS 客户可以免费试用。
