关于Kong 网关的研究---详尽版--个人原创

关于Kong 网关的研究 ================

1. 什么是 kong
   Kong 是一个开源的 API 网关，它是一个针对 API 的一个管理工具。你可以在那些上游服务之前，额外地实现一些功能。

Kong 本身是一款基于 OpenResty（Nginx + Lua 模块）编写的高可用、易扩展的，由 Mashape 公司开源的 API Gateway 项目。Kong 是基于 NGINX 和 Apache Cassandra 或 PostgreSQL 构建的，能提供易于使用的 RESTful API 来操作和配置 API 管理系统，所以它可以水平扩展多个 Kong 服务器，通过前置的负载均衡配置把请求均匀地分发到各个 Server，来应对大批量的网络请求。

2. 为什么选择 kong

身份认证插件:Oauth2.0 authentication、 HMAC authentication 、JWT 、LDAP authentication

安全控制插件：ACL（访问控制）、CORS（跨域资源共享）、动态 SSL、IP 限制、爬虫检测

流量控制插件：请求限流（基于请求计数限流）、上游响应限流（根据 upstream 响应计数限流）、请求大小限制。限流支持本地、Redis 和集群限流模式

分析监控插件：zipkin 、Prometheus

协议转换插件：请求转换（在转发到 upstream 之前修改你请求）、响应转换（在 upstream 响应返回客户端之前修改响应）

Kong 的配套体系

Yapi 解决 api 文档管理，mock 数据，自动化测试功能

Consul 服务发现，配置中心

Carrot 操作 kong ，对接 yapi， 对接 Jenkins，对接 scm

3. 高可用方案介绍：
   Kong 作为流量网关来使用，那么我们就需要考虑如何实现 kong 的高可用。现在 kong 的高可用方案我们从两方面考虑

如何避免 kong 网关单点故障导致服务宕机。
kong 主要依赖于 postgresql 进行数据存储，如何保证 postgresql 的高可用性以及如何防止 postgresql 数据库被攻破而导致系统崩溃。
1.架构图
我们的网关基础架构图可设计如下：

Kong 网关基础架构部署图

2.kong 的高可用方案
kong 采用集群部署的方式，外层通过 nginx 进行 kong 网关的负载均衡，同时在内外网之间再通过设立 DMS 网络隔离区来进行内外网络隔离，降低 kong 网关数据库（postgreSQL）被攻破的的可能性。

同时，kong admin Api 的管理端口（8001，8444）建议不对公网进行暴露，避免被接管 kong 的风险，可参见集群部署中关闭监听端口或是代理端口。

参考链接：

1.Kong 系列（一）——Kong 集群部署 - 知乎 (zhihu.com)

2.【2】微服务架构-kong 的集群化部署【图文】_酱酱酱子啊_51CTO 博客

3.kong 未经授权漏洞分析 | Bboysoul’s Blog

4.https://xie.infoq.cn/article/c6703d216c43c2b522b9b4ffa

5、Clustering Reference - v1.2.x | Kong Docs (konghq.com)

6、Hybrid Mode Deployment - v2.0.x | Kong Docs (konghq.com)

3. postgreSQL 的高可用性方案

• [ ]

Postgresql 高可用方案采用异步流复制（主从同步）+主从热备。

   Postgresql 的流复制分为两种：同步流复制、异步流复制。
   
   同步流复制：实时性较高，当备库宕机，主库会被拴住，无法向主库写入数据。
   
   异步流复制：实时性略低，当备库宕机，主库会不受影响，仍可以向主库写入数据，再次启动宕机备库，数据依旧可以同步到备库，当备库宕机时间过长，主库备库不在一个时间线，数据将无法同步。
   
   此处参考文档：
   
   https://blog.csdn.net/Qguanri/article/details/51151974

PostgreSQL: Documentation
流复制+双机热备方案

配置 postgresql 的主从流复制

https://www.cnblogs.com/cxy486/p/5164612.html

利用 pgpool-II 中间件实现高可用性

https://www.iteye.com/blog/iwin-2108807

