网关Ocelot功能演示安排的明明白白~~~
转自博客:
存放个人github路径:https://github.com/xs0910/Ocelot.Samples
前言
网关(Gateway)在微服务架构中至关重要,可以将其理解为是外部客户端(前端、MVC后台等调用方)与后台服务的连接点,通过这层可以做统一的处理,比如路由、身份认证和授权、服务治理等;
网关的好处:
- 统一入口,调用方(客户端)不在为调哪个服务而头大,统一入口即可,由网关路由到对应后台服务;
- 统一处理公共逻辑,比如认证和授权,避免相同逻辑多处实现,易于维护;
- 对后台服务可以做负载均衡,根据指定的负载算法找到合适的后台服务调用,而这些细节调用方都不用理会,只管调就行啦;
- 初步过滤非法请求,可以根据配置的请求规则过滤掉非法请求;
- 屏蔽各服务真实地址,间接保证各服务的安全;
网关带来的问题:
- 在请求过程中,多增加了一层(网关)对请求进行处理,会消耗一些性能;
- 高并发场景,对网关性能要求高,需要开发人员要有足够的能力处理;
整体来看,在微服务架构中,网关带来的便捷和好处肯定大于自身带来的问题,所以不必纠结于此。
目前常用的网关有Kong、Tyk、Zuul、Ambassador、Ocelot等,而在.Net中比较火的是Ocelot和Kong,接下来就以Ocelot为主展开来聊聊。
正文
Ocelot是一个用.NET Core实现并且开源的API网关,它功能强大,除了路由、请求聚合、负载均衡等功能外,还可以集成Consul做服务发现,集成Polly做服务治理等; 相关功能只需简单的配置即可实现。接下来就把比较常用的功能依次举例演示一把,小伙伴们,搞起来~~~
0. 先把项目建好
整个演示中会使用到三个角色:网关层(端口为5000)、后台服务1(端口为8000)、后台服务2(端口为8001)。项目结构如下:
网关对应代码如下:
由于使用的是.NetCore3.1进行演示,则需要的Ocelot包版本最新为16.0.1,然后将对应服务和中间件进行注册;由于Ocelot是通过配置文件进行功能配置的,所以需要一个配置文件,并指定对应的路径;这里的ocelot.json(名字自定义就行)就放在根目录下,将文件属性改为始终复制或如果较新则复制,配置文件内容在下面会细说;这里网关层就完工啦;
两个后台服务接口基本上没动,只是将ServiceAPI1的端口改为8000,ServiceAPI2的端口改为8001;为了后续配置演示,分别新增了控制器,如下图:
1. 路由
路由是指网关根据原始请求,匹配对应的路由配置规则,将其转发到真正的后台服务接口;这是网关的核心功能。
1.1 配置初体验
通过配置,实现统一入口(网关),访问后台两个不同的服务接口,如下配置:
{ "Routes": [ { "UpstreamPathTemplate": "/OcelotTest1/{url}", "UpstreamHttpMethod": [ "Get"], "DownstreamPathTemplate": "/api/{url}", "DownstreamScheme": "http", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 8000 } ] }, { "UpstreamPathTemplate": "/OcelotTest2/{url}", "UpstreamHttpMethod": [ "Get"], "DownstreamPathTemplate": "/api/{url}", "DownstreamScheme": "http", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 8001 } ] } ] }
配置项解析:
- Routes:这是个数组,将所有请求处理都配置在里面,每一个请求处理是一个对象;
- UpstreamPathTemplate:上游请求路径模板;即对应调用方发出的请求,如不符合这个规则,就会被过滤掉;
- UpstreamHttpMethod:上游请求的方式,可以传递多个,比如["Get","Post"];
- DownstreamPathTemplate:下游请求的路径模板;对应真实API的请求地址,只有符合规则,才会正常转发到服务接口上;
- DownstreamScheme:指定下游是http还是https;
- DownstreamHostAndPorts:指定下游的Host和端口,这里可以写多个,多个时可以配置负载均衡;
将网关、后台服务接口1和后台服务接口2运行启动,访问如下:
如路由配置所示,可以用{参数}这种形式,通过上游请求模板传递给下游请求模板中;
1.2 设置匹配的优先级
当请求匹配到配置的多个路由规则时,会选择配置在最前面的路由规则进行转发,可能不是自己需要,如下:
遇到这种情况可以调整配置位置来满足需求,但明显不合理,Ocelot提供优先级(Priority)的配置,配置的值越大就越优先匹配,默认所有配置的路由优先级的值为0;如下配置可以满足需求:
在配置文件中可以配置万能模板,即所有请求都会匹配到该路由模板,但其优先级为最低,如果能匹配到其他模板,优先走其他路由,万能模板配置如下:
1.3 区分匹配路由大小写
默认情况下,匹配路由是不区分大小写的;其实在实际过程中我们通常也不需要区分;但在一些应用场景要求区分大小,那就可以增加"RouteIsCaseSensitive": true配置即可。
2. 路由聚合
路由聚合就是可以将多个一般的路由(上面配置的路由就是)聚合在一起,然后将多个路由响应的结果统一返回给调用方;如下配置
配置说明:
- 路由配置中增加了Key,给需要聚合的路由分别配置一个不重复的Key值;
- 在配置文件中增加Aggregates节点,这个节点和Routes节点是同级的;然后在里面的RouteKeys中配置需要聚合的路由Key,然后再配置一个上游模板路径,配置上游模板路径时同样可以传递参数,如上图所示;
运行结果:
其实在刚开始直接返回字符串时(通常都是是返回Json,只是这里演示遇到了不规范情况,刚好可以说说),返回的结果并不是真正的Json字符串,这样可能前端解析就会出问题,所以需要处理一下返回结果;
如果不处理,就会出现如下情况:
上图中在没处理之前,网关是直接将结果进行拼接,但最后整体不符合Json格式,JsonView就报错啦!!!
解决措施就是将字符串以Json的形式返回即可,简单的处理方式如下:
上面的聚合演示是默认情况,Ocelot提供自定义聚合器的功能(继承IDefinedAggregator接口),并注册相关服务,然后在配置文件指定自定义的聚合器即可,如下(具体细节请详见官网):
具体实现这里就不再演示了,好像自定义聚合器功能用的不太多,通常大家的做法是单独做一个后台聚合服务,若需要聚合数据,从聚合服务中获取即可;
3. 集成Consul做服务发现
如果还是通过配置文件一个一个的配置路由,是不是也太不给力啦,如果能和Consul结合,岂不是完美~~~
3.1 先把Consul集成到网关项目中
引入Ocelot.Provider.Consul,并在ConfigureServices中注册相关服务组件;
3.2 在配置文件中增加Consul相关配置;
配置文件说明:
-
GlobalConfiguration:全局配置,其实可以理解为所有路由共用的配置放在这;
-
ServiceDiscoveryProvider:服务发现的相关配置,Scheme代表用的是http还是https;Host代表的是Consul启动的主机;Port代表Consul启动的Http端口;Type这里使用的是Consul这种服务发现,可以指定其他服务发现框架;
-
BaseUrl:这个配置主要网关对外暴露的地址,也就是调用者使用的地址;
Routes中多了两个和一般路由不同的配置,如下:
-
ServiceName:指定服务名,这里是Consul注册服务时指定的服务名,根据这个名字内部可以获取到对应的Host和端口;所以有了ServiceName,就可以不用手动配置Host和端口啦;
-
LoadBalancerOptions:指定负载均衡算法,其实这里咱们还没有说到负载均衡,但如果不配置会报错,所以就提前配置上了;
3.3 启动Consul服务
将两个后台服务接口注册到Consul中;(过程就不细说啦,详细参考来,Consul 服务发现入个门(一看就会的那种)和运维小姐姐说这篇Consul集群和ACL配置超给力(保姆级)这两篇文章);这里用配置文件的方式,如下配置文件:
然后启动Consul即可,这里为了演示方便,直接就用开发者模式啦;
3.4 运行结果
3.5 动态路由
除了以上显示指定服务名之外,其实可以动态路由,如下配置运行:
Routes节点不需要配置任何路由;
4. 负载均衡
在高并发场景,后台服务是需要做集群部署的,而Ocelot可以在配置路由规则时,开启负载均衡功能,并指定对应的均衡算法,从而实现请求按算法转发到后台服务。
4.1 模拟集群环境
为了方便演示集群效果,这里将后台服务主机的端口打印出来,代码如下:
然后通过命令的方式,将ServiceAPI1后台服务启动多个,只是端口不一样而已;如下:
4.2 将启动起来的服务配置网关中
启动起来之后,将他们配置到路由中,如下:
配置解析:
- DownstreamHostAndPorts中配置多个启动的后台服务Host和端口;
- LoadBalancerOptions指定负载均衡算法,图中指定的是轮询,通常有以下几种:
- LeastConnection 把新请求转发到请求最少的后台服务上;
- RoundRobin 将请求轮询轮询转发都配置的后台服务上;
- NoLoadBalancer 不负载均衡;
- CookieStickySessions 使用cookie关联相关的请求到指定的服务;
4.3 网关运行起来看效果
4.4 搭配Consul一块用
首先进行修改Consul的配置文件,然后将其启动,见下图:
如上图所示,在相同服务名ServiceAPI1Name下面注册了两个服务,一个端口是8000,一个端口是8003;
然后在网关中修改一下配置,然后启动:
咦,到这发现篇幅略长啦,先暂停吧;另外Polly这个知识点之前没聊过,下期先补上,然后继续聊其他功能~~~
总结
本来想通过一篇文章把常用的功能点演示一下的,篇幅太长不太好(小伙伴有反应);下期会继续说Ocelot集成CacheManager做缓存、集成IdentityServer4做认证授权、集成Polly做服务治理。