临邑云速网站建设,做网站优化推广的好处,瑞华特散热器网站谁给做的,WordPress会员卡插件简介#xff1a;随着业务规模的增长#xff0c;业务方对后台服务的弹性诉求越来越强怎么办#xff1f;云原生峰会前线最佳落地实践心得分享#xff1a;看分众传媒如何借助 Serverless 函数计算提升 80% 开发运维效率#xff0c;有效降低计算成本~ 作者 | 吴松#xff08;…简介随着业务规模的增长业务方对后台服务的弹性诉求越来越强怎么办云原生峰会前线最佳落地实践心得分享看分众传媒如何借助 Serverless 函数计算提升 80% 开发运维效率有效降低计算成本~ 作者 | 吴松分众传媒研发总监
本文总结于分众传媒研发总监吴松在阿里云云原生实战峰会上的分享从三个方面详细讲述了对 Serverless 技术的探索。
分众传媒的业务现状 分众传媒的业务场景很简单就是广告主买量然后进行投放排期和统计最后进行效果展示。业务场景前期要做广告设计、视频处理后期还有一个广告投放、效果展示可能会给客户提供各种各样的数据展示。分众传媒主要的业务形态有静态海报市场占有率超过 73%电梯屏幕 30 万块覆盖 91% 中高档的写字楼。 我们把云原生应用架构应用于手机 APP 和视频终端而业务应用则有很多比如员工接入、CRM、视频处理、图片识别、数据上报、数据分析、视频直播。其中视频直播是新开发的业务就是为了把直播视频实时推到分众传媒的屏端上。 云服务则用到 SLB、MQDT、转码服务、IoT 等等。先说一下 IoT我们现在所有屏端都是用的都是阿里云的 IoT 服务。这项服务带来的最大优势是屏端连通率大概可以保持在 95% 左右这大大提升了团队工作效率。
因为以前我们的屏端都是要人工去插卡上刊现在接入 IoT 之后我们的业务量从原来的 50% 提升到了现在的 95%也就是说在外面 100 台设备有 95 台设备连网这可以很好地支撑我们的业务给我们的技术实现带来了很大的价值。
另外我们有 200 万个静态的电梯海报每周都需要上刊在上刊之后会有图片处理的流程。这块目前使用的是自动识别处理每次上刊之后需要判断图片是否上错或者图片有没有放反。这一系列操作现在全部可以实时通知到上刊人员一旦出现上刊之后图片放错、放反的问题可以及时通过手机短信通知到相关负责人提醒他们立刻采取措施去解决保证在一个小时之内完成。
Serverless 的探索实践 传统服务器无法满足我们的业务高速增长主要有三大痛点。耗时太长、资源利用率低、运维复杂对人员技能要求高。
耗时太长以前的人工上刊无法及时知道上刊是否正确或者错误需要花费很多时间去核对和修改资源利用率低上刊的主要业务是集中在周六和周日因此所有资源基本在周六周日使用大部分时间段是不需要使用服务器资源的运维复杂、人员技能要求高大家都会遇到的常规痛点由于业务的复杂度对相关业务人员的技能要求也高同时也需要招聘更高级的人员来支持对应的运维工作。
于是对于我们来说上云有两个选择。第一个是用 K8s 服务自己搭建一套容器集群第二个是用函数计算 FC。那我们是如何选择的呢 在选择 Serverless 时其实我们也有一些担忧。第一是大规模的实践案例第二是图象识别的算法往往很大函数计算 FC 能否适用第三FC 最高规格只能支持 2C3GB这对我们业务有很大的考验。第四是否可以提供 CPU 使用和内存使用的监控等等。这些都是我们很担忧的一些问题。
K8s 和 Serverless 运行原理的差异大家可以从上图中看到如果用 K8s 请求云主机我们需要自己搭建 K8s通过对外的 API 来提供请求而使用 Serverless 计算平台我们不需要关心用了多少服务器或者多少人力我们只需要关心每一次 API 请求是否正确到达和触达就可以确认每次的图象识别是否有确切识别到图片并把识别错误的东西发出来通知到上刊人员。
因此我们最后选择了函数计算因为它有以下 3 个突出优势
自动弹性收缩比如只需要告诉他每周六每周日有两百万处理量要在两天完成其中高峰是早上九到十点或者下午三到四点就可以实现资源的自动弹性收缩资源免运维解决我们需要请专业人员来负责支持运维的痛点可提供大规模的识别能力当我们请求每天上刊人员在早上六点、七点、八点上刊时背后能够实时的在固定时间提供算力
我们用到很多开发语言例如 PHP、C、Python如果用 K8s 去改造难度很大。但如果用 Serverless改造成本就小很多。 我们在图片识别系统进行了的初步试水就是刚才说的我们分众有两百万电梯海报每周上刊需要每张图片精准送达。所以说我们在上线图片识别系统时每一张图片都会上传 OSS通过 OSS 打通我们 MNS 服务再把消息发送到函数计算 FC然后再对消息进行处理之后就可以对图片进行加水印、图象识别、图片匹配了从而可以精准地告诉正在上刊的工人你的图片上刊成功了可以上刊下一张图片了。
在这个业务峰值图上可以看到FC 支持一分钟内扩充到 7000 的实例。如果我们自己部署 K8s 会牵扯到很多人力和物力因此我们最终选择了 Serverless。
All On Serverless 化繁为简
2021 年年底我们对 Serverless 进行了业务升级。以前服务是在 NAS 上这会导致我们们必须实时关注 NAS 有没有挂掉因为 NAS 挂掉的话FC 业务就启动不起来了。比如我们周末排查业务时发现 NAS 挂掉了导致算法接不进这类问题。于是我们对服务端就进行了升级把业务放在容器里通过镜像来部署这样可以提高缓存解决很大的高峰时的业务问题镜像启动比以前通过 NAS 挂载要快很多这是对业务提升最大的地方。
升级后的 Serverless 提供了丰富的监控指标提升监控效率提升了很多错误统计、CPU 效率等指标可以基于监控数据快速定位到现在业务运行状态。
通过 Serverless 的实践可以让我们的开发更关注到业务开发里比如可以让图象识别的开发人员更关注图象识别的识别率把更多运维工作交给 FC 去处理所以说 Serverless 给我们提供了极致弹性、自动扩容、应对流量突增、让开发更加关注业务等益处。 我们用了 Serverless 之后可以看到团队的开发运维效率提升了 80%计算成本下降了 50%。以前我们会部署很多的服务器以及 GPU 服务器去实现我们的图像算法的一块业务现在我们都不用了弹性效果提升了十倍以上。
总结和思考
我们现在将 Serverless 主要应用于图象识别算法上他具有 CPU 密集型、对弹性有极致要求的特点。此外Serverless 也适用于事件驱动的业务模型来简化架构复杂度从而不需要关注背后的东西。如果用 K8s这会牵扯到很多的业务逻辑。
后续我们还会考虑将 Serverless 和 Kafka 进行结合用在大数据的处理上这样的效率会更的简化Flink的使用成本。视频直播业务上直播流实时推送到视频终端的部分也是我们尝试使用 Serverless 来解决。
微服务方面我们也正在考虑另一款 Serverless 形态的产品——Serverless 应用引擎 SAE来简化我们的运维、提高效率值得期待。
原文链接
本文为阿里云原创内容未经允许不得转载。
