10

开发运维效率提升 80%，计算成本下降 50%，分众传媒的 Serverless 实践

 3 years ago
source link: https://segmentfault.com/a/1190000041453637
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

作者：吴松

本文总结于分众传媒研发总监吴松在阿里云云原生实战峰会上的分享，从三个方面讲述了对 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，来简化我们的运维、提高效率，值得期待。

点击此处，前往云原生子社区查看更多相关资讯。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK