TapTap 算法平台的 Serverless 探索之路

Serverless 在构建应用上为我们节省了大量的运维与开发人力，在基本没投入基建人力的情况下，直接把我们非常原始的基建，或者说是资源管理水平拉到了业界相对前沿的标准。最直观的数据是，我们组仅投入了个位数的人力，就可以为 TapTap 整个搜广推相关的所有业务提供全套 AI 和大数据方面的支持。————陈欣昊

心动介绍

心动创立于 2003 年，是一家全球游戏开发和发行商，拥有丰富的研发、发行和代理运营经验。截至 2022 年中，心动运营 38 款免费和付费游戏，在全世界拥有 5,000 万月活跃用户，主要分布在大中华地区、东南亚、北美和南美。2016 年，心动推出手机游戏社区和应用商店 TapTap，玩家可以通过官方渠道免费或付费购买下载手机游戏，亦可在社区中与其他玩家交流，截至 2022 年 6 月，TapTap 在全球已拥有超过 5,000 万月活跃用户。

业务背景

TapTap 不同于传统的应用商店的分成模式，至今一直坚持做渠道零分成，这也决定了，TapTap 目前的商业化，主要由广告驱动。TapTap 的广告属于站内的原生广告，与其他非商业化在内容上形态保持高度一致，给用户更好的体验。比如首页的游戏推荐，发现页的内容推荐，搜索引导页的底纹词，以及搜索输入时会出现的搜索建议词，还有搜索最后的落地页等等，广告的部分就穿插在这些战略内容之间。

我们的 serverless 实践也是基于这几个业务场景的实际需求来进行推进的。例如，目前搜广推都依赖的深度学习模型自动化更新/部署，以及组内算法同学都需要依赖的模型实验记录平台，还有站内新内容的一些 NLP 分析处理等。

早期，我们绝大部分的后端服务都是部署在 ECS，通过 Rundeck 来进行管理和部署，在效率和管理上并不是那么理想。在基建升级方案的需求上，我总结了 4 点：

●能大幅提升开发运维效率●以较低的人力成本来满足业务需求●服务足够可靠，能够具备良好的性能●因为我们工程目前主要是以 Go 语言为主，所以在后续基建升级上需要对 Go 有良好的支持。

方案对比

我们考虑了两种主流的方案架构，一个是云主机+自建 K8s 全套的解决方案， 还有一种就是 Serverless 架构，使用 Serveless 应用引擎（SAE）和函数计算 FC。

经过对比后，我们选择了后者。一方面是 Serverless 可以免去机器的购买流程，不需要提前购买 ECS。而且本身也自带了一些可选的默认环境，如果没有特殊需求的话，可以基本免去环境搭建的繁琐；另一方面是 Serverless 已经集成了很多基础组件，基本上可以说是做到免运维直接上线的程度。

然后在后续维护上，Serverless 产品在计费精度上相比 ECS 有更高的精度，可以做到分钟级，甚至秒级的计费，做到真正业务使用资源时才进行付费，相比 K8s+ECS 的模式，在早期开发和后续运维上, 都能节省较大的人力成本。

从我们自己实际实验的体验来理解 Serverless 的两个产品的话。

函数计算 FC 把业务的调度和触发逻辑与业务逻辑本身解耦，开发、算法同学可以先在函数计算控制台控制整个业务逻辑的触发与调度逻辑，就不需要再额外地开发，可以更加专注业务逻辑本身的设计，这也决定了函数计算更加适用于有业务驱动的场景，在事件真正发生时去申请资源进行业务逻辑的运行。

而 Serverless 应用引擎 SAE 在我们看来类似于功能更丰富的、提供了全套微服务能力的增强版 K8s，可以极大降低维护成本，并做到真正的开箱即用。这个就比较适合做微服务改造，把原先在 ECS 上的旧服务直接迁移上来，可以在不投入运维人力的情况下获得一套完整的容器化运维方案。

