Kong集群(hybrid混合)部署模式

Kong集群(hybrid混合)部署模式kong集群部署与promethues指标采集

大家好,又见面了,我是你们的朋友全栈君。

一.简介

        上一篇文章简单入门和了解到了Kong自定义插件开发方式。紧跟着,这篇主要介绍Kong集群部署模式。生产环境/流量较大的环境下,我们的Kong就要解决单点问题和性能问题,单个Kong节点无法满足我们高并发、高访问量的需求。那么我们自然想到,Kong自身有提供集群部署模式么?答案是肯定的。

          如果Kong自身没有提供集群模式,那么我们也可以自己通过负载均衡的模式,在前端架设一个高可用的7层入口代理Nginx(例如阿里云的ALB、腾讯的SLB等等),再反向代理到后端每个Kong结点,理论上也是可行的。 但是我们要考虑到一个问题,Kong每个节点的配置信息可能是存在缓存更新问题,通过LB虽然可以分摊访问压力,但是配置信息的及时更新又造成新的问题。例如A节点更新了某个route配置,但是此时新的流量跑到了B节点,B节点的配置还未及时更新,导致执行到旧的逻辑等等此类问题。

        所以,看起来仅仅我们用LB负载均衡的方式来实现,是不太完美的。那我们看看Kong自身是如何来解决这个集群问题的.

        Kong将节点分为2种角色:

        1.数据平面节点(Data Panle, 简称DP节点)

        2.控制平面节点(Control Panle ,简称CP节点)

        实现架构原理还跟版本不一样, 1.x版本是DP、CP节点通过共享PgSQL数据库和定时更新缓存来更新配置信息, 2.x版本则是所有DP节点的配置信息都依赖CP节点,CP节点依赖PgSQL数据库,保证配置信息统一及时更新的问题(大致看了一下,应该是通过websocket的方式来实现配置同步)。

二.1.x版本集群-实现原理

1.原理介绍

        多个Kong节点连接同一个PgSQL数据库,定时从数据库读取拿到配置信息(Route、Service、Upstream、Target)等等,然后缓存到自己的内存中。

        优点:  
                部署简单,只要Kong都连接一个PgSQL数据库即可

        缺点:  
                Config配置信息同步不及时,例如A节点同步删除了一个Route,但是B节点还没去轮询DB拿到新的Config数据,则导致信息同步延迟落后,导致B节点访问出现错误.

2.架构图  Kong集群(hybrid混合)部署模式

三.2.x版本集群-实现原理 

1.原理介绍

        所有的DP节点连接同一个CP节点的8005端口来读取Config配置信息并且可以进行缓存。如果CP节点改变了配置信息,DP节点能及时拿到更新消息,对自己的缓存进行更新.(实现原理:  websocket)

        优点:

                1.消息同步及时,无延迟。规避了1.x版本同步Config配置不及时的问题.无须配置PgSQL相关信息,只需要配置CP节点连接ip与端口即可。

        缺点:

                1.配置相对于1.x版本门槛较高,需要设置几个配置项。才能让DP节点连接到CP节点,协助搭建成集群为外部提供服务。

2.架构图

Kong集群(hybrid混合)部署模式

四.集群模式-Promethues指标采集问题

        大家可能会发现部署完Kong集群之后,相对于查看或者部署单个节点时候,采集Prometheus指标的方式明显发生了变化。 如果我们部署单个节点的Kong,利用Grafana官方的dashbord可以明显查看到流量信息、service信息、route、upstream等等信息。但是如果采用集群模式部署以后,CP节点(ip:8001/metrics)只采集到集群信息了。但是此时我们想查看整个集群的流量信息,那我们该怎么采集呢? 访问DP节点(ip:8001/metrics)也不能访问,那怎么搞?

        1.采集CP节点指标

                1.添加全局Promethues插件

                2.访问ip:8100/metrics即可采集CP节点信息。

                如果此时是单个Kong节点模式,则采集到的是Data数据,不存在集群相关信息。如果是集群模式,则采集的是集群信息,不包含route、upstream、target等数据信息。

        2.采集DP节点指标

                1.添加全局Promethues插件

                2.修改配置文件,开启 status_listen=0.0.0.0:8100 配置项. kong prepare && kong reload重启后,  访问ip:8100/metrics则可以拿到数据节点的指标信息.

                因为此时是【集群模式】,DP和CP节点责任分离,DP节点自然不会开启8100端口(admin api管理端口)的监听,访问ip:8100/metrics肯定是失败的。 这里估计会懵逼很多人,有坑。要不然是采集不到DP节点的相关指标信息的。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/153163.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号