网关Ocelot功能演示安排的明明白白~~~

前言

网关(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. 路由聚合

路由聚合就是可以将多个一般的路由(上面配置的路由就是)聚合在一起,然后将多个路由响应的结果统一返回给调用方;如下配置

image-20210402123033237

配置说明:

  • 路由配置中增加了Key,给需要聚合的路由分别配置一个不重复的Key值;
  • 在配置文件中增加Aggregates节点,这个节点和Routes节点是同级的;然后在里面的RouteKeys中配置需要聚合的路由Key,然后再配置一个上游模板路径,配置上游模板路径时同样可以传递参数,如上图所示;

运行结果:

image-20210402123819897

其实在刚开始直接返回字符串时(通常都是是返回Json,只是这里演示遇到了不规范情况,刚好可以说说),返回的结果并不是真正的Json字符串,这样可能前端解析就会出问题,所以需要处理一下返回结果;

如果不处理,就会出现如下情况:

返回结果不对

上图中在没处理之前,网关是直接将结果进行拼接,但最后整体不符合Json格式,JsonView就报错啦!!!

解决措施就是将字符串以Json的形式返回即可,简单的处理方式如下:

优化之后

上面的聚合演示是默认情况,Ocelot提供自定义聚合器的功能(继承IDefinedAggregator接口),并注册相关服务,然后在配置文件指定自定义的聚合器即可,如下(具体细节请详见官网):

image-20210402124814838

具体实现这里就不再演示了,好像自定义聚合器功能用的不太多,通常大家的做法是单独做一个后台聚合服务,若需要聚合数据,从聚合服务中获取即可;

3. 集成Consul做服务发现

如果还是通过配置文件一个一个的配置路由,是不是也太不给力啦,如果能和Consul结合,岂不是完美~~~

3.1 先把Consul集成到网关项目中

引入Ocelot.Provider.Consul,并在ConfigureServices中注册相关服务组件;

image-20210402134110433
3.2 在配置文件中增加Consul相关配置;
image-20210402223213939

配置文件说明:

  • 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配置超给力(保姆级)这两篇文章);这里用配置文件的方式,如下配置文件:

image-20210402221640328

然后启动Consul即可,这里为了演示方便,直接就用开发者模式啦;

3.4 运行结果
image-20210402222950495
3.5 动态路由

除了以上显示指定服务名之外,其实可以动态路由,如下配置运行:

image-20210402225019606

Routes节点不需要配置任何路由;

4. 负载均衡

在高并发场景,后台服务是需要做集群部署的,而Ocelot可以在配置路由规则时,开启负载均衡功能,并指定对应的均衡算法,从而实现请求按算法转发到后台服务。

4.1 模拟集群环境

为了方便演示集群效果,这里将后台服务主机的端口打印出来,代码如下:

image-20210403002543495

然后通过命令的方式,将ServiceAPI1后台服务启动多个,只是端口不一样而已;如下:

image-20210403221010139
4.2 将启动起来的服务配置网关中

启动起来之后,将他们配置到路由中,如下:

image-20210403204553359

配置解析:

  • DownstreamHostAndPorts中配置多个启动的后台服务Host和端口;
  • LoadBalancerOptions指定负载均衡算法,图中指定的是轮询,通常有以下几种:
  • LeastConnection 把新请求转发到请求最少的后台服务上;
  • RoundRobin 将请求轮询轮询转发都配置的后台服务上;
  • NoLoadBalancer 不负载均衡;
  • CookieStickySessions 使用cookie关联相关的请求到指定的服务;
4.3 网关运行起来看效果
image-20210403220600727
4.4 搭配Consul一块用

首先进行修改Consul的配置文件,然后将其启动,见下图:

image-20210403221739328

如上图所示,在相同服务名ServiceAPI1Name下面注册了两个服务,一个端口是8000,一个端口是8003;

然后在网关中修改一下配置,然后启动:

负载均衡

咦,到这发现篇幅略长啦,先暂停吧;另外Polly这个知识点之前没聊过,下期先补上,然后继续聊其他功能~~~~~

项目地址:https://github.com/zyq025/IDS4Demo/tree/main/OcelotDemo/OcelotCodeDemo

 

本篇文章来源于微信公众号: dotNET跨平台

标签:   |  
时间: 2021年04月12日下午17:46  |  
作者:
LEAVE A REPLY

loading