共计 3233 个字符，预计需要花费 9 分钟才能阅读完成。
作者：地平线云原生开发工程师 – 张昕
在以后的汽车行业，大多数公司都在向主动驾驶和新能源方向转型，而对于主动驾驶方面，每家企业都投入了大量的资源来实现主动驾驶模型的开发与训练，其中呈现了很多明星企业，比方汽车智能计算平台引领者地平线。地平线次要从事汽车智能计算平台的研发，具备当先的深度学习算法和芯片设计能力，致力于通过底层技术赋能，推动汽车产业的翻新倒退。
智能汽车是机器人时代第一个大终端，地平线同时也通过软硬件的联合，宽泛赋能泛机器人行业的利用落地。在硬件层面，地平线基于自主研发的专用计算架构 BPU(Brain Processing Unit)，推出面向智能驾驶的计算平台征程系列和面向泛机器人的夕阳系列。在软件层面，面向智能汽车 AI 软件产品开发及迭代需要，地平线打造地平线艾迪®AI 开发平台，可能为智能汽车 AI 开发者提供数据标注、训练、优化、部署、治理与性能剖析等能力。整套基础设施，开箱即用，用户无需从零搭建一套简单的主动驾驶跨平台零碎，只需聚焦于外围价值积攒。
对于一家疾速倒退的科技公司而言，如何保障业务稳固运行与轻松治理是十分重要的，而网关则是保障业务稳固的第一道关卡。因为之前网关存在了一些无奈解决的问题，因而地平线对网关从新进行选型，最终抉择了 Apache APISIX Ingress Controller 作为公司的流量网关，对立提供服务。
网关选型之路
Traefik 的有余
在应用 APISIX Ingress 之前，业务零碎应用的 Ingress Controller 是 Traefik 1.x 版本，然而存在以下几个问题：
- Traefik 1.x 是通过 Ingress 来配置路由规定的，局部插件须要通过增加
annotation的形式进行配置。这种形式，只能针对以后 Ingress 下的所有规定增加插件，无奈实现更细粒度的配置。 - Traefik 1.x 不反对具体规定可视化配置，无奈依据 Request URL 通过页面间接定位到具体服务。
- Traefik 的默认配置文件（
configmap）内容较少，许多默认配置须要翻阅官网文档，并且有些参数和 NGINX 默认配置不统一，导致保护起来比拟麻烦。
针对以上问题，地平线的技术团队决定更换 Ingress Controller，在选型初期也有思考将 Traefik 降级到 Traefik 2.0 解决上述问题，然而因为也须要采纳新的 CRD 来进行降级，迁徙老本也不低，不如尝试下其余 Ingress 计划。
APISIX Ingress 的劣势
在选型初期，咱们次要比照了 APISIX Ingress、Kong Ingress 和 Envoy，然而除了 APISIX Ingress 其余网关或多或少在性能或性能上无奈满足现有场景的需要，因而最终抉择了 APISIX Ingress，除了一些通用的性能外，咱们更看重以下几点：
- 插件丰盛：插件生态好，APISIX 反对的插件，均能够应用
apisix-ingress-controller做申明式配置，并且能够针对ApisixRoute下的单条backend定制插件。 - 可视化配置：搭配 APISIX Dashboard 能够看到每条
apisixroute。如果同一域名配置在多个namespace或者是多个yaml文件中，发生冲突时能够联合 APISIX Dashboard 搜寻path前缀即可疾速定位。 - 细粒度校验：APISIX Ingress Controller 会对其治理的 CRD 申明的资源进行校验，如果在 CRD 中申明了不存在的 Service，则会将报错信息存储在
ApisixRoute的event中，此次变更也不会失效，在肯定水平上缩小了一些因误操作造成的问题。 - 功能丰富：APISIX 反对热更新和热插件、代理申请重写、多种身份认证、多语言插件开发等诸多个性，更多功能请参考 APISIX 的性能。
- 社区沉闷：Issue 的响应速度很快，绝对其余社区，APISIX 沉闷开发者数量多。
- 高性能：从下图中，能够看到在和 Envoy 进行压测比照时，APISIX 性能是 Envoy 的 120% 左右，外围数越多 QPS 差距越大。
整体架构
从上面的架构图中能够看出，APISIX Ingress 作为一个全流量的入口，无论是命令行工具、Web、SaaS 平台或者 OpenAPI，所有拜访的流量均通过 APISIX Ingress 进入上游（业务服务）。而在认证鉴权上，因为公司自身有一个专门的认证服务，所以间接应用了 APISIX 的 forward-auth 插件，实现内部鉴权认证。
在网关层，所有的流量均是通过拜访域名进入，此时流量会先通过 LVS，由 LVS 别离转发到后端的 APISIX 节点中，最初再由 APISIX 依据路由规定对流量进行散发，转发至绝对应的 Pod 中。而在 LVS 上，为了使 LVS 能够间接指向 APISIX Ingress，他们也将 APISIX Ingress 默认端口由 9180 更换为 80，能够更不便的对流量进行转发解决。
应用场景
理解完整体架构后，接下来将分享几个公司目前利用 APISIX Ingress 实现的场景。
超大文件上传
首先是大文件上传场景，该场景在个别公司可能会比拟少，然而如果是做 AI 模型训练的公司，这个场景就比拟常见了。该场景次要是在地平线模型训练零碎中，研发车采集到的数据会通过网络上传到该零碎中，数据大小个别都是在几百 GB 以上，在不调整 APISIX 任何参数的状况下，上传数据量过大时就会产生 OOM。
因为默认 client_body_buffer_size 是 1M`B`，缓冲区满了就会把临时文件写入磁盘，因而造成磁盘 IO 过高。
如果将写入临时文件的目录指向 /dev/shm 共享内存，则又会导致 APISIX（cache）过高。
通过一直的调试，发现是因为 APISIX 没有开启流式上传，针对这个场景，咱们将 APISIX 版本由 2.11 降级至 2.13，并且对 APISIX 的参数进行了调整，首先更改 apisix configmap 启用流式上传的参数 proxy_request_bufferin`g off，其次再通过 APISIX Ingress Controller 提供的 CRD ApisixPluginConfig 将可复用的配置抽离进去，作为 namespace 级别的配置为须要此场景的路由动静设置 client_max_body_size` 的大小。
多云环境下的服务调用
在多云环境下的服务调用中，局部业务流量首先会达到本地 IDC，之后会通过 APISIX Ingress 达到 Pod，而在 Pod 中，有些服务则会通过域名拜访 Acloud 的服务，局部场景也会存在服务与服务之间进行调用。
次要是波及到多云训练，用户会以 IDC 为入口，抉择集群后即可将工作提交到对应的云端集群。
应用 forward-auth 实现内部认证
在咱们刚开始应用 APISIX Ingress 时，APISIX 并没有反对 forward-auth 插件，因而咱们基于 apisix-go-plugin-runner 自定义了一个插件，然而这样做就多了一层 gRPC 地调用，调试比拟艰难，很多日志都无奈看到。而在今年年初 APISIX 反对了 forward-auth 插件，咱们就将自定义插件更换为官网插件，这样就缩小一层 gRPC 地调用，也更加不便的进行监控。
利用监控
在利用监控中，咱们在全局启用了 APISIX 的 prometheus 插件，并针对本身业务进行了一些调试和优化，比方减少了实时并发数、QPS、APISIX 实时接口成功率以及 APISIX 的实时带宽，对 APISIX 进行更细粒度的监控。
总结
以后咱们仅在局部业务线应用了 Apache APISIX Ingress Controller 作为流量网关，后续也将上线其余业务，为社区带来更加丰盛的利用场景。如果你也正在对 Ingress Controller 进行选型，心愿通过浏览本文，可能给你一些帮忙。越来越多的用户在生产环境中应用 Apache APISIX Ingress，如果你也正在应用 APISIX Ingress，欢送在社区中分享你的应用案例。
