作者 | 庄徐麟

从咱们理解 SAE 产品到整体上线一共是 7 天工夫。3 天实现外围利用 API 网关上线，第 5 天验证完结 100% 流量打到 SAE 上，第 6-7 天把其余 30 多个零碎疾速迁徙到 SAE，整个过程十分顺利。应用 SAE 后，运维效率晋升 70%，老本降落超过 40%，扩容效率晋升 10 倍以上，这是给咱们带来的直观扭转。_

南瓜电影成立于 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 很有信念。

​

最初，衷心感谢阿里云 SAE 在南瓜电影倒退历程中的携手与反对，应用 SAE 当前，大面积的故障到当初为止还没有产生过一次。整个过程中，咱们也播种了很多教训，让咱们能够疾速通过它对用户提供服务。

南瓜电影也会判若两人地为宽广影迷敌人们带来最优质的影片资源和最极致的观影体验，为社会发明更多的正能量。也祝福阿里云敢幻想敢翻新再创佳绩，服务寰球更多的企业！