API網關模式

什麼是網關

    網關一詞來源於計算機網絡中的定義，網關(Gateway)又稱網間鏈接器、協議轉換器。網關的準肯定義是： 兩個計算機程序或系統之間的鏈接，網關做爲兩個程序之間的門戶，容許它們經過不一樣計算機之間的協議通訊來共享信息。顧名思義API網關就是API之間相互調用的關卡和屏障。

API之間爲何須要網關

    試想一下咱們在實現一個很是龐大的業務系統，分爲不一樣的業務domain和子系統，各個domain和子系統提供處理業務的API，不一樣系統之間以API的方式進行數據交互。一般狀況下咱們可能會將全部實現業務功能的API集成到一塊兒（API Center）給不一樣的Channel的Portal提供數據處理的能力。當有一天咱們的系統須要與第三方發生交互，咱們既須要暴露給外部系統調用的公開API，同時也須要調用外部的API實現自身的業務需求。此時咱們將會考慮不少的問題，好比：服務之間訪問的受權和認證，安全和性能的監控，緩存和日誌的處理，超時的Retry，負載和熔斷的處理，查詢請求的聚合等等一系列的問題。此時你須要一個能夠集中處理全部可能在服務調用之間須要處理的一切事情，就像是小區的物業和安保同樣，須要對小區全部的業主處理職責範圍內的一切事情。

    這是一般狀況下API網關須要幫咱們處理的事情，隨着系統業務的不斷複雜化，咱們的系統越越龐大，API的交互愈來愈錯綜複雜。此時咱們可能會考慮將這個龐大的系統拆分紅多個細小的domain，分別提供各自domain的API。這即是時下最流行的話題：微服務。當咱們的系統演進到微服務的架構時，API網關將是系統必不可少的關鍵部分。在微服務體系結構中，客戶端應用程序一般須要使用多個微服務的功能。客戶端若是直接消費某服務，那一般狀況下將須要處理和協調用多個微服務endpoint。當應用程序引入新的微服務或更新現有微服務時會發生什麼?試想一下若是你的應用程序有許多微服務，那麼處理和協調來自客戶端如此多的endpoint的請求，那對系統來講是一場噩夢，並且因爲客戶端應用程序將與這些endpoint產生耦合，這將會使咱們的系統邊的混亂不堪。

    所以，咱們須要一箇中間層或間接層(Gateway)來處理不一樣client對API的請求，這將會使得咱們的應用程序處理起來很是方便。若是沒有API網關，客戶端應用程序必須直接向微服務發送請求，這就會產生不少混亂的問題，好比：

耦合: 若是沒有API網關，客戶端的應用程序將與內部微服務間耦合。客戶端序須要知道實現業務需求的API分散在服務中的哪些部分，當咱們開發和重構內部服務時，將會影響到客戶端應用程序，而且很難維護，由於客戶端應用程序須要跟蹤多個服務的endpoint

屢次請求:客戶端應用程序中的一個頁面可能須要屢次調用多個服務來完成某個功能，這可能致使客戶端和服務器之間的屢次往返請求，增長了顯著的延遲。咱們知道在中間級別處理的聚合能夠提升客戶端應用程序的性能和用戶體驗。

安全問題:若是沒有網關，全部的服務都必須公開給「外部世界」，這使得攻擊面比隱藏內部服務更大，而這些服務不是客戶端應用程序直接使用的。攻擊面越小應用程序就越安全。

橫切關注點:每一個公開發布的服務都必須處理諸如受權、SSL等問題。在許多狀況下這些關注點能夠在一個層中處理，這樣內部服務就能夠簡化，這讓我想起了面向切面的編程（AOP）

什麼是網關模式

    當咱們在使用多個客戶端應用程序設計和構建大型或複雜的基於微服務的應用程序時，能夠考慮使用API網關，這是爲某些微服務組提供單一入口點的服務，它相似於面向對象設計的Facade（外觀類）模式，但在微服務中它是系統的一部分。API網關模式的一個變體也稱爲「Backend for front-end」(BFF)，由於你可能會根據每一個客戶端應用程序的不一樣需求建立多個API網關。所以API網關位於客戶端應用程序和微服務之間，它充當反向代理將請求從客戶端路由到服務，它還能夠提供額外的橫切特性，如身份驗證、SSL終止和緩存。

下面的圖顯示了自定義API網關如何適合於基於微服務的體系結構。

