為什麼要使用API閘道器而不是直接通訊？

在微服務架構中，客戶端應用程式通常需要使用來自多個微服務的功能。如果直接執行該消費，則客戶端需要處理多個微服務端點以進行呼叫。當應用程式發展並引入新的微服務或更新現有的微服務時會發生什麼？如果您的應用程式有許多微服務，則從客戶端應用程式處理如此多的端點可能是一場噩夢，並且由於客戶端應用程式將耦合到這些內部端點，因此未來發展微服務可能會對客戶端應用程式造成很大影響。

因此，具有中間級別或間接層級（閘道器）對於基於微服務的應用程式非常方便。如果您沒有API閘道器，則客戶端應用程式必須將請求直接傳送到微服務，並引發問題，例如以下問題。

• 耦合：如果沒有API閘道器樣式，客戶端應用程式將耦合到內部微服務。客戶端應用程式需要知道應用程式的多個區域如何在微服務中分解。在發展和重構將影響客戶端應用程式的內部微服務時，由於客戶端應用程式需要跟蹤多個微服務端點，因此很難維護它們。

• 往返次數過多：客戶端應用程式中的單個頁面/螢幕可能需要多次呼叫多個服務。這可能導致客戶端和伺服器之間出現多次網路往返，增加了嚴重的延遲。在中間級別處理的聚合可以改善客戶端應用的效能和使用者體驗。

• 安全問題：沒有閘道器，所有微服務必須暴露於“外部世界”，使得攻擊面比隱藏客戶端應用程式未直接使用的內部微服務更大。攻擊面越小，應用程式就越安全。

• 跨領域問題：每個公開釋出的微服務都必須處理諸如授權，SSL等問題。在許多情況下，這些問題可以在單層中處理，以便簡化內部微服務。

Ocelot：輕量級和開源API閘道器。非常適合使用.NET Core微服務開始學習這種樣式

Ocelot是一款基於開源.NET核心的API閘道器，特別針對需要統一進入系統的微服務架構。它輕巧，快速，可擴充套件，並提供許多其他功能之間的路由和身份驗證。

選擇Ocelot用於eShopOnContainers參考應用程式的主要原因是因為它是一個.NET Core輕量級API閘道器，您可以將它部署到您部署微服務/容器的相同應用程式部署環境中，例如Docker主機， Kubernetes，Service Fabric等，由於它基於.NET Core，因此它是跨平臺的，允許您在Linux或Windows上進行部署。

在初始架構和樣式解釋部分之後，下一部分將介紹如何使用Ocelot實現API閘道器。

什麼是API閘道器樣式

當您使用多個客戶端應用程式設計和構建大型或複雜的基於微服務的應用程式時，考慮的一個好方法可以是API閘道器。這是為某些微服務組提供單一入口點的服務。它類似於外觀樣式從物件-導向的設計，但在這種情況下，它是一種分散式系統的一部分。API閘道器樣式的變體也被稱為“前端後端”（BFF），因為您可能會根據每個客戶端應用程式的不同需求建立多個API閘道器。

因此，API閘道器位於客戶端應用程式和微服務之間。它充當反向代理，將來自客戶端的請求路由到服務。它還可以提供額外的交叉功能，如身份驗證，SSL終止和快取。

下圖顯示了自定義API閘道器如何適用於基於微服務的體系結構。

使用實現為自定義Web API服務的API閘道器

在前面的示例中，API閘道器將作為以容器執行的自定義Web API或ASP.NET WebHost服務的形式實現。

突出顯示在該圖中非常重要，您將使用面向多個不同客戶端應用程式的單個定製API閘道器服務。這個事實可能是一個重要的風險，因為您的API閘道器服務將根據客戶端應用程式的許多不同要求而不斷增長和發展。最終，它會因為這些不同的需求而臃腫，並且它可能非常類似於單一應用程式或單一服務。這就是為什麼非常推薦將API閘道器分成多個服務或多個較小的API閘道器，例如每種形式的閘道器型別。

