当视频恋爱 App 用上了 Serverless

北京米连科技有限公司成立于 2015 年，是国家高新技术企业，旗下品牌伊对 App 上线于 2018 年，专注于移动端交友和相亲，将视频、直播和线上红娘创造性地融合在一起，开辟了视频恋爱社区的独立赛道，为单身人群提供了全新的社交体验。截至2020年，伊对 App 注册用户已达 1 亿，每月撮合线上相亲活动约 1000 万场，成为视频恋爱社交垂直领域最具影响力的品牌之一。

业务需求

---

随着伊对 App 业务的快速增长，核心应用的系统规模和系统复杂度也在经历着翻天覆地的变化。伊对 App 技术团队通过引进新的技术手段，维护整套系统架构的技术先进性，以更好地支持业务需求，降低IT成本。从成立以来，伊对 App 的核心系统架构完成了多次重大的升级，涉及微服务化、容器化、分布式数据库、大数据和人工智能等重要的技术，特别在 Serverless 技术的探索方面，伊对 App 投入了很大精力，以充分享受到云计算时代资源快速弹性伸缩的价值。

在伊对 App 的业务场景里面，视频直播是最为重要的环节，基于视频直播这个骨架，可以融入线上红娘等多类创新业务模式，这也对视频直播的内容安全提出了极高的要求。不论是自身通过 AI 技术对视频直播内容进行智能分析，还是应对监管的要求，都需要在每一路视频直播流开始后，根据固定频率对视频进行截帧，并通过统一的审核服务对截帧生成的图片进行处理。

在这个需求里面，截帧服务承担着关键职责，这个服务不仅需要通过 FFmpeg 命令对每一路直播视频流进行截帧操作，还需要将生成的图片保存到对象存储 OSS，并将截帧信息写入到 Kafka。这样下游的截帧服务就能从 Kafka 上拉取截帧信息，并从截帧信息中得到图片在 OSS 中的地址，从而完成对于图片的审核。在这个架构中，引入 Kafka 是为了通过异步处理机制缓解审核服务在业务高峰期的负载。

业务痛点

---

FFmpeg 截帧命令使用非常简单，但这是一个对于 CPU 算力要求非常高的操作。根据伊对 App 技术团队的多次试验，采用 ECS 部署截帧服务，是一个相对成本最优的选择。如果按照每秒钟1次截帧的固定频繁，1台 ECS 能够同时支撑大约数百路直播视频流的截帧任务。为了保障业务高峰期的资源储备，伊对 App 准备了大量 ECS 来部署截帧服务。跟绝大多数互联网应用一样，伊对 App 的负载也存在着波峰波谷，这样的波动对伊对 App 整体的资源规划带来了极高的挑战，如果按照固定的 ECS 集群规模来部署截帧服务，会存在两个非常明显的弊端：

1、为了支持业务高峰，必须按照高峰期的用户量来评估集群规模，在业务低峰期就会造成巨大的浪费。

2、在某些场景下，比如节假日效应的带动，业务量会有突增，有可能需要对集群进行临时扩容，这种情况下往往扩容速度会滞后于业务流的增速，造成部分业务的降级处理。

为了节省资源成本，伊对 App 也探索过很多种弹性伸缩策略，比如通过弹性 ECS 实例配合容器化的方式部署应用，以实现集群规模能动态适配真实业务量的变化。但这些策略的实现都比较复杂，弹性伸缩能力都相对滞后。其中根本的原因是在传统的服务架构中，一个应用启动后都是长期保持运行的，在运行期间会并发会处理多个业务需求，不管业务量如何变化，这个应用占据的计算力都不会有本质的变化。

有没有一种直截了当的方式，可以在一路直播视频流开启后，拉起对应的计算力承接截帧任务，而在视频流关闭后，自动将计算力释放呢？这样的方式不需要应用实例长驻，可以实现真正的计算资源按需分配，也不需要借助额外的手段动态调整截帧服务的集群规模，是一种最为理想的方案。

作为云原生 Serverless 技术的代表，阿里云函数计算FC就正好实现了这样的思路。

函数计算FC有哪些独特之处？

---

阿里云自研的 Serverless 产品函数计算 FC 是事件驱动的全托管计算服务，完美契合了伊对 App 的需求和痛点。使用函数计算，用户无需采购与管理服务器等基础设施，只需编写并上传代码。函数计算会自动准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。借助函数计算 FC，可以快速构建任何类型的应用和服务，并且只需为任务实际消耗的资源付费。