https://www.xiaomastack.com/2019/08/16/postgresql%E9%9B%86%E7%BE%A4/

利用 keepalived+pgpoll-II 完成双机热备切换

https://www.cnblogs.com/songyuejie/p/4561089.html

4. Kong 的 API 服务调用监控
   方案一、Prometheus+grafana
   prometheus+Kong 网关对于服务的监控方案如下：

kong 可以通过集成 prometheus +grafana 来实现对 kong 的监控告警。目前 Grafana 有与 Prometheus 插件配套使用的 Dashboard （模板编号 7424)。Prometheus 可以通过采集 kong 网关的指标进行存储。之后通过引入 Grafana BI 应用进行数据图表展示，从而达到服务监控数据可视化的效果。告警模块在 grafana 有基础功能模块。

一、开启插件
二、配置 prometheus
安装 prometheus 需要调整并指定 prometheus.yml 文件：

注意：需要严格按照 yml 文件的格式进行填写，否则 prometheus 会启动失败。

添加的数据如下：

- job_name: ‘kong-gateway’

metrics_path: ‘/metrics’

scrape_interval: 5s

static_configs:

- targets: [‘110.42.229.44:8001’]

三、部署 grafana 并启动
Docker 部署：

$ docker pull grafana/grafana

启动脚本内容如下：

启动成功后访问端口：3000

测试端口：$ curl http://localhost:3000 初始用户密码为：admin/admin

登陆会要求重置密码。

四、设置 grafana 数据源
由于我们集成的是 prometheus，所以 grafana 的数据源选择 prometheus,进行配置。

五、引入官方配套 dashboard
模板编码可以去 grafana 官方网站搜索,这里使用的官方推荐模板（7424）。

地址如下：Dashboards | Grafana Labs

六、展示监控页面
监控数据可视化如下图：

图一：kong 网关状态监控

图二：服务调用 RPS 情况展示

图三：kong 网关服务上下游分析

从上图所能监控到的关键指标大体如下：

不同服务不同时间调用状态码 http_status 总共服务连接数，已处理请求数，已接受请求数 数据库是否正常可读 RPS 服务吞吐率
（总请求数/处理请求的总完成时间） 服务出口流量（Egress per Service）以及服务入口流量（Ingress Per
service） P95、9 百分位数值——服务响应时间的重要衡量指标
https://blog.csdn.net/yufaxingxing/article/details/113495258

Prometheus 可用指标

状态代码：上游服务返回的 HTTP 状态代码。这些服务按服务、跨所有服务以及按每个使用者的路由提供。
延迟直方图：在 kong 时测得的延迟：
要求：Kong 和上游服务为请求提供服务所花费的总时间。
Kong：Kong 路由请求并运行所有已配置的插件所花费的时间。
上游：上游服务响应请求所花费的时间。
带宽：流经 Kong 的总带宽（出口/入口）。此指标针对每个服务可用，并作为所有服务的总和提供。
DB 可访问性：值为 0 或 1 的仪表类型，表示 Kong 节点是否可以访问 DB。
连接数 ：各种 Nginx 连接指标，如活动，读取，写入和接受的连接数。
目标运行状况：属于给定上游及其子系统（或）的目标的健康状态（，，，或）。healthchecks_offhealthyunhealthydns_errorhttpstream
数据平面状态：数据平面节点的上次查看时间戳、配置哈希、配置同步状态和证书过期时间戳将导出到控制平面。
**附上测试环境路径：**Kong (official) - Grafana admin/grafana

5. 服务链路监控分析-zipkin
   Kong +zipkin 可以开启对服务调用链路的采集以及链路拓扑展示。链路信息包括 【服务调用层次，服务调用时间，服务调用接口，服务调用耗时，服务调用状态，服务调用接口路径等方面】

一、开启插件
这里选的还是新增全局插件，步骤类似 prometheus 的插件新增，也可以对服务，路由颗粒度比较小的进行链路追踪。

二、部署并启动 zipkin
采用的是 docker 部署。部署命令如下：

docker pull openzipkin/zipkin

