• 网关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;

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

    image-20210403222306562

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

    总结

    本来想通过一篇文章把常用的功能点演示一下的,篇幅太长不太好(小伙伴有反应);下期会继续说Ocelot集成CacheManager做缓存、集成IdentityServer4做认证授权、集成Polly做服务治理。

    一个被程序搞丑的帅小伙,关注"Code综艺圈",跟我一起学~~~

    图片

  • 相关阅读:
    Python老男孩 day09
    mount 挂载usb
    解压以及压缩命令
    flask 安装
    寻找文件 的小栗子
    Linux 环境变量与文件查找
    vim 查找和替换
    vim 基本功能 删除 移动 复制 粘贴
    selenium python 处理alter
    selenium python 显式和隐式等待方法
  • 原文地址:https://www.cnblogs.com/zoe-zyq/p/14620174.html
Copyright © 2020-2023  润新知