南瓜电影 7 天内全面 Serverless 化实践-轻识

作者 | 庄徐麟

从我们了解 SAE 产品到整体上线一共是 7 天时间。3 天完成核心应用 API 网关上线，第 5 天验证结束 100% 流量打到 SAE 上，第 6-7 天把其余 30 多个系统快速迁移到 SAE，整个过程非常顺利。使用 SAE 后，运维效率提升 70%，成本下降超过 40%，扩容效率提升 10 倍以上，这是给我们带来的直观改变。
—南瓜电影 CTO 庄徐麟

南瓜电影成立于 2015 年，是国内近两年发展非常迅速的流媒体平台，凭借着无广告、纯付费的商业模式，在影迷圈中打响了一定的知名度；之后又靠着很强的社区互动性（AI 智能推荐、影评互动、通过放映厅实现线上“云观影”等），迅速完成会员增长及流媒体市场占位；接下来将逐渐往多元化视频平台发展：如纪录片、各类自制节目等。

作为互联网风口上的行业，流量和生命周期会因为市场风向的变化而有着截然不同的表现，这对企业的创新和低成本试错提出了更高的要求。南瓜电影的整体应用架构也随着业务的高速发展，持续不断地进化。今天我主要从三个部分来和大家分享这一段发展历程：

痛点：回顾南瓜电影当时的业务、架构现状和痛点。

选型：分享在技术选型之路上我们的思考和决策，以及为什么最终会选择使用 SAE 这款产品。

实战：我们是怎么一步步落地、在短短 7 天内将整个平台几百台服务器，30 多个系统全面 Serverless 化的。

痛点

从创业之初，南瓜电影的整体应用架构就构建在阿里云之上，是一个典型的“生在云上，长在云上”的企业。底层使用阿里云 ECS，基础设施、中间件，数据库、大数据服务、云安全等也全部使用阿里云产品，最大化云的价值。基础服务之上是我们自研的能力中心，基于算法和视频增强能力，提供会员、自适应码率、搜索引擎、影评、放映厅等服务。通过 SLB 全球调度以及 WAF 安全接入对各种用户提供服务。上层承接多端，基本涵盖了市面上全部的终端类型：包括手机、Pad、网页以及各种客户端、车载设备等。

南瓜电影初始应用架构

但随着业务的不断发展，基于 ECS 的运维架构逐渐暴露了很多问题，主要有：

1）弹性扩容太慢：流量洪峰时，需临时购买新机器再逐台部署，非常耗时也保证不了系统 SLA。

2）发版慢&易出错：互联网频繁发布是常态，但每次几百台服务器一台台部署发版非常慢，一不小心就出错。也尝试过脚本化部署，跑顺确实省事，但当服务器组一多，脚本不断修改过程中，万一中间卡壳了，定位问题非常困难。

3）系统维护成本高：传统集群运维繁琐，人员技能要求非常高：既要精通 lua /ansible 脚本等，又要懂云产品网络配置和监控运维。早期公司并没有专职运维人员，耗费了开发大量的精力，非常之痛。

4）容量规划难，资源利用率低：对流媒体行业，高峰期一般在中午或晚上，其它时间访问都比较低，但很难精准备容。我们一般是按照峰值长期固定保有服务器，资源利用率相对比较低。

5）权限分配繁琐：面对企业多租户时，权限隔离往往是一个非常头疼的问题。尤其是新人到岗或者跨团队联调时，配置用户组、RAM 权限，新机器登陆连接方式，非常繁琐，账号管理人员也时常会成为瓶颈。

一场热映电影加速了南瓜电影技术升级思考

相信会有很多企业也面临和我们一样的难题，同时也制约着公司的发展。但开发人员都存在一定的惰性，认为只要不出事就先继续耗着。而真正让我们下定决心做技术升级的，还得感谢 19 年的那场热映电影。

那天早上接到同学的电话说业务压力大，我说：“不可能，一般早上流量比较少”，他说：“不知道，各种业务都开始预警，我已经开启了预案，不断的买买买机器了”。后来才知道 1 个小时内新增注册用户突破 80W+（是平时峰值的 5 倍以上），对南瓜电影来说是一个巨大的挑战和机遇。很快服务器直接崩了，流量总入口 API 网关撑不住，紧接着后端服务、数据库都异常。