docker run -d -p 9411:9411 openzipkin/zipkin

部署成功后可访问 localhost:9411 进行查看。页面如下：

三、填写插件配置
这里主要关注两个值：http endpoint :填写的是 http://localhost:9411/api/v2/spans 其次：sample ratio 采样率的意思是 记录链路信息的比例。默认是 0.001 意思是 1 千条服务捕获 1 条。置为 1 则为百分百记录。

四、访问服务
为了凸显插件生效，这里服务接口返回的是请求头部信息。

可以看到转发的请求中添加了 zipkin 链路信息的标签。

当关闭插件之后再次访问 getHeader 接口：

头部信息没有刚刚标识的标签了，说明插件关闭成功。

五、验证结果
下图为 Zipkin 所展示的链路调用信息。

图四：zipkin 链路拓扑图展示

图五：链路信息列表展示

图六：服务调用拓扑详情展示

附上测试环境路径：Zipkin

6 日志插件的应用-File log
kong 可以通过 admin api 开启日志插件（File Log）已写文件的形式来记录服务调用情况，并可将日志用于后续对服务访问频次以及进一步的分析。

配置完成之后，需要在容器中查看当前用户，默认为：kong 用户

所以配置日志路径可为：/usr/local/kong/kong.log

如下图为 开启 File log 插件， 访问服务后所生成 log 日志。我们在后续的方案中可以利用这部分数据进行服务多维度的数据分析。

一、开启插件
新增全局日志插件，选择 File-Log

二、进行配置
三、访问服务
四、查看日志
进入容器内：跳转到步骤二配置的路径：/usr/local/kong/kong.log

可查看到路径下多了 kong.log 文件，命令：tail -f kong.log

实时查看记录如下：

服务访问记录日志写入成功。

五、日志格式

request 包含有关客户端发送的请求的属性

response 包含有关发送到客户端的响应的属性

tries 包含负载均衡器为此请求进行的（重新）尝试（成功和失败）列表

route 包含有关所请求的特定路线的 Kong 属性

service 包含与所请求的路线相关联的服务的 Kong 属性

authenticated_entity 包含有关经过身份验证的凭据的 Kong 属性（如果已启用身份验证插件）

workspaces 包含与请求的路由关联的工作空间的 Kong 属性。仅限 Kong Enterprise 版本> = 0.34。

consumer 包含经过身份验证的使用者（如果已启用身份验证插件）

latencies:

包含一些有关延迟的数据：

proxy 是最终服务处理请求所花费的时间

kong 是运行所有插件所需的内部 Kong 延迟

request 是从客户端读取的第一个字节之间以及最后一个字节发送到客户端之间经过的时间。用于检测慢速客户端。

client_ip 包含原始客户端 IP 地址

started_at 包含开始处理请求的 UTC 时间戳。

原文链接：https://blog.csdn.net/qq_41637057/article/details/101051833

7、kong 的负载均衡
kong 网关请求流程如下：

图：服务请求路径流向图

**一、***配置 upstream*
打开 Konga 左侧列表菜单中的 UPSTEAM(上游管理)，点击 create upstream

这里只需要设置 name ：app.com 即可，保证 Service 的配置可以正确的匹配到我们。

二、配置 target
既然是负载均衡，就少不了后端服务，接下来配置在 UPSTEAM 进行负载均衡的目标—targets。

找到我们刚刚创建的上游（upstream），然后点击 details,根据下图点击 Target 之后点击 +ADD TARGET

**三、***配置 Service 发布*
配置一个 Service，字段 Url 填写我们刚刚配置的 Upstream 的 Name

**四、***配置 Route*
在 service 配置好之后进行 route 的配置，匹配规则。如下新增路由，

一个服务可以有多个路由的映射。

**五、***验证结果*
准备两个不同端口的微服务：接口统一，但是返回值有所区别。

可以看到通过配置可以达到负载均衡的效果，同时可以通过对 target 进行调整来进行动态配置。

8、konga 的监控告警
这里存在一个问题：在更新 upstream 之后健康检查会停止。这个是个官方遗留 bug。

