共计 2961 个字符，预计需要花费 8 分钟才能阅读完成。
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 语言低成本微服务化。
