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

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

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

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

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

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

24165462_CC56_40da_9212_8E3BA8F1A350

简化部署编排

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

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

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

4502E324_1E4E_4f04_8909_409A548BA508

简化安全性

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

如果要我来回答以上问题,那么我的答案是否定的。而使用 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,
        }),
       ],
     }
   })
)

新的部署选项

B58B524D_17C8_4e7d_9C05_CFF489CD765B

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

而使用 GraphQL 服务作为代理,就可以推出一个 /v2 容器,同时运行这两个版本的容器。我们可以对 GraphQL 解析器进行变更,使其指向 /v2,而无需变更前端代码。
这种方式使得新功能的部署变得更容易了,还可以为任何服务选择任何部署策略,例如:

  • 蓝 / 绿部署(Blue/Green)
  • 金丝雀发布(Canary Release)
  • 功能标记(Feature Flagging)

BB6EB77C_91B1_4857_B6A2_ACF858B222B0

总 结

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

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/zhibo

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-05-20
本文作者:Tj Blogumas
本文来自:“InfoQ”,了解相关信息可以关注“InfoQ

相关文章
|
1月前
|
API
阿里云微服务引擎及 API 网关 2024 年 2 月产品动态
阿里云微服务引擎及 API 网关 2024 年 2 月产品动态
|
2月前
|
Prometheus 网络协议 JavaScript
api 网关 kong 数据库记录请求响应报文
Kong的tcp-log-with-body插件是一个高效的工具,它能够转发Kong处理的请求和响应。这个插件非常适用于需要详细记录API请求和响应信息的情景,尤其是在调试和排查问题时。
49 0
api 网关 kong 数据库记录请求响应报文
|
2月前
|
监控 应用服务中间件 API
API 网关的功能用途及实现方式
API 网关的功能用途及实现方式
|
5月前
|
Java API Maven
淘东电商项目(05) - Swagger及网关统一管理API
淘东电商项目(05) - Swagger及网关统一管理API
72 0
|
6月前
|
缓存 负载均衡 监控
每日一博 - 反向代理、API 网关、负载均衡
每日一博 - 反向代理、API 网关、负载均衡
83 0
|
2月前
|
安全 前端开发 API
深入理解与实践GraphQL:构建高效、灵活的API
在本文中,我们将探索GraphQL这一强大的API查询语言及其运行原理。不同于传统的RESTful API设计,GraphQL提供了一种更加高效、灵活的方式来交互数据。通过实例和比较,本文旨在揭示GraphQL如何使前端和后端开发更加紧密协作,同时减少数据传输的冗余。我们将从GraphQL的基本概念入手,深入到查询(Queries)、变更(Mutations)和订阅(Subscriptions)的实现,最后探讨如何在实际项目中部署和优化GraphQL服务。此外,本文还将简要介绍如何利用现有的GraphQL工具和库来加速开发过程。
|
9天前
|
API
阿里云微服务引擎及 API 网关 2024 年 3 月产品动态
阿里云微服务引擎及 API 网关 2024 年 3 月产品动态。
|
1月前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 API 网关 2024 年 02 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要。
|
5月前
|
API
在钉钉中,如何通过API接口实现OA审批和企业业务系统打通?
在钉钉中,如何通过API接口实现OA审批和企业业务系统打通?
245 1
|
1月前
|
缓存 中间件 API