解决需要提升 lua-resty-healthcheck 插件版本 ->2.0.0

这里采用的 kong 的版本为 2.7.0 ，使用的是 lua-resty-healthcheck 1.4.2 版本。

一、服务 API 监控告警
前提条件：在配置 details 时需要设置主动健康检查或是被动健康检查

配置如下：

在 konga 配置负载均衡时，有个 alert 告警功能，可以对服务的健康度进行检查，同时发送异常邮件通知。

点击 Settings->Notifucatons 会跳转到邮件配置

这里有两个注意事项：

**告警检查的时间无法进行配置，默认是一分钟检查一次。

**当节点的健康度为 DNS ERROR 或是 unhealthy 时才会告警。

默认情况下节点为 HEALTHYCHECK_OFF 不告警

这里有几种情况会告警一个是 DNS_ERROE, 一个是不健康状态，可以点击眼睛查看。

图示：target 详情

图：服务 API 发生告警的内容。

二、Kong 管理节点告警
当 kong 的管理节点宕机时，也会发生告警，如果配置了邮件配置。页面会有提示如下图：

图示： 邮件告警信息

9、kong 集成 skywalking
kong-plugin-skywalking 插件安装
插件版本：0.1.0

kong 有第三方作者开源写了 skywalking 的集成插件。

Skyworking 插件引入部署：

一、下载插件源代码
源码下载：

kong-plugin-skywalking/kong/plugins at master · polaris-liu/kong-plugin-skywalking (github.com)

上传到本地：/opt/app/kong/skywalking

二、添加插件到 kong 目录
插件引入路径：/usr/local/share/lua/5.1/kong/plugins/

Docker 部署的，可在 kong 的启动脚本中将本地下载好的 skywalking 插件映射到上述路径。命令如下：

-v /opt/app/kong/skywalking:/usr/local/share/lua/5.1/kong/plugins/skywalking

意思是将本地上的 skywalking 插件代码->写入到容器内

同时需要新增配置：

-e “KONG_PLUGINS=bundled,skywalking” \

标识启动时安装 skywalking 插件

三、修改插件常量
启动后以 root 用户进入容器：

命令：

docker exec -it --user root 3581f830fa8d sh

修改：/usr/local/share/lua/5.1/kong/constans.lua

在 local plugins ={} 末尾添加 “skywalking，” 逗号是需要的

四、重启 docker 容器
重启命令：docker restart skywalking

五、安装验证
安装验证，使用 konga，在＂插件管理＂->＂其他插件＂可以看到已新增 skywalking 插件

图：新增 skywalking 插件

skywalking 部署
ｄｏｃｋｅｒ　部署：

Skywalking 版本：8.3

Elasticsearch 版本：7.16.3

1、安装ｅｓ７环境
Ｄｏｃｋｅｒ　命令：

docker pull docker.elastic.co/elasticsearch/elasticsearch:7.16.3

docker run -d --name es -p 9200:9200 -p 9300:9300 -e ES_JAVA_OPTS=“-Xms512m -Xmx512m” -e “discovery.type=single-node” docker.elastic.co/elasticsearch/elasticsearch:7.16.3

2、拉取 skywalking AOP 镜像并启动
docker pull apache/skywalking-oap-server:8.3.0-es7

ｄｏｃｋｅｒ　启动命令：

docker run --name oap --restart always -d -p 11800:11800 -p 12800:12800 -e SW_STORAGE=elasticsearch7 -e SW_STORAGE_ES_CLUSTER_NODES=110.42.229.44:9200 apache/skywalking-oap-server:8.3.0-es7

3、拉取 skywalking 　 UI 镜像并启动
docker pull apache/skywalking-ui:8.3.0

ｄｏｃｋｅｒ　启动命令：

docker run --name ui --restart always -d -p 8200:8080 -e SW_OAP_ADDRESS=110.42.229.44:12800 apache/skywalking-ui:8.3.0

开启 skywalking 插件
１、开启插件
图：新增ｓｋｙｗａｌｋｉｎｇ插件

