【笔记】《由浅入深SCF无服务器云函数实践》

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/CSDN_duomaomao/article/details/78910588

《由浅入深SCF无服务器云函数实践》

学习笔记

来源:DockOne技术交流群分享

主办方:dockone.io

地点:DockOne技术交流群

时间:2017年12月26日晚8:30

分享人:陈杰(腾讯架构平台部)

分享人介绍陈杰,腾讯云架构平台部技术专家。10年云计算经验,现供职于腾讯架构平台部,负责弹性计算及云函数技术研发,致力于提供领先的基础设施平台以提升资源利用率及优化提升程序员开发运维效率。

分享摘要:近年来,互联网服务从一开始的物理服务器托管,虚拟机,容器,发展到现在的云函数,逐步无服务器化。程序员逐步聚焦于最核心的业务逻辑开发,解放了生产力,显著提升服务上线效率。云函数带来了真正的计算服务。


本次分享主要从无服务器云函数实践入手,
从以下几个应用场景来为大家讲解Serverless的实践应用:

使用云函数实现主动拨测工具
使用云函数规整运营统计脚本
使用云函数快速嵌入图片类型识别功能
使用云函数实现游戏AI数据预处理

 

今天给大家分享一下我们团队使用SCF无服务器云函数将一些工作Serverless化的一些经验。

近年来,互联网服务从一开始的物理服务器托管,虚拟机,容器,发展到现在的云函数,逐步无服务器化,如下表所示。程序员逐步聚焦于最核心的业务逻辑开发,解放了生产力,显著提升了服务上线效率。

云函数带来了真正的计算服务,如下表所示,类比腾讯云COS对象存储,SCF以函数为单位封装计算,按需调度执行,无须关心函数的自动扩缩容,故障容灾等,无任何闲置成本。

(图01、图02)

 


云函数给用户带来的价值主要4点:

 

1. 简化架构函数粒度的微服务架构,使得系统的各个功能天然解耦,能像搭积木一样组合自有及外部服务,实现所看即所得的后台服务;

2. 简化开发无需关注底层硬件配置、OS,服务启停、网络收发,故障容灾,服务扩缩容等,只需写最核心的业务逻辑,实现真正的代码即服务;

3. 简化运维无须关注服务部署,服务器运维,安全管控,扩缩容配置等,且应用能无缝升级,实现无痛切换到DevOps模式。

4. 减少支出无闲置成本,仅对函数资源大小,执行时间,执行次数按需计费,相对云主机平均5%~15% 的使用率,价格优势明显,实现了最彻底的按需计费。

 

我们团队正在做弹性计算相关的事情,业务需求多,平台自身也需持续优化来支撑不断扩大的运营规模,现在5人左右的小团队要支撑100w核级别的计算运营,云函数的出现,正好解了我们在人力上的燃眉之急,在这里分享一下,希望能对大家有所启发。

 

一. 使用云函数实现http主动拨测工具

 

  我们有一些低频调用的http服务,比如buffer池空闲机器借还,上架等,这类服务用户调用出错时处理代价较大,要确保用户调用时服务正常,需要有主动拨测的机制,先于用户发现并修复问题,在云函数出现之前,需要开发拨测工具,实现定时调用,并实现工具本身的故障容灾能力,且要申请2台以上的虚拟机或容器发布部署,既耗费人力,也耗费资源。应用云函数后,我们只需简单的3步便可实现:

1. 在SCF云函数平台创建一个函数,如下图所示。

2. 开发主动拨测函数的代码,如下所示,只需关注拨测本身,代码使用curl工具探测url的返回码,如果不为200则告警,无须关心资源分配,故障容灾等。

3. 配置该函数为定时触发,比如5分钟触发一次,如下图所示,配置完成后服务即刻启用。

4. 可以在日志页面查看函数运行状态,当检测到异常时,会调用告警工具发送告警微信。

(图03、图04、图05、图06)

 




在主动拨测工具这个场景,我们从云函数获得的收益主要是快速成形,且无需运营维护,达到了既定目标同时,没有额外增加运营成本。SCF无服务器云函数为每个用户设置了免费额度,该应用场景几乎肯定能包含在免费额度之内。

 

二. 使用云函数规整运营统计脚本

 

我们之前用python开发了大量统计脚本,用来展现平台的运营概况,可用性,质量,趋势等,由crontab驱动每日定期执行,随着时间累积及人员的更替,这些脚本部署管理逐步混乱,比如想要修复某个数据时,可能不知道脚本部署在哪,或者某天服务器故障,恢复统计脚本的正常运营比较麻烦。

针对这些问题,我们利用云函数简单包装便可解决,比如下面是一个统计运营中母机数的函数,直接import原脚本,在入口函数内调用即可。

在规整运营统计脚本这个场景,我们从云函数获得的主要收益是快速帮助我们把散落到各台服务器的脚本规整起来统一维护,且再也不用担心统计脚本运营与服务器故障问题。

(图07)

 

三. 使用云函数快速嵌入图片类型识别功能

 

我们有一个图片压缩服务,上传时压缩图片以降低存储容量及下载带宽消耗,压缩的效果要达到图片质量与压缩比的均衡,在某些场景,比如微信朋友圈,存在一些广告图片,用户一般不会关注其细节,故可以提高压缩比,牺牲质量以进一步的降低运营成本,而图片类型的识别计算复杂度高,无法在逻辑svr本地完成

