作者：洛浩
分众传媒诞生于 2003 年，创立了电梯媒体广告模式，2005 年成为首家在美国纳斯达克上市的中国广告传媒股，2015 年分众传媒回归 A 股，市值破千亿。分众传媒营收超百亿关键在于，抓住了【电梯】这个外围场景。电梯是城市的基础设施，电梯这个日常的生存场景代表着四个词：支流人群、必经、高频、低烦扰，而这四个词正是明天引爆品牌的外围稀缺资源。
分众独有的价值是在支流城市支流人群必经的电梯空间中每天造成了高频次无效达到，从而造成了弱小的品牌引爆的能力。分众电梯媒体，笼罩 3.1 亿中国城市支流生产人群，超过 260 万个电梯终端。除了电梯终端外，还会印发大量的广告海报，怎么确保这些动态资源的张贴成果，成为分众的重要业务指标之一。因而，分众自研了图片辨认解决零碎。当工作人员更换好海报后，会通过 APP 端拍照上传到后盾服务端。而每个周末，动态海报会批量进行更换，后盾零碎就会迎来解决顶峰，大略须要集中处理几百万张图片。工作日的时候，更换频次绝对较低，后盾零碎就会绝对闲暇。周末和工作日的流量峰值均匀相差 10 倍以上，如下图所示，如果依照周末的峰值保有资源，会导致工作日产生大量的闲置资源。
随着业务规模的增长，业务方对后盾服务的弹性诉求也越来越强，怎么能让后盾零碎能更加从容应对波峰波谷，又能均衡资源开销成为最大的痛点。其实早在 2019 年年底，分众就接触了函数计算 FC，同时也在摸索容器的应用形式。通过一段时间的摸索，发现函数计算的模式更适宜业务的倒退。对于业务方来讲，次要关注点在业务和算法，不想接触太多的底层基础设施概念，容器的上手门槛和前期保护要比函数计算更高一些。
函数计算的落地实际
分众最早是采纳单体架构来解决图片辨认性能，切到函数计算后，采纳前后端拆散的架构，后端局部应用 API 网关 + FC，应用 API 网关是为了规范化 API。然而过后 FC 的应用上也并不是一帆风顺，首先对函数计算 FC 的稳定性、易用性、性能等方面也有诸多疑虑，而 FC 过后也确实存在一些限度，比方：
- 没方法提供 CPU 使用率和内存使用率等监控；
- 最大规格只能提供 2C3GB，放心简单算法下，2C 支撑不了算法的资源要求；
- 最大代码包反对 50MB，而图片辨认算法动辄上 GB，最小的压缩包也有几百 MB；
- 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 运行的规格，能够最大化的均衡老本和性能。
总结和瞻望
- FC 在降本增效方面，有着十分不错的吸引力。尤其是对有波峰波谷和须要极速弹性的业务，是十分好的选型。另外像镜像部署、镜像减速、可观测等能力的加强，能够让分众更好的驾驭业务。
- FC 最近还公布反对了 GPU 挂载能力，在业界也是独创，对后续须要依赖 GPU 推理减速的算法模型，也是个不错的抉择。利用 Serverless 弹性伸缩和按需付费的劣势，能够大大降低 GPU “ 用不起 ” 的现状。
- 阿里云的 Serverless 不仅有函数计算平台，针对微服务利用，也在业界最先推出了 Serverless 利用引擎 SAE，对目前分众基于 K8s 部署的后盾微服务也有着显著的劣势：能够显著升高资源保护老本，晋升整体研发效力，而且能够做到零代码革新平迁。后续会和分众一起摸索微服务 On Serverless 的最佳实际。