本文介绍了网易轻舟团队在使用 Knative Serverless 平台时的性能调优实践。通过对Knative数据路径的分析，发现Activator和Queue Proxy是性能优化的关键点。测试显示，移除Activator和优化Queue Proxy可以显著提升性能。此外，文章还探讨了业务流量导入Knative的方案以及对Knative未来发展的展望。
作者 | 刘勤龙
策划 | 田晓旭
首发 | InfoQ
Serverless 技术正在获得越来越多的认可。CNCF 2019 年报告显示，41% 的受访者表示已经在使用 Serverless，另外 20% 的受访者表示计划在未来 12-18 个月内采用 Serverless 技术。
Serverless 技术关注者对其价值点讨论⼤多是基于公有云场景的云函数等产品，其关注点在资源支付方式更加细粒度，和公有云 Baas 的粘合上，和私有云环境中业务团队关注的价值不太契合；在我们对业界落地场景调研以及同业务团队⼀起实践后，我们发现私有云环境中业务团队关心的 Serverless 价值可概括为三点：
-
提效： 加快业务团队迭代效率， Serverless 对开发流水线重新对分工，业务开发人员聚焦业务，无需操心运维和扩容等诸多事项；
-
降本：按需实时弹性可避免资源浪费，最大程度发挥资源优势；
-
解耦：支持事件触发，将各个组件通信的逻辑变成事件进⾏解耦合，非常适合业务的扩展和变化；
其中“提效”和“降本”为核心价值，解耦为重要考虑点。
我们认为 Serverless 出现不是为了替代现有的 Serverful（传统云）框架，两者是互补的关系，Serverless 有其业务场景优势（后续⽂章再展开），合适最重要。笔者目前工作是聚焦轻舟 Serverless（“轻舟”系网易研发的云原生基础设施平台代号）和业务团队⼀起实现业务开发的提效、降本和解耦。当前开源 Serverless 方案很多，而选型强大活跃开源社区方案让我们能够持续改进自己的 Serverless 平台。基于此诉求，我们很早便选型了 Knative，因为从一开始其社区非常活跃，有 Google，IBM，RedHat 等大公司参与，其次是标准先行。而事实也在慢慢印证了我们的选择。
如图所示， Knative 占据了 34% 的份额，遥遥领先于第⼆名 OpenFaaS，Knative 是搭建 Serverless 平台的首选。（ 数 据 来 源 于 CNCF 2019 年 社 区 调 查 报 告 ）
目前，网易轻舟云原生团队已经和网易云音乐前端团队合作共建云音乐Serverless 部署平台ALPACA，将Serverless 用于前端场景。该平台架构如下图。
其中轻舟负责底层能力，Knative 是其中的核心能力，我们基于其业务场景，对Knative 进行了压测分析，也做了性能调优POC，本文主要从性能角度，基于Serverless 前端使用场景对Knative 进行分析，尝试揭开Knative 核心数据路径性能真相并给出调优思考。
⼀、Knative 系统内的数据路径分析
本文暂不讨论流量如何导⼊到ALPACA 平台，先聚焦到ALPACA 平台Knative 系统内部本身。
Knative 系统内部数据路径是， Knative 网关 ->Activator->Queue Proxy-> 业务 App；社区推荐使用的方式是不注入 Sidecar 以获取更佳的性能，因此我们讨论场景是“不注入 Sidecar，管控面使用 Pilot，Knative 网关使用轻舟的 API 网关产品”。
Knative 系统内部默认的数据路径如上图，用户业务流量经过一层 Knative 网关，经过 Activator 到达 Queue Proxy 代理组件，最后到达应用程序。
从上图可知，默认情况下流量经过三层代理（Knative 网关、Activator、Queue Proxy）后才到达应用 APP，每⼀层代理均可能是性能的拦路虎。
我们的分析思路如下：
-
Knative 网关这⼀层承载了流量管理、灰度发布等功能必须存在，当前使用轻舟 API 网关产品充当，性能均调优过，本身性能没什么问题，非本次核心关注点
-
App 为用户的业务代码性能无法控制，平台层面不可操作，也非关注点
于是将性能分析要点集中到剩余的两层代理（Activator 和 Queue Proxy）上。
首先 Activator
最低0.47元/天 解锁文章
扫一扫
365
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
