本文整顿自爱奇艺高级研发师何聪在 Apache APISIX Meetup – 上海站的演讲，通过浏览本文，您能够理解到基于 Apache APISIX 网关，爱奇艺技术团队是如何进行公司架构的更新与交融，打造出全新的网关服务。
背景形容
爱奇艺在之前有开发了一款网关——Skywalker，它是基于 Kong 做的二次开发，目前流量应用也是比拟大的，网关存量业务 日常峰值为百万级别 QPS，API 路由数量上万。但这款产品的有余随着应用也开始逐渐体现。
- 性能差强人意，因为业务量大，每天收到很多 CPU IDLE 过低的告警
- 零碎架构的组件依赖多
- 运维开发成本较高
往年在交接到此我的项目后，咱们根据上述问题和窘境，开始对相干网关类产品做了一些调研，而后发现了 Apache APISIX。
Apache APISIX 劣势
在抉择 Apache APISIX 之前，爱奇艺平台曾经在应用 Kong 了，然而起初 Kong 被放弃了。
为什么放弃 Kong？
Kong 应用 PostgreSQL 来存储它的信息，这显然不是一个好形式。同时在调研过程中咱们查看了 Apache APISIX 与 Kong 的性能的比照，在性能优化方面 Apache APISIX 比 Kong 晋升了 10 倍，这个指标是十分让人惊喜的。同时咱们也比拟了一些次要的网关产品，Apache APISIX 的响应提早比其它网关低 50% 以上，在 CPU 达到 70% 以上时 Apache APISIX 仍能稳固运行。
咱们也发现 Apache APISIX 其实和 Kong 一样，都是基于 OpenResty 技术层面做的开发，所以在技术层面的迁徙老本就比拟低。而且 Apache APISIX 具备良好的环境适应性，可能被轻易地部署在包含云计算平台在内的各种环境上。
同时也看到 Apache APISIX 整个开源我的项目的活跃度十分高，对问题的解决十分迅速，并且我的项目的云原生架构也合乎我司后续布局，所以咱们抉择了 Apache APISIX。
基于 Apache APISIX 下的爱奇艺网关架构
爱奇艺网关的总体架构如下图所示，蕴含域名、网关到服务实例和监控告警。DPVS 是公司外部基于 LVS 做的一个开源我的项目，Hubble 监控告警也是基于开源我的项目做的深度二次开发，Consul 这块做了些性能和高可用性方面的优化。
利用场景一：微服务网关
对于网关这块，简略从管制面和数据面介绍一下。
数据面次要面向前端用户，从 LB 到网关整个架构都是多地多链路灾备部署，以用户就近接入准则进行布点。
从管制面的角度来说，因为多集群形成，会存在一个微服务平台，去做集群治理和服务治理。微服务平台能够让用户体验服务裸露的一站式服务，立刻应用，无需提交工单。管制面后端会有 Gateway Controller 和 Service Controller，前者次要管制所有的 API 的创立、插件等相干配置，后者则是管制服务注册登记和健康检查。
利用场景二：根底性能
目前阶段，基于 Apache APISIX 调整后的 API 架构实现了一些根底性能，如限流、认证、报警、监控等。
首先是 HTTPS 局部，爱奇艺方面出于对安全性的思考，证书和密钥是不会寄存在网关机器上，会放在一个专门的近程服务器上。之前应用 Kong 时咱们没有在这方面做相干反对，采纳前置 Nginx 做 HTTPS Offload，此次迁徙到 Apache APISIX 后，咱们在 Apache APISIX 上实现了该性能，从链路上来说就少了一层转发。
在限流性能上，除了根底的限流、还增加了精准限流以及针对用户粒度的限流。认证性能上，除了根本的 API Key 等认证，针对专门业务也提供了相干的 Passport 认证。对于黑产的过滤，则接入了公司的 WAF 平安云。
监控性能的实现目前是应用了 Apache APISIX 自带插件——Prometheus，指标数据会间接对接公司的监控零碎。日志和调用链分析也通过 Apache APISIX 失去了相干性能反对。
利用场景三：服务发现
对于后面提到的服务发现，次要是通过服务中心把服务注册到 Consul 集群，而后通过 DNS 服务发现的形式去做动静更新，其中 QAE 是咱们公司外部的一个微服务平台。简略举例说明一下更新后端利用实例时的大体流程。
实例变更时，首先会从 Consul 中登记对应节点，并通过 API 网关 Controller 向网关发送更新 DNS 缓存的申请。缓存更新胜利后，Controller 再反馈 QAE 平台能够进行相干后端利用节点，防止业务流量再转发到已下线节点。
利用场景四：定向路由
网关是多地部署的，当时搭建好一整套多地互备链路，同时倡议用户后端服务也是多地就近部署。随后用户在 Skywalker 网关平台上创立一个 API 服务，Controller 会在全 DC 网关集群上都部署好 API 路由，同时业务域名默认 CNAME 到对立的网关域名上。
间接为业务提供多地就近接入、故障灾备切换能力，同时也反对用户自定义解析路由。针对用户本身的故障切流、蓝绿部署、灰度公布等需要，用户能够通过采纳 uuid 域名来自定义解析路由配置，同时也反对后端服务发现的自定义调度。
利用场景五：多地多级容灾
前边咱们也提到过，针对业务量大、集群多，还有客户端受众广的状况，在业务层面咱们会有业务就近接入和灾备的需要。
针对灾备，除了要多地多链路互备，还要思考多级多节点问题，故障节点越向客户端凑近，受影响的业务和流量越大。
- 如果是最远的后端服务节点故障，依附网关和服务中心的健康检查机制，能够实现故障单节点的熔断或者故障 DC 的切换，影响范畴限度在指定业务上，用户无感知。
- 如果是网关级别故障，须要依附 L4 DPVS 的健康检查机制，熔断故障网关节点，影响范畴小，用户无感知。
- 如果故障点并非上述述熔断措施所能修复，就须要依附域名粒度的外网多点可用性拨测，实现域名解析级别的故障主动切换，这种形式故障修复速度绝对较慢，影响业务多，用户可感知。
迁徙过程中遇到的问题
在咱们从 Kong 到 Apache APISIX 的迁徙实际过程中，咱们解决、优化了一些架构存在的已知问题，但同时也遇到了一些新的问题。
成绩一：解决了前端不反对 SNI 的兼容问题
当初大部分前端都是反对 SNI 的，但也会碰到有一些前端在 SSL 过程中无奈传递 hostname。目前咱们针对这种状况做了一个兼容，采取端口匹配的形式进行相干证书获取。
成绩二：优化了大量 API 路由匹配问题
前边也说过，目前咱们线上间接运行的 API 业务数量就有 9000 多个，后续可能还会减少。针对这一问题咱们进行了相干性能上的优化，依据 API 来决定优先匹配域名还是门路。
成绩三：解决了 ETCD 接口限度问题
在接入 Apache APISIX 后，ETCD 接口的限度问题也曾经解决，目前曾经解除了 4M 的限度。
成绩四：优化了 ETCD 连贯数量的性能问题
目前是 Apache APISIX 的每个 worker 都会跟 ETCD 连贯，每一个监听目录都会去建一个连贯。比方一台物理机是 80 core，监听目录有 10 个，单台网关服务器就有 800 个连贯。一个网关集群 10 台的话，8000 个连贯对 ETCD 压力蛮大的。咱们做的优化是只拿一个 worker 去监听无限的必要目录，和其余 worker 之间共享信息。
除了上述问题，还有一些问题也正在致力优化中。
- 大量 API 的问题，即便 APISIX 可能反对，咱们也要思考其余依赖组件的瓶颈。比方上述的 ETCD、Prometheus 监控和日志服务。所以后续咱们可能会采取大集群共享和小集群独立这两种形式来混合部署业务，比方一些重要业务咱们会以小集群形式进行部署。
- 对于 Prometheus 监控指标，后续咱们也会进行相应的缩减和优化，对 DNS 服务发现这块做更多的优化。
对 Apache APISIX 的冀望
咱们心愿 Apache APISIX 能在后续的开发更新中，除了反对更多的性能，也能够始终放弃性能的高效和稳固。
对于作者
作者何聪，高级研发师，IIG 基础架构部 – 计算云，次要负责爱奇艺网关开发和运维工作
对于 Apache APISIX
Apache APISIX 是一个动静、实时、高性能的开源 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。Apache APISIX 能够帮忙企业疾速、平安的解决 API 和微服务流量，包含网关、Kubernetes Ingress 和服务网格等。
- Apache APISIX GitHub：https://github.com/apache/apisix
- Apache APISIX 官网：https://apisix.apache.org/
- Apache APISIX 文档：https://apisix.apache.org/zh/…