API网关升级布署方案（Nginx->Kong）

本文介绍如何从现有的Nginx代理服务器升级到Kong

现状

目前我们使用Nginx管理以下内容

  • 反向代理
  • 负载均衡
  • 静态页面的服务器
  • 端口转发

四套环境

  • 开发
  • 测试
  • 集成
  • 生产

升级方案

方案一

  1. 接口的反向代理和负载均衡使用Kong，静态页面的服务器和端口转发仍然使用Nginx
  2. Kong的端口使用8000/8443，Nginx端口使用80/443
  3. 升级后，前后端需要使用不同的域名：前端沿用目前的不变，服务端API域名增加一个api后缀区分，如：前端域名为：dev.51trust.com，服务端API域名为：dev-api.51trust.com
  4. 前端请求接口的写法需要调整，目前假设前后端使用相同域名，编码上采用相对路径；升级后，需要把相对路径修改

优点：前后端分流，减轻Nginx压力

缺点：接口调用需要调整，尤其是第三方厂商的调用和低版本App兼容，调整成本较高

方案二

前两点和方案一相同

  1. 升级后，前后端仍然使用相同的域名，所有流量先打到Nginx，然后优先匹配前端路由，没有匹配项时转到Kong
  2. 前后端无需任何调整

优点：前后端接口无需任何调整

缺点：Nginx流量压力没有减轻

布署方案

  1. konga为管理端，可通过配置，管理所有kong节点，布署2套，阿里云：192.168.1.6，内网：192.168.126.21
  2. konga云端的访问域名：kong.51trust.com，内网使用IP访问
  3. kong布署4套，每个环境一套，复用Nginx节点，Kong的端口使用8000/8443，Nginx端口使用80/443（生产环境目前医师端和公众端的Nginx是分开的，暂时保持不变，每个Nginx对应一个Kong）
  4. pgsql布署2套，内网一套（192.168.126.122），已部署，云端一套（192.168.2.12，复用redis副本）
  5. kong数据库，名称：开发：kongdev，测试：kongbeta，集成：kongpre，生产：kongon，用户名密码共用一套