大家紧绷着神经，开始了全链路紧急扩容：从买 ECS，上传脚本到新机器，运行脚本，扩容 DB…...整个过程断断续续对用户产生影响，有些用户直接访问不了，持续了 4 个小时才最终完全恢复。

因平台都是付费客户，那天我们的客服电话从早上忙到晚上，不断有用户来投诉，说早上不能使用，要求赔偿。

所以，像这种突然袭击对团队来说是比较锻炼团队的事，而对公司来说是损失比较大的事。我们对那天所有打开 APP 的用户都进行了赔偿：当天使用全部免费，这也是业务层面的损失。不过最终因为这场电影，南瓜电影的日新增注册用户一路高涨，业务增速明显。但回顾整个运维过程，耗时 4 个小时，太惊险刺激了，我们不想再经历第二次了。

选型

针对以上的问题，我们在想下一步应该怎么改造，当时内部有两个方案，但都存在一些弊端：

方案一：脚本深度优化，虽然能解决一些重复运维问题，但维护成本太高了，真正能把脚本写好的运维人员太难招了。我们也一直在用脚本，但确实没办法完全自动化，紧急扩容时还得人工购买 ECS。

方案二：自建 K8s，虽然能很好解决高密部署的问题，极大降低成本，也能自动扩容应用实例，但爆炸半径比 ECS 大，我们还是有点担心。最重要的是 K8s 学习成本实在是太高了，搭个环境跑跑容易，但正儿八经上生产的话还是要组建好专业团队，短期内显然无法完成。

后来，经过阿里云同事介绍，很快又有了方案三 —— 使用 SAE，也是最终落地的方案。

方案三：选择阿里云 Serverless 应用引擎（简称 SAE），对 SAE 的第一印象就是简单上手，省时省力，不用做任何改造，WAR/JAR 包直接上传部署，也不用买机器运维机器，节省开发大量时间。并且，SAE 就是一个超大规模的弹性资源池，想弹多少弹多少，想什么时候弹就什么时候弹，非常适合南瓜电影的业务场景。

SAE 初印象

实战

ROUND 1：CI/CD Pipeline – 加速迭代效率

在正式迁移业务之前，我们做的第一件事是基于 Travis CI + SAE 把 CI/CD 的流水线打通，提升发版效率。之前，当我们在 GitHub 上提交代码时，Travis CI 工具会自动集成，自动进行单元测试，测试通过后，会把文件上传到私有化 OSS 上，然后部署到 ECS 上。使用 SAE 后，只需要把 deploy 到 ECS 改成 deploy 到 SAE，非常简单，对开发侧没有任何影响。并且在应用部署的时候还能选择配置单批、分批、金丝雀等多种发布策略，异常时立刻中止和回滚，十分高效。

ROUND 2：上线第一个应用 API 网关

接下来就是挑选第一个应用实战了。当时我们做了一个大胆的决定：首先迁移 API 网关。API 网关是我们内部最核心的应用也是压力最大的应用，为什么这么选择呢？

首先，它有全国各地的部署。第二，它本身就有大量的 ECS 集群，我们只要操作调度系统把部分流量打到 SAE，假设 SAE 出现不稳定，也可以瞬间把流量切回到 ECS，对用户几乎没有影响。第三，API 网关作为总流量入口，突发流量较多，比较匹配 SAE 的弹性优势，可以最大程度的测试出 SAE 是否适合我们的业务。

起初上生产环境，我们自己也很担心，为防止意外发生，我们决定让原有的 ECS 实例和 SAE 上的实例一起跑，如果一方发生问题立马切换流量，跑稳之后再将 ECS 实例作为灾备链路。

ROUND 3：API 网关自动扩缩，应对突增流量

光在常态流量下能稳定运行还不能证明 SAE 是靠谱的。于是我们先后在测试、生产环境重点验证了流量突增时，SAE 的弹性能力。

我们用上一次热映电影的 5 倍的流量规模进行系统性的压测，将压测出来的 CPU、memory、QPS、RT 的阈值设置在 SAE 弹性规则里面，然后再实时观察 SAE 控制台上应用监控各项指标，发现都正常。SAE 真的能在峰值时秒级自动扩容，峰谷时按需自动缩容，就像下面这张图呈现的，使用 SAE 之后比以往 ECS 长期保有方式节省了 40% 左右的硬件成本。