２、进行配置
图：配置ｓｋｙｗａｌｋｉｎｇ

这里的ｕｒｌ地址填写的是ｓｋｙｗａｌｋｉｎｇ组件中ａｏｐ的对外端口。

３、访问服务
４、验证结果
打开ｓｋｙｗａｌｋｉｎｇ的ｗｅｂ　ＵＩ　页面：端口为前面设置的８２００

页面显示效果如下：

图示：skywalking 的服务链路追踪

图示：skywalking 的 APM 监控

图示：kong-service 的服务拓扑图

skywalking 应用指南
1、指标维度分析
模块栏目

仪表盘：查看被监控服务的运行状态

拓扑图：以拓扑图的方式展现服务直接的关系，并以此为入口查看相关信息

追踪：以接口列表的方式展现，追踪接口内部调用过程

性能剖析：单独端点进行采样分析，并可查看堆栈信息

告警：触发告警的告警列表，包括实例，请求超时等。

自动刷新：刷新当前数据内容（我这好像没有自动刷新）

仪表盘

控制栏

第一栏：不同内容主题的监控面板，应用/数据库/容器等

第二栏：操作，包括编辑/导出当前数据/倒入展示数据/不同服务端点筛选展示

第三栏：不同纬度展示，服务/实例/端点

APM 展示栏

Global 全局维度

第一栏：Global、Server、Instance、Endpoint 不同展示面板，可以调整内部内容

Services load：服务每分钟请求数

Slow Services：慢响应服务，单位 ms

Un-Health services(Apdex):Apdex 性能指标，1 为满分。

Global Response Latency：百分比响应延时，不同百分比的延时时间，单位 ms

Global Heatmap：服务响应时间热力分布图，根据时间段内不同响应时间的数量显示颜色深度

底部栏：展示数据的时间区间，点击可以调整。

Service 服务维度

Service Apdex（数字）:当前服务的评分

Service Apdex（折线图）：不同时间的 Apdex 评分

Successful Rate（数字）：请求成功率

Successful Rate（折线图）：不同时间的请求成功率

Servce Load（数字）：每分钟请求数

Servce Load（折线图）：不同时间的每分钟请求数

Service Avg Response Times：平均响应延时，单位 ms

Global Response Time Percentile：百分比响应延时

Servce Instances Load：每个服务实例的每分钟请求数

Show Service Instance：每个服务实例的最大延时

Service Instance Successful Rate：每个服务实例的请求成功率

Instance 实例维度

Service Instance Load：当前实例的每分钟请求数

Service Instance Successful Rate：当前实例的请求成功率

Service Instance Latency：当前实例的响应延时

JVM CPU:jvm 占用 CPU 的百分比

JVM Memory：JVM 内存占用大小，单位 m

JVM GC Time：JVM 垃圾回收时间，包含 YGC 和 OGC

JVM GC Count：JVM 垃圾回收次数，包含 YGC 和 OGC

CLR XX：类似 JVM 虚拟机，这里用不上就不做解释了

Endpoint 端点（API）维度

Endpoint Load in Current Service：每个端点的每分钟请求数

Slow Endpoints in Current Service：每个端点的最慢请求时间，单位 ms

Successful Rate in Current Service：每个端点的请求成功率

Endpoint Load：当前端点每个时间段的请求数据

Endpoint Avg Response Time：当前端点每个时间段的请求行响应时间

Endpoint Response Time Percentile：当前端点每个时间段的响应时间占比

Endpoint Successful Rate：当前端点每个时间段的请求成功率

DataSource 展示栏

当前数据库：选择查看数据库指标

Database Avg Response Time：当前数据库事件平均响应时间，单位 ms

Database Access Successful Rate：当前数据库访问成功率

Database Traffic：CPM，当前数据库每分钟请求数

Database Access Latency Percentile：数据库不同比例的响应时间，单位 ms

Slow Statements：前 N 个慢查询，单位 ms

All Database Loads：所有数据库中 CPM 排名

Un-Health Databases：所有数据库健康排名，请求成功率排名

