共计 3601 个字符，预计需要花费 10 分钟才能阅读完成。
背景介绍
金山办公是目前国内最大的办公软件厂商，旗下产品波及 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/…
