Kong

Kong网关混合部署实际部署资源为一个2核4G的虚拟机，部署在了一台虚拟机上，有条件的的能够把数据节点部署到别的机器上。 具体思路是一台虚机部署Kong的管制节点，治理端端口只能本机拜访，Konga和管制节点部署到一块。 数据节点能够部署到其余机器上，Nginx能够独自部署，也能够部署到其余机器上。 基于PostgresSQL数据库，本文不波及数据库装置局部。 因为nginx守护过程须要root，lua插件装置也要应用root用户，所以部署全程应用root用户 1. 部署Kong下载kong安装包 mkdir -p /data/kong cd /data/kong curl -Lo kong-enterprise-edition-2.8.1.1.rpm $(rpm --eval "https://download.konghq.com/gateway-2.x-centos-%{centos_ver}/Packages/k/kong-enterprise-edition-2.8.1.1.el%{centos_ver}.noarch.rpm")装置Kong sudo yum install kong-enterprise-edition-2.8.1.1.rpm部署管制节点生成密钥# 创立证书寄存的文件夹mkdir kong_certcd kong_cert# 证书默认有限期为三年 能够通过 --days参数进行调整kong hybrid gen_cert将证书文件夹复制到CP节点的同一目录下。进入Kong配置文件夹 并复制出配置文件cd /etc/kong# 复制默认的配置文件cp kong.conf.default kong.confKong在启动时会默认查找 /etc/kong/kong.conf /etc/kong.conf配置文件。Kong配置文件批改vim /etc/kong/kong.conf减少以下配置： # kong工作的文件夹prefix = /data/kong/kong# 插件plugins = bundled# 管制节点role = control_plane# 证书cluster_cert = /data/kong/kong_cert/cluster.crt# 证书keycluster_cert_key = /data/kong/kong_cert/cluster.key# 治理后盾监听的端口 通过此端口进行数据的增加admin_listen = 127.0.0.1:8001# 集群监听端口cluster_listen = 0.0.0.0:8005# 数据库 相干信息依据本人状况进行批改database = postgres# 主机pg_host = 172.16.166.129 # 端口pg_port = 5432# 用户名pg_user = kong # 明码pg_password = kong # 数据库pg_database = kong启动Kongkong start部署数据节点将管制层面的证书复制到数据节点的文件夹中 /data/kong/kong_cert进入 /etc/kong ，创立配置文件 vim /etc/kong/kong-data.conf批改配置文件# kong工作的文件夹 因为我部署到一块了 所以批改了一下名字prefix = /data/kong/kong-data# 插件 以及自定义插件plugins = bundled# 数据立体role = data_plane# 敞开数据库 数据都从管制层面获取database = off#数据申请监听端口proxy_listen = 0.0.0.0:8000# 管制立体端口cluster_control_plane = 172.16.166.134:8005# 证书cluster_cert = /data/kong/kong_cert/cluster.crt# 证书keycluster_cert_key = /data/kong/kong_cert/cluster.key# 缓存大小设置 具体参考 此链接 https://docs.konghq.com/gateway/latest/plan-and-deploy/sizing-guidelines/#in-memory-caching# 4core and 8G ram 倡议 4-6G缓存mem_cache_size = 4028M启动kongkong start -c /etc/kong/kong-data.conf验证是否部署胜利执行以下命令，验证是否部署胜利,<admin-hostname> 替换为你的主机地址。 ...

