Bumblebee是.netcore下開源基於BeetleX.FastHttpApi擴充套件的HTTP微服務閘道器元件，它的主要作用是針對WebAPI叢集服務作一個集中的轉發和管理；作為應用閘道器它提供了應用服務負載，故障遷移，安全控制，監控跟蹤和日誌處理等。它最大的一個特點是基於C#開發，你可以針對自己業務的需要對它進行擴充套件具體的業務功能。
元件部署
元件的部署一般根據自己的需要進行引用擴充套件功能，如果你只需要簡單的應用服務負載、故障遷移和恢復等功能只需要下載Bumblebee.ConsoleServer編譯部署即可（暫沒提供編譯好的版本）。Bumblebee.ConsoleServer提供兩個配置檔案描述'HttpConfig.json'和'Gateway.json'分別用於配置HTTP服務和閘道器對應的負載策略。
可執行在什麼系統
任何執行.net core 2.1或更高版本的作業系統(liinux,windows等)
HTTP配置
'HttpConfig.json'是用於配置閘道器的HTTP服務資訊，主要包括服務端，HTTPs和可處理的最大連線數等。
{ "HttpConfig": { "Host": "", //服務繫結的地址，不指定的情況預設繫結所有IPAddress.Any "Port": 9090, //閘道器對外服務埠 "SSL": false, //是否開啟HTTPs服務，如果開啟預設繫結443埠 "CertificateFile": "", //證書檔案 "CertificatePassword": ", //證書密碼 "UseIPv6":true //是否開啟ipv6 } }
閘道器策略配置
'Gateway.json'主要用於配置負載的服務資訊，主要包括負載的服務應用 和負載策略等
{ "Servers": [ //需要負載的服務應列表 { "Uri": "http://192.168.2.19:9090/", //服務地址，可指定域名 "MaxConnections": 1000 //指向服務的最大連線數 }, { "Uri": "http://192.168.2.25:9090/", "MaxConnections": 1000 } ], "Urls": [ //負載的Url策略 { "Url": "*", //*是優先順序最低的匹配策略，優先順序採用長正則匹配 "HashPattern": null, //一致負載描述，不配置的情況採用權重描述 "Servers": [ //對應Url負載的服務應 { "Url": "http://192.168.2.19:9090/", //服務地址，可指定域名 "Weight": 10 //對應的權重，區間在0-10之前，0一般情況不參與負載，只有當其他服務不可用的情況才加入 }, { "Url": "http://192.168.2.25:9090/", "Weight": 5 } ] } ] }
HashPattern
如果需要一致性負載的時候需要設定，可以通過獲到Url,Header,QueryString等值作為一致性負載值。設定方式如下：
[host|url|baseurl|(h:name)|(q:name)]
可以根據實際情況選擇其中一種方式
-
Host 使用Header的Host作為一致性轉發
-
url 使用整個Url作為一致性轉發
-
baseurl 使用整個BaseUrl作為一致性轉發
-
h:name 使用某個Header值作為一致性轉發
-
q:name 使用某個QueryString值作為一致性轉發
應用擴充套件
Bumblebee只是一件元件，最終肯定需要針對業務需求來擴充套件它來實現相關功能；在講解之前先看一下元件執行代理負載的流程圖：
元件提供三個事件和一組過慮器來實現功能擴充套件，通過事件和過慮器可以對請求進行驗證，攔截，日誌記錄和監控處理等功能。以下簡單地預覽一下這三個事件的實現
g.Requesting += (o, e) => { Console.WriteLine("Requesting"); Console.WriteLine($" Request url ${e.Request.BaseUrl}"); //e.Cancel = true; }; g.AgentRequesting += (o, e) => { Console.WriteLine("agent requesting:"); Console.WriteLine($" Request url ${e.Request.BaseUrl}"); Console.WriteLine($" url route {e.UrlRoute}"); Console.WriteLine($" agent server {e.Server.Uri}"); //e.Cancel = true; }; g.Requested += (o, e) => { Console.WriteLine("Requested"); Console.WriteLine($" Request url ${e.Request.BaseUrl}"); Console.WriteLine($" url route {e.UrlRoute}"); Console.WriteLine($" agent server {e.Server.Uri}"); Console.WriteLine($" response code {e.Code} use time {e.Time}ms"); };
如何驗證請求
對於微服務閘道器來說，統一控制使用者請求的有效性是重要的功能；雖然元件沒有整合這些策略配置，不過可以通過制定元件的事件或IRequestFilter來實現控制。
Requesting事件
Requesting是閘道器元件接受請求後觸發的事件，通過這個事件可以對來源的一些請求資訊進行驗證，並決定是否繼續轉發下去；定義事件程式碼如下:
g.Requesting += (o, e) => { //e.Request //e.Response e.Gateway.Response(e.Response, new NotFoundResult("test")); e.Cancel = true; };
通過設定e.Cancel屬性來確定是否轉發來源的請求。
IRequestFilter
IRequestFilter是元件針對相應Url請求處理的過慮器，可以實現這一介面對某些請求的Url進行控制處理。介面實現方式大致如下：
public class NotFountFilter : Filters.IRequestFilter { public string Name => "NotFountFilter"; public void Executed(Gateway gateway, HttpRequest request, HttpResponse response, ServerAgent server, int code, long useTime) { } public bool Executing(Gateway gateway, HttpRequest request, HttpResponse response) { gateway.Response(response, new NotFoundResult("test")); return false; } }
新增Filter到閘道器，並設定到*上.
g.AddFilter<NotFountFilter>(); g.Routes.GetRoute("*").SetFilter("NotFountFilter");
斷熔擴充套件
同樣元件並不提供服務斷熔的處理，但通過擴充套件的確可以輕鬆地完成這個工作。首先可以在Requested事件統計完成的情況，參考指標可以是，url資訊，5xx狀態、加響應延時等進行一個連續計數並生成斷熔策略，通過這些策略資料就可以在Requesting或IRequestFilter對相應的請求進行控制。大概的擴充套件流程如下:
監控統計
由於閘道器需要處理大量的請求轉和規則處理，所以元件預設並沒有提供詳細的監控和日誌功能，不過元件同樣提供事件方式來制定這些資料的記錄。使用者可能通過事件把資料記錄到自有的系統中進行分析統計，這些資料主要包括：Header,Cookie,QueryString,http請求的狀態和處理損耗的時間.事件定義如下:
g.Requested += (o, e) => { //e.Request 請求資訊 //e.Response 響應資訊 //e.Code Http狀態 //e.Time 執行完成時間，單位毫秒 //e.Server 接收請求的服務 };
以下是針元件資料收集的一些統計擴充套件例項.
效能測試
作為閘道器，效能和可靠性比較重要，畢竟它是服務之首；以下是針對Bumblebee作為代理閘道器的測試，主要測試不同資料情況下的效能指標。測試配置描述
- 閘道器伺服器:e3-1230v2,部署Bumblebee
- webapi伺服器:e5-2676v2,部署webapi
- 測試伺服器:e5-2676v2,測試工具bombardier
- 測試頻寬環境:10Gb
plaintext
D:\>bombardier.exe -c 500 -n 1000000 http://192.168.2.18:9090/home/plaintext Bombarding http://192.168.2.18:9090/home/plaintext with 1000000 request(s) using 500 connection(s) 1000000 / 1000000 [===============================================] 100.00% 9s Done! Statistics Avg Stdev Max Reqs/sec 104050.45 15852.09 133791.97 Latency 4.80ms 10.35ms 3.06s HTTP codes: 1xx - 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0 others - 0 Throughput: 19.15MB/s
json
D:\>bombardier.exe -c 500 -n 1000000 http://192.168.2.18:9090/home/json Bombarding http://192.168.2.18:9090/home/json with 1000000 request(s) using 500 connection(s) 1000000 / 1000000 [===============================================] 100.00% 9s Done! Statistics Avg Stdev Max Reqs/sec 105541.22 9336.18 126993.02 Latency 4.73ms 1.45ms 337.02ms HTTP codes: 1xx - 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0 others - 0 Throughput: 20.90MB/s
employees
D:\>bombardier.exe -c 500 -n 1000000 http://192.168.2.18:9090/home/employees Bombarding http://192.168.2.18:9090/home/employees with 1000000 request(s) using 500 connection(s) 1000000 / 1000000 [==============================================] 100.00% 14s Done! Statistics Avg Stdev Max Reqs/sec 69943.34 8672.45 91544.97 Latency 7.02ms 2.75ms 641.04ms HTTP codes: 1xx - 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0 others - 0 Throughput: 361.74MB/s
orders
D:\>bombardier.exe -c 500 -n 1000000 http://192.168.2.18:9090/home/orders Bombarding http://192.168.2.18:9090/home/orders with 1000000 request(s) using 50 0 connection(s) 1000000 / 1000000 [==============================================] 100.00% 12s Done! Statistics Avg Stdev Max Reqs/sec 78498.29 15013.95 101544.42 Latency 6.22ms 5.33ms 689.04ms HTTP codes: 1xx - 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0 others - 0 Throughput: 260.52MB/s D:\>
其他問題
- 元件是否穩定？
只能說在測試範圍內穩定性和效能都比較出色，是否存在bug這個就不好說，只能等待發現解決…… - 元件優勢
元件最大的特點是簡單和基本C#開發，擴充套件起來比較方便 - 為什麼基於Beetlex.FastHttpApi擴充套件，而不是KestrelHttpServer
主要原因Beetlex.FastHttpApi也是由基礎開發，整體控制性和擴充套件性要對我來說比較方便 ，Beetlex.FastHttpApi同樣也有著出色的效能指標。 - 需要注意的地方
由於Http部分是Beetlex.FastHttpApi，所以在一些特別的場需瞭解Beetlex.FastHttpApi的一些基礎引數配置，主要是buffer配置這一塊。