随着时间的推移以及应用程序安全和性能行业的快速发展，许多公司已经开始部署多个供应商来提供服务。有时客户选择使用多个供应商是出于监管/公司合规性、弹性、性能或成本的考虑。
尽管一些客户希望出于本文档中讨论的各种原因实施多供应商解决方案，但多供应商部署可能会引入额外的复杂性、由于多个仪表板和配置而导致的更高运营成本，以及更陡峭的学习曲线。此外，在尝试建立跨多个供应商支持的功能基准时，客户最终可能会采用最低公共分母的设置，而无法利用供应商的最新功能/创新。客户在继续进行多供应商部署之前，应仔细考虑目标和要求，并与所有利益相关者权衡利弊。
本文档探讨了为什么一些客户部署多供应商或双供应商方法，以及如何将 Cloudflare 整合到此类解决方案中。具体而言，本文档介绍了如何实现应用程序安全和性能的多供应商方法。本文档的目标读者是架构师以及有兴趣使用基于云的多供应商解决方案来实现安全和性能的人员。
本参考架构专为对其组织现有网络基础结构负有一定责任或熟悉的 IT、安全或网络专业人员而设计。对应用程序安全和性能（包括代理、DNS 和防火墙）重要的技术和概念有一些经验是很有用的。
为了建立对 Cloudflare 更强大的基础了解，我们推荐以下资源：
阅读本参考架构的人将学到：
- Cloudflare 应用程序安全和性能功能如何与现有技术供应商一起工作
- 了解在使用多个供应商时需要做出的决定
在讨论多供应商安全和性能解决方案之前，重要的是要注意提供这些服务的基于云的解决方案通常是如何工作的，以及流量是如何通过它们路由的。
像 Cloudflare 这样基于云的安全和性能提供商作为反向代理工作。反向代理是位于 Web 服务器前面并将客户端请求转发到这些 Web 服务器的服务器。通常实施反向代理是为了帮助提高安全性、性能和可靠性。
没有反向代理时的正常流量流将涉及客户端发送 DNS 查找请求，接收源 IP 地址，并直接与源服务器通信。这在图 1 中可视化。
引入反向代理后，客户端仍将其 DNS 查找请求发送给其解析器，这是 DNS 查找的第一站。在这种情况下，DNS 解析器将供应商的反向代理 IP 地址返回给客户端，然后客户端向供应商的反向代理发出请求。基于云的代理解决方案现在可以提供额外的安全性、性能和可靠性服务，如 CDN ↗、WAF ↗、DDoS ↗、API Shield ↗、Bot Management ↗ 功能等，然后根据安全策略决定是否将客户端请求路由到相应的源服务器。这在图 2 中可视化。
在某些情况下，提供反向代理的供应商也提供 DNS 服务；这在下面的图 3 中可视化。这对于从单个仪表板管理所有服务以及简化操作非常有益。
Cloudflare 使用其全球 任播网络（anycast network） ↗ 提供反向代理架构，以提供其相应的安全性、性能和可靠性服务。任播是一种网络寻址和路由方法，其中传入请求可以路由到广播相同 IP 地址空间的各种不同位置或“节点”。由于任播及其在全球 数百个城市 ↗ 的业务，Cloudflare 的性能和可靠性极高。Cloudflare 还直接连接到 12,000 个网络，包括每个主要的 ISP、云提供商和企业，距离世界上 95% 的连接互联网的人口在大约 50 毫秒以内。
Cloudflare 拥有一个全球网络，每项服务都在每个 Cloudflare 数据中心的每台服务器上运行。由于 Cloudflare 的网络使用任播，距离客户端最近的数据中心将响应客户端请求。这减少了延迟，同时由于流量在 Cloudflare 网络中的整体分布增加，提高了网络的弹性、可用性和安全性。
Cloudflare 的全球任播网络 ↗ 提供以下优势：
- 传入流量路由到距离最近且有能力有效处理请求的数据中心。
- 固有的可用性和冗余。由于多个节点广播相同的 IP 地址，如果一个节点发生故障，请求只需路由到附近的其他节点。
- 由于任播跨多个数据中心分布流量，它增加了跨 Cloudflare 网络的整体流量分布，防止任何一个位置被请求淹没。由于这个原因，任播网络对 DDoS 攻击非常有弹性。
本节简要概述了 Cloudflare 的初始配置选项，这有助于在深入了解有关多供应商解决方案的详细信息之前进行理解。初始配置的方法允许在如何部署/配置多供应商解决方案方面存在差异。如果您已经熟悉 Cloudflare 初始配置选项，可以跳到讨论多供应商解决方案的下一节。
Cloudflare 提供了多种选项来轻松进行初始配置和使用安全、性能和可靠性服务。通过代理设置提供的云解决方案的一个优势是易于初始配置和入门，因为它主要涉及将客户端请求路由通过代理的 DNS 配置。然而，即使在具有 DNS 配置的初始配置中，Cloudflare 也提供了多个选项和灵活性。
核心要求是，流量必须通过 Cloudflare 代理；这也称为“点亮橙色云（orange-clouded）”，因为站点的流量正在通过 Cloudflare 代理。在仪表板中，您将看到特定 DNS 条目的状态为“Proxied（已代理）”以及橙色云图标，如下面的图 5 所示。
有几种方法可以通过 Cloudflare 代理流量，使用的方法将取决于客户的需求。
1. 完整 DNS 设置 - Cloudflare 作为主 DNS 提供商
将 Cloudflare 配置为主 DNS 提供商，并配置 A 记录以通过 Cloudflare 代理流量。在 DNS 记录上启用代理时，响应将是 Cloudflare 任播 IP 地址，从而使 Cloudflare 成为代理。
2. 辅助 DNS 设置与辅助 DNS 覆盖
将 Cloudflare 配置为辅助提供商，所有 DNS 记录都从主提供商传输。Cloudflare 提供了一个称为 Secondary DNS override（辅助 DNS 覆盖） 的功能，允许客户覆盖从 Cloudflare 辅助名称服务器提供的响应。这使得客户可以利用区域传输（zone transfers）在 DNS 提供商之间进行自动同步。它还提供了灵活性，可以在 Cloudflare DNS 中更新选定的记录，以将某些流量重定向到另一个服务提供商（如 Cloudflare）。在这种情况下，响应将是 Cloudflare 任播 IP 地址，从而使 Cloudflare 成为代理。
3. 部分 / CNAME 设置
在这种设置中，Cloudflare 不是权威 DNS 提供商，客户在外部管理 DNS 记录。
转换为 CNAME 设置确保主机名最终解析为 Cloudflare IP。当客户不想更改其当前的 DNS 设置但仍想使用其他 Cloudflare 服务时，这很有用。
如果客户当前的 DNS 提供商不支持像 Cloudflare 通过 CNAME Flattening（CNAME 扁平化） 那样在区域顶点（有时称为“根域”或“裸域”）上使用 CNAME，您必须从 Cloudflare 购买静态 IP 并在提供商 DNS 中创建指向这些静态 IP 的 A 记录。在 Cloudflare 中，然后您可以创建 A 记录以将区域顶点指向源站。
许多使用 Cloudflare 服务的客户利用跨产品的集成和创新，以及单一 UI 带来管理的便利和操作的简易性，并将多个 Cloudflare 服务（如 CDN 和 WAF）一起使用。尽管不推荐，但也可以将 WAF 等安全服务与其他 CDN 提供商一起使用，方法是通过 CNAME 将流量通过 Cloudflare 转发，并通过缓存规则（Cache Rules）禁用 Cloudflare 缓存。
通常，客户选择多供应商方法是出于监管/公司合规性、弹性、性能和成本的考虑。
一些客户可能必须遵守有关不依赖单一供应商提供所有安全、性能和可靠性服务的监管/公司政策。这可能是由于公司为了减轻特定供应商中断/问题的风险，或为了获得筹码以缓解供应商定价/成本增加的影响而制定的政策。为了符合这些政策，多供应商策略是必需的。
当单个供应商用于所有安全和性能服务时，这可能会被视为单点故障。这可能是由于在所有关键系统中提高可靠性的监管压力、现有供应商经历过的中断或单一供应商长期可靠性的不确定性。
在许多情况下，单个供应商可能连接得非常好，并在某些地区提供了预期的性能水平，但在其他地区则不然；这可能是由于许多原因，包括投资、资源有限、地缘政治原因等。许多客户希望通过实施多供应商方法（通常与实时性能监控相结合，以根据该数据将流量引导到最理想的供应商），全面优化对性能要求很高的应用程序和媒体的速度。
正如特定供应商的性能可以根据内容、时间和位置而变化一样，成本也是如此。通过特定供应商发送特定流量有助于优化交付的总体成本。通常在非常特定的用例（如针对高容量媒体流量）中可以看到推动多供应商策略的这些好处，因为在特定小众用例之外，加入和管理多个供应商的成本通常会增加金钱和资源成本。此外，采用多供应商方法有助于避免被任何单一提供商锁定，从而在供应商之间提供更大的灵活性和议价能力。
任何多供应商架构都会包含组织在实施之前必须在业务和技术层面决定的几个组件。此外，有几点需要记住，以帮助优化您的设置，使其与 Cloudflare 的优势和独特的差异化相一致。
优化功能集和交付方法。Cloudflare 能够提供与大多数主要供应商同等的功能，并可轻松通过我们的无服务器计算服务交付自定义功能。在交付方法方面，Cloudflare 的任播架构是独一无二的，每台服务器都可以交付 Cloudflare 提供的每一项服务，使其成为主动/主动（active/active）方法的理想候选者。
尽可能利用 Cloudflare 的 API 和快速部署功能。由于 Cloudflare 首先通过 API 提供每个功能，并且配置更改通常在几秒钟内可见，这使得团队能够以编程方式轻松测试和部署更改，而无需等待较长的部署时间。
避免“堆叠”方法。这意味着避免将 Cloudflare 放置在另一个供应商之后的请求流中。我们经常听说公司考虑将供应商堆叠起来，希望通过让相同流量以线性方式通过每一层来提供深度防御。从理论上讲，这将允许运行两家供应商的策略，任何未被一家供应商捕获的不良流量都有望被下一家捕获。我们在实践中看到的使用这种设置的情况截然不同。主要缺点是位于另一个供应商后面时会失去全面的流量可见性，这阻碍了许多 Cloudflare 由威胁情报驱动的服务，如 Bot Management（机器人管理）、Rate Limiting（速率限制）、DDoS 缓解和 IP 信誉数据库。从性能方面来看，这也是非常不理想的，因为流量在回到源站之前必须通过两个网络，每个网络都有自己的处理和连接开销。此外，它在操作、管理和支持中造成了不必要的复杂性。
关于堆叠方法的一点注意的是，在特定情况下的特定点解决方案中，将一种供应商解决方案置于另一种之前是有意义的，例如特定的机器人管理解决方案和 API 网关，尤其是在向新供应商/提供商迁移时。在这些场景中，了解每个解决方案在请求流中的位置以优化有效性非常重要。
虽然 Cloudflare 和许多提供商保持了高度的可用性和强大的容错架构，但一些客户进一步希望减少依赖并分别减少单一供应商的单点故障。重要的是要计划在一些或所有供应商的服务中断的最坏情况场景中，以及如何在短时间内解决该问题。客户必须考虑如何在 DNS 提供商、网络和源站连接中建立冗余，以消除单一供应商/组件故障级联为大范围中断的风险。
虽然具体的细节可能因供应商和业务案例而大不相同，但多供应商部署的技术考虑可以分为三个领域：路由逻辑、配置管理和源站连接。
当关注多供应商策略时，必须做出的第一个可能也是最重要的决定是如何将流量路由到每个提供商。这取决于驱动多供应商策略的业务逻辑以及相关每个供应商的技术能力。到每个提供商的流量将使用 DNS 路由，并根据当前的条件和业务需求进行转移。Cloudflare 支持作为权威 DNS 提供商、辅助 DNS 提供商或区域非 Cloudflare DNS (CNAME) 设置的配置。
这里可以利用基于 DNS 的负载平衡和健康检查，以便向域/站点的客户端请求分布在健康的源服务器之间。DNS 提供商监控服务器的健康状况，DNS 使用带有相应 IP 的轮询（round-robin）方法响应客户端请求。
如果也希望通过多供应商 DNS 方法实现 DNS 级别的弹性，可以使用来自不同供应商的多个权威名称服务器进行多种配置。有关更多详细信息，请参阅本文档中的“多供应商 DNS 设置选项”部分。这里的关键是确保多个提供商之间的配置一致。根据 DNS 设置/配置，可以使用不同的方法（如区域传输、通过 Terraform 或 OctoDNS 等工具实现的自动化、通过脚本实现的监控/自动化，甚至手动配置）解决这种一致性。
虽然许多供应商都可以提供类似的最终用户体验，但提供商之间的配置和管理可能会大相径庭，这增加了成功实施的成本。最终，这意味着业务必须熟悉每个供应商的配置逻辑并开发一个系统在它们之间进行映射。只要可能，寻找那些优化管理简便性、自动化支持和快速部署的供应商，以帮助最小化成本和管理开销。
API 对所有供应商产品功能的支持在这里变得至关重要。保持一致的配置不仅在某些多供应商 DNS 设置的路由中很重要，而且在流量可以路由到任一提供商时，对于保持 WAF、API 安全等所有相关服务的一致性也很重要。Terraform 等自动化工具或自定义脚本自动化工具将利用 API 保持供应商之间的这种一致性。
必须做出的另一个重要决定是每个提供商如何连接回您的组织。这在很大程度上取决于供应商的能力加上您组织的技术和安全要求。
客户端将通过 Internet 发出请求，请求将路由到供应商云上相应的供应商代理服务。在最基本的场景中，代理将简单地通过 Internet 将流量路由到源站；这是默认设置。
如果客户想要更高的安全性或额外的性能优势，他们可能决定利用供应商提供的连接选项，例如到源站的加密隧道或从客户数据中心直接通过交叉连接从客户设备直接连接到 Cloudflare 数据中心的直接连接选项。供应商可能还提供加速路由功能，在其中主动监控互联网上最快的路径，以确保使用到源站的最理想路由。
Cloudflare 提供所有这些连接选项以及智能路由（Smart Routing），以确保使用最快的源站路径。本文档的“Cloudflare 连接选项”部分更详细地讨论了这些连接选项。
运营和故障排除
设计多供应商解决方案时，一些重要的注意事项是运营和故障排除。拥有多供应商解决方案可能会增加运营成本并影响故障排除，因为您现在有两个不同的环境要管理和排障。
Cloudflare 的主要重点始终是运营的简便性和提供可见性。Cloudflare 提供一个单一统一的仪表板，您可以从一致且操作简单的 UI 访问所有的安全性、性能和可靠性服务。
此外，Cloudflare 提供日志记录、分析和安全分析仪表板。具有更多详细信息的日志也可以从 UI 访问。客户拥有可用于分析和故障排除的粒度数据。
下面的图 7 显示了 Cloudflare Security Analytics 的视图，它将 Cloudflare 的所有检测功能汇集在一个地方。这为安全工程师和管理员提供了有关其站点的当前流量和安全见解的快速视图。
除了每种产品的分析和上面显示的安全分析之外，您还可以查看 UI 中的日志并将日志导出到 Cloudflare 或第三方云或产品，以进行额外分析。
在下面的图 8 中，正在配置 Logpush 以将日志自动导出到外部目标。
选择多供应商解决方案的供应商时，您应确保选择满足以下标准的供应商：
- 供应商提供易于运营的服务，带有用于所有操作的单一一致 UI，用户可以在一个地方轻松管理和完成工作。
- 供应商具有有用的安全分析，以提供对站点流量的了解、安全见解和用于排障的有用数据。
- 供应商有能力将日志/请求数据导出到第三方云/应用程序。
- 供应商采用 API 优先的方法，并提供用于所有操作的 API，以便可以轻松地使任务自动化。
- 供应商声誉良好，并在需要时提供有效的支持和帮助。
- 员工经过培训，具有使用供应商产品的专业知识，或者乐于使用。
下图描述了一个典型的多供应商设置，其中两个供应商都是“活动的”，即它们都为相同的资源 (www.example.com) 提供流量并且流量在两者之间分配。
在路由方面，这个例子显示了驻留在两家提供商外部的权威 DNS，并在它们之间进行负载平衡。这个 DNS 提供商可以自行托管，也可以放在另一个第三方提供商上。通过针对特定提供商的 CNAME 记录或针对顶点域流量（apex domain traffic）使用静态 IP 响应针对 www.example.com 的查询，将流量引导到每家提供商。为了实现这种流量分割，第三方 DNS 提供商需要具备一些负载平衡流量的能力。大多数主要的 DNS 提供商都会有一些机制来执行基于 DNS 的负载平衡，并且在复杂性和可配置性方面具有不同程度的水平。这在最简单的情况下可能意味着记录之间的轮询，或者根据客户位置、健康检查数据等改变响应。
根据权威 DNS 提供商，流量可以在两家之间均匀分配或动态调整。通常，客户会选择利用从 Thousandeyes 或 Catchpoint 等第三方监控服务获取的性能/可用性数据来通知 DNS 路由，并根据该数据调整 DNS 响应。第三方监控服务通常用于捕获完整的 HTTP 请求/响应指标，以便根据实时性能进行路由。可以通过更新权威 DNS 并等待记录 TTL 到期，轻松将流量移离提供商。
值得注意的是，这里的第三方服务查看的是端到端的应用程序性能指标，而不仅仅是 DNS 响应时间或 DNS 解析器使用的有限数据。将根据性能数据更新 DNS 记录，以反映指向正确安全供应商代理的情况。
管理员通过 Terraform 通过调用每个提供商的 API 推出更改来保持两个提供商的配置同步。请记住，虽然 Cloudflare 确实提供每项功能的完整 API 支持，但这不一定适用于每一个提供商。
如果仅使用一家外部 DNS 提供商，则当该 DNS 提供商中断时会产生单点故障。减轻这种风险的一种方法是实施多供应商 DNS 解决方案；本文档中的 多供应商 DNS 选项 部分对此进行了更详细的讨论。
并行方法的另一个挑战是保持提供商之间的配置同步以提供一致的最终用户体验。这意味着管理员需要熟悉两个供应商的配置管理，并了解如何实现功能对等。
一旦流量通过 DNS 路由到安全和性能服务提供商，就会应用所有安全和性能服务以及各自的策略，并且流量然后通过 Internet 路由回源站，在那里客户的防火墙允许每家提供商指定的 IP。
以下示例描述了一个设置，其中 DNS 提供商也是安全代理供应商，并且 DNS 记录通过区域传输保持同步。推荐采用多供应商 DNS 解决方案作为首选且最具弹性的解决方案。
这里可以在不同的 DNS 供应商之间进行不同的设置，本文档的“多供应商 DNS 设置”部分对此进行了更详细的讨论，并附带了各自的优缺点。
在这个示例中，使用了多个权威 DNS 提供商，其中一个是主要的，另一个是辅助的。根据对辅助 DNS 和各自标准的使用，区域传输允许在不同提供商之间轻松保持 DNS 配置的同步。
为了在此模型中将请求指向两个提供商（针对相同的主机），被设置为辅助的供应商必须能够覆盖旨在经过代理的记录。如果没有作为辅助覆盖记录的能力，所有主记录的目的地将保持静态，并降低整体设置的灵活性和弹性；Cloudflare 借助 Secondary DNS override（辅助 DNS 覆盖） 提供了这种能力。例如，如果将诸如 Cloudflare 这样的提供商设置为辅助，Cloudflare 将使 DNS 通过区域传输自动从主 DNS 同步给他们，并可以使用 Secondary DNS override（辅助 DNS 覆盖）来更新 A 记录以指向它自己的代理/服务。
虽然此处不需要基于 DNS 的负载平衡，但使每一个提供商拥有这方面的能力以可以跨多个供应商可预测地拆分请求是有帮助的，否则流量拆分很大程度上由客户端解析器对名称服务器的选择决定。
在权威 DNS 提供商处，每家供应商列出了它们的 NS 记录，客户端将根据它们的解析器选择名称服务器。解析器在收到请求后，将接收全套的权威名称服务器。大多数解析器使用的逻辑通常会考虑解析时间以及可用性。在这种情况中，将根据其已有的性能/可用性数据，利用解析器来做出决定应使用哪台名称服务器。
这里有一点非常重要，通常 DNS 解析器已经见过与所使用的名称服务器相关的查询和响应。例如，供应商分配给客户的名称服务器可能已经被其他站点的权威 DNS 所使用，而且解析器已经拥有非常强大的历史性能数据基准，可以立即开始利用。
在此示例中，我们也看到通过定期区域传输保持记录同步。Cloudflare 能够支持传出和传入区域传输。流量通过提供商特定的 CNAME 记录或静态 IP 引导到每个代理。
DNS 端的配置可以有所不同；下一节将详细讨论不同选项。可以将 DNS 建立在一家提供商作为主提供商，另一家提供商作为辅助提供商的形式上。所有 DNS 配置都在充当主提供商的 DNS 提供商上完成，辅助 DNS 通过区域传输接收配置的副本。
像 Cloudflare 等一些 DNS 提供商提供的功能，使辅助 DNS 能够覆盖 A 和 AAAA 记录。这样根据期望使提供商可以将 A/AAAA 记录重写为将流量通过不同的供应商进行代理。在这种情况下，针对相同的主机名，辅助 DNS 提供商提供的响应与主要提供商的不同。这意味着根据客户端解析器所查询到的名称服务器，请求将被路由到供应商对应的网络上。在名称服务器缓慢或无法连接时，它依赖于通过客户端解析器进行流量引导和故障切换，从而实现了高度的灵活性以及复杂性的降低。随之而来的代价即是不再对向哪一家客户端提供商的选择具有直接的控制以及可预测性。
另一个变体是通过特定提供商托管特定的应用程序/主机名。这意味着，在上述例子中，无论哪个提供商解析了初始 DNS 查询，主 DNS 服务器和辅助 DNS 服务器都将 www.example.com 映射到 Cloudflare 地址。
重要的路由决策是由 DNS 决定的。如上所述，多 DNS 设置可以有多种配置。以下内容假定您使用的是两个 DNS 提供商，它们同时也是安全解决方案的提供商。
1. 两个权威 - 一主一辅
这种设置涉及将一个提供商设置为主提供商，将第二个提供商设置为辅助提供商。辅助 DNS 的目的是支持多 DNS 解决方案，其中主辅助配置之间的同步是自动化的。
在这种设置中，两个 DNS 提供商都是权威的，但只有一个是主要且真实的来源，以及在此可以进行 DNS 配置更改/更新的地方。通过由提供商管理的区域传输（zone transfer）将对主的配置进行更改/更新同步到辅助 DNS 提供商。两个提供商的 DNS 都会回答 DNS 查询。
这种部署模型的优势和主要用例在于它使用跨多个提供商同步 DNS 的标准，并正因这个原因而创建，而且 DNS 提供商负责区域传输。此选项为保持提供商之间 DNS 同步提供了简易性。
有时由于以下原因，客户可能决定使用另一个选项：
- 在记录管理和区域传输管道发生故障时需要更新 DNS 记录。
- 不希望依靠第三方/供应商进行 DNS 同步并希望有更多的控制权。
- 具有排除此选项的特定限制/法规。
建议希望通过辅助 DNS 和提供商来维持同步简便性的客户采用这种设置。
优点：
- 使用标准（AXFR，IXFR）保持 DNS 同步并自动完成区域传输。
- 易于维护，因为 DNS 提供商负责 DNS 同步。
缺点：
- 如果记录管理和区域传输管道发生故障，DNS 记录将无法更新。
- 一些客户不想依靠供应商/第三方进行 DNS 同步，希望获得更多的控制权和灵活性。
2. 两个权威 - 都是主（Primary）
一些客户也希望确保在记录管理和区域传输管道出现故障时能够更新 DNS 记录。他们也可能不想为了进行 DNS 同步而依赖第三方/供应商并且需要更多控制。在这种情况下，两个 DNS 提供商都可以用作主要的。
在这种设置中，每个 DNS 提供商都具有权威性且为主要的。没有辅助 DNS，并且可以在任何一个提供商处更改/更新 DNS；另外，这两个 DNS 提供商都响应 DNS 查询。
在提供商之间保持 DNS 配置同步至关重要，在这种设置下，使两个提供商之间的 DNS 保持同步现在变成了客户责任。客户通常使用诸如 OctoDNS、Terraform 之类的自动化工具，或利用提供商的 API 通过定制的自动化来执行此同步。
建议希望采用最灵活、最具弹性选项的客户使用此设置——该选项在管理管道或区域传输出现故障时仍支持更新 DNS 记录——以及希望更好地控制 DNS 同步的客户。
优点：
- 如果其中一家提供商的控制平面出现故障，DNS 记录仍能在另一家提供商中予以更新。
- 具有更多控制，在执行 DNS 记录同步操作中无需依赖 DNS 供应商。
缺点：
- 在提供商之间保持 DNS 同步更复杂。
- 配置以及记录管理和同步是客户的责任（通过 API、自定义自动化或手动流程）。
3. 一个或多个权威 - 隐藏主和多个辅助
在隐藏的主设置中，用户建立一个未列出的主服务器来存储所有区域文件和更改，然后启用一个或多个辅助服务器来接收和解析查询。尽管主服务器在大多数时候都是权威的，但并非必须如此。在这个选项中，主服务器不在注册商处列出。主服务器不响应查询，其主要目的是成为唯一的真实来源。
尽管辅助服务器本质上实现了主服务器的功能，但隐藏设置允许用户隐藏其源 IP，保护其免受攻击。此外，可将主服务器离线进行维护而不会导致 DNS 服务中断。
此设置推荐给希望获得辅助 DNS 及同步简单性的客户。该方案还允许在需要时将主服务器离线进行维护，影响较小。
优点：
- 允许客户在自己的基础设施上管理 DNS 记录，并使用标准区域传输自动保持 DNS 同步。
- 主服务器仅作为唯一真实来源（source of truth），可在需要时将主服务器离线进行维护。
缺点：
- 如果记录管理和区域传输管道发生故障，DNS 记录将无法更新。
- 部分客户不想依赖供应商/第三方进行 DNS 同步，希望拥有更多控制权。
图 11 描述了在并行管理 Cloudflare 和其他提供商的配置时看到的典型模式。在这个例子中，我们假设相同的工作负载通过这两个提供商分离，并且管理团队正在通过 Terraform 通过 API 更新两个配置。这也可以捆绑到内部 CI/CD 管道中以匹配典型的开发人员工作流。所有的 Cloudflare 功能都可以通过 API 进行配置，并且首先通过 API 交付。此图还描述了发送到通用 SIEM 的日志以及可以基于性能、安全或管理标准的警报，通过电子邮件、webhook 或 PagerDuty 传送的本机警报功能。
Cloudflare 提供广泛的自定义选项（Ruleset Engine、原生功能、Workers 自定义等），通常可与市场上大多数其他主要供应商实现功能对等，但不保证这些功能以相同方式配置。因此，与 Cloudflare 客户团队密切合作，了解操作上的关键差异和最佳实践以对齐工作流非常重要。
对于多供应商产品，重要的是考虑每家提供商提供的源站连接方法，以及在安全性、性能和弹性方面的权衡。Cloudflare 提供多种选项以满足大多数用例，可并行部署，并以每个应用程序（主机名/DNS 记录）为粒度，适应混合客户环境。
在最基本的场景中，代理会通过互联网将流量路由到源站；这是所有供应商的默认设置。在此设置中，客户端和源站都通过各自 ISP 直接连接到互联网。请求经互联网从客户端路由到供应商代理（通过 DNS 配置），然后代理经互联网将请求路由到客户源站。
下图描述了请求流经 Cloudflare 网络时到源站的默认连接。当请求命中已代理的 DNS 记录并需要到达源站时，Cloudflare 会使用一组 Cloudflare 拥有的地址，经互联网将流量从网络发送到源站。
客户还可以选择使用 Dedicated CDN Egress IPs（专用 CDN 出站 IP），为 Cloudflare 连接回源站分配客户专用 IP。我们建议仅允许来自这些网络的流量（allowlisting），以避免直接访问。除在源站防火墙进行 IP 阻止外，我们强烈建议通过 Full (Strict) SSL 设置或 mTLS 认证进一步验证流量，确保所有流量来自通过客户配置区域的请求。
配置 BYOIP 后，Cloudflare 全球网络将播发客户自有的 IP 前缀，这些前缀可与相应的 Cloudflare 第 7 层服务配合使用。
另一种选择是通过互联网建立私有隧道/连接以提高安全性。部分供应商通过隧道或 VPN 提供私有连接（可加密或未加密）；这些方案在复杂度和管理方面各不相同，并需要更新安全/防火墙以允许连接。传统 VPN 设置还受限于通过集中式供应商位置回到源站。
Cloudflare 提供 Cloudflare Tunnel，这是一种隧道软件，在源站与 Cloudflare 网络之间提供加密隧道。由于 Cloudflare 在其全球网络上使用任播，源站也会像客户端一样连接到最近的 Cloudflare 数据中心。
运行隧道时，您基础设施中的轻量级守护进程 cloudflared 会在源站服务器与 Cloudflare 网络之间建立四条仅出站 (outbound-only) 连接。这四条连接至少分布在两个不同数据中心的四台不同服务器上，提供强大的弹性。可以安装多个 cloudflared 实例以提高源站服务器与 Cloudflare 网络之间的弹性。
cloudflared 在源站 Web 服务器与最近的 Cloudflare 数据中心之间创建加密隧道，无需打开任何公共入站端口。这简化了实施，无需更改防火墙安全设置，并降低了防火墙配置错误导致公司易受攻击的风险。
在此模型中，防火墙和安全态势通过防火墙锁定所有源服务器端口和协议来加强。一旦 Cloudflare Tunnel 到位并应用了相应的安全措施，所有 HTTP/S 端口上的请求都将被丢弃，包括容量型 DDoS 攻击。数据泄露企图（例如传输中的数据窃听或暴力登录攻击）将被完全阻止。
上图描述了通过 Cloudflare Tunnel 的连接模型。请注意，此选项为您提供了一种无需公开可路由 IP 地址即可将您的资源安全连接到 Cloudflare 的方法。Cloudflare Tunnel 可以安全地将 HTTP Web 服务器、SSH 服务器、远程桌面和其他协议连接到 Cloudflare。
大多数供应商还提供了直接连接到其网络的选项。与使用公共互联网相比，直接连接提供了安全性、可靠性和性能优势。这些直接连接是在对等互联设施、互联网交换中心 (IX)（互联网服务提供商 (ISP) 和互联网网络可以在此相互连接）或通过供应商合作伙伴完成的。
上图描述了通过 Cloudflare 网络互连 (CNI) ↗ 的源站连接，它允许您将您的网络基础设施直接与 Cloudflare 连接，并且仅通过这些直接链接进行通信。CNI 允许客户将分支机构和总部位置直接与 Cloudflare 互连。客户可以通过以下三种方式之一与 Cloudflare 互连：在 Cloudflare 对等设施 ↗ 提供的专用网络互连 (PNI) 上，通过 Cloudflare 参与的 众多全球交换中心之一 ↗ 的 IX，或通过我们的 互连平台合作伙伴 ↗ 之一。
无论您的基础设施和员工在何处，Cloudflare 的全球网络都可以轻松连接到网络。
大多数供应商还提供附加功能，用于在与源站通信时增强/优化路由和附加的安全功能。如果期望在性能和安全能力方面达到对等，您应查看相应供应商的文档以确认支持。
Cloudflare 提供 Argo Smart Routing（Argo 智能路由） 以在 Cloudflare 网络中查找和使用优化路由，从而更快地向用户交付响应；以及 Authenticated Origin Pulls（经过身份验证的源站拉取，mTLS），以确保向您的源站服务器发出的请求来自 Cloudflare 网络。
Argo Smart Routing 是一项服务，可在 Cloudflare 网络中找到优化路由，从而更快地将响应交付给用户。
Argo Smart Routing 通过考虑来自每秒超过 2800 万个 HTTP 请求路由的实时数据和网络智能来加速流量；它确保通过 Cloudflare 网络到达源服务器遍历的是最快、最可靠的网络路径。平均而言，Argo Smart Routing 使 Web 资产的性能提高了 30%。
此外，Cloudflare CDN 利用 Argo Smart Routing 来为 Argo Tiered Cache（Argo 分层缓存）确定最佳的上层数据中心。可以启用 Argo Smart Routing，以确保始终采用上层数据中心和源服务器之间通过 Cloudflare 网络的最快路径。如果没有 Argo Smart Routing，上层数据中心到源服务器之间的通信仍会智能地绕过互联网上的问题路由，以确保源站的可达性。有关 Argo Smart Routing 在 CDN 方面的更多信息，请参阅 Cloudflare CDN 参考架构。
Authenticated Origin Pulls 有助于确保对源站服务器的请求来自 Cloudflare 网络，这在 Cloudflare 提供的 Full 或 Full (strict) SSL/TLS 加密模式之上提供了额外的安全层。
结合 Cloudflare Web Application Firewall (WAF)，这种身份验证变得尤为重要。与 WAF 一起，您可以确保在从您的源服务器接收到响应之前评估所有流量。
如果您希望您的域符合 FIPS ↗ 标准，您必须上传自己的证书。此选项适用于 区域级（zone-level） 和 每主机名（per-hostname） 经过身份验证的源站拉取。
总而言之，成功的应用程序安全和性能多供应商策略需要仔细考虑您的业务目标、基础设施要求和供应商能力。在部署多供应商策略时有多种选项可供选择，每种选项都有各种优点和局限性。Cloudflare 可以通过 Cloudflare 全球网络提供服务来支持这些配置，该网络具有高度的弹性、高性能和成本效益，可满足您组织的多供应商策略。
将此页面下载为 PDF