本系列相關文章：

• 《ASP.NET Core中Ocelot的使用：API網關的應用》

• 《ASP.NET Core中Ocelot的使用：基于Spring Clound Netflix Eureka的動態路由》

本文將基于前兩篇文章所述內容，繼續介紹如何在服務發現和動態路由的基礎上，使用Ocelot實現負載均衡。Ocelot本身是帶有負載均衡功能的，這一點其實跟Nginx提供的HTTP load balancer是類似的功能（我覺得整個Ocelot提供的功能，通過Nginx也都可以實現，不過Ocelot更加.NET化，對于.NET開發人員來說更為簡單和容易接受）。根據官方文檔，Ocelot支持如下幾種負載均衡策略：

• LeastConnection：根據服務當前正在處理的請求個數來決定將使用哪個服務來處理新接收到的請求，將請求轉發給當前連接數最少的服務

• RoundRobin：經典模式，輪詢法，逐個選擇可用的服務來處理接收到的請求

• NoLoadBalancer：僅使用第一個可用的服務來處理接收到的請求

• CookieStickySessions：通過使用Cookie，確保特定的請求能夠被分配到特定的服務上進行處理

今天我們選擇RoundRobin來看看如何基于服務發現來實現負載均衡。同樣，首先需要對架構進行調整。

調整架構

與上文中的架構相比，這里不會引入新的服務，而相比之下會讓兩個A服務的實例同時運行。調整后的架構如下圖所示：

整個API的調用過程如下：

A服務的兩個實例、B服務以及API網關在啟動的時候均向Spring Cloud Eureka注冊自己

API用戶通過訪問Eureka獲得API網關的地址

API用戶使用獲得的API網關地址，發送一個查詢A服務的請求

API網關根據指定的A服務的名稱，從Eureka查詢A服務所注冊的服務實例

API網關根據設定的負載均衡策略，向找到的服務實例發出請求，并將調用結果反饋給API用戶

可以看到，前面部分的調用過程與上文所述都是非常類似的，不同的僅有API網關在尋找A服務的實例這個部分，前面是直接獲得訪問地址，而此處則通過負載均衡來選擇一個地址。接下來，我們看看如何改變我們的代碼，來實現這個架構。

代碼修改

這里的代碼修改會基于上文結尾時的代碼，也就是實現了Ocelot的動態路由。首先，我們在計算服務（也就是A服務）中增加一個API，用以返回當前設置在主機上的machineName環境變量（如果設置為空，那么就直接返回主機機器名）：

12345678910

[Route("api/[controller]")][ApiController]public class ValuesController : ControllerBase{????[HttpGet("info")]????public ActionResult<string> Info()????????=> Environment.GetEnvironmentVariable("machineName") ?? Environment.MachineName;????// 其它代碼省略}

然后，就是配置Ocelot，使其能夠實現負載均衡：

1234567891011121314151617181920

{??"ReRoutes": [??],??"GlobalConfiguration": {????"RequestIdKey": "OcRequestId",????"AdministrationPath": "/administration",????"ServiceDiscoveryProvider": {??????"Host": "localhost",??????"Port": 8761,??????"Type": "Eureka",??????"Token": null,??????"ConfigurationKey": null????},????"LoadBalancerOptions": {??????"Type": "RoundRobin"????},????"DownstreamScheme": "http"??}}

只需注意上面的LoadBalancerOptions部分，這里我們采用了RoundRobin模式，這個配置文件的其它部分都與之前的一樣，沒有區別。

好了，代碼改好了。什么？就改好了？對的，就是這么簡單！接下來讓我們測試一下。先在Eclipse里啟動Spring Cloud Eureka：

然后，進入CalcService的編譯輸出目錄，首先設置machineName環境變量，然后用下面的命令啟動服務：

用同樣的命令再啟動另一個CalcService的實例：

OK，兩個CalcService的實例已經啟動，分別偵聽49814和49815兩個端口，接下來，啟動我們的Ocelot API網關。等Ocelot API網關啟動之后，查看Eureka的服務注冊，可以看到所有的服務已經就緒：

請注意，對于CALC這個應用程序，我們可以看到，有兩個實例已經注冊成功。然后，我們通過訪問API網關進而訪問剛剛新加的Info API，可以看到，服務調用成功。然后按F5刷新，可見返回的結果會在CalcService-1與CalcService-2之間來回切換，也就意味著我們的請求被依次分配到兩個不同的Calc服務的實例上執行。動圖為證：

由此可見，我們已經實現了基于Ocelot API網關的負載均衡。當然，我們可以繼續修改ASP.NET Core MVC的前端頁面，讓它能夠直觀地顯示這個效果。這里也就不貼代碼了，大家可以按本文后面的源代碼鏈接下載源碼，自己研究。

解決方案容器化

同樣，我們可以把整個解決方案容器化，與上一篇文章所述的容器化有區別的一點是，對于CalcService的Dockerfile，我們要擴充它的EXPOSE的端口范圍，原來是寫死的49814，現在讓它能夠曝露從49800到49899的所有端口，以便新的服務可以通過不同的端口接收請求。此外，還需要在docker-compose.yml中增加另一個Calc服務的配置，詳細可以仿照docker-compose.yml中已有的服務配置信息，這里也不多啰嗦了，源代碼庫中有完整的內容供參考。

完成這些配置之后，可以直接用docker-compose一次性啟動所有服務，然后看看我們的API頁面，其中的“計算服務名稱”會隨著頁面的刷新動態改變：

總結

本文對前文的案例做了一些簡單的調整，實現了基于Ocelot API網關的負載均衡。其實，負載均衡還可以實現在某個微服務的多個實例的層面，然后將這個層面的負載均衡器地址注冊到Eureka上，也是可以的。這樣的架構能夠更好地控制每個服務的伸縮，并對其進行監控。接下來的文章中，我會繼續嘗試基于微服務的一些部署拓撲，以及在云中如何運行我們的微服務架構。

源代碼的使用

請訪問https://github.com/daxnet/ocelot-sample/releases/tag/chapter_3下載本文相關案例的源代碼。

相關文章：

• 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的動態路由

原文地址:?http://sunnycoding.cn/2018/11/06/aspnetcore-ocelot-service-discovery-load-balancing/

---

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

總結

以上是生活随笔為你收集整理的ASP.NET Core中Ocelot的使用：基于服务发现的负载均衡的全部內容，希望文章能夠幫你解決所遇到的問題。

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