拓扑图

1：选择不同的服务关联拓扑

2：查看单个服务相关内容

3：服务间连接情况

4：分组展示服务拓扑

：服务告警信息

：服务端点追踪信息

：服务实例性能信息

：api 信息面板

追踪

左侧：api 接口列表，红色-异常请求，蓝色-正常请求

右侧：api 追踪列表，api 请求连接各端点的先后顺序和时间

性能剖析

新建任务：新建需要分析的端点

左侧列表：任务及对应的采样请求

右侧：端点链路及每个端点的堆栈信息

新建任务

服务：需要分析的服务

端点：链路监控中端点的名称，可以再链路追踪中查看端点名称

监控时间：采集数据的开始时间

监控持续时间：监控采集多长时间

起始监控时间：多少秒后进行采集

监控间隔：多少秒采集一次

最大采集数：最大采集多少样本

告警

不同维度告警列表，可分为服务、端点和实例。

原文链接：https://blog.csdn.net/lizz861109/article/details/107535100

10 问题方案思考：
1、Kong 网关的集群部署模式，是采用主从还是多活模式？如何部署？发生故障是手动切换还是自动切换机制？机器发生故障是否有完善的报警机制？数据库如何配置？
关于 kong 网关的部署方案，在版本 2.1 之前更多的采用的是集群方式部署，在 2.1 之后引入了混合部署的方式。

混合部署：
在 Kong 2.0 中，官方引入了一种部署 Kong 的新方法，称为混合模式，也称为控制平面/数据平面分离（CP / DP），一种免费的部署模式，只需在部署时进行配置即可。

在此模式下，群集中的 Kong 节点分为两个角色：控制平面 （CP），其中管理配置并为管理 API 提供服务，以及数据平面 （DP），为代理提供流量。每个 DP 节点都连接到其中一个 CP 节点。DP 节点不是在传统的部署方式中直接访问数据库内容，而是保持与 CP 节点的连接，并接收最新的配置。

使用混合模式进行部署具有许多优点：

1、大大减少数据库上的流量，因为只有 CP 节点需要直接连接到数据库。

2、提高了安全性，如果其中一个 DP 节点被入侵，攻击者将无法影响 Kong 群集中的其他节点。

3、易于管理，因为管理员只需与 CP 节点交互即可控制和监视整个 Kong 群集的状态。

4、部署灵活性：用户可以在不同的数据中心、地理位置或区域中部署数据平面组，而无需为每个 DP 组使用本地群集数据库。

5、 高可用性：数据库的可用性不会影响数据平面的可用性。每个 DP 都会在本地磁盘存储上缓存从控制平面接收到的最新配置，因此，如果 CP 节点关闭，DP 节点将继续运行。

网络拓扑图：

如图：混合部署架构图

版本兼容性

Kong 网关控制平面仅允许来自具有相同主要版本的数据平面的连接。控制平面不允许从具有较新次要版本的数据平面进行连接。

例如，Kong Gateway v2.5.2 控制平面：

接受 Kong 网关 2.5.0、2.5.1 和 2.5.2 数据平面。
接受 Kong 网关 2.3.8、2.2.1 和 2.2.0 数据平面。
接受 Kong 网关 2.5.3 数据平面（接受数据平面上较新的修补程序版本）。
拒绝 Kong 网关 1.0.0 数据平面（主要版本不同）。
拒绝 Kong 网关 2.6.0 数据平面（数据平面上的次要版本较新）。
局限性

配置不灵活

当通过管理 API 在控制平面级别进行配置更改时，它会立即触发所有数据平面配置的群集范围更新。这意味着相同的配置将从 CP 同步到所有 DP，并且无法计划或批处理更新。对于具有不同配置的不同 DP，它们将需要自己的 CP 实例。

插件不兼容

当插件在混合模式下的数据平面上运行时，不会直接从该 DP 公开管理 API。由于 Admin API 仅从控制平面公开，因此所有插件配置都必须从 CP 进行。由于此设置以及 CP 和 DP 之间的配置同步格式，某些插件在混合模式下存在限制：