不多说，性能测试结果直接给上： 我们将市场上的同类热门产品进行比较，使用相同的环境和条件，测试以下产品：Goku、Kong、Tyk。 注：本次压测对象均为单个网关节点，并且均未启用插件功能。 测试详情一、硬件环境1.后端服务所在服务器CPU: Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz * 12Linux version 3.10.0-957.27.2.el7.x86_64Total 48G，47G available memory 2.节点所在服务器CPU: Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz * 12Linux version 3.10.0-957.27.2.el7.x86_64Total 48G，47G available memory 3.压测程序所在服务器CPU：Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz * 4Linux version 3.10.0-957.27.2.el7.x86_64Total 16G，15G available memory 二、压测条件压测工具：Jmeter使用插件：concurrency thread group 阶梯式加压工具 压力配置： 基准测试报告一、直接访问后端服务Starting the test @ Tue Sep 24 19:02:40 CST 2019 (1569322960758)Remote engines have been startedWaiting for possible Shutdown/StopTestNow/Heapdump message on port 4445summary + 370204 in 00:00:18 = 20504.2/s Avg: 28 Min: 0 Max: 3412 Err: 0 (0.00%) Active: 1200 Started: 1200 Finished: 0summary + 743800 in 00:00:30 = 24792.5/s Avg: 80 Min: 0 Max: 15227 Err: 0 (0.00%) Active: 3000 Started: 3000 Finished: 0summary = 1114004 in 00:00:48 = 23180.9/s Avg: 63 Min: 0 Max: 15227 Err: 0 (0.00%)summary + 733900 in 00:00:30 = 24465.8/s Avg: 152 Min: 0 Max: 31097 Err: 0 (0.00%) Active: 4800 Started: 4800 Finished: 0summary = 1847904 in 00:01:18 = 23674.7/s Avg: 98 Min: 0 Max: 31097 Err: 0 (0.00%)summary + 726800 in 00:00:30 = 24227.5/s Avg: 221 Min: 0 Max: 32674 Err: 1 (0.00%) Active: 6000 Started: 6000 Finished: 0summary = 2574704 in 00:01:48 = 23828.2/s Avg: 133 Min: 0 Max: 32674 Err: 1 (0.00%)summary + 562492 in 00:00:53 = 10555.1/s Avg: 279 Min: 0 Max: 63191 Err: 23 (0.00%) Active: 0 Started: 6000 Finished: 6000summary = 3137196 in 00:02:41 = 19444.0/s Avg: 159 Min: 0 Max: 63191 Err: 24 (0.00%)Tidying up remote @ Tue Sep 24 19:05:23 CST 2019 (1569323123294)... end of run二、使用Goku API GatewayStarting the test @ Tue Sep 24 19:20:20 CST 2019 (1569324020256)Remote engines have been startedWaiting for possible Shutdown/StopTestNow/Heapdump message on port 4445summary + 97104 in 00:00:09 = 10927.8/s Avg: 36 Min: 1 Max: 1128 Err: 0 (0.00%) Active: 600 Started: 600 Finished: 0summary + 334400 in 00:00:30 = 11148.2/s Avg: 139 Min: 1 Max: 1382 Err: 0 (0.00%) Active: 2400 Started: 2400 Finished: 0summary = 431504 in 00:00:39 = 11097.5/s Avg: 116 Min: 1 Max: 1382 Err: 0 (0.00%)summary + 330100 in 00:00:30 = 11002.2/s Avg: 302 Min: 1 Max: 1599 Err: 0 (0.00%) Active: 4200 Started: 4200 Finished: 0summary = 761604 in 00:01:09 = 11056.0/s Avg: 197 Min: 1 Max: 1599 Err: 0 (0.00%)summary + 322600 in 00:00:30 = 10748.3/s Avg: 473 Min: 1 Max: 2114 Err: 0 (0.00%) Active: 6000 Started: 6000 Finished: 0summary = 1084204 in 00:01:39 = 10962.6/s Avg: 279 Min: 1 Max: 2114 Err: 0 (0.00%)summary + 316800 in 00:00:30 = 10564.9/s Avg: 568 Min: 1 Max: 2329 Err: 0 (0.00%) Active: 6000 Started: 6000 Finished: 0summary = 1401004 in 00:02:09 = 10870.1/s Avg: 344 Min: 1 Max: 2329 Err: 0 (0.00%)summary + 27696 in 00:00:05 = 5278.4/s Avg: 547 Min: 1 Max: 1963 Err: 0 (0.00%) Active: 0 Started: 6000 Finished: 6000summary = 1428700 in 00:02:14 = 10651.3/s Avg: 348 Min: 1 Max: 2329 Err: 0 (0.00%)Tidying up remote @ Tue Sep 24 19:22:35 CST 2019 (1569324155252)... end of run三、使用Kong GatewayStarting the test @ Tue Sep 24 19:26:51 CST 2019 (1569324411486)Remote engines have been startedWaiting for possible Shutdown/StopTestNow/Heapdump message on port 4445summary + 86604 in 00:00:08 = 10814.7/s Avg: 34 Min: 0 Max: 1039 Err: 0 (0.00%) Active: 600 Started: 600 Finished: 0summary + 358400 in 00:00:30 = 12056.0/s Avg: 123 Min: 1 Max: 3932 Err: 0 (0.00%) Active: 2400 Started: 2400 Finished: 0summary = 445004 in 00:00:38 = 11792.6/s Avg: 105 Min: 0 Max: 3932 Err: 0 (0.00%)summary + 343700 in 00:00:30 = 11371.8/s Avg: 271 Min: 4 Max: 15668 Err: 0 (0.00%) Active: 4200 Started: 4200 Finished: 0summary = 788704 in 00:01:08 = 11605.4/s Avg: 178 Min: 0 Max: 15668 Err: 0 (0.00%)summary + 345500 in 00:00:30 = 11602.9/s Avg: 398 Min: 4 Max: 31638 Err: 0 (0.00%) Active: 6000 Started: 6000 Finished: 0summary = 1134204 in 00:01:38 = 11604.7/s Avg: 245 Min: 0 Max: 31638 Err: 0 (0.00%)summary + 335200 in 00:00:30 = 11115.5/s Avg: 527 Min: 1 Max: 63127 Err: 0 (0.00%) Active: 6000 Started: 6000 Finished: 0summary = 1469404 in 00:02:08 = 11489.3/s Avg: 309 Min: 0 Max: 63127 Err: 0 (0.00%)summary + 46501 in 00:00:25 = 1828.7/s Avg: 1123 Min: 1 Max: 63166 Err: 6 (0.01%) Active: 0 Started: 6000 Finished: 6000summary = 1515905 in 00:02:33 = 9887.0/s Avg: 334 Min: 0 Max: 63166 Err: 6 (0.00%)Tidying up remote @ Tue Sep 24 19:29:25 CST 2019 (1569324565588)... end of run四、使用Tyk GatewayStarting the test @ Thu Sep 26 15:53:16 CST 2019 (1569484396886)Remote engines have been startedWaiting for possible Shutdown/StopTestNow/Heapdump message on port 4445summary + 10004 in 00:00:13 = 752.9/s Avg: 508 Min: 0 Max: 3021 Err: 0 (0.00%) Active: 900 Started: 900 Finished: 0summary + 7900 in 00:00:29 = 272.2/s Avg: 4769 Min: 1229 Max: 11116 Err: 0 (0.00%) Active: 2700 Started: 2700 Finished: 0summary = 17904 in 00:00:42 = 423.2/s Avg: 2388 Min: 0 Max: 11116 Err: 0 (0.00%)summary + 6000 in 00:00:30 = 197.9/s Avg: 13697 Min: 9694 Max: 16971 Err: 0 (0.00%) Active: 4500 Started: 4500 Finished: 0summary = 23904 in 00:01:13 = 329.1/s Avg: 5227 Min: 0 Max: 16971 Err: 0 (0.00%)summary + 8000 in 00:00:30 = 269.3/s Avg: 17018 Min: 15093 Max: 18762 Err: 0 (0.00%) Active: 6000 Started: 6000 Finished: 0summary = 31904 in 00:01:42 = 311.7/s Avg: 8183 Min: 0 Max: 18762 Err: 0 (0.00%)summary + 7400 in 00:00:31 = 241.8/s Avg: 22188 Min: 17459 Max: 25974 Err: 0 (0.00%) Active: 5481 Started: 6000 Finished: 519summary = 39304 in 00:02:13 = 295.6/s Avg: 10820 Min: 0 Max: 25974 Err: 0 (0.00%)summary + 5686 in 00:00:22 = 257.1/s Avg: 25384 Min: 23820 Max: 27167 Err: 0 (0.00%) Active: 0 Started: 6000 Finished: 6000summary = 44990 in 00:02:35 = 290.1/s Avg: 12661 Min: 0 Max: 27167 Err: 0 (0.00%)Tidying up remote @ Thu Sep 26 15:55:52 CST 2019 (1569484552762)... end of run相关链接项目地址：https://github.com/eolinker/g...控制台Docker：https://hub.docker.com/r/eoli...节点Docker：https://hub.docker.com/r/eoli...官网地址：https://www.eolinker.com ...

