最终,我选择了GraphQL 作为企业 API 网关

Posted 架构头条

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了最终,我选择了GraphQL 作为企业 API 网关相关的知识,希望对你有一定的参考价值。

作者 | Tj Blogumas
策划 | 田晓旭

最近,我参与了一个从头开始构建新应用程序的项目,该项目是一个拥有许多前端用户的大型企业级业务应用程序。为了实现所需的逻辑和功能,该项目的架构设计中需要构建大约 50 个微服务,其中一些微服务需要原生地部署到云上,而另一些则需要托管在本地的 OpenShift 集群中,且 OpenShift 集群将成为与遗留数据系统的连接纽带。

由于这家公司之前从未构建过这么多微服务,也从未涉足过云计算领域,所以遇到的很大挑战就是如何编排服务网格,以确保对前端的更改不会破坏应用程序,对后端服务的更改也不会破坏前端。

我推荐的解决方案是:将 GraphQL 用作企业 API 网关。

最终,我选择了GraphQL 作为企业 API 网关

1 简化部署编排

几乎所有 API 都存在这样一个问题:如果对其中一个 API 做了更改,那么很可能会导致另一个 API 崩溃。虽然“微服务”的存在本身就是解决这个问题,但在实际应用中也会发生响应时缺少数据的情况。

如果同时部署了不同服务的平台,情况会变得更加复杂。这时,我们往往会使用不同的 CI/CD 管道来实现本地 OpenShift 与云原生 Lambda 服务。

而使用 GraphQL 则相当于为所有服务都提供了前端,简化了将编排部署到平台的步骤。前端应用程序只会和一个端点通信,而这个端点是用于查询和发布数据的无版本模式,因此,当后端发生了更改时,不需要对前端进行更改。GraphQL 端点保持不变,即使后端发生变化,它也可以继续运行。

最终,我选择了GraphQL 作为企业 API 网关Lambda 的 CI/CD 管道示例

2 简化安全性

这个架构的另一个挑战就是如何保护所有的服务?我们是否构建了一个在使用其他服务之前必须先确定其安全性的安全令牌服务?我们是否为每个服务添加了逻辑以确保令牌在头文件中、在任何地方都经过了验证?

如果要我来回答以上问题,那么我的答案是否定的。而使用 API网关来管理所有的服务,可以将安全检查 / 验证向上移一层,开发人员可以专注于开发中具有业务价值的功能,同时还减少了到处重复的膨胀和冗余代码。

为了提高安全性,我们可以使用 GraphQL 实现以下几点:

深度限制
import depthLimit from 'graphql-depth-limit'import express from 'express'import graphqlHTTP from 'express-graphql'import schema from './schema'const app = express()app.use('/graphql', graphqlHTTP((req, res) => ({ schema, validationRules: [ depthLimit(10) ]})))
速率限制

使用 GraphQL 速率限制(GraphQL Rate Limit)插件,我们可以通过三种不同方式(自定义指令 graphql-shield、或者基本速率限制函数)为查询和突变指定限制。

该插件允许我们设置时间窗口和限制,针对高度易受攻击的突变和查询(如登录),可以设置一个较大的时间窗口,而针对较不易受攻击的查询,可以设置更短的限制。这种方式可以为合法用户提供良好的体验,对攻击者来说则是一个噩梦。

查询成本限制
app.use( '/graphql', graphqlExpress(req => { return { schema, rootValue: null, validationRules: [ costAnalysis({ variables: req.body.variables, maximumCost: 1000, }), ], } }))
3 新的部署选项

最终,我选择了GraphQL 作为企业 API 网关

如果没有 GraphQL,我们就不得不十分小心的对 API 进行发版和更新。如果运行多个版本的 API,例如 /v1 和 /v2,我们就必须确保上游 API 和前端应用程序对 /v2 进行了更新才能退出 /v1。另外,还必须要在同一代码库或容器中同时支持这两个版本,这使得整个架构变得更加脆弱了,也容易受到重大变更的影响。

而使用 GraphQL 服务作为代理,就可以推出一个 /v2 容器,同时运行这两个版本的容器。我们可以对 GraphQL 解析器进行变更,使其指向 /v2,而无需变更前端代码。

这种方式使得新功能的部署变得更容易了,还可以为任何服务选择任何部署策略,例如:

  • 蓝 / 绿部署(Blue/Green)

  • 金丝雀发布(Canary Release)

  • 功能标记(Feature Flagging)

蓝 / 绿部署示例

4 总结

目前,开发新的应用程序的首选架构是微服务模式,拆分的所有小型服务一起工作,并通过 API 网关暴露出来,以便前端 SPA 应用程序可以使用它们向最终用户呈现信息。而 GraphQL 可以减少攻击面,简化应用程序的开发以及服务的实际部署。

拓展阅读:

https://levelup.gitconnected.com/graphql-is-the-new-api-gateway-383edeed4bcd

今日推荐文章


活动推荐

前阿里 & Intel 架构师、《大型网站技术架构》作者李智慧老师和极客时间联合开设的「 架构师训练营 」火热报名中,训练营采用全程直播的形式,将带你通过 100 天高强度实战训练,助你斩获大厂 60W 高薪 Offer,学完可达到阿里 P6-P7 水平。课程根据架构师的工作职责分为 11 个部分,每个章节会细致讲解不同工作职责,所需要的技能、思路以及经验分享,面试题解析与案例的剖析讲解等,包含了 14 个大厂核心案例。「 架构师训练营」将是你的不二之选 。明晚涨价至 ¥2799,现在可享受早鸟价 ¥2499,抓紧上车

以上是关于最终,我选择了GraphQL 作为企业 API 网关的主要内容,如果未能解决你的问题,请参考以下文章

GraphQL - 使用对象作为参数

我怎么知道所有客户都订阅了我的 graphql 数据?

Node GraphQL从API解析空数据[重复]

公开基于 GraphQL 的 API

GraphQL是新的API网关

从 json api 响应生成 Graphql 模式