费用节省 50%，函数计算 FC 助力分众传媒降本增效

作者：洛浩

分众传媒诞生于 2003 年，创建了电梯媒体广告模式，2005 年成为首家在美国纳斯达克上市的中国广告传媒股，2015 年分众传媒回归 A 股，市值破千亿。分众传媒营收超百亿关键在于，抓住了【电梯】这个核心场景。电梯是城市的基础设施，电梯这个日常的生活场景代表着四个词：主流人群、必经、高频、低干扰，而这四个词正是今天引爆品牌的核心稀缺资源。

分众独有的价值是在主流城市主流人群必经的电梯空间中每天形成了高频次有效到达，从而形成了强大的品牌引爆的能力。分众电梯媒体，覆盖 3.1 亿中国城市主流消费人群，超过 260 万个电梯终端。除了电梯终端外，还会印发大量的广告海报，怎样确保这些静态资源的张贴效果，成为分众的重要业务指标之一。因此，分众自研了图片识别处理系统。当工作人员更换好海报后，会通过 APP 端拍照上传到后台服务端。而每个周末，静态海报会批量进行更换，后台系统就会迎来处理高峰，大概需要集中处理几百万张图片。工作日的时候，更换频次相对较低，后台系统就会相对空闲。周末和工作日的流量峰值平均相差 10 倍以上，如下图所示，如果按照周末的峰值保有资源，会导致工作日产生大量的闲置资源。

随着业务规模的增长，业务方对后台服务的弹性诉求也越来越强，怎样能让后台系统能更加从容应对波峰波谷，又能平衡资源开销成为最大的痛点。其实早在 2019 年年底，分众就接触了函数计算 FC，同时也在摸索容器的使用方式。经过一段时间的探索，发现函数计算的模式更适合业务的发展。对于业务方来讲，主要关注点在业务和算法，不想接触太多的底层基础设施概念，容器的上手门槛和后期维护要比函数计算更高一些。

函数计算的落地实践

分众最早是采用单体架构来处理图片识别功能，切到函数计算后，采用前后端分离的架构，后端部分使用 API 网关 + FC，使用 API 网关是为了规范化 API。但是当时 FC 的使用上也并不是一帆风顺，首先对函数计算 FC 的稳定性、易用性、性能等方面也有诸多疑虑，而 FC 当时也的确存在一些限制，比如：

1. 没办法提供 CPU 使用率和内存使用率等监控；
2. 最大规格只能提供 2C3GB，担心复杂算法下，2C 支撑不了算法的资源要求；
3. 最大代码包支持 50MB，而图片识别算法动辄上 GB，最小的压缩包也有几百 MB；
4. FC 没办法常驻进程，担心弹性效率不足，影响响应耗时。

经过和分众的沟通测试，发现 FC 运行原理和云主机其实是不一样的，一些担忧点都可以被解决。对于 FC，每个请求都可以独占实例资源，通过水平弹性扩展来承载大流量。比如同时有 10 个请求到 FC，那么 FC 就可以同时启动 10 个同规格的容器来运行请求，当前请求执行完后才会接下个请求，因此可以保障每个请求的 CPU 资源都是独占的，而且请求间还可以做到故障隔离。

经过实际测试，发现 2G/约 1.33C 的资源规格可以满足大部分的图片识别场景，部分操作如加水印，还可以缩减到 512MB/约 0.33C（最小规格 128MB 内存/约 0.1C），达到最佳的资源使用配比，以节省费用。而针对体积较大的算法包，通过挂 NAS 盘的方式，也可以解决。在弹性方面，函数计算可以做到百毫秒级的弹性伸缩（冷启动），对 APP 端的 API 接口，端到端平均响应大约在 300ms 左右，基本可以满足；对图片识别来讲，因为是异步调用，所以对延迟并不敏感。最终上线后，大致的业务架构如下：

经过一段时间的线上运行，函数计算比较好的承载了线上的业务，弹性能力和响应耗时基本都符合业务诉求。业务峰值的时候，会扩容 7K 多个容器实例同时处理图片识别，峰谷的时候，实例会自动回缩。相比之前云主机的使用方式，费用节省至少在 50% 以上。另外还有个显著的好处是，函数计算对发布部署效率的提升，发布时间大概缩短了一个数量级，而且更加便捷。之前采用云主机部署的方式，全量更新代码需要写脚本每台机器上运行一遍，而 FC 只用上传一次代码后，底层的机器会自动替换成最新的代码，业务还能不中断。

函数计算的优化升级

但是随着业务的不断发展，峰值处理图片的数量也在一直变大，一向稳如泰山的 FC 在业务高峰期，逐渐开始产生一些流控和超时的报错，如下图：

经过排查发现，原来 FC + NAS 挂载算法依赖的方式运行代码，在业务高峰时，会遇到带宽瓶颈，导致部分请求运行耗时变大，加剧了并发的消耗，最终导致被流控和运行超时。如监控显示，原来在 NAS 中放置的代码依赖大概有 1GB 多，当并发被陡然拉起时，大量的 FC 实例会去 NAS 加载依赖，造成网络拥堵。最直接的办法是直接升级 NAS 实例的带宽，但是治标不治本。而经过 1 年多的发展，函数计算也增加了非常多的实用功能，和分众沟通后，推荐直接用镜像的方式来部署。对比原先 ZIP 包的部署方式，会增加一步打镜像的操作，但是带来的收益更加明显，首先依赖包和业务代码可以一起部署维护，镜像的方式更加标准；另外也可以省掉 NAS 盘，降低了网络依赖和单点故障风险。

部署过程当中也面临另外个问题，镜像太大！Python 3.8 基础镜像接近 1GB，所有算法依赖接近 3GB，最终生成的镜像有 4.2GB。直接部署到 FC，冷启动过程当中单单加载镜像就要 1 分多钟，幸好 FC 提供了镜像加速能力，加载时间极大的缩短到了 10 秒左右，如下是加速效果的对比。

另外，FC 也支持了大规格实例，可以直接部署16C32GB大规格实例，对一些强依赖CPU资源的算法，也可以直接部署到FC上运行。还有个比较好的功能，是 FC 在可观测方面的增长，像之前提到的CPU和内存使用率，也都开放支持了。在服务配置功能里，开启实例级别的监控后，在函数的监控视图下，就可以看到实例的 CPU 使用率、内存使用率、网络带宽情况等。这个对对分众的业务来讲，非常有用，针对不同的图片处理算法，可以根据 CPU 使用情况，来调整 FC 运行的规格，可以最大化的平衡成本和性能。

总结和展望

1. FC 在降本增效方面，有着非常不错的吸引力。尤其是对有波峰波谷和需要极速弹性的业务，是非常好的选型。另外像镜像部署、镜像加速、可观测等能力的增强，可以让分众更好的驾驭业务。
2. FC 最近还发布支持了 GPU 挂载能力，在业界也是首创，对后续需要依赖 GPU 推理加速的算法模型，也是个不错的选择。利用 Serverless 弹性伸缩和按需付费的优势，可以大大降低 GPU "用不起" 的现状。
3. 阿里云的 Serverless 不仅有函数计算平台，针对微服务应用，也在业界最先推出了 Serverless 应用引擎 SAE，对目前分众基于 K8s 部署的后台微服务也有着明显的优势：可以显著降低资源维护成本，提升整体研发效能，而且可以做到零代码改造平迁。后续会和分众一起探索微服务 On Serverless 的最佳实践。