基于 Docker 的 Kong 的环境搭建本次操作都是基于 Docker 进行操作的，使用的 Kong 的版本是 1.2.0 ，使用的 PostgreSQL 版本是 9.6。本文档的前提是已经安装最新版 Docker，并能够连接至 Docker 官方镜像中心下载镜像。如果有不满足的条件，自行调整命令。 创建 Kong 专用网络 创建一个 Kong 相关镜像的专用网络，通过这个网络实现网络互通。 docker network create kong-network安装数据库 使用 Docker 安装 PostgreSQL 数据库，加入 Kong 专用网络，创建用户kong，创建数据库kong。 docker run -d \ --name kong-database \ --net kong-network \ -p 5432:5432 \ -e "POSTGRES_USER=kong" \ -e "POSTGRES_DB=kong" \ postgres:9.6初始化数据库 使用 Kong 官方镜像提供的功能初始化 PostgreSQL 数据库。因为接入了Kong专用网络，所以这里的KONG_PG_HOST 直接写 kong-database ，也就是前面创建的 PostgreSQL 数据库的容器 name。 docker run --rm \ --net kong-network \ -e "KONG_DATABASE=postgres" \ -e "KONG_PG_HOST=kong-database" \ -e "KONG_PG_PASSWORD=kong" \ -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \ kong:1.2.0 kong migrations bootstrap安装 Kong ...

