Bumblebee微服务网关的部署和扩展
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配置这一块。
