分享嘉宾简海清，视源股份运维负责人。
视源股份（CVTE）自成立以来，依靠在音视频技术、人机交互、利用开发、系统集成等电子产品畛域的软硬件技术积攒，建设了教育数字化工具及服务提供商希沃（seewo）、智慧协同平台 MAXHUB 等多个业内知名品牌。其中希沃从 2012 年到 2021 年间断 10 年蝉联中国交互智能平板行业市占率桂冠，已成为货真价实的行业标杆企业。
为了应答日趋成熟及快速增长的业务现状，希沃又是如何在网关层面进行跟进的呢？
随着技术的飞速发展，在人际交互智能畛域，业务需要也对架构迭代有了更高的要求。为了应答日趋成熟及快速增长的业务现状，希沃又是如何在网关层面进行跟进的呢？
网关往期迭代与痛点
希沃网关的倒退经验了四个版本的迭代。2013 年公司开始尝试互联网业务，那时候采纳了 OpenResty + NGINX 动态配置的形式搭建了最后的网关，开发人员通过 SCP（Secure Copy）进行公布。与此同时一个比较严重的问题就是，每次上线公布都须要运维人员的帮助能力保障平滑上线。
随着业务的倒退和人员的裁减，2016 年咱们开发了第二代公布零碎和相干迭代网关。这次是基于 OpenResty 集成了 upsync 模块，同时配合 Consul 来进行服务发现。第二代的零碎解决了上一代开发人员无奈独立公布上线的问题，但仍须要运维帮助能力进行扩容。
之后公司业务开始了迅猛发展，开始对网关以及产品的弹性扩缩能力有了更高的要求。2018 年咱们基于 K8s 开发了第三代零碎。思考到仍有局部利用遗留在数组机上，所以整个网关架构是在 K8s 上应用 Ingress NGINX 来当作第二层的网关，第一层网关仍是 OpenResty 配合的双层网关架构。这种状况下尽管解决了前代公布扩容等自助问题，但又引入了新的麻烦。
业务的疾速裁减以致对于整体稳定性的要求越来越高。采纳这种双层网关架构后，一层 NGINX 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% 以上（如上图所示），所以咱们将这部分采集去掉了。去掉这部分后，业务层面还是满足了咱们的监控应用需要，并未造成影响。
不过最近咱们针对这个问题又有了新的计划，目前还处于 demo 阶段。这套新计划是对 NGINX 源码进行批改，通过多启动⼀个或多个 worker 过程（isolation process) 来专⻔监听特定端口的申请（比方 Prometheus、Admin API、Control API 等），不监听解决失常业务端口申请。其它的 worker 过程则勾销监听上述端口，只解决失常业务端口申请，来确保 APISIX 外部申请和失常业务申请间不会相互影响。
默认路由匹配异样
在上线 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 的应用场景。期待将来有更多的共建性能上线。