概述什么是KongKong是一个在Nginx中运行的Lua应用程序，可以通过lua-nginx模块实现，Kong不是用这个模块编译Nginx，而是与OpenRestry一起发布，OpenRestry已经包含了lua-nginx-module，OpenRestry是Nginx的一组扩展功能模块。 为什么是KongKong是一个Api Gateway，通过插件的形式提供负载均衡，日志记录，身份验证，速率限制，转换等功能。 Kong可以很轻松扩展功能，模块化，可以运行在任何基础设施上。 术语Route：是请求的转发规则，按照Hostname和PATH，将请求转发给Service。 Services：是多个Upstream的集合，是Route的转发目标。 Consumer：是API的用户，里面记录用户的一些信息。 Plugin：是插件，plugin可以是全局的，绑定到Service，绑定到Router，绑定到Consumer。 Certificate：是https证书。 Sni：是域名与Certificate的绑定，指定了一个域名对应的https证书。 Upstream：是负载均衡策略。 Target：是最终处理请求的Backend服务。 特性动态负载均衡基于散列的负载均衡断路器健康检查WebsocketsOAuth2.0日志记录安全性 Syslog 监控 转发代理 认证 速率限制 故障检测和恢复 …… 更多详情参考：https://docs.konghq.com/hub/ 开源/企业对比 架构架构图 1.1版本以后支持无db模式 执行流程加入kong后，每个客户端对API的请求将首先到达Kong，然后被代理到最终API，在请求和响应之间，Kong将执行任何已安装的插件，扩展API功能集，Kong有效的成为每个API的入口点。 部署Kong支持在任何基础设施上运行，支持docker、packages、vagrant、Homebrew、CloudFormation、AWS、Azure、Kubernetes等。 本次部署基于package方式，部署软件版本。 软件版本Kong1.0.3Postgresql9.6Kong-dashboard3.5.001部署Postgresql docker run --name postgres -e POSTGRES_PASSWORD=123456 -p 5432:5432 -d postgres:9.602创建用户及数据库 登陆 psql - U postgres - h 10.20 . 1.190 - p 5432 创建用户 create user kong with password ‘ kong ’; ...

