.Net6 使用 Ocelot + Consul 看这篇就够了
前言
卯兔敲门,新的一年,祝大家前‘兔’似锦!希望大家假后还能找到公司的大门 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,感兴趣的同学欢迎继续关注!