Kong网关初探

2024-03-07 00:32
文章标签 初探 网关 kong

本文主要是介绍Kong网关初探,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

安装

Kong安装文档

Kong开源版不提供dashboard支持,只有Kong企业版才有该功能。但有第三方控制台Konga同样可以友好地管理Kong Admin API对象,快速安装如下:

docker run -d -p 1337:1337  \
--name konga  \
--network=kong-net \
-e DB_ADAPTER=postgres   \
-e DB_HOST=kong-database  \
-e DB_PORT=5432  \
-e DB_USER=kong  \
-e DB_PASSWORD=kong  \
-e DB_DATABASE=konga  \
pantsel/konga

使用

需求定位是通过网关不仅实现API网关功能,也要能够替代原先Nginx。因此需要的主要功能如下:

  • 服务负载均衡
  • 负载节点健康检查
  • 静态资源访问
  • 调用方认证、路由鉴权
  • 限流、IP黑白名单
  • 灰度发布
  • 监控

Kong网关的主要概念有route、service、upstream、target,其逻辑关系见下图:

在这里插入图片描述

负载均衡

当前的负载均衡逻辑为Nginx做负载均衡,服务发版时通过动态模板解析实现:Jenkins自动化脚本修改Nginx的upstream文件实现。例如对某服务的a、b两节点发版时具体逻辑如下:

  1. 先修改Nginx的upstream脚本摘除该服务的a节点
  2. 等待a节点无流量请求后发布重启a节点的新版本
  3. 最后再修改Nginx的upstream脚本重新添加a节点
  4. 接着同样的逻辑操作b节点

通过以上逻辑实现服务的无缝发版,但每次节点变动都需要reload一次Nginx。虽然现在的Nginx版本的reload已经支持配置平滑更新,但实际上reload操作依然会造成CPU竞争、Nginx性能降低以及提前关闭HTTP长连接导致部分客户端调用异常。

在这里插入图片描述

为了避免以上问题,常见的解决方案如下:

  1. DNS动态解析
  2. lua脚本解析

Kong网关对以上两种方案均支持,基于这两种方案,可以对当前上述服务发版流程优化成功以下几种方式:

集成Kubernetes

集成Kubernetes,通过Kubernetes的DNS服务发现实现负载均衡。Kong网关只负责路由匹配、调用者认证、路由鉴权等网关责任,而服务注册发现的逻辑全部交由Kubernetes处理,使Kong网关完全脱离upstream的逻辑处理。

集成注册中心

在这里插入图片描述

Kong网关提供了API接口,可以通过这些开放的API接口来管理Kong内部的各个对象,例如上线/下线节点target,详见官方文档admin-api/add-target。

# 节点上线
curl -X POST http://127.0.0.1:8001/upstreams/test-upstream/targets \
--data "target=172.17.0.1:8080" \
--data "weight=100"# 节点下线
curl -X POST http://127.0.0.1:8001/upstreams/test-upstream/targets \
--data "target=172.17.0.1:8080" \
--data "weight=0"

因此可以搭建如上图的架构方案,自行代码实现一个节点监听服务,通过对接注册中心的API来实时监听各个服务节点的状态。当某服务节点上下线后,注册中心将节点上下线事件推送给监听服务,然后监听服务通过Kong的开放API修改该节点对应的Kong中的target对象状态。

通过上述方案从而实现一个注册中心同时管理微服务之间的服务发现和网关到服务的服务发现。此时应用发布流程例如对某服务的a、b两节点发版时具体逻辑如下:

  1. 请求注册中心下线该服务的a节点
  2. 监听服务监听到a节点下线后自动将Kong中的a节点下线
  3. 等待a节点无流量请求后发布重启a节点的新版本
  4. a节点启动成功后自动将自己重新注册到注册中心
  5. 监听服务监听到a节点上线后自动将Kong中的a节点上线
  6. 接着同样的逻辑操作b节点

自动化脚本

该方案需要配合健康检查使用,具体逻辑与动态模板解析方案基本相同,仅仅是将模板修改操作替换成API请求操作。例如对某服务的a、b两节点发版时具体逻辑如下:

  1. 请求Kong网关API摘除该服务的a节点
  2. 等待a节点无流量请求后发布重启a节点的新版本
  3. 最后再请求Kong网关API重新添加a节点
  4. 接着同样的逻辑操作b节点

健康检查

Kong的upstream支持target健康检查,详细文档见health-checks-circuit-breakers。

Kong支持两种健康检查方式,即可以单独使用,也可以组合使用。通过健康检查target的健康状态,被标记为不健康的target不再有请求路由到该节点。

  • 主动健康检查:定时请求target的指定path,并通过响应状态码标记该target为健康/不健康
  • 被动健康检查:target的指定响应码数量超过阈值后标记该target为不健康

