标签:ref issues 疑问 -o 直接 踩坑 节点 start type
历史原因,笔者所在公司的项目目前还在使用 .NET CORE 2.2版本,在所有业务应用升级完成服务注册发现之后,最后剩下 Ocelot 网关服务升级。在升级过程中,遇到一些问题,记录此文,以便有相同情况的同学参考。
根据官方文档 ,通过简单的添加配置,既可以将原有配置方式改为服务发现:
安装插件
Install-Package Ocelot.Provider.Consul 13.5.2,.Net Core 2.x 最后一个版本
配置服务
s.AddOcelot()
.AddConsul();
"ServiceDiscoveryProvider": {
"Host": "localhost",
"Port": 8500,
"Type": "Consul"
}
{
"DownstreamPathTemplate": "/api/values}",
"DownstreamScheme": "https",
"UpstreamPathTemplate": "/spider/api/values",
"UpstreamHttpMethod": [ "Get" ],
"ServiceName": "spider",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
}
简单的几个步骤,Ocelot 升级完成,然而经过测试,却发现 Ocelot 并没有向我们预期那样,路由到后端的服务,而是报如下错误:
刚开始以为是配置问题,直到将日志级别调至 Debug,查看更加详细的日志才发现,下游请求的 URL 拼接有问题。
具体来说,就是 Ocelot 采用了 Consul 服务节点的 Node Name,而不是节点上对应的该服务的 IP 地址。
既然问题定位到,那么翻阅源码应该可以找到原因,首先根据 nuget 包信息导航到 https://github.com/ThreeMammals/Ocelot.Provider.Consul 地址查看 Provider 源码,经过加载调试,发现居然是正常的,但是有个疑问是,这个源码仓库中只有最早期的几个版本tag,后续版本都没有,经过查找,原来后续版本均已合并到 Ocelot 主库中,而 Nuget 包中的项目URL 并未更新,汗!
既然问题跟版本有关,就翻阅了一下 Issue 列表,还真找到了问题,而且看问题下面的讨论,踩坑的人应该不少。具体原因请直接参看以下链接:
https://github.com/ThreeMammals/Ocelot/issues/954
.NET CORE2.2 下 Ocelot+Consul服务发现踩坑记录
标签:ref issues 疑问 -o 直接 踩坑 节点 start type
原文地址:https://www.cnblogs.com/xboo/p/12659842.html