作者：莊徐麟
審核校對：營火
編輯&排版：雯燕

從我們了解 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）添加云原生小助手！獲取更多相關資訊！

總結

以上是生活随笔為你收集整理的南瓜电影 7 天内全面 Serverless 化实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。