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

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

配置说明：

• 路由配置中增加了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；

然后在网关中修改一下配置，然后启动：