什么是联合网关？

在集中式系统中，单一网关（自身连接并负责管理多个 API）可处理所有客户端查询。同时，网关联合则允许组织使用分布式 API 网关网络，每个网关负责管理各自独立的一组服务。

在联合网关系统中，团队可以按需添加服务，而不会影响整个系统，从而实现高效的资源利用和流量管理。各部门也可以使用不同的协议来管理相应网关。该框架为团队提供了自主管理 API 的自由度，从而提高了灵活性、运营弹性等能力。

这种方法还有助于避免流量瓶颈和其他与集中式 API 网关相关的问题，并且可以通过将网关功能部署于更接近最终用户的位置来实现性能优势。网关联合策略可以应用于各类 API 架构风格和协议，包括 REST、gRPC 和 SOAP，每种方案都具备独特的优势与局限性。

从 IT 角度来看，联合网关的优势在于其支持开发运维 (DevOps) 团队开发和部署专属 API，同时确保其遵守企业级 API 平台管理、治理和安全政策。团队可以快速、独立地移动以完成其领域内的项目（推动创新、加速上市），同时遵循组织级标准，在团队自主权和集中式监督之间取得平衡。

GraphQL 联合是一种替代概念和架构方法，用于创建统一的 GraphQL API。它基于 GraphQL，这种查询语言可通过单个 API 查询精准定位来自多个服务的资源。

GraphQL 联合将不同服务（即子图）连接到名为“超图”的统一架构，每个子图均拥有定义其管理数据的独立架构。单一网关面向客户端应用程序开放此超图架构，联合多个底层服务和字段，并路由所有 API 查询。相比之下，网关联合则通过中央控制平面连接多个 API 网关，每个网关自主处理查询。

联合是一种通用的系统管理方法，它通过公共控制平面连接自主组件。

在集中式网关系统中，所有客户端请求都流经单一网关，该网关负责管理路由、身份验证、授权和监控等功能。与联合架构不同，这些职责并未分散至多个实例。

这种方法可以简化日志记录、流量管理、安全执行和其他任务，因为这些流程均可通过网关进行。组织还可以从单一点启动发布，而无需跨多个网关和服务进行版本更新。

但是，部署集中式框架的企业可能更易面临瓶颈，尤其是在扩大其运营规模时。作为系统的单一通过点，网关很容易出现拥塞。此外，它还存在单点故障；一旦发生错误，就会波及整个系统。

与集中式系统不同，联合网关架构由多个网关组成，每个网关负责一组不同的服务和相关 API。这些网关独立运行，尽管其都由中央控制平面管理。

与集中式框架相比，联合系统赋予开发团队对各自领域更大的控制权，从而提高灵活性和自主性。这一分散式布局还能提升联合系统抵御中断和系统故障的韧性。

然而，联合系统的操作更加复杂，可能会导致团队间出现治理分歧和沟通不畅。由于每个网关都必须单独管理和更新，因此发布可能需要更长的时间，且维护成本也更高。

企业选择联合网关系统的原因如下：

首先，网关联合通常应用于并购案例，企业从其所收购的公司继承不同的堆栈和 API 管理系统。企业不再单独管理多个独立架构（每个架构都设有不同的安全协议、技术标准和治理结构），也不再尝试利用现有的企业系统改造已收购系统，而是转向网关联合。这种方法可帮助组织将现有的 API 网关及其底层系统整合至中央控制平面所提供的上层结构。

同样，在由不同团队构建且分散于多种环境的大量微服务场景中，通常也需要部署多个网关。企业也可能会选择联合系统来获得性能优势。

例如，假设某家物流公司在全球范围内设有多个办事处，每个办事处均服务于特定地区。通过将网关、服务器、服务和其他资源部署于更接近客户端访问的位置，这家公司就能优化延迟和相关性能因素。

在网关联合中，中央控制平面负责管理、监控和治理，但客户端通常无法访问。API 消费者与构成联合系统的网关直接交互（查询负责相关服务的端点），但无法查询控制平面本身。只有在发生 API 调用后，平面才能接收元数据和日志。

虽然这种方法可能会引入操作复杂度，但它也有助于提升独立性。例如，它可以帮助平台团队配置专属网关和服务以满足其特定需求，自主选择协议并独立部署发布。联合架构抵御错误配置和安全漏洞的韧性也更强，因为错误会被隔离到源网关，以免其扩散到网络中的其他网关。

同时，在 GraphQL 联合中，来自多个独立服务（即子图）的架构可组合成统一的超图架构。单一网关或路由器可为客户端查询提供单个入口点，从而打造统一的 API 体验。

