.Net6 使用 Ocelot + Consul 看这篇就够了

2023-01-31 00:00:00 网关 请求 服务 配置 下游

前言

卯兔敲门,新的一年,祝大家前‘兔’似锦!希望大家假后还能找到公司的大门 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 FabricButterfly 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 是低优先级,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,感兴趣的同学欢迎继续关注!

代码仓库地址

https://github.com/fengzhonghao8-24/Consul.Ocelot

相关文章