GraphQL 碰撞 Apache APISIX，提升 API 领域的安全与性能

本文介绍了 Apache APISIX 和 GraphQL 的特性，以及如何使用 API 网关 Apache APISIX 代理 GraphQL 请求，并提出解决实际场景痛点的方案。

背景信息

GraphQL 是一个开源的、面向 API 而创造出来的数据查询操作语言以及相应的运行环境。最初由Facebook 于 2012 年内部开发，2015 年公开发布。2018 年 11 月 7 日，Facebook 将 GraphQL 项目转移到新成立的 GraphQL 基金会。

您可以把 GraphQL 类比为 SQL 查询语句来理解，与 SQL 查询语句相比，GraphQL 对 API 中的数据提供了一套易于理解的完整描述，让客户端能够通过自定义的描述来准确获得其所需要的数据。这也让 API 能够从容面对日益复杂的接口发展，并避免最终成为一个令人望而生畏的复杂接口。

Apache APISIX 作为云原生网关，在设计之初就已经具备识别 GraphQL 语法的匹配能力。通过对请求中携带的 GraphQL 语句进行高效匹配，筛除异常流量，进一步保证安全性和提高系统性能。

场景解析

我们正处于大数据大流量的时代，Apache APISIX 和 GraphQL 可以通过结合的方式，形成共赢的局面。接下来举一个场景具体说明。

本文将会讨论微服务架构场景下的 Apache APISIX 和 GraphQL 的实际应用。

实际场景中遇到的问题

在项目进行到后期时，往往会出现业务复杂化、团队人员流动性高等问题，而微服务架构已经成为解决这类问题的常见解决方案。在微服务架构中，GraphQL 暴露出的接口分为分散式和集中式两种，然而只有集中式接口设计才能够最大化体现 GraphQL 的优势，但是在集中式接口设计中，所有的微服务对外暴露的是同一个接口，因此处理流量的路由就不能简单地根据 URL 进行转发，而是应该根据请求中包含的不同字段进行转发。

由于 NGINX 处理请求时仅会处理 URL 以及一些参数，但是只有解析请求参数中的查询信息才可以知道客户端访问的资源，从而进行路由转发，因此这种路由转发方式通过传统的 NGINX 是无法完成的。在实际应用场景中，将 GraphQL 接口直接对外暴露非常危险，因此需要一个专业的高性能 API 网关保护 GraphQL 的接口。

解决方案

基于 Apache APISIX 安全、稳定、高性能的特性，增加 GraphQL 灵活的路由匹配规则是解决 GraphQL 集中式接口设计问题的最佳方案。

不支持在 Docs 外粘贴 block

在此方案中，Apache APISIX 作为 API 网关部署在 GraphQL Server 之前，为整个后端系统提供了安全保障，并且 Apache APISIX 根据自身所具备的 GraphQL 匹配功能，筛选一部分请求之后再由 GraphQL Server 进行处理，使整个请求资源过程变得更高效。

得益于 Apache APISIX 的动态特性，您可以启用限流限速、身份认证、可观测性等插件，无需重启服务，进一步提高此方案的运行效率，方便运维工作。

此外，Apache APISIX 还可以针对不同的 graphql_operation 进行不同的权限校验、针对不同的 graphql_name 转发到不同的 Upstream，具体细节将会在下文中进行描述。

综上所述**，Apache APISIX** + GraphQL 的解决方案**，在充分利用 GraphQL 搜索优势的同时也能拥有** Apache APISIX 作为 API **网关所具备的安全