Serverless最佳实践——伊对App视频直播场景

北京米连科技有限公司成立于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架构，在拥抱新技术的同时也能充分享受到云计算的红利。

查看更多：原文链接
本文为阿里中间件原创文章，未经允许不得转载。