摘要：協(xié)議轉(zhuǎn)換微服務(wù)架構(gòu)允許使用不同的協(xié)議以便于獲得使用不同技術(shù)的優(yōu)勢。過于龐大的在實現(xiàn)時，應(yīng)當(dāng)避免將非通用邏輯如領(lǐng)域特定數(shù)據(jù)轉(zhuǎn)換放入其中。服務(wù)應(yīng)始終對其數(shù)據(jù)域擁有完全的所有權(quán)。構(gòu)建一個過于龐大的，從服務(wù)團(tuán)隊爭奪控制權(quán)，這違反了微服務(wù)的理念。

我們團(tuán)隊的后端服務(wù)中，一開始只有一個大服務(wù)，所有的東西都往里面寫，可以想象下，當(dāng)這個服務(wù)變得不斷的龐大，將會變得多么難以維護(hù)。后來逐漸把一些數(shù)據(jù)服務(wù)抽離成多帶帶的 API 服務(wù)，在原有的服務(wù)里，就還剩一些模板渲染，數(shù)據(jù)聚合還有一些耦合的業(yè)務(wù)邏輯。目前來說拆的還不夠干凈，我們的目標(biāo)其實是希望這個舊的服務(wù)充當(dāng)一個 API Gateway，或者說一個給前端用的中間層。單一職責(zé)原則，其實是一個很重要的解耦方式，一個服務(wù)干好一件事就好了。偶然間看到下面的文章，雖然只是一些很簡單的介紹，也讓我了解到很多東西。也分享給 大家看看。

閱讀原文

客戶端一般都需要經(jīng)過一些認(rèn)證以及滿足在數(shù)據(jù)傳輸時的安全要求，才能獲得訪問微服務(wù)架構(gòu)中的服務(wù)的權(quán)利。不同的服務(wù)在認(rèn)證上都會或多或少存在一些差異，API Gateway 就像一個集線器，用它來抹平各種服務(wù)協(xié)議之間的差異，并滿足對特定客戶端的特殊處理。他的存在，方便了客戶端對各類服務(wù)的享用。

微服務(wù)適合用在團(tuán)隊可以獨立設(shè)計、開發(fā)、運(yùn)行服務(wù)的架構(gòu)體系中。它允許系統(tǒng)中的各個服務(wù)存在技術(shù)多樣性，團(tuán)隊可以在適合的場景使用合適的開發(fā)語言、數(shù)據(jù)庫和網(wǎng)絡(luò)協(xié)議。例如，一個團(tuán)隊中使用 JSON 和 HTTP REST，而另一個團(tuán)隊則可能使用 gRPC 和 HTTP/2 或者像 RabbitMQ 這樣的消息代理。

有些場景中使用不同的數(shù)據(jù)序列化方式和協(xié)議可能收益巨大，但是需要使用我們服務(wù)的客戶端可能會有不同的需求。由于存在各種各樣的客戶端，需要我們支持的數(shù)據(jù)格式也是多種多樣，比如一個客戶端可能希望拿到的數(shù)據(jù)是 XML 格式的，而另一個客戶端則希望數(shù)據(jù)是 JSON。另一個你可能需要面對的問題是，可能不同服務(wù)之間存在著一些公共的邏輯(比如權(quán)限認(rèn)證之類)，總不能在每個服務(wù)里都實現(xiàn)一遍吧？

總結(jié)：我們不想把一些支持多個客戶端等相關(guān)的公用邏輯重復(fù)實現(xiàn)在微服務(wù)中，我們需要一個 API Gateway 來提供一個中間層來處理服務(wù)協(xié)議之間的差異，并滿足特定客戶端的需求。

API 網(wǎng)關(guān)是微服務(wù)架構(gòu)中的一種服務(wù)，它為客戶端提供共享層和 API，以便與內(nèi)部服務(wù)進(jìn)行通信。 API 網(wǎng)關(guān)可以路由請求，轉(zhuǎn)換協(xié)議，聚合數(shù)據(jù)，并實現(xiàn)一些共享邏輯，如身份驗證和速率限制器等。

你可以將 API Gateway 看做是一個享用各種微服務(wù)的入口。

我們的系統(tǒng)可以有一個或多個 API Gateway，這具體取決于客戶端的需求。例如，我們可以為桌面瀏覽器，移動應(yīng)用程序和公共API提供多帶帶的網(wǎng)關(guān)。

由于 API Gateway 為客戶端應(yīng)用程序（如瀏覽器）提供了支持，它可以由負(fù)責(zé)前端應(yīng)用程序的團(tuán)隊來實現(xiàn)和管理。

這也意味著 API Gateway 的實現(xiàn)語言應(yīng)由負(fù)責(zé)客戶端的團(tuán)隊選擇。由于 JavaScript 是開發(fā)瀏覽器應(yīng)用程序的主要語言，即使你的微服務(wù)架構(gòu)用不同的語言開發(fā)，Node.js 也可以成為實現(xiàn) API Gateway 的絕佳選擇。
Netflix 成功地使用 Node.js API Gateway 及其 Java 后端來支持廣泛的客戶端, 了解更多。

我們之前討論過，可以將通用共享邏輯放入 API Gateway，本節(jié)將介紹其常見用法。

我們將 API Gateway 定義為微服務(wù)的入口。 在你的 API Gateway 中，你可以將請求從客戶端路由到指定的服務(wù)。 你甚至可以在路由期間對服務(wù)程序的版本進(jìn)行選擇或更改后端接口，而公開的接口可以保持不變。你還可以在你的 API Gateway 中集合多個微服務(wù)到一點。

