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

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

閱讀原文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在第一個(gè) API Gateway 示例中，我們?cè)谄浯碚?qǐng)求到真實(shí)的服務(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ā)送請(qǐng)求，再將響應(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 提供了一個(gè)中間層來(lái)協(xié)調(diào)客戶端和微服務(wù)架構(gòu)。它有助于幫助我們完成單一職責(zé)原則，讓我們的應(yīng)用或者服務(wù)持續(xù)的關(guān)注一件事。你可以將通用邏輯放入 API Gateway 中，但是也應(yīng)該注意不要過(guò)度的使用 API Gateway。