前言
卯兔敲门，新的一年，祝大家前‘兔’似锦！希望大家假后还能找到公司的大门 O(∩_∩)O ！
书接上文，我们使用了 Consul实现了服务注册与发现，对Consul不熟悉的同学可以先看看。这篇文章我们来学习Ocelot网关，在这之前我们首先得需要知道“什么是API网关?”,“为什么要选择Ocelot？”以及“如何将Consul与Ocelot结合起来”等等，同样这些知识点网上的文章也介绍得比较详细了，我这里也只做简单的介绍，然后本文只是个人学习与分享，不喜勿喷，谢谢。
什么是API网关?
API网关是系统暴露在外部的一个访问入口。就像一个公司的门卫承担着寻址、限制进入、安全检查、位置引导、等等功能。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理等等。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
Ocelot 介绍
Ocelot的开源地址：GitHub - ThreeMammals/Ocelot: .NET core API Gateway
Ocelot是一个用.NET Core实现并且开源的API网关，它功能强大，包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与Service Fabric、Butterfly Tracing集成。而且这些功能都只需要简单的配置即可完成。
Ocelot工作流程
实际上Ocelot就是一系列按特定顺序排列的中间件。
Ocelot首先通过配置将HttpRequest对象保存到一个指定的状态直到它到达用来创建HttpRequestMessage对象并将创建的HttpRequestMessage对象发送到下游服务中的请求构造中间件。通过中间件来发出请求是Ocelot管道中做的最后一件事。它不会再调用下一个中间件。下游服务的响应会存储在每个请求 scoped repository中，并作为一个请求返回到Ocelot管道中。有一个中间件将HttpResponseMessage映射到HttpResponse对象并返回给客户端。
基本集成
想要了解更多信息请移步官网 Big Picture — Ocelot 1.0.0 documentation
环境准备
.Net 6
Docker desktop
Visual Studio 2022
GitHub - fengzhonghao8-24/ConsulIntroduction
项目配置
在我们之前的Consul示例项目中新增一个WebApi项目Gateway
添加Ocelot的NuGet包
在Program.cs 文件中将Ocelot进行IOC注入，并替换我们原有的管道模型
增加Ocelot配置文件
这里配置分为两个部分。一组Routes和一个GlobalConfiguration。Routes是告诉 Ocelot 如何处理上游请求的对象。GlobalConfiguration全局配置，允许覆盖特定于路由的设置。如果您不想管理大量特定于路线的设置，这将很有用。
- DownstreamPathTemplate：下游服务转发地址模板
- DownstreamScheme：下游服务http schema
- DownstreamHostAndPorts：下游服务的地址，一般只会包含一个条目，如果想希望对下游服务的请求进行负载的话这里可以填多项，同时选择一个负载均衡器 LoadBalancerOptions
- UpstreamPathTemplate: 上游也就是用户输入的请求Url模板
- UpstreamHttpMethod: 上游请求http方法，可使用数组
Program增加应用文件配置
Ocelot 支持在更改时重新加载 json 配置文件。
builder.Configuration.AddJsonFile("ocelot.json", optional: false, reloadOnChange: true);
然后通过Gateway项目来访问我们上篇文章配置好的服务ServiceA
OK，成功访问，最基础的配置就这么简单。
然后还有一些常用的配置
路由
万能模板
此模板的优先级低于任何其他 Route。如果你的配置中也有下面的 Route，那么 Ocelot 会在 catch all 之前匹配它。
{
"DownstreamPathTemplate":"/{url}",
"DownstreamScheme":"https",
"DownstreamHostAndPorts":[
{
"Host":"localhost",
"Port":80,
}
],
"UpstreamPathTemplate":"/{url}",
"UpstreamHttpMethod":["Get"]
}
Prioirty优先级
可以通过在 ocelot.json 中包含“优先级”属性来定义您希望路由与上游 HttpRequest 匹配的顺序
{
"Priority": 0
}
0 是最低优先级，Ocelot 始终将 0 用于 /{catchAll} 路由，硬编码设置
路由负载均衡
当下游服务有多个节点的时候，我们可以在DownstreamHostAndPorts中进行配置。
LoadBalancerOptions将决定负载均衡的算法
- LeastConnection – 将请求发往最空闲的那个服务器
- RoundRobin – 轮流发送
- NoLoadBalance – 总是发往第一个请求或者是服务发现
当然这里只是作为示例演示，都只是硬编码模式，实际情况我们需要动态的管理服务实例，所以最终会结合Consul来进行使用。
自定义负载均衡策略
当然也可以自定义负载均衡策略，实现ILoadBalancer接口然后根据抽象出来的下游节点信息 Service来做自定义操作即可
这里不做多概述，感兴趣的同学可以参考源码自行实现。
其他
当然Ocelot还支持很多其他功能，感兴趣的同学可以移步官网Big Picture — Ocelot 1.0.0 documentation
Consul + Ocelot
为什么要将Consul与Ocelot结合使用？
在Ocelot已经支持简单的负载功能，也就是当下游服务存在多个结点的时候，Ocelot能够承担起负载均衡的作用。但是它不提供健康检查，服务的注册也只能通过手动在配置文件里面添加完成。这不够灵活并且在一定程度下会有风险。这个时候我们就可以用Consul来做服务发现，它能与Ocelot完美结合。
添加Consul配置
在我们 Geteway 项目中安装 Ocelot.Provider.Consul Nuget包，然后在 Program.c 中增加IOC配置
然后在ocelot.json文件中增加配置
- UseServiceDiscovery：true – 使用服务发现
- ServiceDiscoveryProvider – 服务发现的配置
- LoadBalancerOptions – 负载方式
- ServiceName – 注册到Consul的服务名称
如果Consul有集群的话，ServiceDiscoveryProvider 这里可以使用 例如 Nginx 地址来做配置。
检查Consul
检查Consul服务注册情况，这里我们就只为 ServiceA 启动了两个服务节点，方便测试负载。
启动项目
第一次访问 - 端口5050
第二次访问 - 端口5051 
到这里，我们就差不多大功告成了。
然后这里可能会遇到一些端口问题，导致通过网关访问不到服务，这里不清楚的同学可以去了解下Docker的网络模式，这里就不做多概述。
结尾
本文只是简单的介绍了Ocelot的使用以及怎么与Consul结合，后面还会继续学习网关对接JWT或者IdentityServer4，然后还有Polly，感兴趣的同学欢迎继续关注！