就这样，我们的第一个应用 API 网关迁移成功，老的 ECS 实例也全面下线。阿里云 SAE 用稳定高效的表现向我们证明之前的担心是多余的。于是我们陆续对其它业务线进行迁移。

ROUND 4：开箱即用全链路监控&诊断能力

在迁移过程中，偶尔也会碰到一些应用状态异常的问题。SAE 内置的 ARMS 监控系统对于我们线上问题的分析、排查和解决，提供非常棒的支持，节省了大量的排查时间。在 SAE 上能看到应用的调用关系拓扑图、可以定位到慢 SQL、慢服务、方法的调用堆栈、进而定位到代码级别的问题。

不仅如此，SAE 还接受了我们合理化建议，提供了各种维度的 TopN 应用报表：能做到 1 个人轻松运维成百上千个应用，当下哪些应用问题最大，最应该关注都一目了然，胸有成竹。

ROUND 5：【企业级特性】权限隔离&审批

SAE 还帮我们解决了一个老大难的问题：权限隔离和审批。

大家看下这张对比图：以往 ECS 模式下，跨团队要互访应用时，需要配置用户组、以机器粒度给不同的人添加 RAM 权限。如果涉及到运维部署，还得修改脚本配置，在跳板机上配置好新机器的用户名、密码、操作日志。一旦人多机器多的时候，权限配置就会变得非常繁琐。而且运维操作没有审批，风险不可控，开发都有机器的用户名和密码，发布比较随意。

使用 SAE 后，一切都变得简单了。以应用粒度添加权限，一个应用只要添加一次即可，省心省力。SAE 还通过主子账号设计了运维审批流程：子账号发起某个资源的运维操作后，需得到主账号审批通过才能继续执行，否则 SAE 将中止任务，有效收敛了线上随意发布带来的质量风险。

ROUND 6：落地完成

通过和 SAE 平台不断的磨合验证，在第 7 天的时候，我们所有应用已经全面 Severless 化，ALL ON SAE 了。整个迁移过程平滑，无任何改造成本，零故障，并且只投入了 1～2 个研发人员。

我们整体分析了一下，SAE 给南瓜电影带来的价值，可以归纳成几点：

1）扩容更快：再也不用考虑高峰期不够、低谷期浪费了，SAE 会按照最优化自动伸缩调整实例数。

2）发布更快：通过 CI/CD 流水线提升发版效率、通过 Cloudtoolkit 插件快速实现本地一键部署到云端 SAE，开发调试很方便。

3）运维更省心：免运维不是不运维，对我们来说当你收到告警，登上控制台，开始修复的一刹那，基本上就已经完成了，整个运维速度比人工更加快捷

4）查问题更快：SAE 自带的监控能力，给我们排查问题节省了大量的时间。

经过测算，相比我们之前传统服务器模式，开发效率提升 70%，成本下降超过 40%，扩容效率提升了 10 倍以上。

总结&期待

最后，我们把使用过程中的一些总结、踩过的坑分享给大家。

1）多可用区部署：之前我们所有应用都只配置单可用区 A 就吃过亏，后来在 SAE 团队的建议下，全部切成多可用区部署容灾，所以严重推荐这个注意点。

2）分批/灰度发布策略：多实例的应用一定要分批或者灰度发布，以避免异常情况对整体业务的影响，并且整个发布一定要做完整的测试。

3）健康检查：应用自定义的健康检查脚本一定要前置 check，避免因脚本自身的问题导致应用一直启动失败。

4）扩容阈值的合理设置：扩容的阈值一定要多测试，做过系统压测之后再定。必要的时候适当调小点阈值，宁愿多扩实例也不要出现线上故障。

5）配置 SLS 日志和 ARMS 报警：建议一定配置 SLS 本身日志和 ARMS 报警，为事后问题定位提供非常大的帮助。

我们同时也对 SAE 充满了期待：比如希望优化 Java 冷启动时长，我们有些应用光启动就要 1-2 分钟（后来了解 SAE 已经实现了）。也希望 SAE 更进一层，提供一套完整 Serverless 架构给到用户：不只是应用层，还包括数据库，网络等，彻底让我们只关注业务开发。虽然这个实现起来可能会比较难，需要点时间，但我们对 SAE 很有信心。