某零售商超行業的龍頭企業，其主要業務涵蓋購物中心、大賣場、綜合超市、標準超市、精品超市、便利店及無人值守智

慧商店等零售業態，涉及全渠道零售、倉儲物流、餐飲、消費服務、資料服務、金融業務、跨境貿易等領域。為了持續支

持業務高速且穩定地發展，其在快速上雲後，將核心業務改造為全 Serverless 架構的中臺模式，採用函式計算 + API 網

關 + 表格儲存 OTS 作為計算網路儲存核心，彈性支撐日常和大促峰谷所需資源，輕鬆支撐 618/ 雙 11/ 雙 12 大促。

傳統企業為什麼更需要關注 Serverless

為了降低技術研發成本、提升運維效率，越來越多的企業選擇使用 Serverless 作為基礎研發底座，大力發展業務。在 CNCF 

Serverless 研究報告中顯示，大量的國內開發人員正在將傳統架構往 Serverless 上做遷移。**Serverless 的出現給傳統企業

數字化轉型帶了更多機遇。

現如今，大量尖端技術人才更偏向在網際網路公司就業，傳統企業又面對著大量技術升級和重構技術架構的剛需，人才缺口和

技術升級之間產生了對雲原生技術的需求。Serverless 的出現抹平了研發人員在預算、運維經驗上的不足。在幫助企業對抗

業務洪峰的情況下，研發人員能輕易掌控處理，不僅極大地降低了研發技術門檻，而且大規模提升了研發效率。對於開發者

而言，線上預警、流量觀測等工具一應俱全，關鍵是免去了運維負擔，切實為廣大開發者提供了普惠技術紅利。對傳統企業

而言，Serverless 縮短了網際網路公司與傳統企業之間技術競爭力的距離。

從上雲到雲原生

2016 年以後，隨著國內公共雲的迅速發展，全面上雲勢不可擋。某知名大型商場在 2018~2019 年期間，把自建機房中的

各個系統模組逐漸遷移到了公有云，整體架構沒有太大改變，因此遷移工作比較順利。

系統全面遷移上雲後一些改進和不足

不再需要關心網路、作業系統的硬體細節

比如阿里雲的 ECS 會提前做排程和預警，把使用者資料轉移並做多份資料的備災，防止磁碟壞掉的情況發生。

升級快捷簡單

比如使用者使用的是 4 核的機器，當發現業務增長迅速需要做硬體升級時，就只需要做一個映象。比如在夜間做一個磁碟快照

重新申請一臺新機器，然後把快照恢復上去，就可以完成一鍵遷移。對使用者來說這是非常快捷的方式，對開發者來說也是較

好的體驗。

機器擴容時間大幅縮短

上面提到的是單機擴容，比如 4 核升到 8 核、16G 升到 32G 的記憶體。除此之外還有橫向的擴容，例如使用者交易系統的 API

介面，隨著業務的發展需要由原來的 2 臺機器擴到 8 臺機器，這種情況下使用者只需去申請機器，然後將映象擴充套件到不同的機

器上即可。

資源預算困難

無法預估業務遇到大促活動時所能達到的體量，因此無法準確計算出所需硬體的數量。

水平擴充套件

水平擴充套件對研發有較高的要求。比如資料是否要做到無狀態，無狀態的話水平擴充套件會比較容易，而如果是有狀態，資料可能

就需要做快取，這就會涉及到資料庫相關的問題，例如資料過期、一致性等。如果對這些瞭解不夠透徹，做水平擴充套件就會比

較困難。

水位監控

許多開發者在水位監控上處理得並不完善，如果將各個業務系統混在一臺機器上，當遇到機器水位較高，想要快速排查問題

並及時進行流控、拆分、臨時修復等就顯得尤為困難。

財務預算困難

與資源預算困難類似。

硬體升級成本高

要做到使用者無感無損升級，可能會涉及到連線上的處理與資料庫一致性的問題。如果多個模組需要同時升級，還要注意資料

結構的相容問題。

資料庫單點故障

許多廠家將資料全部放在一個資料庫中，如果處理不妥當可能會造成單點故障。這就要做資料拆分，粗拆的話，需要注意事

務和鎖相關的問題，效率會大打折扣；細拆的話，做查詢和排序時就會比較困難，給業務實現造成一定麻煩。

業務挑戰

在一次年中大促時，由於線上業務使用者訪問不可控，資料量過大，MySQL 單機訪問被打爆，導致了儲存資料庫出現問題，

影響到了多個系統，造成了一定的損失。因此在後續服務化改造過程中，資料庫選型由 MySQL 更改為表格儲存 OTS，表格

儲存最大的優點是使用者不需要關心訪問量和機器數的比例關係。只要訪問量擴大，後臺會自動擴容增擴機器，滿足高併發的

資料讀取；在資料併發請求降低處於低峰期時，後臺就會將機器回收，使用者不再需要關心機器的數量及如何調動。

Serverless 改造

針對使用者流量不可控問題，客戶引入了阿里雲的產品 “API 閘道器” ，API 閘道器可以針對不同渠道商做管控釋出及流量控制。