被动健康检查不会将不健康的target标记成功健康状态,需要人工手动标记该target为健康状态从而恢复流量路由到该目标。因此如果需要使用被动健康检查,务必与主动健康检查组合使用,通过主动健康检查自动将恢复响应的target标记为健康状态。

静态资源

Kong目前仅支持API路由,不支持静态资源映射,为了最简单地方式使Kong实现静态资源访问,可以搭建下图所示的架构。单独搭建一个Nginx服务做静态资源服务器,然后在Kong中将该Nginx服务配置成service并设置路由规则,将静态资源访问请求通过路由规则请求到该Nginx上。

在这里插入图片描述

限流

Kong自带限流插件rate-limiting

local function get_identifier(conf)local identifierif conf.limit_by == "service" thenidentifier = (kong.router.get_service() orEMPTY).idelseif conf.limit_by == "consumer" thenidentifier = (kong.client.get_consumer() orkong.client.get_credential() orEMPTY).idelseif conf.limit_by == "credential" thenidentifier = (kong.client.get_credential() orEMPTY).idelseif conf.limit_by == "header" thenidentifier = kong.request.get_header(conf.header_name)elseif conf.limit_by == "path" thenlocal req_path = kong.request.get_path()if req_path == conf.path thenidentifier = req_pathendendreturn identifier or kong.client.get_forwarded_ip()
end

rate-limiting插件限流逻辑的对象选择关键代码如上,当基于path限流时,该插件的后续处理逻辑有点反常识。正常逻辑下对指定path限流意味着path规则匹配时则限流,path不匹配时不限流,但该插件的逻辑是path规则匹配时限流,path规则不匹配时按调用方ip限流。

且该插件的path匹配规则仅支持单个完全匹配,不支持范围匹配、正则匹配等常见规则。因此如果需要基于path做限流控制,可以对官方插件稍作修改后使用。

计数模式config.policy支持3种策略:

  • local: 节点本地内存中计数,应用场景为单节点模式,性能影响最小
  • redis: redis中计数,应用场景为集群模式,需要额外依赖redis服务,性能影响中
  • cluster: 集群计数,应用场景为集群模式,不需要额外依赖服务,但性能影响最大

灰度发布

灰度发布是指通过将更改缓慢推广到一小部分用户,降低在生产环境中引入新软件版本的风险。Kong开源版官方不提供该插件,但有第三方插件支持kong-plugins-canary。

支持通过ip、header、cookie、args四种匹配方案来做灰度流量控制,并支持单个、多个、正则匹配规则。

数据监控

启用prometheus插件

首先在Kong控制台启用prometheus插件,如下图所示,直接在全局范围启用该插件,关于prometheus插件更多配置详见官方文档。

在这里插入图片描述

插件启动后访问KongAdmin的/metrics地址,如下图所示,则说明prometheus插件启动成功。

image

安装prometheus

prometheus

修改配置文件,将KongAdmin的访问地址添加到targets值域中,如下图,然后启动prometheus服务。

image

docker run -d \
--name prometheus \
--network=kong-net \
-p 9090:9090 \
-v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus

访问prometheus的访问地址http://host:9090后,在搜索栏中输入关键字kong后如下图自动补全搜索关键字,则表示prometheus成功收集到了Kong的监控数据。

image

安装grafana

docker run -d \
--name=grafana \
--network=kong-net \
-p 3000:3000 \
grafana/grafana

访问grafana的控制台地址http://host:3000(默认账号密码admin:admin),需要先关联prometheus服务。如下图,在配置栏添加prometheus数据库,并输入prometheus的服务访问地址http://host:9090

image

image

image

prometheus数据库配置完成后,添加Kong的dashboards,直接输入模板ID7424或者访问
https://grafana.com/grafana/dashboards/7424下载模板JSON文件后导入均可,如下图。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iN2oAYaN-1616828418728)(https://img.wakzz.cn/202102/N8zKbiCnsX.png)]

image

最终效果展示:

image

image

image

这篇关于Kong网关初探的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/781870

相关文章

计算机网络基础概念 交换机、路由器、网关、TBOX

提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 文章目录 前言一、VLAN是什么?二 、交换机三、路由器四、网关五、TBOXTelematics BOX,简称车载T-BOX,车联网系统包含四部分,主机、车载T-BOX、手机APP及后台系统。主机主要用于车内的影音娱乐,以及车辆信息显示;车载T-BOX主要用于和后台系统/手机APP通信,实现手机APP的车辆信息显示与控

Java后端微服务架构下的服务网关设计:Spring Cloud Zuul

