API網關模式怎么理解

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網關模式怎么理解的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！