比如發現微信渠道流量有異常，就可以藉助 API 閘道器進行限流。

另外計算也是一個非常重要的問題，客戶經過探索發現阿里雲函式計算 FC 非常契合其業務場景。比如定時搶購、優惠券投放

等活動造成巨大的 burst 衝擊，當發現計算資源不夠的時候再去買機器肯定是來不及的，而函式計算及時擴容的功能就很好地

解決了這個問題。另外其資料觀測和異常報警功能，也吸引到了客戶。

今年 3 月，權威諮詢機構 Forrester 釋出 2021 年第一季度 FaaS 平臺評估報告，阿里雲函式計算憑藉在產品能力、安全性、

戰略願景和市場規模等方面的優勢脫穎而出，產品能力位列全球第一，這也是首次有中國雲廠商進入 FaaS 領導者象限。

在緊張的測試驗證後，技術人員發現函式計算的優異表現很契合自身業務高度彈性的會員查詢系統。從 2019 年 7 月開始，

客戶的技術團隊在不到 3 個月的時間裡，將原有的會員資料全部副本映象遷移到表格儲存，並將所有渠道商的 API 全面遷移

到阿里雲 API 閘道器做分發，會員查詢業務的計算業務也全面遷移到阿里雲函式計算。

2019 年的雙 11，函式計算作為計算模組，表格儲存作為儲存模組，順利地幫助客戶渡過大促，扛住高峰流量的同時確保了應

對業務的彈性。而未使用 Serverless 的業務因為預估不足，出現了一些異常。正是因為函式計算在雙 11 中的表現讓客戶技術

人很振奮。在順利度過大促活動後，客戶就在所有業務中全面使用函式計算及表格儲存！

新零售商超整體架構圖

- 全 Serverless 架構：函式計算 + API 閘道器 + 表格儲存；

- 彈性高可用：毫秒級彈性擴容、充足的資源池水位、跨可用區高可用；

- 敏捷開發免運維：函式式極簡程式設計可專注於業務創新，無採購和部署成本、提供監控報警等完備的可觀測能力。

2019 年下半年，阿里雲函式計算宣佈推出 2.0，支援預留模式，全面解決冷啟動延遲大的問題；推出單例項多請求問題，

較少例項支援重 IO 高併發型別請求呼叫；支援自定義執行時，支援一鍵遷移傳統 Web 架構伺服器。2.0 的出現讓函式計算

在業務和規模上實現了巨大升級。

在經歷了過去的線下場景考驗後，客戶將各渠道商的業務及旗下的移動 App，以及線上交易、定時搶優惠券、秒殺業務也全

部從 ECS 遷移到了函式計算 2.0，在開啟預留模式調整好單例項多併發的模式後，順利地扛過了是平時數十倍的洪峰流量請

求。

比較上述的“時間-流量圖”及“時間-延遲”兩圖可以看到，急劇上升的突發流量對使用者造成的延遲變化影響非常小，從實

際使用者反饋來看確實也證實了使用者體驗非常順滑。

所有的資料和業務上雲，減輕的不只是研發人員的心理壓力，更為研發人員大量減負，從而讓大家可以做更聚焦在業務邏輯

上的事情。函式計算可以讓研發人員不用管理伺服器這些基礎設施，只要編寫程式碼上傳，系統就會準備好計算資源，還提供

日誌查詢、效能監控、報警等功能。如果是按照以前的模式，超市搞 雙 11 大促，相關的技術團隊都睡不著覺，只靠擴充套件機

器支撐大體量的流量和業務，誰心裡都沒譜。現在擴容的問題交給阿里雲，水位遠遠高於客戶原有的儲備能力的極限。

今年，Serverless 迎來重大升級。函式計算重磅釋出容器映象加速技術，容器啟動延時縮短 50%-80%，將原本屬於開發者

的映象最佳化負擔轉由函式計算承擔，進一步幫助開發者提高生產效率，專注業務創新。該技術源於阿里集團超大規模和場景

高度複雜的容器環境，對映象儲存、加速技術有深厚的積累，並出色地承擔了 3 年雙十一、雙十二、春節等大促秒殺場景的

嚴苛的挑戰。

同時，Serverless 應用引擎(SAE)重磅釋出 Java 應用啟動加速功能，首度將 Alibaba Dragonwell (阿里雲開源的 Open JDK 

長期支援版本) 的冷啟動加速技術、多執行緒執行加速技術和 SAE 自身的原地升級策略、映象預熱策略相結合，實現了 Java 應

用的端到端啟動速度提升 45%，最快僅需 15s，多執行緒效能提升 30%。

由於業務場景、使用者習慣迅速變化，許多行業數字化業務出現急速增長，加快數字化業務發展成為傳統企業的必然選擇。

雲原生是企業數字化最短路徑，越來越多的傳統企業正在擁抱雲原生，藉助更加快速、靈活的開發和交付模式，滿足市場快

速變化的需求，進而加速業務創新。傳統零售企業藉助 Serverless 保證了一次次大促的成功，正是這一趨勢的最好證明。