密钥身份验证已加密： 生存时间设置 （） 确定凭据保持有效的时间长度，在混合模式下不起作用。
速率限制高级： 此插件不支持混合模式下的策略。必须改用该策略。clusterredis
OAuth 2.0 身份验证： 此插件与混合模式不兼容。对于其常规工作流，插件需要生成和删除令牌，并将这些更改提交到数据库，这在 CP / DP 分离中是不可能的。
自定义插件

自定义插件（您自己的插件或未随 Kong 一起提供的第三方插件）需要以混合模式安装在控制平面和数据平面上。

负载平衡

目前，对于控制平面和数据平面之间的连接，没有自动负载平衡。您可以通过使用多个控制平面并使用 TCP 代理重定向流量来手动进行负载平衡。

集群部署:
可以通过部署多个 Kong 节点，外层使用 Nginx 进行负载均衡，每个 Kong 节点访问同一数据库，同时根据功能不同分为业务节点以及管理节点。业务节点开放 8000 端口，控制节点只开放 8001 端口，同时 kong 的管理页面框架可根据不同需求采用 konga 或是 kongx。数据库部署可参见高可用方案介绍 ：postgreSQL 的高可用性方案

架构图：

kong 1 为管理节点，仅开放 8001 管理端口，禁用路由代理端口

在部署时调整/etc/kong/kong.conf 配置：stream_listen = off 以及 proxy_listen = 0.0.0.0:8000 调整为 proxy_listen = off。

Kong2/为数据节点，仅开放 8000/8443 路由接口，禁用管理端口 8001

在部署时调整 kong.conf 配置，调整为: admin_url =offf

方案取舍：
由于混合部署不支持 Othau2 权限插件，以及后续可能出现其他插件不支持的情况，虽然混合部署安全性较高，但考虑到使用 kong 主要是基于 kong 的插件多样化,灵活配置特性，故采用集群部署方式

集群部署之后，kong 提供了集群状态检查接口：

# on Control Plane node http :8001/clustering/status

我们可以通过外部定时轮询检查集群节点状态，同时看是否有需要引入告警系统或是开发告警系统。目前还没有比较完善的告警机制。数据库采用 postgresql ，同时选用主从流复制以及做双机热备方案，以此达到安全以及高可用性。

关于告警模块，grafana 有自身的告警模块以及通知机制。

附上 Kong 混合集群部署链接：https://docs.konghq.com/gateway/2.7.x/plan-and-deploy/hybrid-mode/

2、对外开发的服务接口需要记录流量，接口调用频率，以时间，用户等多个维度去分析接口的调用情况，并形成一个数据可视化的管理页面。
针对这个问题，大体可以理解为需要能够对网关服务整体进行监控，包括：总访问量、API 的 QPS、最高访问量的 API、API 的响应时长分布等相关指标进行监控。

现状：

目前没有一个比较成熟可用的方案可直接使用。根据官方文档的介绍，可以通过管理页面开启 prometheus 插件，同时集成引入 prometheus 以及 grafana 组件，实现监控服务的调用频率，以及出入口流量情况的，但是无法通过维度分组（用户，服务）进行更深层次的数据分析，也暂时无法形成一个数据可视化的管理页面，后续如果需要进一步根据不同维度分析服务数据的话，可引入其他开源 BI 框架。

有如下 3 个方案：

通过日志收集框架近实时收集网关的访问日志，借助 kibana 或 grafana 展现工具对相关指标数据进行展现，同时需要进行数据分析来获取不同维度的统计。
优点：无需开发代码，通过集成组件来完成日志生成，日志采集以及报表展示需求。

缺点：无法定制化开发，无法按照自己期望的维度进行数据分析，同时，部署组件涉及量较多。如下图：

附上参考链接：Kong 访问日志监控方案 - 知乎 (zhihu.com)

