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

Posted 2021-11-11 阿里系统软件技术

本文将讲述南瓜电影对 SAE 的选择路程，以及 SAE 为南瓜电影带来的变化。

作者：庄徐麟
审核校对：营火
编辑&排版：雯燕

从我们了解 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 很有信心。

最后，衷心感谢阿里云 SAE 在南瓜电影发展历程中的携手与支持，使用 SAE 以后，大面积的故障到现在为止还没有发生过一次。整个过程中，我们也收获了很多经验，让我们可以快速通过它对用户提供服务。

南瓜电影也会一如既往地为广大影迷朋友们带来最优质的影片资源和最极致的观影体验，为社会创造更多的正能量。也祝愿阿里云敢梦想敢创新再创佳绩，服务全球更多的企业！

点击这里，查看 SAE 相关详情！

了解更多相关信息，请扫描下方二维码或搜索微信号（AlibabaCloud888）添加云原生小助手！获取更多相关资讯！

阿里云 Serverless 助力企业全面拥抱云原生

相信随着云计算的发展，Serverless 将成为云时代默认的计算范式，越来越多的企业客户将会采用这个技术。

作者：洛浩

Serverless 应用引擎的组件架构

最早的时候，大家设计软件一般按照单体架构，包括和软件相关的数据库，存储等，会直接部署到一台物理服务器上。但是单体应用的问题在于，随着企业的规模逐步增大，扩展性较差，发布效率非常低。后来，就进入了微服务时代，微服务主要用的框架是基于 Java 语言。微服务架构的一个优势在于迭代效率非常高，扩展性也比较好，但是微服务对资源的占用和成本相对较高。随着技术的演进，容器化加速了微服务的落地。但并不是所有的企业都适合微服务，随着系统复杂性的提升，微服务的效率，运维成本也在增加。企业选用单体架构，还是微服务取决于系统的复杂程度。

随着公有云的发展，越来越多的用户会把业务部署到云上。随着云的使用深度越高，架构的优势也就越明显。第一阶段叫 Rehost，就是重新托管，使用云主机替换本地物理服务器，不改应用，但是这种托管模式是最基础使用云的方式，它的效率并没有达到最大化。随着进一步的发展，我们需要 Re-platform，使用托管的云服务替换自建应用基础设施，基本不改应用。但 Re-platform 也不是最好的一种方式，随着进一步的发展，我们可以重新去架构这个应用，即 Refactor。这个时候，可以用微服务加容器的方式，重构底层架构和软件架构，把云的价值发挥到最大。从长期来看，整体的收益是最大的，但是短期内它的迁移成本要求也是比较高的。

如果应用能够按照云上原生的产品或服务进行重构开发，就能够最深的享受云计算的便利性。但与此同时它有几个问题：

• 投入成本（迁移/改造）；
• 云厂商绑定程度；
• 云的易用性（上手门槛/维护）；
• 安全性。

阿里云推出了 Serverless 应用引擎（SAE），专门针对应用或者微服务，提供一个全托管的平台。比如 Java 微服务，目前可以做到零改造迁移部署到云上，并且支持完整的微服务治理能力。如果用户想做容器化升级，也可以使用这个平台。

Serverless 应用引擎的核心技术

SAE 由哪些组件构成？是怎样把各种产品能力结合到一起的？可以看下这个组件架构。图中绿色部分，是用户需要关注的，是各种各样的业务应用。同时，SAE 会提供各种工具，比如 Cloudtoolkit 插件辅助本地代码部署到云端，比如对接云效提供流水线能力。图中橘黄色部分，就是 SAE 平台，会提供很多种能力。比如说写了一个商城应用，前台就是一个独立的服务模块，可以单独迭代、开发或者管理。还可以给前台服务配置弹性策略，例如在大促期间，前台服务可以根据实际流量自动弹性伸缩，这个也是 SAE 的一个核心价值。所以 SAE，既可以提供资源管理能力，又能提供应用生命周期管理、微服务治理，是一个全托管式的应用平台。在资源层面，SAE 封装了K8s 集群，K8s 之下是基础设施，由神龙服务器和安全容器构建，SAE 在资源层面，会帮助用户提供资源管理和调度能力。

接下来讲一下 SAE 的核心能力。首先，我们先看一下传统企业用户部署应用的整个流程，首先是需要购买 ECS 资源，然后搭一个集群，对集群进行初始化，然后构建环境。研发开发完成后，开始进行测试部署，另外还要去部署监控、日志等组件。等业务全部上线后，就进入维护状态，包括资源的运维和业务的运维。而使用 SAE 可以省掉很多步骤，首先底层的 K8s 集群由云厂商来维护，用户只用提交镜像或者 JAR 包，就可以把系统部署到 SAE 平台。其次，监控和日志系统，这些已经由平台提供，用户只需要关注业务逻辑，不需要去维护资源。