路由器可将查询智能拆分为较小的子请求，从多个子图中检索相关信息，将其编译为连贯响应并返回至客户端。

想象一下，某个医疗保健平台可提供以下服务：

• 患者：管理患者详细信息、联系方式和病史
  
  
• 预约：安排和跟踪后续就诊
  
  
• 计费：处理发票和计费通知

GraphQL 联合并非通过单独的 API 调用来查询每个端点，而是提供统一的界面，支持客户端（本例中指的是为医生或患者提供服务的应用程序或仪表板）访问患者的病历、安排预约及确认未付费用，而无需分别发起三次独立请求。

GraphQL 联合提供了一种在分布式环境中构建可扩展 GraphQL API 的方法。该框架支持独立开发和部署服务，同时可为客户端查询提供统一的前端。但是，GraphQL 联合可能会面临成本和复杂性挑战、安全漏洞、拥塞以及冗余等问题。

Apollo 联合于 2019 年问世，是 GraphQL 联合的一种实现方案；它采用 GraphQL 架构定义语言中的特殊指令（如 @key 或 @extends）来定义跨子图的类型关联。

尽管 Apollo 是一项常见的解决方案，但它并非唯一可用的 GraphQL 联合选项。常见的替代方案包括 Hive、Mesh、Indigo 和 WunderGraph Cosmo，它们均能提供不同级别的自定义功能。

根据研究公司 Gartner 的数据，虽然 2024 年仅有不到 5% 的企业部署联合 GraphQL 系统，但到 2027 年，这一比例预计将达到 30%。Amazon Web Services (AWS) 和 Microsoft Azure 等主流云供应商以及 GitHub 等代码存储库也支持包含内置可观测性和验证工具的 GraphQL API。

GraphQL 联合具备多个显著优势，特别是其简化客户端 API 访问的能力。团队可以通过部署、管理和扩展其子图来保持一定程度的独立性。

但作为集中式框架，GraphQL 联合更易出现安全漏洞、拥塞问题和性能低下。它也受制于 GraphQL 架构，API 网关联合则可兼容多种协议。

在制定 API 策略时，组织会决定是否采用 GraphQL API 框架或将其他架构风格（如 REST）应用于其 API。

最终，组织可能会选择将 GraphQL 联合和其他架构风格纳入其系统，各自负责处理不同的功能。常见配置中，企业会在内部使用 GraphQL（通过严格的防护措施以规避安全、成本或复杂性问题），同时对外部 API 采用 REST 等其他架构风格（以实现更精细的控制且更易推行）。在此场景中，组织还可以使用联合 API 网关，通过中央控制平面来统一这些不同的架构风格。

在标准 API 网关配置中，单一网关负责处理所有用户流量、路由和分析。虽然这种方法有助于简化设置，但在面对更复杂的环境时容易引发瓶颈。

联合网关不依赖单一 API 网关，而是依托一组网关阵列。每个网关都用于管理对一组特定服务的 API 调用，网关与控制平面相连，并由后者负责管理和治理。

服务网格则属于东西向配置，因其负责管理微服务间的连接，但并不会与用户直接交互。服务网格主要用于保障单一环境或簇内的通信和可观测性。然而，名为“混合云网格”的变体经过优化，可在多个簇和环境（包括多云、混合云和本地环境）中执行加密、负载均衡和身份验证等功能。

组织可以通过各种策略来利用联合网关中分布式架构的优势，同时减少与联合系统相关的部分操作复杂性和维护成本。这些实践有助于维护团队自主权，同时保持团队间交流渠道的畅通，并实现统一监督。

企业应清晰界定团队职责，明确各个团队应负责构建和维护哪些服务。这种做法有助于强化责任制，并避免团队在无意中重复或错误配置员工的工作内容。推而广之，这种方法能够深化团队对其目标和责任（以及行动自由度）的认知，从而提升团队生产力。

安全与合规协议及标准在各网关和 API 间的实施过程不一致，可能会引发安全、法律及声誉风险。在分布式系统中，维护各网关的日志记录、加密、身份验证和其他安全实施标准是组织的优先事项。组织可以通过中央管理平面有效响应事件报告、开展全面审计并防范未来攻击，无论威胁源自哪个领域。

分布式系统中的可观测性差距可能会导致安全风险和性能问题。至关重要的是，中央管理平面可为团队提供了解系统健康状况和性能所需的全面可见性。这一功能支持组织在出现问题时迅速采取修复措施，并根据安全和性能指标主动进行优化。