Java后端微服务架构下的服务网关设计:Spring Cloud Zuul 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,服务网关是微服务系统与外部世界的入口点,它负责请求路由、负载均衡、认证、监控等任务。Spring Cloud Zuul是一个基于Spring Boot的网关服务,它为微服务架构提供了一种灵活、高效的网关解决方案。 服务

Java注解初探

什么是注解 注解(Annotation)是从JDK5开始引入的一个概念,其实就是代码里的一种特殊标记。这些标记可以在编译,类加载,运行时被读取,并执行相应的处理。通过注解开发人员可以在不改变原有代码和逻辑的情况下在源代码中嵌入补充信息。有了注解,就可以减少配置文件,现在越来越多的框架已经大量使用注解,而减少了XML配置文件的使用,尤其是Spring,已经将注解玩到了极致。 注解与XML配置各有

微服务之网关安全基于Zuul并实现网关限流

微服务网关安全 微服务架构下的问题 处理安全和业务逻辑耦合,增加了复杂性和变更成本 随着业务节点增加,认证服务器压力增大 多个微服务同时暴露,增加了外部访问的复杂性 通过网关处理流程 1、请求令牌。2、转发请求。3、返回令牌。4、转发令牌各客户端应用。5、携带令牌发送请求。6、校验令牌。7、返回校验结果信息。8、访问微服务。 实例 引入依赖 <dependencies><depe

API 网关 OpenID Connect 实战:单点登录(SSO)如此简单

作者:戴靖泽,阿里云 API 网关研发,Higress 开源社区 Member 前言 随着企业的发展,所使用的系统数量逐渐增多,用户在使用不同系统时需要频繁登录,导致用户体验较差。单点登录(Single Sign-On,简称 SSO)正是为了解决这一问题。当用户登录一次后,即可获取所有系统的访问权限,不需要对每个单一系统逐一登录。 目前,SSO 的实现方案常见有以下几种: 基于 JWT:

基于阿里云函数计算(FC)x 云原生 API 网关构建生产级别 LLM Chat 应用方案最佳实践

作者:计缘 LLM Chat 应用大家应该都不陌生,这类应用也逐渐称为了我们日常的得力助手,如果只是个人使用,那么目前市面上有很多方案可以快速的构建出一个LLM Chat应用,但是如果要用在企业生产级别的项目中,那对整体部署架构,使用组件的性能,健壮性,扩展性要求还是比较高的。本文带大家了解一下如何使用阿里云Serverless计算产品函数计算构建生产级别的LLM Chat应用。 该最佳实践会

IOS Core Data框架初探

在IOS系统中已经集成了关系型数据库SqLite3数据库,但是由于在OC中直接操作C语言风格的SqLite3相对繁琐,因此Apple贴心的提供了一个ORM(Object Relational Mapping对象关系映射)框架——Core Data让我们在程序中以面向对象的方式,操作数据库。Core Data框架提供的功能相当强大,属于入门容易精通难的东西,值得我们用心专研。现在,就先记录一下我对该

基于OGC300工业级LORA网关与OM201L数传终端的化工厂人员定位系统解决方案

化工行业作为高风险的行业之一,其安全管理一直备受关注。化工生产过程中涉及到各种危险品和复杂的工艺,一旦发生事故,往往会造成严重的人员伤亡和财产损失。因此,化工企业急需一套可靠的安全管理系统来监测安全隐患、预防事故发生。 在这一背景下,基于先进的LORA自组网技术、BLE高精度定位技术、5G通讯技术、AI图像智能识别技术、云计算与数字孪生技术等前沿技术,北京东用科技提出了一套全新的化工厂人

网关,DNS,MAC地址,子网掩码,网段分别是什么?

网关、DNS、MAC地址、子网掩码和网段是计算机网络中的基础概念,它们在网络通信和数据交换中扮演着关键角色。以下将详细解释每个概念及其功能: 网关 定义:网关(Gateway)又称网间连接器或协议转换器,是用于连接两个高层协议不同的网络的设备。功能:网关主要用来实现不同网络之间的数据传递和通信。在TCP/IP协议中,网关通常是网络通向其他网络的IP地址。例如,主机发现数据包目的主机不在本地网络内

网关桥梁:modbus 转 profinet 网关中频加热机的智能融合之旅

一、项目序章:金属热处理的智慧曙光在金属锻造的辉煌舞台上,中频感应加热电源以其高效节能、精准控温的卓越才艺,成为了热处理、焊接与成型艺术中不可或缺的幕后英雄。然而,随着工业自动化的浪潮汹涌而至,如何让这位英雄融入智能工厂的广阔天地,实现远程指挥与智能操控,成为了新时代的命题。本案例,便是一场关于中频感应加热电源与工业网关携手,共绘智能工厂新蓝图的壮丽篇章。 二、系统蓝图:织就智慧互联的经纬1