网关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：指定负载均衡算法，其实这里咱们还没有说到负载均衡，但如果不配置会报错，所以就提前配置上了；