可通过 File log 收集本地 kong 网关的日志，同时编写 api 向 prometheuss 提供 /metrics 接口数据，然后集成 grafana ，通过自定义配置表达式或是引入 dashboard 进行数据可视化。
优点：网关日志采集可轻松配置，在本地生成日志文件，同时 grafana 也有现成的 dashboard 可用。

缺点：如果要达到比较好的效果，组件学习成本高，通过向 prometheus 提供自定义/metrics 接口，以及集成 grafana 进行自定义配置，都需要对两者组件有相当的熟悉程度方可实现。

可通过 File log 收集本地 kong 网关的日志，同时格式化日志文件，以常规 ELK 的方式进行数据分析，包括各个维度分析，同时需根据需求看是否需要开发数据报表系统。
优点：自定义维度分析由自己开发维护，比较容易匹配需求。

缺点：进行用户维度级别的分析以及报表系统的开发，均需要投入人力成本。

图：kong 网关的服务调用日志

4、服务链路监控还可以引入 skywalking 中间件

3、kong 是否有国产好用的管理页面？
目前官网搜索到推荐的有 konga 以及目前发现了使用 java 开发的开源项目 kongx。

KongA:

Konga 带来的一个很大的便利就是我们可以通过 UI 观察到 kong 的所有配置，并且可以管理 kong 节点情况进行查看、监控、和预警》

konga 主要特点：

多用户管理

管理多个 kong 节点

电子邮件异常信息通知（针对节点异常）

使用快照备份，还原和迁移 Kong 节点

使用运行状态检查监控节点和 API 状态

轻松的数据库集成（Mysql、postgresSQL、MongoDB）

原文链接：https://blog.csdn.net/weixin_44001568/article/details/108501898

Konga 为外国友人开发，代码开源，由于全英文页面，在使用体验上做的不是很友好，同时针对一些菜单以及用户管理权限方面做的比较粗糙，不易维护以及二次开发，但是 konga 带来的一个最大的便利就是可以很好地通过 UI 观察到现在 kong 的所有的配置，并且可以对于管理 kong 节点情况进行查看、监控和预警

附上 konga 的页面：

附上测试环境网址：http://110.42.229.44:1337/#!/dashboard

用户：chenks/[email protected]

部署方面：KongA 支持本地部署以及 Docker 部署。

详情见：kong/konga 之 docker 部署 - 简书 (jianshu.com)

Kongx 由 java 代码开发，代码开源，且容易进行二次开发。kongx 是网关 kong 的可视化界面管理平台(参考 konga 的部分界面布局方式)，能够集中化管理应用不同环境的网关配置，提供同步各环境的网关配置功能，并且具备规范的权限管理、参数配置、环境管理及日志审计等特性，使用友好。

附上相关介绍：https://gitee.com/raoxy/kongx 最新版本为 2.2.0

附上相关页面：

附上已搭建的测试环境:

http://110.42.229.44:8095/#/login admin/123456

附上 kongx 帮助文档：4.8.2 配置文本格式 · kongx 使用指南 · 看云 (kancloud.cn)

两者功能比较：

相同点：均含有 kong 所提供的 api 接口管理页面，以及基本的用户管理，用户权限管理，均是代码开源项目。

不同点: konga
有快照管理，且功能免费，页面展示为全英文，官方推荐，使用人数较多，但缺乏详细的技术文档，技术选型上前后端不分离，较难二次开发，目前发现个遗留问题，单机
kong 节点挂了也会导致 konga 宕机。

日志如下：

而 Kongx 提供同步各环境的网关配置功能，并且具备规范的权限管理、参数配置、环境管理及日志审计等特性，使用友好，页面展示为中文，使用人数较少，有帮助文档，但文档收费，前后端分离，可自行进行二次开发。

综上：kongx 在除了 konga 的基本网关 API 管理之外，kongx 还具有规范的权限管理，菜单配置，以及日志审计等功能模块，但是使用的人数较少，属于个人开发，可能存在未知漏洞未被发现，如果需要使用 kongx，建议对 kongx 进行源码二次开发或是源码解读分析后使用。

同时也可以部署 konga 进行快照管理，弥补 kongx 缺失的功能。

5、验证环境地址