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配置這一塊。