传统的办法是实现一个图片类型识别服务,但实现该服务需要开发工作量较大,比如需要写接入,逻辑server,实现容灾分布,负载均衡等,且由于图片上传有明显的波峰波谷效应,还需要实现自动扩缩容,不仅如此,部署也较为复杂,难以满足快速试错上线的需求。

使用云函数后,我们只需创建并实现一个类型识别函数,如下图所示。

(图08)


实现时在函数里调用算法工程师实现的C++图片识别程序即可,无须关心容灾分布,负载均衡,自动扩缩容及服务的部署与运维等。

(图09)


在嵌入图片类型识别功能这个场景,我们从云函数获得的主要收益是使用极小的成本便快速扩展了现有平台的能力,短时间内便试错验证了依据图片类型选择不同压缩比在运营成本上的收益。

 

四. 使用云函数实现游戏AI数据预处理

 

尝到甜头后,我们越来越有信心使用云函数来实现更复杂的需求,正好当前在支持游戏AI团队做一些计算(数据预处理,特征提取等),典型的AI计算过程如下图所示,模型训练前的数据预处理耗费了大量的时间与计算资源

(图10)


以王者荣耀的AI为例,如下图所示,数据预处理一般分为两步:

 

Mapper计算从cos读取游戏录像文件,提取英雄等级,血量,攻击,法强,技能冷却等特征,使用hdf5文件保存;

Reducer计算读取选定范围的hdf5文件,shuffle处理随机化后,规整成每个文件5120帧,再输出供模型训练使用

(图11)


我们应用云函数实现该预处理,只需实现mapper/reducer计算函数,并配置合适的计算触发规则即可,比如实现Mapper函数如下所示(省略若工具型函数代码),并配置为cos上传触发,这样当有录像文件上传时,可自动调用mapper函数转化为hdf5文件。(这里代码较多,只贴部分代码,详细代码可见dockerone相关文章。)

(图12-14)

 




实现Reducer函数如下所示(省略若工具型函数代码),亦可配置cos写文件触发,当上传文件数达到一定数量且符合其他条件时,执行reducer函数的处理功能。

(图15-18)

 




在游戏AI训练数据预处理这个场景,我们从云函数获得的主要收益是快速实现数据预处理服务,避免AI工程师陷入到考虑计算分布化,容灾,扩容,服务器故障处理等平台性事项中,能够更专注于算法设计;另外AI计算资源耗费量巨大,云函数实现了资源真正按需分配,无需保留大批服务器造成资源浪费。

在应用SCF无服务器云函数实践过程中,深刻体会到了其减少设计开发,运营维护工作量及在运营成本方面的优势,如果开发新的功能,云函数会成为我们团队的首选。

作为团队架构师,应该承当好的一个责任是与时俱进的引入新生产力工具,持续推进团队开发运营效率提升及持续的追求成本优化,由于云函数在加速服务上线时间方面革命性的优势及按需使用计费的特点,它可能会比docker容器更快被广泛接受,谁能更快的拥抱云函数,谁便能更快的建立研发与运营的优势

欢迎大家试用腾讯云-SCF无服务器云函数,一起更好的迎接并促进Serverless无服务器时代的到来。

 

Q:云函数怎么和其它业务系统集成

A:在腾讯云产品中,云函数已经和COS、CMQ、API gateway、日志等打通,可直接配置事件触发关系,另外用户在函数代码里,可自行实现与其它业务系统集成的代码,当前云函数直接可访问公网服务,马上可访问用户VPC里的服务

 

Q:云函数实际应用中,和一般写法有什么不同,有什么缺点?

A:云函数当前支持python2.7, 3.6, node.js 6.10, Java 8等运行环境,可在本地开发编写代码上传,也可在云端直接编写,对比一般程序的写法,无须实现网络监听,故障容灾,扩容,日志监控等相关代码,极大的减少大家的代码开发量,缺点是调试不如本地方便,比如不能直接用GDB等工具单步调试

 

Q: 腾讯SCF对于有状态服务是怎么滚动更新的扩容的 

A: SCF一般用来承载无状态的微服务,如果是有状态的实现滚动更新,需要把状态数据保存到CMQ, COS等持久化存储里

 

Q: 对云函数不是太懂  云函数与函数之间调用是通过http协议吗 还是rpc或者其他方式?

A: 函数之间调用采用http协议,这是业内cloud function的通用做法,内部模块之间使用rpc通信

 

Q: 如果一个函数一个容器 那一个项目函数至少几万个吧 这样岂不是要部署上万个容器?

A:  函数被真实调用时,才会去分配容器,同时存在的容器数取决于有多少个函数正在被调用,调用的并发次数是多少,这是云函数的最大价值之一:避免资源闲置

 

Q: 代码文件是通过dockerfile打包进容器的吗?这样构建会不会有点慢,像在线执行代码这类的,感觉都很及时。

A: 通过docker file打包成镜像再下载,确实耗时很长,所以实际运行代码没打包到镜像里,而是直接下发到母机,再将目录挂到容器里面

 

好的,今天分享到此结束,感谢@陈杰

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

展开阅读全文

没有更多推荐了,返回首页