.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 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 是低优先级，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

相关文章