歡迎光臨
每天分享高質量文章

.NET微服務體系結構中為什麼使用Ocelot實現API網關

為什麼要使用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網關非常靈活,因為您可以將它與微服務一起部署到選定的環境(任何編排器)。

已同步到看一看
赞(0)

分享創造快樂