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

相關文章：

• .NET Core開源API網關 – Ocelot中文文檔

• Ocelot——初識基于.Net Core的API網關

• Ocelot API網關的實現剖析

• 微服務網關Ocelot

• API網關Ocelot 使用Polly 處理部分失敗問題

• 談談微服務中的 API 網關（API Gateway）

• Ocelot網關

• Ocelot統一權限驗證

• 應用監控怎么做？

• ASP.NET Core之跨平臺的實時性能監控

• .Net Core 2.0+ InfluxDB+Grafana+App Metrics 實現跨平臺的實時性能監控

• 應用程序的8個關鍵性能指標以及測量方法
  

• 使用Metrics監控應用程序的性能

• 下一個計劃 : .NET/.NET Core應用性能管理

• Ocelot監控

• Ocelot 集成Butterfly 實現分布式跟蹤

• Ocelot中使用Butterfly實踐

• Ocelot + Consul實踐

原文地址：https://www.toutiao.com/a6556480905353888263

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的.NET微服务体系结构中为什么使用Ocelot实现API网关的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。