关于阿里云开发者:当视频恋爱-App-用上了-Serverless

1次阅读

共计 3461 个字符,预计需要花费 9 分钟才能阅读完成。

简介: 阿里云自研的 Serverless 产品函数计算 FC 是事件驱动的全托管计算服务,完满符合了伊对 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 集群规模来部署截帧服务,会存在两个非常明显的弊病:

为了反对业务顶峰,必须依照高峰期的用户量来评估集群规模,在业务低峰期就会造成微小的节约。

在某些场景下,比方节假日效应的带动,业务量会有突增,有可能须要对集群进行长期扩容,这种状况下往往扩容速度会滞后于业务流的增速,造成局部业务的降级解决。

为了节俭资源老本,伊对 App 也摸索过很多种弹性伸缩策略,比方通过弹性 ECS 实例配合容器化的形式部署利用,以实现集群规模能动静适配实在业务量的变动。但这些策略的实现都比较复杂,弹性伸缩能力都绝对滞后。其中基本的起因是在传统的服务架构中,一个利用启动后都是长期保持运行的,在运行期间会并发会解决多个业务需要,不论业务量如何变动,这个利用占据的计算力都不会有实质的变动。

有没有一种含糊其辞的形式,能够在一路直播视频流开启后,拉起对应的计算力承接截帧工作,而在视频流敞开后,主动将计算力开释呢?这样的形式不须要利用实例长驻,能够实现真正的计算资源按需分配,也不须要借助额定的伎俩动静调整截帧服务的集群规模,是一种最为现实的计划。

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

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

阿里云自研的 Serverless 产品函数计算 FC 是事件驱动的全托管计算服务,完满符合了伊对 App 的需要和痛点。应用函数计算,用户无需洽购与治理服务器等基础设施,只需编写并上传代码。函数计算会主动筹备好计算资源,弹性地、牢靠地运行工作,并提供日志查问、性能监控和报警等性能。借助函数计算 FC,能够疾速构建任何类型的利用和服务,并且只需为工作理论耗费的资源付费。

函数计算 FC 提供了一种事件驱动的计算模型,函数的执行是由事件驱动的。函数的执行能够通过函数使用者本人触发,也能够由其它一些事件源来触发。能够在指定函数中创立触发器,该触发器形容了一组规定,当某个事件满足这些规定,事件源就会触发相应的函数。比方对于 HTTP 触发起而言,用户的一次 HTTP 申请就能触发一个函数;而对于 OSS 触发器而言,OSS 上新增或批改一个文件就能触发一个函数。在伊对 App 的视频截帧场景中,函数只须要在每一个直播流开始推送之前,通过业务程序被动触发一个截帧函数就能够了。因而之前截帧业务的架构只须要做很小的调整,就能迁徙到函数计算平台上来,以享受 Serverless 的价值。

解决方案及劣势

1、反对多种编程语言的 Runtime

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

其实函数计算 FC 对于开发语言没有要求,任何支流的开发语言都能够很好的反对。通过函数计算 FC 提供的 Custom Runtime,能够为工作语言建设自定义的运行环境。Custom Runtime 实质上是一个 HTTP Server,这个 HTTP Server 接管了函数计算零碎的所有申请,包含来自事件调用或者 HTTP 函数调用。

2、极致弹性和高可用性

因为在 Serverless 架构下,每一路直播视频流都会拉起新的计算资源来承接截帧工作,因而并不需要采纳高规格的 ECS 实例同时并发解决多个截帧工作。通过重复的测试,伊对 App 采取了最适宜的函数计算实例来实现每路视频流的截帧工作。

函数计算 FC 在计算资源的启动方面做了大量优化,配合云化的资源池,可能在 100 毫秒的工夫内调度大量计算实例,以承载非凡状况下突增的业务流量。

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

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

对于超过 1 小时的直播,同样能够反对:在截帧场景中,当一个函数实例将要达到运行时长限度的时候,只须要再拉起一个新的函数实例对截帧工作进行接力就能够了,对于截帧业务的失常运行不会有任何影响。

3、节俭资源,降本增效

函数计算 FC 在实现计算资源按需调度,按量计费的同时,还通过预留实例的模型更进一步升高应用老本。依据初步的评估,在直播截帧这个业务场景上,通过基于函数计算 FC 的 Serverless 架构,可能帮忙伊对 App 缩小 20% 以上的资源老本开销。

此外,因为函数计算 FC 不须要预留计算资源,也不须要对底层的软硬件进行保护,极大水平升高了经营老本,能够让伊对 App 的技术团队更专一在简单业务逻辑的实现上,这也是 Serverless 技术为宽广企业和开发者带来的微小价值之一。

总结

在直播截帧场景试点 Serverless 技术胜利后,伊对 App 持续在更多业务畛域挖掘 Serverless 技术的匹配场景。将来,伊对 App 将持续基于本身的技术特点不断深入摸索 Serverless 架构,在拥抱新技术的同时,也能充沛享受到云计算的红利。

版权申明: 本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

正文完
 0