簡介：Serverless 的出現給傳統企業數字化轉型帶了更多機遇。

某零售商超行業的龍頭企業，其主要業務涵蓋購物中心、大賣場、綜合超市、標準超市、精品超市、便利店及無人值守智慧商店等零售業態，涉及全渠道零售、倉儲物流、餐飲、消費服務、數據服務、金融業務、跨境貿易等領域。為了持續支持業務高速且穩定地發展，其在快速上云后，將核心業務改造為全 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 保證了一次次大促的成功，正是這一趨勢的最好證明。

原文鏈接：https://developer.aliyun.com/article/786344?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的当新零售遇上 Serverless的全部內容，希望文章能夠幫你解決所遇到的問題。

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