基本上通过两者结合，可以覆盖掉我们绝大多数的业务场景，实现所有应用服务 All On Serverless。

业务实践

函数计算 FC

1）通过 OSS 触发的全自动模型部署/小时级更新服务。

我们有一个通过 OSS 触发的模型自动部署与更新服务，实现模型导出及部署。算法同学在训练完自己的模型，无论是 TensorFlow 还是 PyTorch 以及其他格式的机器学习模型，只需要导出到指定的 OSS B 存储空间 ucket，就会触发模型的更新与部署服务，实现完整的导出即部署。这样算法同学哪怕在不依赖其他工程人力的情况下也能自行进行模型的部署、更新以及后续的弹性缩扩容。

2）通过 HTTP 触发的模型实验管理平台（WEB 服务）

算法同学通过 HTTP 触发器实现的内部模型实验管理与参数平台提交模型训练任务之后，我们会自动地将它训练的参数以及日志地址、日志实例记录下来，实现所有的实验可追溯、可管理，这本身是一个 Web 服务，它是有前端的，但又是一个对内的服务，对 QPS 和性能要求不是很高，于是就放到函数计算上，在管理成本上相当有优势，尤其是近期函数计算有免费额度，所以基本没花钱。

3）通过 Kafka 触发新内容 NLP 处理/解析服务

当我们站内的用户发了一个新的帖子，我们会通过 Kafka 推送到 NLP 分析服务商进行 NLP 的处理与解析，存下来用于之后的搜索，这可以实现用户发一条内容调一次服务，精确地控制成本。

4）每周/每日定时统计资源消费

每周/每日定时触发的 MaxCompute、EAS 资源消费统计，我们会自动拉取阿里云后台的非结构化消费账单，然后将它聚合到每一位同学，每个任务以及每个模型上，推送给组内的同学，协助组内同学提升自己的成本意识，也帮助各个业务线更好地做成本管理。

Serverless 应用引擎 SAE

在 SAE 的落地上，我们选择了组内的预估服务，这个服务本身整合了搜索、推荐、广告都需要的模型推理、特征开发以及样本回传的能力，本身是一个中台型微服务，所有业务线都可以非常低成本的接入目前组内最成熟的线上预估服务。例如现在的搜索页的推荐词的点击率预估，国际版的游戏点击率预估等。

通过 SAE，我们的服务快速具备了 Serverless 的能力，因为 SAE 本身屏蔽了很多资源管理、环境管理以及基础运维组件管理工作，使得我们可以快速地为国内国外的新场景、新业务上线一套独立的预估服务。

与此同时，我们也集成了 SAE 的告警平台，事件中心以及日志服务，我们通过钉钉告警就可以实时感知线上业务的状态，例如是否发生了 OOM 还是重启、错误日志之类的。

另外，本身这个服务也是接入了 Dubbo Go 框架使服务直接具备了服务注册发现，IP 直连，优雅上下线等微服务能力。相比之前使用 ECS 的模式，这套方案在运维管理以及开发上线和后续的成本管控上都有较大的优势，基本可以覆盖从开发上线后续运维的全流程，大大节省的组内的开发成本。

业务价值

简单运维，省心省力：开发可以轻松搞定应用开发、部署、管理全流程，让自己更专注于业务，也大大节省了运维的投入和成本。

不停机发布 +分钟级上线：SAE 支持灰度发布、滚动发布的能力，还提供了较为完善的 Open API，可以集成到 Git 中快速部署，使我们的服务具备了分钟级发版的能力，这个对于新业务尤其具有吸引力。

秒级弹性缩扩容：SAE 支持配置像 CPU、内存、QPS、RT、定时等不同维度指标的扩缩策略，可以帮助提升资源利用率。尤其是业务规模大了之后，通过配置更加精细的弹性策略，可以显著降低机器成本。

多语言微服务能力：SAE 提供了 PHP、Python、GO 等多种运行时，并且基于 K8s Service 多语言服务注册发现，实现了 Go 语言低成本微服务化。