當新零售遇上Serverless
某零售商超行業龍頭企業，主要業務涵蓋購物中心、大賣場、綜合超市、標準超市、精品超市、便利店、無人值守智慧商店等零售業態，涉及全渠道零售、倉儲物流、餐飲、消費服務、數據服務、金融業務、跨境貿易等領域。為了持續支持業務高速且穩定地發展，其在快速上雲後，將核心業務改造為全Serverless架構的中臺模式，採用函數計算 + API網關 + 表格存儲OTS作為計算網絡存儲核心，彈性支撐日常和大促峰谷所需資源，輕鬆支撐618/雙11/雙12大促。
傳統企業為什麼更需要關注 Serverless?
為了降低技術研發成本、提升運維效率，越來越多的企業開始選擇使用 Serverless 作為基礎研發底座，大力發展業務。在 CNCF Serverless 研究報告中顯示，大量的國內開發人員正在將傳統架構往 Serverless 上做遷移。Serverless 的出現給傳統企業數字化轉型帶了更多機遇。
傳統企業為什麼更要關注 Serverless 呢？現如今，大量尖端技術人才更偏向在互聯網公司就業，但傳統企業又面對著大量技術升級和重構技術架構的剛需，人才缺口和技術升級之間產生了對雲原生技術的需求。Serverless 的出現抹平了研發人員在預算、運維經驗上的不足。在幫助企業對抗業務洪峰的情況下，研發人員能輕易掌控處理，不僅極大地降低了研發技術門檻，而且大規模提升了研發效率。對於開發者而言，線上預警、流量觀測等工具一應俱全，關鍵是免去了運維負擔，切實為廣大開發者提供了普惠技術紅利。對傳統企業而言，Serverless 縮短了互聯網公司與傳統企業之間技術競爭力的距離。
從上雲到雲原生
2016 年以後，隨著國內公共雲的迅速發展，全面上雲勢不可擋。某知名大型商場在 2018~2019 年期間，把自建機房中的各個系統模塊逐漸遷移到了公有云，整體架構沒有太大改變，因此遷移工作比較順利。
系統全面遷移上雲後一些改進和不足：
（1）改進
- 不再需要關心網絡、操作系統的硬件細節
比如阿里雲的 ECS 會提前做調度和預警，把用戶數據轉移並做多份數據的備災，防止磁盤壞掉的情況發生。
- 升級快捷簡單
比如用戶使用的是 4 核的機器，當發現業務增長迅速需要做硬件升級時，就只需要做一個鏡像。比如在夜間做一個磁盤快照，重新申請一臺新機器，然後把快照恢復上去，就可以完成一鍵遷移。對用戶來說，這是非常快捷的方式，對開發者來說也是比較好的體驗。
- 機器擴容時間大幅縮短
上面提到的是單機擴容，比如 4 核升到 8 核、16G 升到 32G 的內存。除此之外還有橫向的擴容，例如用戶交易系統的 API 接口，隨著業務的發展需要由原來的 2 臺機器擴到 8 臺機器，這種情況下用戶只需去申請機器，然後將鏡像擴展到不同的機器上即可。
（2）不足
- 資源預算困難
由於無法預估業務遇到大促等活動時所能達到的體量，因此無法準確計算出所需硬件的數量。
- 水平擴展
水平擴展對研發有較高的要求。比如數據是否要做到無狀態，無狀態的話水平擴展會比較容易，而如果是有狀態，數據可能就需要做緩存，這就會涉及到數據庫相關的問題，例如數據過期、一致性等。如果對這些瞭解不夠透徹，做水平擴展就會比較困難。
- 水位監控
許多開發者在水位監控上處理得並不完善，如果將各個業務系統混在一臺機器上，當遇到機器水位較高，想要快速排查問題並及時進行流控、拆分、臨時修復等就顯得尤為困難。
- 財務預算困難
與資源預算困難類似。
- 硬件升級成本高
要做到用戶無感無損升級，可能會涉及到連接上的處理與數據庫一致性的問題。如果多個模塊需要同時升級，還要注意數據結構的兼容問題。
- 數據庫單點故障
許多廠家將數據全部放在一個數據庫中，如果處理不妥當可能會造成單點故障。這就要做數據拆分，粗拆的話，需要注意事務和鎖相關的問題，效率會大打折扣；細拆的話，做查詢和排序時就會比較困難，給業務實現造成一定麻煩。
業務挑戰
在一次年中大促時，由於線上業務用戶訪問不可控，數據量過大，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 保證了一次次大促的成功，正是這一趨勢的最好證明。
新零售 Serverless 最佳實踐鏈接： https://bp.aliyun.com/detail/212