如果用户想要做灰度发布该怎么办？SAE 也给用户提供了单批、分批、金丝雀等发布策略。让部署到平台上的业务能够做到不停机更新，这个能力也是默认就提供的。

关于用户诉求非常强烈的金丝雀发布，SAE 可以以做到按请求内容灰度 ，和按流量比例灰度。比如要做流量比例灰度，分批发布直接 50%，两批即可发完。同时，也可以按照精准的流量比例进行灰度。

用户使用这个平台也会非常关注弹性能力，而 SAE 提供了非常丰富的弹性配置。可以基于基础监控指标（CPU、Mem）和业务监控指标（QPS 、RT）来触发水平伸缩 。按照这种负载模型去做弹性扩缩容，一般比较适用于突发流量、或者有典型脉冲的应用场景。比如互联网游戏，社交平台。第二种是定时弹性，这种模型比较适合像餐饮，出行这种有波峰波谷的应用场景。

那么弹性效率能不能跟得上弹性诉求呢？正常情况下，当我们把一个镜像部署到平台，系统要经过一个资源调度，然后创建 POD，拉用户镜像，创建容器，启动容器等几个步骤。为了提升这个效率，SAE 首先针对应用做了原地升级能力。就是针对应用升级发布，可以直接在原有资源上，直接拉用户最新的镜像进行更新和部署，避免重建 POD，从而帮用户提升了 42% 的部署效率。

其次，SAE 还做了镜像加速能力，能帮用户提升 30% 的弹性效率。也就是在用户在创建容器的时候，会同步按需去拉取用户镜像，可以降低服务启动时间。

第三，SAE 针对 Java  应用的启动也做了加速。提供的 Dragonwell JDK版本，可以在 JVM 和进程启动的时候，生成缓存，再应用二次启动的时候，进行加速，缩短启动时间。

最后，SAE 会给用户提供这种监控和应用诊断能力，可以查询服务的调用链、接口的响应耗时、GC 次数、慢 SQL 等，帮用户快速定位问题。

Serverless 应用引擎的最佳实践

微服务/应用迁移到 SAE，大概有几个步骤。首先如果是单体，可以直接打一个压缩包，部署到平台上来，但是单体应用需要做存算分离，也就是数据库和计算代码分离开，把计算部分部署到 SAE。微服务应用可以选择写一个 docker file，做成镜像，然后推到镜像仓库，即可完成部署。微服务应用也可以选择打成 JAR/WAR 包直接部署到 SAE。

关于降本方面，SAE 也推出了一键启停功能。针对不同的环境，可以开启定时起停应用。比如对于测试环境，在晚上没人用的时候，就可以把测试环境直接关掉，来节省成本。

SAE 提供多种工具和方法来构建 DevOps 体系。比如大部分企业用户常用的 Jenkins，或者选择云上的云效等来做 CI/CD。在应用侧，可以在 SAE 平台配置定时启停、监控告警等完成业务运维。

关于企业用户比较关注的环境管理和权限划分，SAE 推荐使用命名空间，来做环境的隔离，不同的命名空间下的应用是不能互访的。另外，SAE 推荐使用权限助手来给不同的团队，生成对应命名空尽或者应用服务的权限策略，最终做到不同团队之间的应用，相互不可见不可操作。

还有的用户会关注 SAE 和 ECS 比，做了哪些能力增强呢？首先是提供的这种免运维全托管能力，其次是一站式的全应用生命周期管理能力，以及针对微服务的治理和优化、应用监控等，都是 SAE 给用户提供的增值体验。

Serverless 应用引擎的客户案例

第一个 Timing app，是在教育领域的在线课程学习 app，它是典型单体应用重构成微服务，迁移到 SAE 平台。随着疫情的发展，Timing 的流量激增之后，原有架构难以承载业务的发展，开始做微服务改造。在微服务化的过程当中选了 SAE 平台，像用户中心，学习中心，自习中心、图书馆中心等等，都被拆成独立的服务模块。对比使用云主机自建微服务的方式，大约节省 35% 成本。

另外想要分享的案例是爱奇艺·体育，其整个业务都部署在 SAE 平台上。在今年 6、7 月份的时候，爱奇艺·体育转播了欧洲杯赛事，当时的流量非常高；但是体育赛事结束之后，流量又开始回落，因此弹性能力对其尤为重要。而 SAE 丰富的弹性能力，可以帮助节省大量的运维开销，扩容效率比之前提升了 40%。其次内置的应用监控平台，在业务遇到问题的时候，排障处理效率也提升了 30%。整体上 SAE 帮助爱奇艺·体育还提升了近 50% 的资源利用率。

相信随着云计算的发展，Serverless 将成为云时代默认的计算范式，越来越多的企业客户将会采用这个技术。

戳此处，前往查看视频解析~