Error message here!

Hide Error message here!

忘记密码?

Error message here!

请输入正确邮箱

Hide Error message here!

密码丢失?请输入您的电子邮件地址。您将收到一个重设密码链接。

Error message here!

返回登录

Close

Bumblebee微服务网关的部署和扩展

smark 2019-02-22 10:47:00 阅读数:215 评论数:0 点赞数:0 收藏数:0

Bumblebee

.netcore下开源基于[BeetleX.FastHttpApi](https://github.com/IKende/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 classNotFountFilter : Filters.IRequestFilter {public string Name => "NotFountFilter";public void Executed(Gateway gateway, HttpRequest request, HttpResponse response, ServerAgent server, int code, longuseTime) { }public boolExecuting(Gateway gateway, HttpRequest request, HttpResponse response) { gateway.Response(response,new NotFoundResult("test"));return false; } }

添加Filter到网关,并设置到

/*上.

g.AddFilter(); 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 500connection(s)1000000 / 1000000 [===============================================] 100.00%9s Done!Statistics Avg Stdev Max Reqs/sec 104050.45 15852.09 133791.97Latency4.80ms 10.35ms 3.06s HTTP codes: 1xx- 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0others- 0Throughput: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.02Latency4.73ms 1.45ms 337.02ms HTTP codes: 1xx- 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0others- 0Throughput: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 500connection(s)1000000 / 1000000 [==============================================] 100.00%14s Done!Statistics Avg Stdev Max Reqs/sec 69943.34 8672.45 91544.97Latency7.02ms 2.75ms 641.04ms HTTP codes: 1xx- 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0others- 0Throughput: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 0connection(s)1000000 / 1000000 [==============================================] 100.00%12s Done!Statistics Avg Stdev Max Reqs/sec 78498.29 15013.95 101544.42Latency6.22ms 5.33ms 689.04ms HTTP codes: 1xx- 0, 2xx - 1000000, 3xx - 0, 4xx - 0, 5xx - 0others- 0Throughput:260.52MB/s D:>

其他问题

  • 组件是否稳定?
    只能说在测试范围内稳定性和性能都比较出色,是否存在bug这个就不好说,只能等待发现解决……
  • 组件优势
    组件最大的特点是简单和基本C/#开发,扩展起来比较方便 
  • 为什么基于Beetlex.FastHttpApi扩展,而不是KestrelHttpServer
    主要原因Beetlex.FastHttpApi也是由基础开发,整体控制性和扩展性要对我来说比较方便 ,Beetlex.FastHttpApi同样也有着出色的性能指标。
  • 需要注意的地方
    由于Http部分是Beetlex.FastHttpApi,所以在一些特别的场需了解Beetlex.FastHttpApi的一些基础参数配置,主要是buffer配置这一块。
版权声明
本文为[smark]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/smark/p/10416971.html

编程之旅,人生之路,不止于编程,还有诗和远方。
阅代码原理,看框架知识,学企业实践;
赏诗词,读日记,踏人生之路,观世界之行;

支付宝红包,每日可领