API Gateway 可以幫助你分解臃腫的應(yīng)用程序。由于業(yè)務(wù)的不斷迭代，從頭開始把整個應(yīng)用重寫成一個微服務(wù)架構(gòu)的系統(tǒng)似乎不太可行。

在這種情況下，我們可以將代理或 API Gateway 置于我們的整體應(yīng)用之前，并將新功能作為微服務(wù)實現(xiàn)，只需要保證 API Gateway 能將新接口路由到新服務(wù)，同時保證舊接口依然能夠訪問。慢慢的我們要把這些舊的服務(wù)遷移成微服務(wù)以達(dá)到分解臃腫應(yīng)用程序的目的。
通過小步迭代設(shè)計，我們能夠平滑的從龐大的整體過渡到微服務(wù)架構(gòu)。

大多數(shù)微服務(wù)是需要通過認(rèn)證才可以使用的。將類似身份驗證的共享邏輯放在 API Gateway 上可以讓你的微服務(wù)更加專注。

在微服務(wù)架構(gòu)中，您可以通過網(wǎng)絡(luò)配置將服務(wù)放置于 DMZ（非軍事區(qū)域）中，并通過API Gateway 將其暴露給客戶端。該網(wǎng)關(guān)還可以處理多個身份驗證方法，例如，可以支持基于cookie和基于 token 的身份驗證。

在微服務(wù)架構(gòu)中，客戶端可能會需要不同聚合程度的數(shù)據(jù)。 在這種情況下，我們可以使用 API Gateway 來解決這些依賴關(guān)系并從多個服務(wù)收集數(shù)據(jù)。

這種問題發(fā)生在不同客戶端需要不同格式數(shù)據(jù)的需求中。

想象一下，在微服務(wù)中如果我們使用了 JSON，但是在某個客戶端中只支持 XML 的 API，這個時候怎么辦？我們完全可以把 JSON 轉(zhuǎn)換 XML 這一過程放在 API Gateway 中，而不是在每個微服務(wù)中實現(xiàn)。

微服務(wù)架構(gòu)允許使用不同的協(xié)議以便于獲得使用不同技術(shù)的優(yōu)勢。然而，大多數(shù)客戶端只支持一種協(xié)議。在這種情況下，我們需要轉(zhuǎn)換客戶端的服務(wù)協(xié)議。

API Gateway 也可以成為介于客戶端和微服務(wù)之間的一個協(xié)議轉(zhuǎn)換層。

下面的圖片中你可以看到，客戶端只使用 HTTP REST 來和各種服務(wù)交換信息，而實際上我們內(nèi)部的各種微服務(wù)可以基于不同的規(guī)范、協(xié)議來進(jìn)行信息傳遞。

除了身份驗證之外，你還可以在 API Gateway 中實現(xiàn)速率限制，緩存和各種可靠性相關(guān)的功能。

在實現(xiàn) API Gateway 時，應(yīng)當(dāng)避免將非通用邏輯（如領(lǐng)域特定數(shù)據(jù)轉(zhuǎn)換）放入其中。

服務(wù)應(yīng)始終對其數(shù)據(jù)域擁有完全的所有權(quán)。 構(gòu)建一個過于龐大的 API Gateway，從服務(wù)團(tuán)隊爭奪控制權(quán)，這違反了微服務(wù)的理念。

這就是為什么你應(yīng)該注意你的API網(wǎng)關(guān)中的數(shù)據(jù)聚合 —— 如果你明確它的職責(zé)，它可以是很強(qiáng)大的，應(yīng)當(dāng)避免在 API Gateway 中處理業(yè)務(wù)邏輯，是誰的事情就交給誰干，一定要明確其在整個架構(gòu)中的角色。

如果你希望在 API Gateway 中執(zhí)行一些簡單的操作，例如將請求路由到特定的服務(wù)，你可以使用像nginx這樣的反向代理。 但在某些時候，你可能需要實現(xiàn)一般代理不支持的邏輯。 在這種情況下，你可以在 Node.js 中實現(xiàn)自己的 API Gateway。

在 Node.js 中，你可以使用 http-proxy 完成一些簡單的代理請求的服務(wù)，當(dāng)然也可以使用具有更多功能的 express-gateway。

在第一個 API Gateway 示例中，我們在其代理請求到真實的服務(wù)之前，先進(jìn)行權(quán)限認(rèn)證。

const express = require("express") 
const httpProxy = require("express-http-proxy")  
const app = express()

const userServiceProxy = httpProxy("https://user-service")

// Authentication
app.use((req, res, next) => {
  // TODO: my authentication logic  
  next()
})
// Proxy request 
app.get("/users/:userId", (req, res, next) => {    
  userServiceProxy(req, res, next)
}) 

另一種方式是由 API Gateway 向微服務(wù)發(fā)送請求，再將響應(yīng)回饋給客戶端：

const express = require("express")  
const request = require("request-promise-native")  
const app = express()
// Resolve: GET /users/me
app.get("/users/me", async (req, res) => {  
  const userId = req.session.userId
  const uri = `https://user-service/users/${userId}`
  const user = await request(uri)
  res.json(user)
})

API Gateway 提供了一個中間層來協(xié)調(diào)客戶端和微服務(wù)架構(gòu)。它有助于幫助我們完成單一職責(zé)原則，讓我們的應(yīng)用或者服務(wù)持續(xù)的關(guān)注一件事。你可以將通用邏輯放入 API Gateway 中，但是也應(yīng)該注意不要過度的使用 API Gateway。