前言
网关(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 配置初体验
通过配置，实现统一入口(网关)，访问后台两个不同的服务接口，如下配置：
<pre spellcheck="false" class="md-fences md-end-block md-fences-with-lineno ty-contain-cm modeLoaded" lang="bash" cid="n141" mdtype="fences" style="box-sizing: border-box; overflow: visible; font-family: var(--monospace); font-size: 0.9em; display: block; break-inside: avoid; text-align: left; white-space: normal; background-image: inherit; background-position: inherit; background-size: inherit; background-repeat: inherit; background-attachment: inherit; background-origin: inherit; background-clip: inherit; background-color: rgb(248, 248, 248); position: relative !important; border: 1px solid rgb(231, 234, 237); border-radius: 3px; padding: 8px 4px 6px 0px; margin-bottom: 15px; margin-top: 15px; width: inherit; color: rgb(51, 51, 51); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;"> {
"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
}
]
}
]
}</pre>
配置项解析：
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做服务治理。
一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一起学~~~
