Categories
程式開發

最終,我選擇了GraphQL 作為企業 API 網關


最近,我參與了一個從頭開始構建新應用程序的項目,該項目是一個擁有許多前端用戶的大型企業級業務應用程序。為了實現所需的邏輯和功能,該項目的架構設計中需要構建大約50 個微服務,其中一些微服務需要原生地部署到雲上,而另一些則需要託管在本地的OpenShift 集群中,且OpenShift集群將成為與遺留數據系統的連接紐帶。

由於這家公司之前從未構建過這麼多微服務,也從未涉足過雲計算領域,所以遇到的很大挑戰就是如何編排服務網格,以確保對前端的更改不會破壞應用程序,對後端服務的更改也不會破壞前端。

我推薦的解決方案是:將 GraphQL 用作企業 API 網關。

最終,我選擇了GraphQL 作為企業 API 網關 1

簡化部署編排

幾乎所有 API 都存在這樣一個問題:如果對其中一個 API 做了更改,那麼很可能會導致另一個 API 崩潰。雖然“微服務”的存在本身就是解決這個問題,但在實際應用中也會發生響應時缺少數據的情況。

如果同時部署了不同服務的平台,情況會變得更加複雜。這時,我們往往會使用不同的 CI/CD 管道來實現本地 OpenShift 與雲原生 Lambda 服務。

而使用 GraphQL 則相當於為所有服務都提供了前端,簡化了將編排部署到平台的步驟。前端應用程序只會和一個端點通信,而這個端點是用於查詢和發布數據的無版本模式,因此,當後端發生了更改時,不需要對前端進行更改。 GraphQL 端點保持不變,即使後端發生變化,它也可以繼續運行。

最終,我選擇了GraphQL 作為企業 API 網關 2Lambda 的 CI/CD 管道示例

簡化安全性

這個架構的另一個挑戰就是如何保護所有的服務?我們是否構建了一個在使用其他服務之前必須先確定其安全性的安全令牌服務?我們是否為每個服務添加了邏輯以確保令牌在頭文件中、在任何地方都經過了驗證?

如果要我來回答以上問題,那麼我的答案是否定的。而使用 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,
        }),
       ],
     }
   })
)

新的部署選項

最終,我選擇了GraphQL 作為企業 API 網關 3

如果沒有 GraphQL,我們就不得不十分小心的對 API 進行發版和更新。如果運行多個版本的 API,例如 /v1 和 /v2,我們就必須確保上游 API 和前端應用程序對 /v2 進行了更新才能退出 /v1。另外,還必須要在同一代碼庫或容器中同時支持這兩個版本,這使得整個架構變得更加脆弱了,也容易受到重大變更的影響。

而使用 GraphQL 服務作為代理,就可以推出一個 /v2 容器,同時運行這兩個版本的容器。我們可以對 GraphQL 解析器進行變更,使其指向 /v2,而無需變更前端代碼。

這種方式使得新功能的部署變得更容易了,還可以為任何服務選擇任何部署策略,例如:

  • 藍 / 綠部署(Blue/Green)
  • 金絲雀發布(Canary Release)
  • 功能標記(Feature Flagging)

最終,我選擇了GraphQL 作為企業 API 網關 4

總結

目前,開發新的應用程序的首選架構是微服務模式,拆分的所有小型服務一起工作,並通過 API 網關暴露出來,以便前端 SPA 應用程序可以使用它們向最終用戶呈現信息。而 GraphQL 可以減少攻擊面,簡化應用程序的開發以及服務的實際部署。

原文鏈接:

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