三、Ocelot请求聚合与负载均衡 _生活百科

【三、Ocelot请求聚合与负载均衡】上一篇文章介绍了在.Net Core中如何使用Ocelot：https://www.cnblogs.com/yangleiyu/p/16847439.html
本文介绍在ocelot的请求聚合与负载均衡配置。
一、请求聚合1、概念Ocelot可以定义多组路由，然后根据优先级对上游服务发出的请求进行不同的转发处理，每个路由转发都匹配唯一的一个下游服务API接口。但是有时候，上游服务想要获得来自两个API接口返回的结果。Ocelot允许我们在配置文件中声明聚合路由Aggregates，从而实现这样的效果
2、路由配置

文章插图
可以看到这里多加了一个Key属性。Aggregates跟Routes是同级的，而且也是一个数组，这代表着我们可以声明多个聚合路由，而在我们声明的这一组聚合路由中的属性RouteKeys ，它包含的元素就是我们真正需要响应的路由的Key属性值。
3、结果

文章插图

文章插图
4、注意事项仅支持GET方式
下游服务返回类型要求为application/json
返回内容类型为application/json ，不会返回404请求
此处必须返回Json，下游接口返回类型必须为IActionResult，如果返回String ，那么聚合返回的下游json就会是乱码（别问我怎么知道的，又踩坑了）
二、高级请求聚合自定义请求聚合，此处暂不过多说明，后续介绍
三、负载均衡我们全部的路由配置中都是一组路由配置一个下游服务地址，也就说明当上游服务请求一个Url，Ocelot就必定转发给某一个固定的下游服务，这样其实是不安全的，因为有可能某一个下游服务阻塞，甚至挂掉了，那就可能导致整个服务瘫痪了，这肯定是不行的。Ocelot能够通过可用的下游服务对每个路由进行负载平衡。我们来看看具体的路由配置

文章插图
LeadConnection负载均衡器算法共有4种：
LeastConnection 把新请求发送到现有请求最少的服务上
RoundRobin 轮询可用的服务并发送请求
NoLoadBalancer 不负载均衡，总是发往第一个可用的下游服务
CookieStickySessions 使用cookie关联所有相关的请求到制定的服务
注意：经测，官网上面说的时轮询可用的服务，但是测试发现并不是，不可用的会报错
四、配置{"GlobalConfiguration": {"BaseUrl": "http://192.168.50.118:8003/" //网关暴露的的地址。},"Routes": [{"UpstreamPathTemplate": "/QiantoonService/Oam", //上游Api请求路由规则"DownstreamPathTemplate": "/QiantoonService/Oam/Oam", //网关转发到下游路由规则"UpstreamHttpMethod": [ "Get" ], //上下游支持请求方法"DownstreamScheme": "http", //下游服务配置"DownstreamHostAndPorts": [{"Host": "192.168.50.118", //下游地址"Port": 8001 //下游端口号}],"Key": "Oam"},{"UpstreamPathTemplate": "/QiantoonService/SelfReg", //上游Api请求路由规则"DownstreamPathTemplate": "/QiantoonService/SelfReg/SelfReg", //网关转发到下游路由规则"UpstreamHttpMethod": [ "Get" ], //上下游支持请求方法"DownstreamScheme": "http", //下游服务配置"DownstreamHostAndPorts": [{"Host": "192.168.50.118", //下游地址"Port": 8002 //下游端口号},{"Host": "192.168.50.118", //下游地址"Port": 8004 //下游端口号}],"Key": "Reg","LoadBalancerOptions": { "Type": "RoundRobin" }}],"Aggregates": [{"RouteKeys": ["Oam","Reg"],"UpstreamPathTemplate": "/QiantoonService"}]}