您需要註意API閘道器樣式。通常，使用單個API閘道器彙總應用程式的所有內部微服務並不是一個好主意。如果確實如此，它就像一個單一的聚合器或協調器，並透過耦合所有微服務來違反微服務自治。

因此，API閘道器應該根據業務邊界和客戶端應用進行分離，而不是作為所有內部微服務的單一聚合器。

將API閘道器層拆分為多個API閘道器時，如果您的應用程式有多個客戶端應用程式，那麼在識別多個API閘道器型別時可能是主要關鍵點，以便您可以根據每個客戶端應用程式的需要設定不同的外觀。這種情況是一種名為“前端後端”（BFF）的樣式，其中每個API閘道器都可以為每個客戶端應用型別提供不同的API，甚至可以基於客戶端形式因子實現特定的配接器程式碼，該程式碼在下麵呼叫多個內部微服務，如下圖所示。

上圖顯示了一個具有多個細粒度API閘道器的簡化體系結構。在這種情況下，為每個API閘道器確定的邊界完全基於“前端後端”（BFF）樣式，因此僅基於每個客戶端應用程式所需的API。但是在更大的應用程式中，您還應該進一步研究並根據業務邊界建立其他API閘道器作為第二個設計支點。

API閘道器樣式中的主要功能

API閘道器可以提供多種功能。但是，根據產品可能提供更豐富或更簡單的功能，任何API閘道器的最重要和最基本的功能都是以下設計樣式。

反向代理或閘道器路由。API閘道器提供反向代理來重定向或路由請求（第7層路由，通常是Http請求）到內部微服務的端點。閘道器為客戶端應用程式提供單個端點或URL，然後在內部將請求對映到一組內部微服務。這種路由功能有助於將客戶端應用程式與微服務分離，但透過將API閘道器置於整體式API和客戶端應用程式之間來實現整體式API的現代化時，它也非常方便，然後您可以將新的API作為新的微服務新增，同時仍在使用傳統的單片API，直到將來它被分成許多微服務。由於API閘道器，客戶端應用程式不會註意到所使用的API是作為內部微服務還是單片API實現的，更重要的是

有關更多資訊，請檢視閘道器路由樣式資訊。

請求聚合。作為閘道器樣式的一部分，您可以將針對多個內部微服務的多個客戶端請求（通常是Http請求）聚合為一個客戶端請求。當客戶端頁面/螢幕需要來自多個微服務的資訊時，此樣式特別方便。透過這種方法，客戶端應用程式將向API閘道器傳送一個請求，該請求將向內部微服務傳送幾個請求，然後彙總結果並將所有內容發送回客戶端應用程式。這種設計樣式的主要優點和標的是減少客戶端應用程式與後端API之間的溝通，這對於微服務所在資料中心內的遠端應用程式尤其重要，例如移動應用程式或來自SPA應用程式的請求客戶端遠端瀏覽器中的Javascript。

根據您使用的API閘道器產品，它可能能夠執行此聚合。但是，在許多情況下，在API閘道器的範圍內建立聚合微服務更加靈活，因此您可以在程式碼中定義聚合（即C＃程式碼）。

有關更多資訊，請檢視閘道器聚合樣式資訊。

交叉擔憂或閘道器解除安裝。根據每個API Gateway產品提供的功能，您可以將各個微服務的功能解除安裝到閘道器，從而透過將橫切關註點合併到一個層級中來簡化每個微服務的實施。這對於特殊功能來說尤其方便，因為這些功能在每個內部微服務（如以下功能）中都可以很複雜地實現。

• 認證和授權

• 服務發現整合

• 響應快取

• 重試策略，斷路器和QoS

• 限速和節流

• 負載均衡

• 記錄，追蹤，關聯

• 標題，查詢字串和宣告轉換

• IP白名單

根據每種實現方式，API閘道器產品可能存在更多的交叉問題，但這些是最常見的功能。例如，Azure API Management提供了大多數這些功能以及許多對商業API非常有用的高階功能。但是，對於更簡單的方法，像Ocelot這樣的輕量級API閘道器非常靈活，因為您可以將它與微服務一起部署到選定的環境（任何編排器）。