作者：胡功林
部署方案的要求
- 网关对用户请求的处理完全符合预期，保证结果准确。
- 新老网关切换过程中要求平滑切换，调用方无感知。
- 需要线上灰度一段时间。
- 灰度期间，两个网关同时生效，两个网关之间的数据需要保持一致性。
上线前的准备工作
- 网关客户端SDK测试。 SDK封装了请求头设置及请求签名方法，我们提供了PHP，Golang，Java，Python的SDK，基于我们提供的接口及用户数据，我们对分别对每一个用户，使用我们提供的 SDK 对全部接口做了测试，以确保数据和功能正常。
- 迁移underload网关数据到kong网关。 Underload 网关的数据是业务方认证数据权限数据的一份同步数据，我们以业务方数据为准，把业务方数据转换为 Kong 网关运行所需要的数据。在实际的迁移过程中，我们最开始的方案是以 Underload 网关数据为准进行迁移，后对比业务方用户及用户权限数据发现 Underload 网关数据存在冗余数据，后查实是业务方同步用户及用户权限信息存在 bug 导致 Underload 网关数据存在冗余，所以后来我们决定以业务方数据为准，把业务方用户及用户权限相关数据同步到 Kong 网关。
上线过程
根据以上部署要求，我们在部署新网关的过程中采取了以下局部的小方案来满足上述要求：
- 部署的结果要求准确。针对准确性，我们在业务服务上使用 Nginx 流量镜像做准确性验证，所有通过 Underlord 网关的请求在转发给 service_a 的同时通过 mirror 到 Kong 网关，这些请求如果能全部通过Kong 的插件验证，则说明针对合法请求的处理，两个网关的处理结果是一致的。
ps：此方案需要考虑的是，mirror 到 Kong 网关的用户请求会不会再次转发给 service_a 处理。建议做准确性验证的时候，Kong 网关后面不要接入真实的业务服务，以免一些非幂等性的请求产生错误的业务数据。关于 Nginx mirror 配置，可参考 http:// nginx.org/en/docs/http/ ngx_http_mirror_module.html#mirror
- 部署过程要求平滑，用户无感知。针对平滑性，我们让原 Underlord 网关与 Kong 网关并行运行，通过前置 SLB_for_gateway 控制两种网关的流量权重，逐步减少原 Underlord 网关的流量，增大 Kong 网关的流量，实现平滑切换。同时该方案也是灰度方案。
ps：上述针对准确性的验证，我们是单独做的。与实现平滑性的部署方案无关。
- 灰度期间，两个网关同时生效，所以两个网关处理用户请求所需要的数据（比如实现用户请求token有效性验证的数据，实现用户请求服务访问权限验证的数据）需要保持一致。我们此次以业务数据为准，定时主动的通过Kong 网关提供的管理接口，同步用户、用户认证token、用户权限等数据，这里的实现方案不具普适性，就不再赘述。
线上运行监控
- 使用了 Kong 提供的 http-log 插件记录用户的请求及业务接口响应，这些 log 数据记录在 hive，基于这些 log 数据，可以出相关的汇总报表。
http-log 实际使用过程中如 queue_size 参数设置不当，会存在内存泄露的情况。我们生产环境该参数值为100。
- 使用 Promtheus 实时对 response StatusCode 进行计数，Grafana 基于 Promtheus 的统计数据在监控后台进行展示，及时发现 response StatusCode 异常情况并进行告警。同时在满足用户需求的前提下，使用 Kong 提供的 rate-limiting 插件对用户的请求频率做了限制，避免用户因接口使用不当而对网关及后端服务产生不必要的压力。