.NET Core微服务之路：基于Ocelot的API网关实现--http/https协议篇
前言 ? ?
最近一直在忙公司和私下的兼職，白天十個小時，晚上四個小時，感覺每天都是打了雞血似的，精神滿滿的，連自己那已經學打醬油的娃都很少關心，也有很長一段時間沒有更新博客了，特別抱歉，小伙伴們都等得想取關了吧！哈哈，開個玩笑，這里十分感謝小伙伴們一直以來的關注和支持。
還有不到半個月的時間，豬年就要到來，在這里先提前祝大家豬年吉祥，愿君身體健康，福壽綿長，吉祥如意，財源滾滾，心想事成，萬事順利，新年快樂，好運平安！
?
你看這小豬多可愛，有點像麥兜！甜品先到這兒，我們一起來看本節（也是第三部分的主要思想）重點。你可能會問，怎么突然一下畫風全變了，而且還多了這么多的框框和一些看不懂的圖標，不急，本來筆者想直接就中間那一部分單獨拎出來講解，但確實無法讓部分朋友理解，索性直接將整個微服務架構全部展現了出來。
?
什么是網關？
上一篇我們通過DotNetty構建的遠程RPC框架，已經實現了遠程客戶端的調用，使用的體驗是：跟在本地調用接口一樣沒有任何的區別。但是，這調用是沒有任何限制的，任何人、任何客戶端、只要知道了服務節點地址，并通過TCP實現RPC調用，便可大大方方的、肆無憚忌的調用這些服務節點，如果就這樣部署在生產環境上，是非常危險的。因此，我們需要引入“網關”這樣的中間服務，來限制和管理流入的請求合法性和合規性。
當然，這里我們提到的網關，并非物理機上的實體網關交換機（如下圖所示）：
而是將一臺服務器的部分組件，通過軟件技術，實現網絡管理，比如網卡（筆者曾見過一臺DELL服務器上裝了11塊網卡），通過OSI模型進行管理，實現比如流量限制，路由轉發、驗證、簽權等等一些列功能，所以，我們一般稱之為API網關。我們看看網上的統一解釋：
API網關是一個服務器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定制的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。 --百度
通常情況下， API 網關要做很多工作，它作為一個系統的后端總入口，承載著所有服務的組合路由轉換等工作，除此之外，我們一般也會把安全，限流，緩存，日志，監控，重試，熔斷等放到 API 網關來做，那么可以試想在高并發的情況下，這里可能會出現一個性能瓶頸。
另外，如果沒有開源項目的支撐前提下，自己來做這樣一套東西，是非常大的一個工作量，而且還要做 API 網關本身的高可用等，如果一旦做不好，有可能最先掛掉的不是你的服務節點，而就是這個API網關。
這個時候，通常我們會去找一些開源的 API 網關項目，目前社區關于 API Gataway 的項目有以下這些：
Tyk：Tyk是一個開放源碼的API網關，它是快速、可擴展和現代的。Tyk提供了一個API管理平臺，其中包括API網關、API分析、開發人員門戶和API管理面板。Try 是一個基于Go實現的網關服務。
Kong：Kong是一個可擴展的開放源碼API Layer(也稱為API網關或API中間件)。Kong 在任何RESTful API的前面運行，通過插件擴展，它提供了超越核心平臺的額外功能和服務。
Orange：和Kong類似也是基于OpenResty的一個API網關程序，是由國人開發的，學姐也是貢獻者之一。
Netflix zuul：Zuul是一種提供動態路由、監視、彈性、安全性等功能的邊緣服務。Zuul是Netflix出品的一個基于JVM路由和服務端的負載均衡器。
apiaxle: Nodejs 實現的一個 API 網關。
api-umbrella: Ruby 實現的一個 API 網關。
ocelot: .Net平臺下實現的一個API網關，其中我們的張隊（張善友）也參與了此項目的開發。
本系列單從Net?Core入手，所以我們只討論Ocelot網關的作用和使用。
?
什么是Ocelot：
Ocelot是一個用.NET Core實現并且開源的API網關，它功能強大，包括了：路由、請求聚合、服務發現、認證、鑒權、限流熔斷、并內置了負載均衡器與Service Fabric、Consul集成，并且這些功能都只需要簡單的配置即可完成? ? ? ? 。
?
簡單的說，Ocelot是一堆的asp.net middleware組成的一個管道。當有收到請求后會用一個RequestBuilder去創建一個HttpRequestMessage發送（或請求）到下游服務器，等下游服務器返回Response后再由一個Middleware將HttpRequestMessage映射到當前請求Context中的Response上，并返回給請求者。
這里從張隊這邊借用一張圖，如想了解更多有關Ocelot的原理剖析，可在張隊的博客中了解到更多：https://www.cnblogs.com/shanyou/p/7787183.html。當然，筆者也推薦查看官方原始API文檔：https://ocelot.readthedocs.io
?
?? ?? ????
?
Ocelot的使用結構圖：
用一臺web api來作為Ocelot的宿主，在這里有一個json配置文件，里面設置了所有對當前這個網關的配置。它會接收所有的客戶端請求，并路由到對應的下游服務器進行處理，再將請求結果返回。而這個上下游請求的對應關系也被稱之為路由。
一起來看看官方給出的基礎結構圖：
在公共網絡上，無論是客戶端a還是客戶端b，還是其他任何智能設備，通過http/https進行訪問，都將經過Ocelot進行一次過濾，而這些過濾將通過Ocelot的配置文件及其簡單的配置便可實現下游路由轉發，然后，在通過指定的下游路由配置，請求到映射的指定服務節點上。當然，這是最只是Ocelot基礎的路由轉發。
?
結合IdentityServer：
??
私有網絡中，不做驗證的暢通訪問是極不可取的、非常危險的，因此，Ocelot為我們提供了私有網絡身份驗證解決方案，我們可以通過跟IdentityServer進行結合，實現私有網絡身份驗證，當網關需要認證信息的時候會與IdentityServer服務器進行交互來完成。
?
網關的集群：
?
只有一個網關是很非常危險的，也就是我們通常所講的單點，一旦只要它掛了，所有的服務全部掛掉，這顯然無法達到高可用的目的，所以我們也可以部署多臺網關，當然，這個時候在多臺網關前，你還需要一臺負載均衡器，用于平衡請求到網關的負載的平衡。
?
Consul服務發現：
?
在Ocelot已經支持簡單的負載功能，也就是當下游服務存在多個結點的時候，Ocelot能夠承擔起負載均衡的作用。但是它不提供健康檢查，服務的注冊也只能通過手動在配置文件里面添加完成，這不夠靈活并且在一定程度下會有風險，這個時候，我們就可以用Consul來做服務發現，它能與Ocelot完美的結合。
?
Ocelot的使用：
在ASP.NET Core中集成Ocelot網關
既然Ocelot是通過Asp.net中間件進行網關管理，那么我們肯定就需要一個Asp.net作為宿主，為了演示DEMO，筆者建立了三個模板為Web API的Asp.net core項目，在其中一個asp.net core里通過nuget即可完成安裝和集成Ocelot，或者命令行dotnet add package Ocelot以及通過vs2017 package manager添加Ocelot nuget引用都可以，甚至你還可以跟筆者一樣喜歡全家桶系列（VS固然非常強大，甚至宇宙第一，但筆者更喜歡三大平臺都一模一樣的Jetbrains全家桶），用Rider的Nuget管理來安裝Ocelot也可以。
?? ??? ?
我們把這個網關項目取名為ApiGatway，然后在這個項目的Startup中添加依賴注入和中間件，即可完成Ocelot安裝和注入
添加配置
我們需要添加一個.json的文件用來添加Ocelot的配置，以下是最基本的配置信息。
要特別注意一下BaseUrl是我們外部暴露的Url，比如我們的Ocelot運行在http://127.0.0.1的一個地址上（或一個端口上），但是前面有一個Nginx綁定了域名https://api.mybusiness.com，那這里我們的BaseUrl就應該是?https://api.mybusiness.com。?
將配置文件加入ASP.NET?Core Configuration
我們需要通過IWebHostBuilder將我們添加的json文件添加進Asp.net?Core中
Ocelot的功能配置介紹
通過配置文件可以完成對Ocelot的功能配置：路由、服務聚合、服務發現、認證、鑒權、限流、熔斷、緩存、Header頭傳遞等。在配置文件中包含兩個根節點：ReRoutes和GlobalConfiguration。ReRoutes是一個數組，其中的每一個元素代表了一個路由，我們可以針對每一個路由進行以上功能配置。下面是一個較完整的配置文件，根據筆者的理解，并加上了詳細的注釋，方便初學者理解。官方路徑戳這兒：https://ocelot.readthedocs.io/en/latest/features/configuration.html
{
? "ReRoutes": [
? ? // 路由規則配置節點，數組形式
? ? // 可配置多個路由協議和規則，實現路由、服務聚合、服務發現、認證、鑒權、限流、熔斷、緩存、Header頭傳遞等
? ? {
? ? ? /*
? ? ? ?下游服務配置配置，網關出口，具體指向的服務器
? ? ? ?/api/values - 使用限定規則的方式配置下游PATH規則
? ? ? ?/{url} - 使用泛型（萬用）規則方式配置下游PATH規則
? ? ? ?*/
? ? ? "DownstreamPathTemplate": "/{url}",
? ? ? "DownstreamScheme": "http",
? ? ? "DownstreamHostAndPorts": [
? ? ? ? /*
? ? ? ? 下游主機信息
? ? ? ? 可以配置多個主機信息，已提供Ocelot路由負載均衡模式，需配合LoadBalancer節點進行路由負載均衡。
? ? ? ? */
? ? ? ? {
? ? ? ? ? "Host": "127.0.0.1",
? ? ? ? ? "Port": 5000
? ? ? ? },
? ? ? ? {
? ? ? ? ? "Host": "127.0.0.1",
? ? ? ? ? "Port": 5001
? ? ? ? }
? ? ? ],
? ? ? /*
? ? ? ?上游服務配置配置，請求和網關的入口。
? ? ? ?/api/values - 使用限定規則的方式配置上游PATH規則
? ? ? ?/{url} - 使用泛型（萬用）規則方式配置上游PATH規則
? ? ? ?*/
? ? ? "UpstreamPathTemplate": "/{url}",
? ? ? // 上游支持的http請求方法
? ? ? "UpstreamHttpMethod": [
? ? ? ? "Get",
? ? ? ? "Post",
? ? ? ? "Delete",
? ? ? ? "Update"
? ? ? ],
? ? ? // 上游域名主機
? ? ? // "UpstreamHost": "domain.com",
? ? ? // 當前路由節點的優先級
? ? ? "Priority": 99,
? ? ? /*
? ? ? ?路由負載均衡:
? ? ? ?LeastConnection – 將請求發往最空閑的那個服務器
? ? ? ?RoundRobin – 輪流發送
? ? ? ?NoLoadBalance – 總是發往第一個請求或者是服務發現
? ? ? ?*/
? ? ? "LoadBalancer": "LeastConnection",
? ? ? "Key": "Route1",
? ? }
? ],
? // 限流配置（請求限流）
? // 對請求進行限流可以防止下游服務器因為訪問過載而崩潰
? "RateLimitOptions": {
? ? // ClientWhitelist - 白名單列表
? ? "ClientWhitelist": [],
? ? // EnableRateLimiting - 是否啟用限流
? ? "EnableRateLimiting": true,
? ? // Period - 統計時間段 1s, 5m, 1h, 1d
? ? "Period": "1s",
? ? // PeriodTimespan - 多少秒之后客戶端可以重試
? ? "PeriodTimespan": 1,
? ? // Limit - 在統計時間段內允許的最大請求數量
? ? "Limit": 1,
? ? // Http頭 X-Rate-Limit 和 Retry-After 是否禁用
? ? // X-Rate-Limit: 為防止濫用，你應該考慮對您的 API 限流。 例如，您可以限制每個用戶 10 分鐘內最多調用 API 100 次。
? ? // Retry-After: 響應的 HTTP 報頭指示所述用戶代理應該多長時間使一個后續請求之前等待
? ? "DisableRateLimitHeaders": false,
? ? // QuotaExceededMessage - 當請求過載被截斷時返回的消息
? ? "QuotaExceededMessage": "Customize Tips!",
? ? // HttpStatusCode - 當請求過載被截斷時返回的http status
? ? "HttpStatusCode": 999,
? ? // ClientIdHeader - 用來識別客戶端的請求頭，默認是 ClientId
? ? "ClientIdHeader": "Test"
? },
? // 熔斷的意思是停止將請求轉發到下游服務。
? // 當下游服務已經出現故障的時候再請求也是無功而返，并且增加下游服務器和API網關的負擔。
? // 這個功能是用的Pollly來實現的，我們只需要為路由做一些簡單配置即可
? "QoSOptions": {
? ? // ExceptionsAllowedBeforeBreaking - 允許多少個異常請求
? ? "ExceptionsAllowedBeforeBreaking": 3,
? ? // DurationOfBreak - 熔斷的時間，單位為秒
? ? "DurationOfBreak": 5,
? ? // TimeoutValue - 如果下游請求的處理時間超過多少則自如將請求設置為超時
? ? "TimeoutValue": 5000
? },
? // 本地配置
? // 可配置多個路由協議和規則，實現服務聚合、服務發現、認證、鑒權、限流、熔斷、緩存、Header頭傳遞等
? "GlobalConfiguration": {
? ? // 全局基礎路徑
? ? "BaseUrl": "http://127.0.0.1:8080"
? }
}
Downstream：是下游服務配置
UpStream：是上游服務配置
Aggregates：服務聚合配置
ServiceName, LoadBalancer, UseServiceDiscovery：配置服務發現
AuthenticationOptions：配置服務認證
RouteClaimsRequirement：配置Claims鑒權
RateLimitOptions：為限流配置
FileCacheOptions：緩存配置
QosOptions：服務質量與熔斷
DownstreamHeaderTransform：頭信息轉發
?
路由：
ocelot的主要功能是接收傳入的HTTP請求并將其轉發到下游服務，不過目前只支持HTTP請求的形式（將來可能是任何傳輸機制，暗中竊喜，默默關注和等待吧）。ocelot將一個請求路由到另一個請求描述為路由，為了讓任何請求在ocelot中工作，我們需要在配置中設置一個路由。
{ ? ?"ReRoutes": [] }下面這個配置信息就是將用戶的請求 /post/1?轉發到 localhost/api/post/1
DownstreamPathTemplate：下游服務的路徑模板，支持RESTful模板路徑。
DownstreamScheme：下游服務協議，支持http和https。
DownstreamHostAndPorts：下游服務的地址和集合，用于定義要將請求轉發到的任何下游服務的主機和端口，通常，這只包含一個條目，但有時您可能希望向下游服務加載負載均衡。
UpstreamPathTemplate:?上游也就是用戶輸入的請求Url模板，支持RESTful模板路徑，或者設置一個空列表以允許其中任何一個方法。
UpstreamHttpMethod:?上游請求http方法，可使用數組。
?
捕獲所有（通用模板）：
通用模板即所有請求全部轉發，UpstreamPathTemplate與DownstreamPathTemplate設置為 “/{url}”
萬能模板的優先級最低，只要有其它的路由模板，其它的路由模板則會優先生效。?
上游Host：
上游Host也是路由用來判斷的條件之一，由客戶端訪問時的Host來進行區別。比如當a.jessetalk.cn/users/{userid}和b.jessetalk.cn/users/{userid}兩個請求的時候都可以進行區別對待。
優先級：
對多個產生沖突的路由設置優化級，可通過priority屬性來定義我們希望路由與上游HttpRequest的匹配順序。
比如你有同樣兩個路由，當請求/goods/delete的時候，則下面那個會生效，也就是說Prority數值越大的會被優先匹配。?
請求聚合：
ocelot允許我們指定組成多個正常路由的聚合的重路由，并將它們的響應映射到一個下游對象中，通常情況下，當你有一個客戶機向一個服務器發出多個請求時，它可能只是一個服務器，這個特性允許您使用ocelot開始實現前端類型體系結構到后端，還可以減少對后端服務節點的重復處理負載。
{
? ? "ReRoutes": [
? ? ? ? {
? ? ? ? ? ? "DownstreamPathTemplate": "/",
? ? ? ? ? ? "UpstreamPathTemplate": "/laura",
? ? ? ? ? ? "UpstreamHttpMethod": [
? ? ? ? ? ? ? ? "Get"
? ? ? ? ? ? ],
? ? ? ? ? ? "DownstreamScheme": "http",
? ? ? ? ? ? "DownstreamHostAndPorts": [
? ? ? ? ? ? ? ? {
? ? ? ? ? ? ? ? ? ? "Host": "localhost",
? ? ? ? ? ? ? ? ? ? "Port": 51881
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ],
? ? ? ? ? ? "Key": "Laura"
? ? ? ? },
? ? ? ? {
? ? ? ? ? ? "DownstreamPathTemplate": "/",
? ? ? ? ? ? "UpstreamPathTemplate": "/tom",
? ? ? ? ? ? "UpstreamHttpMethod": [
? ? ? ? ? ? ? ? "Get"
? ? ? ? ? ? ],
? ? ? ? ? ? "DownstreamScheme": "http",
? ? ? ? ? ? "DownstreamHostAndPorts": [
? ? ? ? ? ? ? ? {
? ? ? ? ? ? ? ? ? ? "Host": "localhost",
? ? ? ? ? ? ? ? ? ? "Port": 51882
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ],
? ? ? ? ? ? "Key": "Tom"
? ? ? ? }
? ? ],
? ? "Aggregates": [
? ? ? ? {
? ? ? ? ? ? "ReRouteKeys": [
? ? ? ? ? ? ? ? "Tom",
? ? ? ? ? ? ? ? "Laura"
? ? ? ? ? ? ],
? ? ? ? ? ? "UpstreamPathTemplate": "/",
? ? ? ? ? ? "Aggregator": "FakeDefinedAggregator"
? ? ? ? }
? ? ]
}
在Startup中添加AddSingletonDefinedAggregator<FakeDefinedAggregator>來統一處理該路由聚合服務。
services.AddOcelot().AddTransientDefinedAggregator<FakeDefinedAggregator>();而FakeDefinedAggregator需要繼承于IDefinedAggregator，這樣下游服務的統一處理將經過該Aggreage后返回到Response中。
有了這個特性，您幾乎可以做任何您想做的事情，因為下游響應包含內容、頭和狀態代碼，請注意，如果httpclient在向聚合中的重新路由發出請求時拋出異常，那么您將不會得到它的下游響應，但會得到任何成功的響應，如果它確實引發了異常，則會記錄此異常。
如果我們設置??/tom 和?/laura?控制器下的返回值分別是 ?{“Age”: 19}?和 {“Age”: 25}，那么我們請求端將收到如下一個Response信息
{"Tom":{"Age": 19},"Laura":{"Age": 25}}需要注意的是：
聚合服務目前只支持返回json
目前只支持Get方式請求下游服務
任何下游的response header并會被丟棄
如果下游服務返回404，聚合服務只是這個key的value為空，它不會返回404
做一些像 GraphQL的處理對下游服務返回結果進行處理
關于GraphQL的功能支持，Ocelot并無原生自帶GraphQL動態API查詢語句，如果需要集成GraphQL，Ocelot官方有自帶示例：https://github.com/ThreeMammals/Ocelot/tree/develop/samples/OcelotGraphQL?
路由負載均衡
當下游服務有多個結點的時候，我們可以在DownstreamHostAndPorts中進行配置。
LoadBalancer將決定負載均衡的算法
LeastConnection –?將請求發往最空閑的那個服務器
RoundRobin –?輪流發送
NoLoadBalance –?總是發往第一個請求或者是服務發現?
限流
對請求進行限流可以防止下游服務器因為訪問過載而崩潰，這個功能就是我們的張隊添加進去的，Ocelot支持上游請求的速率限制，這樣您的下游服務就不會過載。
ClientWihteList?白名單
EnableRateLimiting?是否啟用限流
Period?統計時間段：1s, 5m, 1h, 1d
PeroidTimeSpan?多少秒之后客戶端可以重試
Limit?在統計時間段內允許的最大請求數量
在 GlobalConfiguration下我們還可以進行以下配置
Http頭 ?X-Rate-Limit?和 Retry-After?是否禁用
QuotaExceedMessage?當請求過載被截斷時返回的消息
HttpStatusCode?當請求過載被截斷時返回的http status
ClientIdHeader?用來識別客戶端的請求頭，默認是 ClientId
?
服務質量和熔斷
熔斷的意思是停止將請求轉發到下游服務。當下游服務已經出現故障的時候再請求也是功而返，并且增加下游服務器和API網關的負擔。這個功能是用的Pollly來實現的，我們只需要為路由做一些簡單配置即可。關于Polly的使用，我會在下一個章節中介紹。
ExceptionsAllowedBeforeBreaking?允許多少個異常請求
DurationOfBreak?熔斷的時間，單位為秒
TimeoutValue?如果下游請求的處理時間超過多少則自如將請求設置為超時?
緩存
Ocelot支持一些非常基本的緩存功能，他是基于CacheManager實現的，當然，我們在使用的過程中，也需要安裝CacheManager這個lib包，然后通過Ocelot Cache manager擴展方法來添加CacheManager實現。
"FileCacheOptions": { "TtlSeconds": 15, "Region": "somename" }在這個例子中，ttl設置為15秒，那么緩存所存在的時長就只有15秒。當然，你也可以通過添加你自定義緩存接口來注入自定義緩存服務。
1 services.AddSingleton<IOcelotCache<CachedResponse>, MyCache>()?
認證
如果我們需要對下游API進行認證以及鑒權服務的，則首先Ocelot?網關這里需要添加認證服務。這和我們給一個單獨的API或者ASP.NET?Core Mvc添加認證服務沒有什么區別。
然后在ReRoutes的路由模板中的AuthenticationOptions進行配置，只需要我們的AuthenticationProviderKey一致即可。
簽權
我們通過認證中的AllowedScopes?拿到 claims之后，如果要進行權限的鑒別需要添加以下配置。
"RouteClaimsRequirement": { ? ?"UserType": "registered"}當前請求上下文的token中所帶的claims如果沒有?name=”UserType”?并且 value=”registered”?的話將無法訪問下游服務。
?
一個簡單的例子
上面我們簡單介紹了一下Ocelot的部分功能，要需完整功能介紹，可參考官方文檔進行https://ocelot.readthedocs.io，接下來筆者做了一個簡單的路由轉發的示例，來演示一下Ocelot基于http/https協議的強大而又簡單的功能。
基于上面介紹的三個項目，我們只介紹了作為網關能使用到的功能，另外我們還需要一個上游作為請求客戶端（當然，筆者更喜歡將客戶端做成一個Console控制臺，方便，快捷），一個下游作為服務端，項目名稱任意。
當下游服務端ASP.NET的默認模板被創建后，默認會創建一個ValueController，為了演示和獲取當前路由轉發的結果，我們只需要對其中一個接口稍作修改，設置默認啟動端口為5000。
而上游服務中，可以用HttpClient來模擬一個請求。
此處8080作為ApiGateway服務端，默認使用通用路由模板（上游和下游直接路由通用匹配{url}），代碼不再貼出。啟動8080網關和5000服務端，通過Console控制臺直接訪問8080所配置（映射）出來的公開地址（實際就是5000上的api/values），可看到如下的結果。
如需查看更多的demo示例和源碼，可參考筆者的源碼https://github.com/steveleeCN87/doteasy.rpc/tree/master/src/doteasy.rpc.demo
?
總結
Ocelot能實現的功能遠遠不止這些，更多內容可以參考Ocelot官方API或張隊的解說。
?
補個插曲
對了，關注DotEasy.Rpc小伙伴們，該框架已經更新到1.0.3，主要增加和修改了以下內容：
1.?接口注冊改用Autofac，實現統一批量接口注入，而非每次手動一個一個的去注入接口。
2.?通過代理生成，將原有的“兔子耳朵”取消，增加了客戶端非異步遠程調用方式，避免每次調用均實現Task非阻塞方式來實現接口調用。
3.?通過代理生成，調用端將自動釋放接口實例資源，也就是IDisposable接口的實現，而客戶端不用實現。
4.?通過代理生成，如服務節點中不存在網關服務（非微服務，而是直接的RPC調用），客戶端對服務端的訪問可使用Token進行身份驗證。
?
現在的客戶端代碼是越來越簡單，功能越來越豐富了：
下一步將研究和實現網關中http到rpc協議自動（或手動）轉換，也許會走彎路，喜歡的小伙伴請繼續關注，也將在下一篇介紹。
感謝閱讀！
相關文章：
微服務之:從零搭建ocelot網關和consul集群
IdentityServer4與ocelot實現認證與客戶端統一入口
定制Ocelot來滿足需求
AspNetCore中使用Ocelot之 IdentityServer4
Ocelot-基于.NET Core的開源網關實現
.NET Core微服務之基于Ocelot+IdentityServer實現統一驗證與授權
Swagger如何訪問Ocelot中帶權限驗證的API
Ocelot.JwtAuthorize：一個基于網關的Jwt驗證包
.NET Core微服務之基于Ocelot實現API網關服務
.NET Core微服務之基于Ocelot實現API網關服務（續）
.NET微服務體系結構中為什么使用Ocelot實現API網關
Ocelot簡易教程（一）之Ocelot是什么
Ocelot簡易教程（二）之快速開始1
Ocelot簡易教程（二）之快速開始2
Ocelot簡易教程（三）之主要特性及路由詳解
Ocelot簡易教程（四）之請求聚合以及服務發現
Ocelot簡易教程（五）之集成IdentityServer認證以及授權
Ocelot簡易教程（六）之重寫配置文件存儲方式并優化響應數據
Ocelot簡易教程（七）之配置文件數據庫存儲插件源碼解析
ASP.NET Core中Ocelot的使用：API網關的應用
ASP.NET Core中Ocelot的使用：基于Spring Cloud Netflix Eureka的動態路由
ASP.NET Core中Ocelot的使用：基于服務發現的負載均衡
【.NET Core項目實戰-統一認證平臺】第一章 功能及架構分析
定制Ocelot來滿足需求
【.NET Core項目實戰-統一認證平臺】第三章 網關篇-數據庫存儲配置（1）
【.NET Core項目實戰-統一認證平臺】第四章 網關篇-數據庫存儲配置（2）
【.NET Core項目實戰-統一認證平臺】第五章 網關篇-自定義緩存Redis
【.NET Core項目實戰-統一認證平臺】第六章 網關篇-自定義客戶端授權
【.NET Core項目實戰-統一認證平臺】第七章 網關篇-自定義客戶端限流
【.NET Core項目實戰-統一認證平臺】第八章 授權篇-IdentityServer4源碼分析
【.NET Core項目實戰-統一認證平臺】第九章 授權篇-使用Dapper持久化IdentityServer4
【.NET Core項目實戰-統一認證平臺】第十章 授權篇-客戶端授權
【.NET Core項目實戰-統一認證平臺】第十一章 授權篇-密碼授權模式
【.NET Core項目實戰-統一認證平臺】第十二章 授權篇-深入理解JWT生成及驗證流程
【.NET Core項目實戰-統一認證平臺】第十三章 授權篇-如何強制有效令牌過期
原文地址:
https://www.cnblogs.com/SteveLee/p/Ocelot_Api_http_and_https.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的.NET Core微服务之路：基于Ocelot的API网关实现--http/https协议篇的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 恭贺微软技术俱乐部苏州站正式成立
- 下一篇： 使用 WeihanLi.Npoi 操作