一.简介
上一篇文章简单入门和了解到了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.架构图
三.2.x版本集群-实现原理
1.原理介绍
所有的DP节点连接同一个CP节点的8005端口来读取Config配置信息并且可以进行缓存。如果CP节点改变了配置信息,DP节点能及时拿到更新消息，对自己的缓存进行更新.(实现原理: websocket)
优点:
1.消息同步及时，无延迟。规避了1.x版本同步Config配置不及时的问题.无须配置PgSQL相关信息，只需要配置CP节点连接ip与端口即可。
缺点:
1.配置相对于1.x版本门槛较高，需要设置几个配置项。才能让DP节点连接到CP节点，协助搭建成集群为外部提供服务。
2.架构图
四.集群模式-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节点的相关指标信息的。