说道Kong的管理GUI，网上说的比较多的都是kong-dashboard，但目前最新版（v3.6.0）似乎并未支持1.1.0的Kong，因此需要再另找替代。目前在github能找到star比较多的就是konga了konga部署安装下载源码：$ git clone https://github.com/pantsel/konga.git修改配置$ cd konga$ cp .env_example .env$ vi .envkonga环境变量配置说明：PORT=1337 # Konga的Web服务监听端口NODE_ENV=production # 环境代码，建议使用productionKONGA_HOOK_TIMEOUT=120000 # Konga调用管理API的最长回调等待时间DB_ADAPTER=postgres # 数据库类型,支持mongo,mysql,postgres,sqlserverDB_HOST=localhostDB_PORT=5432DB_DATABASE=kongaDB_USER=konga # 数据库用户名DB_PASSWORD=konga # 数据库密码KONGA_LOG_LEVEL=warn # 日志等级TOKEN_SECRET=some_secret_token配置数据库$ su - postgres$ psql# 创建用户postgres=# CREATE USER konga WITH PASSWORD ‘konga’;# 创建数据库postgres=# CREATE DATABASE konga OWNER konga;# 授权postgres=# GRANT ALL PRIVILEGES ON DATABASE konga TO konga;[可选]如果想让pg能使用密码授权，需修改pg_hba.conf：# vim /var/lib/pgsql/11/data/pg_hba.conf初始化konga数据库node ./bin/konga.js prepare –adapter postgres –uri postgresql://konga:konga@localhost:5432/konga安装依赖并运行$ npm i$ npm run production运行后通过http://host:1337即可访问管理端，首次使用会先要求创建管理员帐号，创建后登录后进入KongAPI的配置界面，按提示配置即可：如果Kong中设置了验证的话，请根据Kong的配置选择KEY AUTH或JWT AUTH并填好相关信息创建链接后，即可进入主界面

我们只演示在 services 上配置jwt认证。service 开启 jwt 插件#创建一个需jwt验证的服务 成功响应返回baiducurl -x POST localhost:8001/services-d “name=service.jwt”-d “url=http://www.baidu.com”#查看插件列表curl -x GET localhost:8001/services/service.jwt/plugins#开启jwt插件curl -x POST localhost:8001/services/service.jwt/plugins-d “name=jwt”#查看jwt插件curl -x GET localhost:8001/services/service.jwt/plugins/jwt#删除jwt插件curl -x DELETE localhost:8001/services/service.jwt/plugins/{jwt.id}创建 route为service.jwt服务绑定routecurl -x POST localhost:8001/services/service.jwt/routes-d “name=route.jwt”-d “paths[]=/api/v1"创建一个 consumercurl -x POST localhost:8001/consumers -d “username=consumer.jwt”{ “custom_id”: null, “created_at”: 1553681695, “username”: “consumer.jwt”, “id”: “2e34d380-ec48-4a0d-926f-6dd8696a7eca”}创建 consumer 的 jwt 凭证可以指定算法algorithm，iss签发者key，密钥secret，也可以省略，会自动生成。curl -x POST localhost:8001/consumers/consumer.jwt/jwt -d “algorithm=HS256” -d “key=big_cat” -d “secret=uFLMFeKPPL525ppKrqmUiT2rlvkpLc9u”//response{ “rsa_public_key”: null, “created_at”: 1553681782, “consumer”: { “id”: “2e34d380-ec48-4a0d-926f-6dd8696a7eca” }, “id”: “61ee520c-3387-42f0-8e5f-02e0dc34d3d4”, “algorithm”: “HS256”, “secret”: “uFLMFeKPPL525ppKrqmUiT2rlvkpLc9u”, “key”: “7Xc3L8TdFpU6kgPEeR4iqMAstqLewJSS”}查看 consumer jwt 凭证curl -x GET localhost:8001/consumers/comsumer.jwt/jwt// 这里我们创建了 2个 jwt 凭证{ “next”: null, “data”: [ { “rsa_public_key”: null, “created_at”: 1553682659, “consumer”: { “id”: “2e34d380-ec48-4a0d-926f-6dd8696a7eca” }, “id”: “6966cec4-6d25-4642-983b-95e512eef608”, “algorithm”: “HS384”, “secret”: “WF3Ig85MgyGMZjvSCoKLOwOevZkD8jNG”, “key”: “big_cat” }, { “rsa_public_key”: null, “created_at”: 1553681990, “consumer”: { “id”: “2e34d380-ec48-4a0d-926f-6dd8696a7eca” }, “id”: “e3d34707-0f4f-4c2d-ae54-25aaed6c9211”, “algorithm”: “HS256”, “secret”: “yBcPzjWsaW0dMquiWCOGlH2ILDQfJIya”, “key”: “wP7ZxrL4OgMVViwE8GYcaYq57cVa2IHL” } ]}jwt 下发业务服务器根据kong生成的jwt凭证中的algorithm、key（iss）、secret进行token的演算和下发。请求鉴权接口需携带Authorization: Bearer jwt进行请求。测试的话可以用 https://jwt.io 生成：请求带有jwt认证的服务的路由curl -X GET localhost:8000/api/v1 -H ‘Authorization: Bearer eyJhbGciOiJIUzM4NCIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJiaWdfY2F0Iiwic3ViIjoiMTIzNDU2Nzg5MCIsIm5hbWUiOiJKb2huIERvZSIsImlhdCI6MTUxNjIzOTAyMn0.8yO2FmP23u2sS3kq94B39uT23SU2WVNuslPTeSJaHfBLoCT4oNmFTODfHS3s6sot’//返回了baidu首页<html> <head> <script> location.replace(location.href.replace(“https://”,“http://”)); </script> </head> <body> <noscript> <meta http-equiv=“refresh” content=“0;url=http://www.baidu.com/"> </noscript> </body></html>否则// 401{ “message”: “Unauthorized”} ...

