乐趣区

关于apisix:Apache-APISIX-在腾讯云智能钛平台中的落地实践

背景介绍

腾讯云智能钛机器学习平台(TI-ONE)是为 AI 工程师打造的一站式机器学习服务平台,为用户提供从数据预处理、模型构建、模型训练到模型评估的全流程开发反对。智能钛机器学习平台内置丰盛的算法组件,反对多种算法框架,满足多种 AI 利用场景的需要。

产品需要

咱们将需要分为两大类:技术需要,即研发团队对于 API 网关的需要;业务需要,即智能钛机器学习平台使用者对于 API 网关的需要。

技术层面次要需要为具备跨横切面性能。具体来说,是将鉴权、限流、日志、监控等跨横切面的性能内聚到 API 网关,对后端服务进行解耦,使研发聚焦性能开发,并且升高保护老本。

思考到后续业务对接腾讯云的需要,API 网关必须反对腾讯定制的鉴权和登录机制以及恪守腾讯云 API 3.0 的格局。

业务层面则次要思考使用者感触。平台进行开发时,AI 和算法共事须要交互式编程环境,那么就须要 API 网关反对 Notebook。实现部署后,API 网关须要具备流量调配性能和足够高的性能,满足多用户间接调用接口的场景。还需反对申请级别的监控,包含日志(Logging)监控和指标(Metrics)监控。

综合以上需要,咱们进行了相干网关产品的调研。

调研比照

进入咱们考查名单的有:Envoy、Kong 以及 Apache APISIX。咱们从多维度对上述三个产品进行了比照,后果如下。

因为 Envoy 的技术栈是 C++,须要定位问题时,很可能要去看 C++ 的源代码。这种定位问题可能会对咱们造成肯定的影响,所以 Envoy 这个计划否决得比拟早。

Kong 和 Apache APISIX 所应用的技术栈雷同,都是 OpenResty。然而在存储依赖这一栏,Kong 依赖的是关系型数据库 PostgreSQL。在软件行业,数据库的高可用配置是非常复杂的。不仅须要装备专门的 DBA,而且施行难度也十分大。关系型数据库太重了,咱们并不需要应用关系型数据库来保障 ACID 和 MVCC。

为什么抉择了 Apache APISIX?

Apache APISIX 在存储依赖和路由规定这两方面做的十分好,很适宜咱们的业务场景。咱们的业务比拟看重路由灵便度和路由匹配算法。目前已接入 50 多个上游和数百条路由规定,所以咱们心愿路由匹配的性能越高越好。Apache APISIX 路由匹配算法复杂度显著优于 Kong,且配置失效工夫小于 1ms,单核 QPS 远高于 Kong。综合以上技术和操作层面,咱们最终抉择了 Apache APISIX。

基于 Apache APISIX 的架构调整

接入 Apache APISIX 后,咱们实现了智能钛机器学习平台网关方面的性能,解决了之前对于技术和业务层面的需要。

从这张图能够看到,Apache APISIX 反对 http+pb、http+json、gRPC、WebSocket 等流量。这些流量通过了 Apache APISIX 之后,会走向智能钛机器学习平台定制开发的一些组件。

智能钛机器学习平台的业务部署在腾讯云 TKE 平台上。为了进步它的可用性,网关、etcd 等都是集群化的部署。智能钛机器学习平台没有应用 Apache APISIX 的 dashboard,而是间接通过 Admin API 进行交互,间接写到 etcd 外面。

实例分享

在实战过程中,咱们总结了一些应用 Nginx 的坑,也发现了一些 Apache APISIX 的长处,在此简略分享一下。

反直觉的 Nginx 配置

以前应用 Nginx 的时候,感觉 Nginx 是一个配置驱动的产品。可能会造成治理艰难、保护老本低等困扰。Nginx 在配置管理的时候,经常会有一些反直觉的事件。在这次实战过程中,我的共事就遇到这么一个反直觉的坑:

对于接触 Nginx 比拟少的人来说,这两行命令加在 if 后面,且 if 外面并没有其余命令笼罩这两行命令,那么它们是必然会被执行的。相熟 Nginx 的人都晓得,if 外面的命令会笼罩掉里面的命令,但这十分反直觉。

测试用例即文档

在实际应用 Apache APISIX 实际的过程中,Apache APISIX 我的项目的测试用例写的十分具体。即便没有深刻理解过如何在 Apache APISIX 中调用某些函数,也往往能在测试用例中找到答案。起初再遇到一些 OpenResty 的问题的时候,我就会到这些测试用例外面找一找有没有相干的代码,每次都能解决问题。

思考与瞻望

在技术选型的初期,除了 Envoy、Kong 和 Apache APISIX 外,也有共事提到了 Service Mesh。有了 Service Mesh,为什么咱们还要抉择 Apache APISIX,这难道不是在技术上倒退吗?对于这个问题,我的观点是这样的:

  1. API 网关在零碎边界,负责解决南北向流量;Service Mesh 在集群外部,负责解决东西向流量。两者的性能不同,无奈间接比拟。
  2. 实践证明 Service Mesh 存在一些性能损耗。然而也有一种声音说,上云了,这点损耗可能并不是业务的性能瓶颈,所以这点是见仁见智的。
  3. 得益于 OpenResty 和 Lua 简略易上手的个性,Apache APISIX 的定制研发效率更高。即便开发团队先前没有应用 OpenResty 或者 Lua 的开发教训,依然能在很短的工夫内实现了业务的定制开发需要。
  4. Apache APISIX 的交付老本要低于 Service Mesh。因为 Istio 社区十分沉闷,版本迭代速度十分快,导致 Istio 的各个版本和 Kubernetes 的各个版本之间有不兼容的问题。在客户的生产环境中,一些 Kubernetes 集群可能有版本差别,而这些 Kubernetes 集群无奈共用一个版本的 Istio,这在理论交付的过程中是会造成一些困扰。

集体冀望

感激 Apache APISIX 发明了一款性能极致而且易于上手的开源 API 网关产品。在智能钛机器学习平台网的开发过程中,心愿后续能够在实践中总结出更多的应用心得,反馈给 Apache APISIX 社区。

对于作者

作者刁寿钧,腾讯优图实验室高级开发工程师,目前负责腾讯云智能钛机器学习平台的开发。

对于 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/…
退出移动版