简介：随着业务规模的增长，业务方对后盾服务的弹性诉求越来越强怎么办？云原生峰会火线最佳落地实际心得分享：看分众传媒如何借助 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，来简化咱们的运维、提高效率，值得期待。
原文链接
本文为阿里云原创内容，未经容许不得转载。