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

從我們瞭解 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）新增雲原生小助手！獲取更多相關資訊！