为什么选择了 Apache APISIX
考虑到产品成熟度和可拓展性，最终我们在 Kong 和 Apache APISIX 中进行对比选择。
从上图对比中可以发现，两者在很多方面基本不相上下，所以存储端成为我们重点考虑的一点。因为 etcd 在我们公司内部的运维体系上已经比较成熟，所以 Apache APISIX 相较 Kong 则略胜一筹。
同时考虑到在开源项目层面，Apache APISIX 的国内交流与跟进处理速度上都非常优秀，项目的插件体系比较丰富全面，对各个阶段的使用类型都比较契合。
所以在 2020 年调研之后，最终选择了 Apache APISIX 作为有赞即将推出云原生 PaaS 平台的流量网关。
使用 Apache APISIX 后的产品新貌
当我们开始接入 Apache APISIX 后，前文提到的两方面问题逐一得到了解决。
效果一：优化了架构性能
Apache APISIX 作为入口网关部署在内部服务区域边缘，前端的所有请求都会经过它。同时我们通过 Apache APISIX 的插件功能实现了与公司内部 CAS 单点登录系统的对接，之前负责流量转发的账号变为纯业务系统。同时在前端我们提供了一个负责鉴权的 SDK 与 Apache APISIX 鉴权接口进行对接，达成一套完整又自动化的流程体系。
于是问题得到了解决：
- 每次增加新的后端服务，只需调用 Apache APISIX 接口，将新的服务配置写入
- 流量转发通过 Apache APISIX 完成，在网关该做的事情上，它完成得十分优秀
- 网关不再是架构中的性能瓶颈
- 对不同的业务需求，可以统一使用同一个网关来实现；业务细节有差异，可以通过插件实现
效果二：内部服务接入标准化
接入 Apache APISIX 后，公司新的内部服务接入时将自带鉴权功能，接入成本极低，业务方可以直接开始开发业务代码。同时在新服务接入时，按内部服务的规范进行相关路由配置，后端服务可以统一拿到鉴权后的用户身份，省时省力。
具体关于内部服务的一些调整细节这里简单介绍一下。
鉴权插件 OPS-JWT-Auth
鉴权插件是基于 JWT-Auth 协议去开发的，用户访问前端时，前端会先去调用 SDK，去前端本地获取可用的 JWT-Token。然后通过下图的路径获得用户有效信息，放在前端的某个存储里，完成登录鉴权。
部署配置升级
在部署层面，我们从简单版本经历三次迭代后实现了目前的多集群配置部署。
-
版本一：双机房 4 个独立节点，管理程序分别写入每个节点的 etcd
-
版本二: 双机房 4 个独立节点，主机房三节点 etcd 集群
-
版本三: 三机房 6 个独立节点，三机房 etcd 集群
目前我们还是计算与存储混合部署在一起，后续我们会去部署一个真正高可用的 etcd 集群，这样在管控平面 Apache APISIX 运行时就可以分离出来，以无状态模式部署。
新增鉴权插件 PAT-Auth
在今年我们又新增了 Person Access Token（PAT）的鉴权插件，这个功能类似于在 GitHub 上去调用 Open API 一样，会生成一个个人 Token，可以以个人身份去调用 Open API。
因为我们自己的运维平台也有一些这样的需求，比如本地的一些开发插件需要以个人身份去访问云平台上的接口时，这种情况下个人 Token 方式就比较方便，允许开发自己给自己授权。
目前 Apache APISIX 2.2 版本后已支持多个 Auth 插件使用，现在可以支持一个 Consumer 运行多个 Auth 插件的场景实现。