负载均衡route根据paths转发给相应的service根据host（upstream的name）转发给 upstream负载均衡至targets，这就是kong的负载均衡执行流程，下面通过restApi分别配置upstream,service,route。upstreams创建名为upstream.api的upstreamcurl -X POST localhost:8001/upstreams-d “name=upstream.api”// reponse{ “created_at”: 1553661443, “hash_on”: “none”, “id”: “04c9c36c-eea8-4d58-8668-3bfa117c34fd”, “name”: “upstream.api”, …}为upstream.api添加后端服务器curl -X POST localhost:8001/upstreams/upstream.api/targets -d “target=192.168.20.6:8888” -d “weight=100”// reponse{ “created_at”: 1553663185.86, “upstream”: { “id”: “04c9c36c-eea8-4d58-8668-3bfa117c34fd” }, “id”: “3386af25-8643-4c9c-aff5-bd30451ae24b”, “target”: “192.168.20.6:8888”, “weight”: 100}curl -X POST localhost:8001/upstreams/upstream.api/targets -d “target=192.168.20.6:9999” -d “weight=100”// reponse{ “created_at”: 1553663185.86, “upstream”: { “id”: “04c9c36c-eea8-4d58-8668-3bfa117c34fd” }, “id”: “3386af25-8643-4c9c-aff5-bd30451ae24b”, “target”: “192.168.20.6:9999”, “weight”: 100}等同于创建了如下配置：upstream upstream.api { server 192.168.20.6:8888 weight=100; server 192.168.20.6:9999 weight=100;}services创建名为service.api的服务，并通过host绑定相应的后端服务upstream.api。curl -X POST localhost:8001/services/service.api-d “name=service.api”-d “host=upstream.api”//{ “host”: “upstream.api”,//绑定的upstream “created_at”: 1553663485, “connect_timeout”: 60000, “id”: “5b93eda7-7ba5-4acc-a536-cf12f58a1144”,//service.id “protocol”: “http”, “name”: “service.api”, “read_timeout”: 60000, “port”: 80, “path”: “/api/v1”, “updated_at”: 1553663485, “retries”: 5, “write_timeout”: 60000}等同于http { server { listen 8000; location waiting-for-define { proxy_pass http://upstream.api; } }}routes为服务service.api绑定路由。需要理解，route并非一条url，它是kong的路由服务，可以为某个kong服务管理管理一套路由集合，route就相当于 http > server 中的 location 规则集合。#为service.api添加路由集合curl -X POST localhost:8001/routes -d “name=route.api” -d “paths[]=/api/v1” -d “paths[]=/api/v2” -d “paths[]=/api/v3” -d “hosts[]=api.service.com” -d “hosts[]=service.com” -d “service.id=5b93eda7-7ba5-4acc-a536-cf12f58a1144”#或者通过 services 的接口curl -X POST localhost:8001/services/service.api/routes -d “name=route.api” -d “paths[]=/api/v1” -d “paths[]=/api/v2” -d “paths[]=/api/v3” -d “hosts[]=localhost” -d “hosts[]=api.service.com” -d “hosts[]=service.com” \我们还同时指定了hosts，相当于server_name，顺手把虚拟主机也做了。大致等同于如下配置：http { server { listen 8000; server_name localhost api.service.com service.com; location /api/v1 { proxy_pass http://upstream.api; } location /api/v2 { proxy_pass http://upstream.api; } location /api/v3 { proxy_pass http://upstream.api; } }}这样我们可以通过localhost:8000/api/v1api.service.com:8000/api/v2service.com:8000/api/v3来访问 service.api服务，此服务后端有两台服务器做 LB。 ...