函数计算 FC 提供了一种事件驱动的计算模型，函数的执行是由事件驱动的。函数的执行可以通过函数使用者自己触发，也可以由其它一些事件源来触发。可以在指定函数中创建触发器，该触发器描述了一组规则，当某个事件满足这些规则，事件源就会触发相应的函数。比如对于 HTTP 触发起而言，用户的一次 HTTP 请求就能触发一个函数；而对于 OSS 触发器而言，OSS 上新增或修改一个文件就能触发一个函数。在伊对 App 的视频截帧场景中，函数只需要在每一个直播流开始推送之前，通过业务程序主动触发一个截帧函数就可以了。因此之前截帧业务的架构只需要做很小的调整，就能迁移到函数计算平台上来，以享受 Serverless 的价值。

解决方案及优势

---

支持多种编程语言的 Runtime

伊对 App 的技术团队第一次和阿里云沟通 Serverless 方案的时候，阿里云的技术人员推荐使用 Python 语言实现截帧函数，因为函数计算 FC 对于 Node.js、Python、PHP、Java 等语言提供了原生的运行环境，而且像 Python 这样的脚本语言可以实现在函数计算平台上直接修改调度代码，使用非常简单。

其实函数计算 FC 对于开发语言没有要求，任何主流的开发语言都可以很好的支持。通过函数计算 FC 提供的 Custom Runtime，可以为任务语言建立自定义的运行环境。Custom Runtime 本质上是一个 HTTP Server，这个 HTTP Server 接管了函数计算系统的所有请求，包括来自事件调用或者 HTTP 函数调用。

极致弹性和高可用性

由于在 Serverless 架构下，每一路直播视频流都会拉起新的计算资源来承接截帧任务，因此并不需要采用高规格的 ECS 实例同时并发处理多个截帧任务。通过反复的测试，伊对 App 采取了最适合的函数计算实例来完成每路视频流的截帧任务。

函数计算 FC 在计算资源的启动方面做了大量优化，配合云化的资源池，能够在 100 毫秒的时间内调度大量计算实例，以承载特殊情况下突增的业务流量。

为了更进一步的适配伊对App的业务场景，阿里云函数计算团队还专门为伊对 App 提供了定时预热的方式，以最大程度的保障业务高峰期冷启动计算资源的性能。这样极致的弹性伸缩能力是 Serverless 的专长，传统的应用架构的弹性伸缩依赖于底层计算资源的调度，以及复杂的初始化工作，在计算实例的启动速度上远远达不到这个水平。

正常情况下，函数计算 FC 上一个普通弹性实例可运行时长为 10 分钟，此外还提供了性能实例，以应对更高的资源需求，性能实例在可运行时长上也提升到了数小时。在伊对 App 的截帧场景中，单实例并不需要有很高的性能，但有必要伴随着直播视频流长期运行，因此阿里云也为伊对 App 适当放开了弹性实例的运行时长限制：达到 1 小时。

对于超过1小时的直播，同样可以支持：在截帧场景中，当一个函数实例将要达到运行时长限制的时候，只需要再拉起一个新的函数实例对截帧任务进行接力就可以了，对于截帧业务的正常运行不会有任何影响。

节省资源，降本增效

函数计算 FC 在实现计算资源按需调度，按量计费的同时，还通过预留实例的模型更进一步降低使用成本。根据初步的评估，在直播截帧这个业务场景上，通过基于函数计算 FC 的 Serverless 架构，能够帮助伊对 App 减少 20% 以上的资源成本开支。 

此外，由于函数计算 FC 不需要预留计算资源，也不需要对底层的软硬件进行维护，极大程度降低了运营成本，可以让伊对 App 的技术团队更专注在复杂业务逻辑的实现上，这也是 Serverless 技术为广大企业和开发者带来的巨大价值之一。

总结

---

在直播截帧场景试点 Serverless 技术成功后，伊对 App 继续在更多业务领域发掘 Serverless 技术的匹配场景。未来，伊对 App 将继续基于自身的技术特点不断深入探索 Serverless 架构，在拥抱新技术的同时，也能充分享受到云计算的红利。

﹀

﹀

﹀

点在看，让更多人看见。