背景介绍
金山办公是目前国内最大的办公软件厂商，旗下产品涉及 WPS、金山文档、稻壳等。在业务层面上由数千个业务以容器化部署在内部云原生平台，目前 Apache APISIX 在金山办公主要负责为中台部门业务（百万级 QPS ）提供相关网关服务。
金山办公的网关演进
在 1.0 阶段时，我们对于 API Gateway 的特性没有什么强需求，只是想解决运维问题，所以基于 OpenResty 与 Lua 进行了自研，实现了动态 Upstream、黑名单、waf 等功能。
虽然自研成功，但在功能上却遗留了一些问题，比如：
- 动态化只做到到 Upstream 维度
- 需要 Reload 才能带出新域名
- 底层设计简单，功能扩展能力不强
后续我们对 API Gateway 功能有了强需求后，开始去调研相关的开源网关产品。
为什么选择了 Apache APISIX？
实际上 2019 年年底开始调研网络产品时，Kong 算是一个比较流行的选择。
但后续经过测试发现，Kong 的性能不太能满足我们的需求，同时我们认为 Kong 的架构不是很优秀：因为其配置中心选用 PostgreSQL，所以 Kong 只能利用非事件驱动去更新路由，依赖每个节点去刷新路由。
进一步调研时，我们发现了 Apache APISIX。首先 Apache APISIX 的性能比 Kong 强，在 Apache APISIX 的 GitHub Readme 中有个非常详细的对比图，列出了两者的性能测试差距，这与我们自己测试下来的数据基本一致。
更多关于 Apache APISIX 与 Kong 的性能测试数据参考，可以查阅： https://gist.github.com/membp...
在架构方面，Apache APISIX 的 etcd 配置对我们而言是一项更优的选择。
当然，最主要的原因是我们觉得社区也很重要。社区如果活跃，在版本更新迭代、问题解决和功能优化上的速度就会很快。从 GitHub 和平时的邮件反馈中我们看到了 Apache APISIX 社区的活跃，为产品功能和稳定性提供了强有力的保证。
网关平滑迁移经验分享
大部分朋友在开始接触 Apache APISIX 时，都会用 CLI 去生成配置并起实例。但在我们做平滑迁移的过程中，并没有使用 CLI 去生成配置。
主要原因是 Apache APISIX 在 OpenResty 中会生效一些 Phase，比如初始化 init、init\_worker、HTTP 和 Upstream 相关 Phase 等。对应到 Apache APISIX 的配置后我们发现，这些都可以脱离 CLI 而存在。
所以基于上述原因，我们最终采取了如下行动进行平滑迁移：
- 不使用 Apache APISIX 的 CLI 生成配置
- 引入 Apache APISIX 的 Package Path 并将 Apache APISIX 作为 Default Server
- 保留其它静态配置中的域名，由于新域名未在静态配置中，将 Fallback 到 Apache APISIX
- 最终将静态配置逐渐迁移到 Apache APISIX 中
当然，除了上述方法，我们也给大家推荐一种「轻混模式」，即使用静态配置配合 Apache APISIX 作为 Location，引入前边提到的一些 Phase 或 Lua 代码进行配置即可。这样做可以在静态配置中引入一些特殊配置，实现动态化等效果。
基于 Apache APISIX 的 Shared State 改进
首先在我个人看来，「转发效率一定不是问题，而 Shared State 是影响稳定性的最大因素」，为什么这么说？
因为转发效率可以通过横向扩容去解决，但 Shared State 是所有的节点共享的，所以是至关重要的模块。
所以在使用 Apache APISIX 后，我们主要针对 Shared State 层面进行了一些调整与优化。
优化一：多台机器监听下的 etcd 架构优化
一般公司网关架构中，都会涉及多台机器，有的可能多至几百台，同时每台机器还要顾及 worker 数量。所以当多台机器监控相同 Key 时，etcd 的压力就会比较大，因为 etcd 的其中一个机制是为了保证数据一致性，需要所有事件返回给监听请求后才能处理新请求，当发送缓冲满了后就会丢弃请求。所以当多台机器同时监听时就会导致 etcd 超时运行，提示 Overload 报错等状况。
针对上述问题，我们使用了自研的etcd Proxy。之前 Apache APISIX 与 etcd 的连接关系如下图左侧所示，每个节点均与 etcd 连接。所以作为一个大规模入口时，连接数量会特别大，对 etcd 造成压力。
既然是监听相同的 Key，我们做了一个代理来进行统一监听，当有结果反馈时，再返回给 Apache APISIX。具体架构如上图右侧所示，在 Apache APISIX 和 etcd 中间放置了 etcd Proxy 组件来监控 Key 值的变化。
优化二：解决路由生效过程中的性能问题
随着公司规模提升，路由数量的增长也会随之而来。我们在实践过程中发现在每次路由更新时，Apache APISIX 都会重建用来匹配路由的前缀树。这个主要是由于 table.sort 性能不足所导致的。
在实践过程中，我们观察到路由频繁更新时，网关 CPU 升高、丢包率升高，进一步排查后发现丢包率升高的主要原因为 Listen overflow 所造成。
在 CPU 升高现象上，通过火焰图可以明显看到大部分 CPU 的时间都是划在 auxsort 上，它是由 FUNCC 触发。而 FUNCC 的触发也指明了一个问题，就是证明相关数据没有经过 LuaJIT，只有图中最右侧的一小部分处理了正常请求。
出现这种现象的原因主要是 LuaJIT 的 table.sort 不是完全依靠 JIT 模式，这点可以在 LuaJIT 官网 wiki 中看到相关说明，所以在 Lua 代码环境中使用 table.sort 效率是比较低的。
针对这个问题，我们自己使用纯 Lua 代码实现了针对上述场景的 sort 配置进行了解决，但其实 Apache APISIX 在之后的版本更新中已经修复了这项问题，具体思路也跟我们理解的类似。
更多 Shared State 使用经验
在修改 Apache APISIX 或者自己进行插件开发时，确保做好 Schema 校验，包含判空，尤其是在匹配部分。因为在匹配部分出问题的话，会造成整体性的影响。
做好业务拆分规划。根据业务量去规划好相关 etcd Prefix 和 IP 数量，部署更稳固的集群，把系统性风险降到最低
开源话题讨论
稳定性与功能层面的取舍
目前金山办公使用 Apache APISIX 已经快两年了，作为产品用户，我认为 Apache APISIX 确实是一款稳定可信的开源产品，在绝大多数情况下，都会及时地与社区最新版本保持一致。
但是一般接触并应用过开源产品的公司应该都有体会，升级版本会有一些新功能的出现，但同时也会带来一些稳定性上的问题，所以在升级版本和稳定性中我们应该如何取舍。
这个问题肯定没有统一的答案，但是我个人觉得针对 Apache APISIX 这项产品，尽量与官网版本保持一致。
就金山办公而言，我们目前因为大规模使用到 Apache APISIX，所以对稳定性有极致追求。之前跟不上官方更新进度时也对我们的使用造成了一定程度的影响，所以推荐大家尽量与官方版本保持一致。
如果说你像我们一样，有时候可能跟不上官方版本，至少也应该做到每周查阅 GitHub 的 Master Change Log 等相关文档，时刻关注产品变化。
Apache APISIX：https://github.com/apache/apisix
基于 Apache APISIX 产品化经验
我们基于 Apache APISIX 包装了很多产品化功能，比如多机房应用比例切量、一键封禁路由等。在实践应用过程中，我们认识到 Apache APISIX 是一个极其灵活强大的产品，所以在进行产品化改造时我们就应该明白一个点：强大 = 避免不了的复杂和危险。
这点在 Apache APISIX 本身的代码设计上也有很多的体现，比如一些插件的改造可能就需要自己去编译，因为毕竟各自应用起来时场景没有办法做到统一。
最后，基于我们前边提到的实践经验，也建议大家在进行 Apache APISIX 项目产品化时，提前规划好网关共享的颗粒度，减少后续使用问题。
关于作者
作者张强，金山办公中台部门 SRE 网络负责人。
关于 Apache APISIX
Apache APISIX 是一个动态、实时、高性能的开源 API 网关，提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。Apache APISIX 可以帮助企业快速、安全地处理 API 和微服务流量，包括网关、Kubernetes Ingress 和服务网格等。
Apache APISIX 落地用户（仅部分）
- Apache APISIX GitHub：https://github.com/apache/apisix
- Apache APISIX 官网：https://apisix.apache.org/
- Apache APISIX 文档：https://apisix.apache.org/zh/...