Kong 镜像: https://hub.docker.com/_/kong官网给定的用户安装手册上并没有设置 PG 的密码，导致如下问题无法启动nginx: [error] init_by_lua error: /usr/local/share/lua/5.1/kong/init.lua:277: [PostgreSQL error] failed to >retrieve server_version_num: connection refusedstack traceback:[C]: in function ‘assert’/usr/local/share/lua/5.1/kong/init.lua:277: in function ‘init’init_by_lua:3: in main chunk后在 issues 中找到问题原因及解决方法（里面还有个docker-compose）：https://github.com/Kong/docke…使用 docker 的安装Kong 使用 postgresql 或 cassandra 存储数据，这里我们选用 PG# 创建 pg 数据库 容器docker run -d –name kong-database -p 5432:5432 -e “POSTGRES_USER=kong” -e “POSTGRES_DB=kong” -e “POSTGRES_PASSWORD=your_pg_password” \postgres:9.6# kong 数据迁移到 pgdocker run –rm --link kong-database:kong-database \ #将 kong-database 容器的地址引入注册到本容器-e “KONG_DATABASE=postgres” -e “KONG_PG_HOST=kong-database” -e “KONG_PG_PASSWORD=your_pg_password” \ # 官方文档未给出此参数 PG 可能不支持无密登录了-e “KONG_CASSANDRA_CONTACT_POINTS=kong-database” \kong kong migrations bootstrap#创建 kong 容器docker run -d –name kong --link kong-database:kong-database -e “KONG_DATABASE=postgres” -e “KONG_PG_HOST=kong-database” -e “KONG_PG_PASSWORD=your_pg_password” -e “KONG_CASSANDRA_CONTACT_POINTS=kong-database” -e “KONG_PROXY_ACCESS_LOG=/dev/stdout” -e “KONG_ADMIN_ACCESS_LOG=/dev/stdout” -e “KONG_PROXY_ERROR_LOG=/dev/stderr” -e “KONG_ADMIN_ERROR_LOG=/dev/stderr” -e “KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl” -p 8000:8000 \ # http 代理端口-p 8443:8443 \ # https 代理端口-p 8001:8001 \ # http 管理接口-p 8444:8444 \ # https 管理接口kong#查看是否启动docker ps#如未启动通过日志查看问题docker logs kong#如正常启动 可访问管理Api（替换成你的IP）curl -X GET http://192.168.20.6:8001因为 kong 服务是在容器中，所以设 KONG_ADMIN_LISTEN 为全局监听才能通过宿主机IP代理访问，宿主机则需对相应的映射端口做访问限制，如本机/内网访问，且不应该对外网可访问，不然谁都可以改你的Api网关策略了。自定义 kong 配置文件kong docker 镜像的配置文件路径为 /etc/kong/kong.conf如需自定义配置文件，自行挂载即可。kong 配置项手册：https://docs.konghq.com/1.0.x……-v /opt/kong/kong.conf:/etc/kong/kong.conf…管理网关的API的使用教程这里就不写了，自行觅食吧~简单的看看下面这篇可以的Kong 集成 Jwt 插件：https://www.cnkirito.moe/kong…kong服务网关API:https://www.jianshu.com/p/ef6… ...