（1）ASP.NET Core3.1 Ocelot介紹

1.簡介

Ocelot原本設計僅為與.NET Core一起使用的，它是一個.NET API網關，作為面向使用.NET運作微型服務/面向服務的體系結構需要統一的系統入口點，即當用戶端（Web站點，手機APP）等通路Web API的時候，Ocelot作為統一的入口點會根據請求位址分發到對應的API站點去（尋址）。而Ocelot還內建很多功能，例路由，認證，授權，限速等等功能點，Ocelot官網還建議認證這塊最好跟身份驗證（IdentityServer4）一起使用，承載令牌輕松內建。具體詳情大家可以去官網（https://ocelot.readthedocs.io/en/latest/introduction/bigpicture.html）了解下。

而檢視Ocelot源碼，我們會看到Ocelot是按特定順序排列的一堆中間件（Middleware）組成的管道。

Ocelot将HttpRequest對象操作到由其配置指定的狀态，直到到達請求建構器中間件，在中間件中它建立一個HttpRequestMessage對象，該對象用于向下遊服務送出請求。送出請求的中間件是Ocelot管道中的最後一件事。它不會調用下一個中間件。來自下遊服務的響應存儲在每個請求範圍的存儲庫中，并在請求傳回Ocelot管道時進行檢索。有一塊中間件将HttpResponseMessage映射到HttpResponse對象，然後将其傳回給用戶端。

2.Ocelot配置

根據官網介紹，Ocelot有五種配置：

2.1基礎內建（Basic Implementation）

當用戶端通路下遊服務站點時候，會統一經過Ocelot網關，Ocelot網關Host主機首先會讀取configuration.json配置資訊，根據配置檔案去尋找對應下遊服務站點并傳回處理結果給用戶端。這一個過程可以稱為路由尋址。

2.2內建IdentityServer（With IdentityServer）

當服務站點涉及認證跟授權的時候，可以通過在Ocelot網關上內建IdentityServer，當用戶端通路下遊服務站點時候，會先通過IdentityServer認證跟授權後才分發到下遊服務站點。

2.3多個網關執行個體叢集（Multiple Instances）

單個Ocelot網關是比較危險的，如果這個網關挂掉了，所有下遊服務站點都将無法通路，這樣子是無法做到高可用的。要解決這個問題，可以部署多台Ocelot網關叢集，而Ocelot也內建了負載均衡器。

2.4內建Consul服務發現（With Consul）

檢視官網文檔負載均衡這一欄目，我們知道Ocelot已經支援簡單的負載功能，當下遊站點存在多個服務結點的時候，Ocelot能夠承擔起負載均衡的作用。但是它不提供健康檢查，服務的注冊也隻能通過手動在配置檔案裡面添加完成。這不夠靈活并且在一定程度下會有風險。這個時候我們就可以用Consul來做服務發現，它能與Ocelot完美結合。

2.5內建Service Fabric（With Service Fabric）

如果您在Service Fabric中部署了服務，則通常将使用命名服務來通路它們。

3.總結

Ocelot網關是系統給外部唯一通路入口，就好比公司的門衛承擔着尋址、出入限制、安全檢查、位置引導等等功能。它還提供了路由，身份驗證、監控、負載均衡、緩存、請求分片與管理、靜态響應處理等等功能。Ocelot網關的核心要點是，所有的用戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常網關也是提供REST/HTTP的通路API，服務端通過網關注冊和管理服務。該章節之後，我會繼續根據GitHub貢獻者開源項目上面Ocelot Demo執行個體介紹它的功能。Ocelot Demo位址https://github.com/catcherwong-archive/APIGatewayDemo。

參考文獻：

Ocelot官網