当前位置:网站首页>(1)ASP.NET Core3.1 Ocelot介紹

(1)ASP.NET Core3.1 Ocelot介紹

2020-11-06 01:32:26 itread01

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

版权声明
本文为[itread01]所创,转载请带上原文链接,感谢
https://www.itread01.com/content/1604563744.html