（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官網