在上面的示例中，API網關將做爲自定義Web API或ASP.NET WebHost服務的一個容器運行

    在該圖中須要強調的是咱們將使用一個面向多個不一樣客戶端的自定義API網關服務。這多是一個重要的風險，由於你的API網關服務將根據客戶端需求的不斷增加和發展，最終因爲這些不一樣的需求，它將變得臃腫不堪，實際上它可能很是相似於單片應用程序或單片服務。這就是爲何咱們很是推薦將API網關拆分爲多個服務或多個更小的API網關。

    在使用API網關模式時咱們也要很是當心，一般使用單個API網關聚合應用程序的全部內部微服務不是一個好的實踐，由於一旦這樣作了它就充當一個總體聚合器或協調器並經過耦合全部微服務來違反微服務自治。所以API網關應該基於業務邊界和客戶端應用程序進行隔離，而不是做爲全部內部微服務的單一聚合器。當把API網關層分解爲多個API網關時, 若是你的應用程序有多個客戶端, 這能夠是一個主要的樞紐來識別多個API的網關類型，這樣你就能夠有不一樣的外觀類來應對每一個客戶端的需求。這是咱們稱之爲「Backend for front-end」的模式(BFF)，其中每一個API網關能夠爲每一個客戶端提供不一樣的API，甚至可能基於客戶端的特定需求實現特定的適配器代碼，該代碼在下面調用多個內部微服務，以下圖所示：

上圖展現了一個帶有多個細粒度API網關的簡化體系結構，在這種狀況下識別每一個API GateWay的邊界純粹是基於BFF的模式，所以只是基於每一個客戶端提供各自所需的API，但在較大的應用程序也應該更進一步，以建立基於業務邊界的網關做爲第二設計衡量因素。

API網關模式中的主要特性 

  API網關能夠根據產品的不一樣提供多種特性，它可能提供更豐富或更簡單的特性，可是對於任何API網關來講，最重要和基本的特性是如下設計方式：

反向代理或網關路由：API網關提供反向代理，將請求(一般是Http請求)從新定向或路由到內部微服務的端點。網關爲客戶端應用程序提供一個endpoint或URL，而後在內部將請求映射到一組內部微服務。這個路由特性有助於從微服務的方式來解耦客戶端，並且也很方便在單一API和客戶端之間實現網關的控制，這樣的話你能夠添加新的API做爲新的microservices同時仍然使用遺留單一的API，直到它在將來被分紅許多microservices。由於API的網關的存在，客戶端應用程序不會注意到所使用的API實現爲內部microservices或單一的API，當在演進和和重構咱們的單一API到 microservices的過程當中由於有了API網關路由的存在，纔不會帶來Client請求的URI的變化。想了解更多網關路由的東西請戳這裏。

請求聚合：做爲網關模式的一部分，你能夠將針對多個內部微服務的多個客戶端請求(一般是Http請求)聚合到單個客戶端請求中。當客戶端頁面須要調用來自多個微服務的數據時，這種模式特別方便。使用這種方法客戶端將發送一個請求到API網關，而後網關將負責發送多個請求來獲取內部microservices而後聚合結果再發送回客戶端。這種設計模式的主要優勢和目標是減小客戶端應用程序和後端API之間的隔閡，對於微服務所在的數據中心以外的遠程應用程序來講這一點尤其重要，好比移動應用程序或來自客戶端遠程瀏覽器中的Javascript的SPA應用程序的請求。對於在服務器環境中執行請求的常規web應用程序(如ASP)，這種模式並不重要，由於延遲比遠程客戶機應用程序要小得多。是否可以執行此聚合取決於你使用的API網關產品，然而在許多狀況下，在API網關的範圍內建立聚合微服務將會更加的靈活，因此你也能夠在代碼中定義聚合(即c#代碼)。想了解更多請求聚合的東西請戳這裏。

橫切關注點或網關卸載：根據每一個API網關產品提供的特性，你能夠將功能從單個微服務轉移到網關，經過將橫切關注點合併到一層來簡化每一個微服務的實現。這對於能夠在每一個內部微服務(如如下功能)中正確實現的複雜的特殊功能來講特別方便。

身份驗證和受權
服務發現集成
響應緩存
重試策略，斷路器和QoS。
速度限制和節流
負載平衡
日誌記錄、跟蹤、相關性
頭文件、查詢字符串和聲明轉換
IP白名單

根據每一個實現API網關產品能夠提供更多的橫切關注點，但這些都是最多見的特性。例如Azure API管理提供了這些特性中的大部分，以及許多對商業API很是有用的高級特性。可是對於更簡單的方法，像Ocelot這樣的輕量級API網關是至關靈活的，由於你能夠將它部署到你所選擇的環境和你的微服務。有關網關卸載模式的更多信息請戳這裏。

 本篇文章主要是介紹了API的網關模式的特性，文章是來自微軟官方博客並加入了本身的一點理解。譯文來自：https://blogs.msdn.microsoft.com/cesardelatorre/2018/05/15/designing-and-implementing-api-gateways-with-ocelot-in-a-microservices-and-container-based-architecture/

參考資料：

API Gateway

http://microservices.io/patterns/apigateway.html

https://docs.microsoft.com/en-us/azure/architecture/microservices/gateway

Aggregation and composition pattern

http://microservices.io/patterns/data/api-composition.html