统一的开发者门户可作为集中式中心，供开发人员访问和了解系统中的任何 API，无论其托管位置或结构如何。它们在联合系统中尤为重要，可通过指南、文档和编码示例，为 DevOps 团队提供清晰的框架，以指导其构建、部署和维护 API。

这些通用标准与 API 密钥和其他访问控制协同配合，确保开发人员能够将 API 无缝添加到系统并自主管理网关，同时维持安全性和一致性。

由于每个团队都具备一定程度的自主权，因此开放式沟通渠道对于分享最佳实践和维护可持续网络至关重要。仪表板和其他协作工具则可帮助团队围绕共同的目标和程序保持同步，尤其在某一领域的变更可能影响关联服务时。

全面的报告机制支持 DevOps 团队快速检测并解决延迟、服务中断和其他异常情况，从而打造更流畅的用户体验。性能指标还可通过确定系统的哪些环节已达到容量上限，哪些环节性能不佳来提高扩展效率。

现代 DevOps 方法，例如基础设施即代码（使用代码自动执行需要手动监督和配置的 IT 流程）和 AIOps（利用 AI 简化 IT 运营）有助于提高联合网关的运行效率。自动化技术还有助于构建更具弹性的网络，这是因为它们可以减少人为错误的可能性，并为 IT 团队提供带宽，助其专注解决更复杂的问题。

网关联合将分散式架构的灵活性和定制性与集中式治理架构相结合，相比传统架构具备多种优势。

这一联合支持团队自主控制网关，以便调整运行时配置、管理更新和定制编码环境，从而充分满足其客户和服务的需求。例如，要调整集中式系统中 API 的速率限制，团队需借助组织的单一网关提交请求。联合系统支持各团队独立、实时地进行调整，而不会影响网络中的其他网关。

中央平面可确保多个网关在保留专属配置的同时，遵守共同的兼容性和安全标准。团队可以灵活自主地调整参数，同时受益于控制平面提供的外部监督。

联合方法认识到，开发团队通常最了解如何改进和维护其负责的领域。一旦发现问题，团队就可以自主调整其 API 或服务，从而提高适应性和敏捷性。

团队甚至可以使用不同的编码语言，同时维持其服务与中央控制平面的关系。最后，各部门可以按需发布更新，而无需依赖中央机构来审批变更，以缩短新功能的上市时间并简化工作流。

联合系统可支持团队自主监控其性能并对速率限制和流量分布进行相应调整，从而实现更高效的资源配置。组织可以仅扩展需要额外容量的服务和功能，将资源从利用率较低的服务或区域引导至需求较高的服务或区域。

此外，由于 API 网关相互独立，漏洞很难在各网关间横向扩散。因此，联合系统抵御攻击与中断的韧性更强，因为故障往往仅能影响单一网关，而非整个系统。

在联合系统中，各 DevOps 团队负责运营和维护其网关。由于职责减少，中央团队可以专注于更高层级的问题，如实施合规法规、促进团队间的交叉沟通和完善系统架构。

数据孤岛的可能性显著降低，因为联合网关可以分析性能并跨域实施防护措施。跨网关指标可以更全面地展示特定服务如何影响相关产品和服务。

分散式所有权和灵活性可能会带来一些挑战，尤其是在治理或可观测性出现问题时。联合网关带来的挑战包括：

团队自主有助于推动创新，但同时也增加了系统的架构复杂性，导致基础设施和计算成本攀升。由于结构分散，联合系统还往往需要更多的维护和安全资源。

因为指标和日志分布于多个 API 网关，因此组织可能更难针对整体系统性能进行内聚分析。数据源可能变得分散且与整体网络脱节，导致潜在配置错误的识别和排查难度增加。组织可以借助完善的标准化协议和原则以及可观测性工具来应对这一挑战。

虽然各个团队可以自行决定是否进行更新，但企业级发布可能比集中式环境耗时更久。联合网关无需更新单个中央代码库，但必须跨多个域分发更新，并由各团队负责独立审批和集成这些变更。

在分布式网关之间维持一致的配置和策略，可能是一项挑战。如果团队采用偏离企业治理标准的协议、发布计划和数据格式，则可能会出现不兼容性和安全漏洞。相反，如果标准和治理策略过于严苛，企业就有可能阻碍实验并拖慢创新步伐。在联合系统中，平衡至关重要。

随着企业在联合系统下不断发展壮大，它们有可能引入新的低效问题，例如当多个团队无意中开发出冗余 API 时，就会出现 API 蔓延。如果此问题进一步恶化，网关将变得难以管理，中央平面也将无法跟踪变化。通过实施有效的治理措施，可以缓解这一问题。