基于Apache APISIX，新浪微博API网关的定制化开发之路

微博之前的 HTTP API 网关基于 NGINX 搭建，所有路由规则存放在 NGINX conf 配置文件中，带来一系列问题：升级步骤长，对服务增、删、改或跟踪问题时，不够灵活且难以排查问题。经过一番调研之后，我们选择了最接近预期、基于云原生的微服务 API 网关：Apache APISIX，借助其动态、高效、稳定等特性以满足业务的快速响应要求。

1、背景说明

在微博，运维同学要创建一个 API 服务，他需要先在 nginx conf 配置文件里面写好，提交到 git 代码仓库里面去，等其它负责上线的运维同学 CheckOut 之后，确认审核成功，才能它们推送部署到线上去，继而粗暴通知 NGINX 重新加载，这才算服务变更成功。

整个处理流程较长，效率较低，无法满足低代码化的 DevOps 运维趋势。因此，我们期待有一个管理后台入口，运维同学在 UI 界面上就可以操作所有的 http api 路由等配置。

经过一番调研之后，我们选择了最接近期盼的基于云原生的微服务 API 网关：Apache APISIX。比较看重的点，有这么几个：

1. 基于 NGINX ，技术栈前后统一，后期灰度升级、安全、稳定性等有保障；
2. 内置统一控制面，多台代理服务统一管理；
3. 动态 API 调用，即可完成常见资源的修改实时生效，相比传统 NGINX 配置 + reload 方式进步明显；
4. 路由选项丰富，满足微博路由需求；
5. 较好扩展性，支持 Consul kv 难度不大；
6. 性能表现也不错。

2、为什么选择定制化开发？

实际业务情况下，我们是没办法直接使用 Apache APISIX 的，原因有以下几点：

1. Apache APISIX 不支持 SaaS 多租户，实际需要运维的业务线上层应用有很多，每个业务线的开发或运维同学只需要管理维护自己的各种 rules、upstreams 等规则，彼此之间不相关联；
2. 当把路由规则发布到线上后，如果出现问题则需要快速的回滚支持；
3. 当新建或者编辑现有的路由规则时，我们不太放心直接发布到线上，这时就需要它能够支持灰度发布到指定网关实例上，用于仿真或局部测试；
4. 需要 API 网关能够支持 Consul KV 方式的服务注册和发现机制；

上述这些需求目前 Apache APISIX 都没有内置支持，所以只能通过定制开发才能让 Apache APISIX 真正在微博内部使用起来。

3、在 Apache APISIX 的控制面，我们改了些什么？

我们定制开发时，使用的 Apache APISIX 1.5 版本，Dashboard 也是和 1.5 相匹配的。

定制开发的目标简单清晰，即完全零代码、UI 化，所有七层 HTTP API 服务的创建、编辑、更新、上下线等所有行为都必须在 Dashboard 上面完成。因此实际环境下，我们禁止开发和运维同学直接调用 APISIX Admin API，假如略过 Dashboard 直接调用 APISIX Admin API，就会导致网关操作没办法在 UI 层面上审计，无法走工作流，自然也就没