扶綏微服務2 微服務架構第2部分 API閘道器。

在微服務系列的這篇文章中，我們將討論api閘道器以及它們如何幫助我們解決基於微服務架構的一些重要問題。我們在本系列的第一篇文章中描述了這些和其他問題。

在所有基於服務的體系結構中，有幾個關注點在所有（或大多數）服務之間共享。基於微服務的架構也不例外。正如我們在第一篇文章中所說，微服務幾乎是孤立開發的。交叉問題由軟體堆疊中的上層處理。 api閘道器是其中乙個層。以下是api閘道器處理的常見問題列表：

大多數閘道器對每個請求（或一系列請求）執行某種身份驗證。根據特定於每個服務的規則，閘道器將請求路由到所請求的微服務或返回錯誤**（或更少的資訊）。大多數閘道器在將請求傳遞給後面的微服務時將身份驗證資訊新增到請求中。這允許微服務在需要時實現使用者特定的邏輯。

許多閘道器作為公共api的單一入口點。在這種情況下，閘道器處理傳輸安全性，然後通過使用不同的安全通道或通過刪除內部網路內不必要的安全約束來分派請求。例如，對於restful http api，閘道器可以執行「ssl終止」：在客戶端和閘道器之間建立安全ssl連線，然後通過非ssl連線將**請求傳送到內部服務。

「許多閘道器作為公共api的單一入口點。」

在高負載情況下，閘道器可以根據自定義邏輯在微服務例項之間分發請求。每項服務可能都有特定的擴充套件限制。閘道器旨在通過考慮這些限制來平衡負載。例如，某些服務可能通過在不同的內部端點下執行多個例項來擴充套件。閘道器可以將請求分派給這些端點（甚至請求更多端點的動態例項化）來處理負載。

即使在正常負載情況下，閘道器也可以為排程請求提供自定義邏輯。在大型體系結構中，隨著團隊工作或生成新的微服務例項（例如，由於拓撲更改），會新增和刪除內部端點。閘道器可以與服務註冊/發現過程或描述如何分派每個請求的資料庫協同工作。這為開發團隊提供了出色的靈活性。此外，故障服務可以路由到備份或通用服務，這些服務允許請求完成而不是完全失敗。

由於微服務處理非常具體的問題，一些基於微服務的架構往往變得「健談」：要執行有用的工作，需要將許多請求傳送到許多不同的服務。出於方便和效能的原因，閘道器可以提供在內部路由到許多不同微服務的外觀（「虛擬」端點）。

正如我們在本系列的第一篇文章中所了解到的那樣，微服務通常是孤立開發的，開發團隊在選擇開發平台時具有很大的靈活性。這可能導致微服務返回資料並使用對於閘道器另一側的客戶端不方便的傳輸。閘道器必須執行必要的轉換，以便客戶端仍然可以與其後面的微服務進行通訊。

我們的示例是乙個簡單的node.js閘道器。它處理http請求並將它們**到適當的內部端點（在傳輸過程中執行必要的轉換）。它處理以下問題：

使用jwt進行身份驗證。單個端點處理初始身份驗證：/ login。使用者詳細資訊儲存在mongo資料庫中，對端點的訪問受角色限制。

/*
* ****** login: returns a jwt if login data is valid.
*/function dologin(req, res) , function(err, user) 
if(user.password === logindata.password) , secretkey, );
res.writeheader(200, );
res.write(token);
res.end(); 
} else 
}, 'users');
} catch(err) 
}, function(err) );}/*
* authentication validation using jwt. strategy: find existing user.
*/function validateauth(data, callback) 
data = data.split(" ");
if(data[0] !== "bearer" || !data[1]) 
var token = data[1]; 
try  else ); 
} } catch(err) 
}

傳輸安全性通過tls處理：所有公共請求首先由具有樣本證書的反向nginx**設定接收。

負載平衡由nginx處理。請參閱示例配置。

根據儲存在資料庫中的配置動態排程請求。支援兩種型別的請求：http和amqp。

請求還支援在多個微服務之間拆分請求的聚合策略：單個公共端點可以聚合來自許多不同內部端點（微服務）的資料。所有返回的資料都是json格式。看看netflix關於這個策略如何幫助他們實現更好效能的優秀帖子。另請檢視我們關於falcor的帖子，該帖子允許從多個**輕鬆獲取資料。

通過記錄錯誤並返回少於請求的資訊來處理失敗的內部請求。

/*
* parses the request and dispatches multiple concurrent requests to each
* internal endpoint. results are aggregated and returned.
*/function servicedispatch(req, res) , function(err, service) 
var authorized = rolecheck(req.context.authpayload.jwt, service);
if(!authorized)  
// fanout all requests to all related endpoints.
// results are aggregated (more complex strategies are possible).
var promises = ;
service.endpoints.foreach(function(endpoint)  
});//aggregation strategy for multiple endpoints.
q.allsettled(promises).then(function(results) ;
results.foreach(function(result)  else 
});res.end(json.stringify(responsedata));
});}, 'services');
}

var user = userdb.model('user', new mongoose.schema ());
var service = servicesdb.model('service', new mongoose.schema () ],
authorizedroles: [ string ]
}));
function rolecheck(jwt_, service)

執行傳輸轉換以在http和amqp請求之間進行轉換。

日誌記錄是集中的：所有日誌都發布到控制台和內部訊息匯流排。在訊息匯流排上偵聽的其他服務可以根據這些日誌採取措施。

獲取完整**。

我們在系列的第一篇文章中告訴過你關於webtasks的事情。由於webtasks是微服務，它們也在閘道器後面執行。 webtasks閘道器處理身份驗證，動態排程和集中式日誌記錄，因此您也沒有。

結論討論：**入知識星球【首席架構師圈】或者小號【jiagoushi_pro】或者qq群

扶綏微服務2 微服務架構第2部分 API閘道器。

扶綏微服務2 扶綏網友，這事你怎麼看？

微服務學習2 如何劃分微服務？

微服務架構 2 服務配置管理

扶綏微服務2 微服務架構 第2部分 API閘道器。

扶綏微服務2 扶綏網友，這事你怎麼看？

微服務學習2 如何劃分微服務？

微服務架構 2 服務配置管理

相關推薦

扶綏微服務2 微服務架構第2部分 API閘道器。