本次内容来自咱们团队同学简海青（视源股份运维负责人）在 APISIX 沙龙上的共享。
网关往期迭代与痛点
希沃网关的发展阅历了四个版本的迭代。2013 年公司开端尝试互联网事务，那时候采用了 OpenResty+NGINX 静态装备的方法搭建了最初的网关，开发人员经过 SCP 来发布。与此一起一个比较严重的问题便是，每次上线发布都需求运维人员的协助才能保证平滑上线。
随着事务的发展和人员的扩大，2016 年咱们开发了第二代发布体系和相关迭代网关。这次是根据 OpenResty 集成了 upsync 模块，一起合作 Consul 来进行服务发现。第二代的体系处理了上一代开发人员无法独立发布上线的问题，但仍需求运维协助才能进行扩容。
之后公司事务开端了迅猛发展，开端对网关以及产品的弹性扩缩才能有了更高的要求。2018 年咱们根据 K8s 开发了第三代体系。考虑到仍有部分运用留传在数组机上，所以整个网关架构是在 K8s 上运用 Ingress NGINX 来当作第二层的网关，第一层网关仍是 OpenResty 合作的双层网关架构。这种状况下尽管处理了前代发布扩容等自助问题，但又引入了新的麻烦。
事务的快速扩大致使关于整体稳定性的要求越来越高。采用这种双层网关架构后，一层 NGINX reload 和二层网关的路由改变，都会形成长衔接断开。这关于一些长衔接运用场景，比方软件对教师的授课状况获取就会断开，从而影响授课进程。
从上图的网关流量拓扑图能够看到咱们前文提到的双层网关架构，本身双层架构就会带来成本层面的一些增加。在双层网关架构下，现在都会呈现 reload 改变的场景，不管是在第一层网关添加域名、修正装备或许添加一些特别规矩等，都需求 reload NGINX。
一起从整体架构来看，组件的合作关于流量操控层面来说比较差。尤其是现在咱们的事务用户体量已到达千万等级，一旦客户端呈现不行躲避的反常，就有或许呈现侵蚀服务端的状况，这种时候假如在网关层面没有必定的流量操控才能，关于后端来说将会形成十分严重的雪崩。
因此，根据上述迭代留传问题和架构痛点，在 2022 年咱们引入了 APISIX 来处理上述问题。一起借助 APISIX，也加强了在网关层面关于流量的操控才能。
可是在搬迁 APISIX 的进程中，也会存在一些已知应战。比方：
- ⼀层 NGINX 域名多，定制化规矩杂乱。现在咱们的事务中有 700+ 域名，一起还存在十分多的定制化装备，比方重定向、黑⽩名单等，这些都需求适配 APISIX 的插件。
- 因为前史留传问题，⼀层 NGINX 和⼆层 Ingress 网关还是⼀对多的联系，关于后续的流量切换是不是会很杂乱，这也是一个待处理问题。
- 内部存在的双层 DNS 架构。现在 DNS 解析主要用于处理公网和服务器内部的解析，所以关于后续的计划咱们更希望是一个能方便回滚一起能够优化内网调用功用的。
搬迁 APISIX 后架构调整
面对上述已知的应战，在搬迁进程中主要进行了以下三个角度的操作。因为整个搬迁进程没有涉及研发内容，所以全部都是由运维人员实施的。
在搬迁进程中，首要要做的便是 APISIX 路由的生成。根据本来的架构，咱们去掉了一层特别功用，比方 rewrite、set-header 等。弱化一层网关的转发，把一切功用都集中在二层的 Ingress 上，然后根据 Ingress 去生成 APISIX 的路由。一起在 NGINX 装备的基础上，需求去适配 APISIX 的插件。
路由生成后，就需求去校验整个转发进程是否正确。咱们根据 goreplay 的录制回放来验证路由转发的正确性，一起经过主动化脚本来验证插件功用是否正常。在功用校验经过的状况下，咱们会继续验证 APISIX 在功用层面是否满意内部需求。因此，在功用压测进程中咱们自研了 elastic-apm 插件，一起针对部分影响 QPS 的插件进行了功用优化。
处理完功用跟功用相关的问题后，最大的应战便是流量切换了，因为流量切换将直接关乎出产质量。
尽管前边咱们现已运用了 goreplay 进行流量录制回放，但咱们仍然需求一个比较牢靠的回滚计划。假设流量切换形成了反常，比方转发反常或许是 APISIX 呈现溃散时，能够进行快速回滚操作。根据此，咱们首要切换了公网流量，因为公网是经过 WAF 回源到 SLB 来进行流量切换的，这时假如咱们切换到 APISIX，就能够很方便地去修正回源地址来将整个流量进行回滚，如上图标示「切换」字样所示。这个反常状况下的流量切换进程基本是在秒等级，或许 10 秒内就把一切流量都切回来了。
完成了公网流量切换的状况下，顺利运行了几天，咱们就经过 APISIX 将内网流量也进行了改变，然后整个出产上的切换就全部完成了。可是这个上线进程中，其实咱们还是遇到了一些问题的。
搬迁进程中的问题与处理计划
Prometheus 插件转发推迟
这个是在咱们内网测验环境中发现的一个问题。因为咱们的内网是 all-in-one 的测验环境，一切部分都运用同一个 APISIX 的入口，所以路由规矩十分多，到达 4000+。这样就会导致每次拉取 Prometheus 插件时， metrics ⼤⼩到达 80M+，形成单个 worker 进程跑满，从而形成 worker 的转发推迟。
这个问题是现在 APISIX 开源版本存在的一个现象，主要是因为事务流量和内部 API 流量（比方Prometheus metrics 和 Admin API）都共用 worker 形成的。咱们在之前是针对 Prometheus 插件进行了修正，其中推迟相关的metrics 占用了90%以上，咱们将这部分采集去掉了，还是满意咱们事务的监控需求。
不过最近咱们针对这个问题又有了新的计划。这套新计划是对 Nginx 源码进行修正，经过多发动⼀个或多个 worker 进程（isolation process) 来专⻔监听特定端⼝（比方 Prometheus、admin、control 等），不监听处理正常事务端⼝恳求。其它的 worker 进程则撤销监听上述特定端口，只处理正常事务端⼝恳求，来确保 APISIX 内部恳求和正常事务恳求不会互相影响。
具体的文章能够参阅：如何修正 Nginx 源码完成 worker 进程隔离
默许路由匹配反常
在上线 APISIX 后，咱们发现域名并没有走精确匹配模式，而是采用了通配符匹配，这跟 NGINX 的域名最长匹配是不一致的。为此，咱们经过更换路由策略，将 URL 方法改成了 host+URL 的方法，处理了该问题。
但关于 APISIX 根据 URL 路由策略作为默许路由的问题，咱们能够在自己的出产环境中进行压测后再决议是否保留。
假如你的出产场景中归于 URL 特别多、域名特别少的类型，那 APISIX 这种默许路由策略是彻底 OK 的。但在咱们的事务场景下，并没有这么多 URL，所以采用 host+URL 的方法是更满意咱们的功用需求。
默许主动绑核问题
在云原生的布景下，大部分用户都会选择将 APISIX 部署在容器中运用。但 APISIX 在默许装备下会进行主动绑核，这样就会导致在容器化场景下，或许只会用到前几个中心，形成前几个中心跑满而后几个中心仍处于空闲的状况。尽管 CPU 运用率不高，但APISIX转发会呈现推迟。
不过 APISIX 社区最近现已开端调整这个装备，将 worker_cpu_affinity 装备的默许值从 true 改为了 false。因此这个问题现在在 APISIX 版本中现已处理了。
版本晋级兼容问题
在上线 APISIX 的进程中，咱们还发现在较老的体系或 OpenSSL 库中，它的 ssl_ciphers 和服务端默许值⽆交集，从而形成 SSL 握手失利。
针对这个问题，咱们主张咱们在上线 APISIX 之前，先经过一些 SSL 东西先去探测一下当前旧网关与 APISIX 网关的 SSL 握手交集是否正确或满意运用场景，然后再进行规模化的搬迁调整。
除此之外，在 APISIX 发布 2.15 LTS 版本后，咱们就在内网进行了晋级，可是晋级后就发现了一些路由匹配相关的问题。
因为从旧版本晋级到新版本时，存在一些兼容性问题，导致 redirect 插件参数 http_to_https 为true 时，参数 http_to_https 和 append_query_string 校验失利，进而路由加载失利，导致路由丢失。这种状况下就会在路由匹配时呈现 404 或许转发到其他上游的状况。
现在这个问题现已在 APISIX 的 master 分支中处理了，可是并没有针对 2.15 版本进行单独处理，所以咱们在运用该版本时也需求留心这部分问题。
运用 APISIX 的收益及展望
尽管前边提到了一些咱们在上线 APISIX 进程中遇到的问题，可是在运用 APISIX 之后，给公司事务层面还是带来了许多价值的。比方：
- 运维效率提升。运用 APISIX 后，再也不存在 reload 相关的烦恼，能够做到随时更新路由和证书等，给开发人员带来了操作上的便当。
- 流量操控才能提升。运用 APISIX 后，咱们在熔断和限流方面都得到了提升，稳固了整个中心流程。
- 自研插件，增强网关才能。得益于 APISIX 的强拓展性和自身插件功用的优异，咱们也会更主动地去开发一些插件。比方咱们在 APISIX 上集成了统一鉴权的才能，新事务⽆需单独对接鉴权体系，加快了产品迭代流程。
- 去掉了冗余的一层 NGINX，完成降本增效。之前的双层网关架构中，一层的 NGINX 关于开发人员并不透明。现在将双层网关合并为一层后，开发人员能够很明晰地看到整个架构的路由、插件等装备，关于排查问题来说愈加方便快捷。 在后续运用 APISIX 的规划中，咱们还是会继续在网关层面进行增强。比方开发针对内部事务的自研插件，供给多租户的才能，或许是将 API 办理的功用带到网关层面等等。
当然在这个进程中，咱们也在积极回馈社区。现在已在社区中贡献了 8 个 PR，帮助完善和修正了一些生态插件相关的问题。比方完善 batch_request ⽀持⾃界说 uri、为 hmac-auth 插件供给恳求 body 校验等功用。
希望在后续的实践进程中，咱们能够更全面地去运用和发挥 APISIX 的特性，一起也会愈加积极地去探索 APISIX 的运用场景，也十分等待未来有更多的共建功用上线。
