一、世紀聯華超市簡介

1. 公司簡介

杭州聯華華商集團有限公司成立于 2002 年 7 月，主要業務涵蓋購物中心、大賣場、超市、便利店等零售業態，G20 杭州峰會食材總倉建設、保障單位，是浙江省商貿龍頭企業。集團 200 多家門店中，主要涉及 POS 機交易、聯華超市、CITY LIFE、天華世紀城等，除此之外還有線上精選 APP，提供線上購買、送貨到家服務，還會不定時推出優惠券領取、限時秒殺等活動。

2. 世紀聯華技術架構演進方案

2002 年，公司成立后一直使用物理單機架構。
2014 年，因為雙十二事件，導致公司不得不做出改變，將業務遷移到中央機房。
2018 年，隨著國內公共云的發展，開始部署全面上云。
2019 年 6 月，公共云上出現數據庫壓力過大，世紀聯華由此開始探索新架構方式。
到 2019 年 11 月，僅用大概 4 個月時間，世紀聯華就把一部分業務搬到了阿里云的 Serverless 上，包括 API 網關、函數計算、表格存儲，在雙11 期間，這三款產品的應用表現非常優異，使得世紀聯華決定 All in Serverless。
截至 2020 年 11 月，All in Serverless 使得整個公司的開發效率得到極大提高，成本大幅節省。

二、技術架構演進

1. 物理單機架構

2014 年及以前物理單機架構下，一個超市通常只有 2~20 臺 POS 機，最多 20 個客戶端，架構非常簡潔，只要在一臺物理機上部署好本地數據庫，交易系統、會員系統、商品管理全都放在一個進程上就足夠。如果要做相關操作，比如調取某個交易、給用戶注冊相關信息、調整商品價格，只要通過 Admin 客戶端連接進程再做相應改動即可。通常來說，一個大型超市只要買一臺性能足夠強的機器，就可以服務好幾十個 POS 機發起的請求。單機架構優劣勢比較：

1）優勢

架構簡潔；
不受外界網絡環境的影響；
POS 機分散后單機沖擊相對小。

2）劣勢

數據遷移查詢匯總困難

2014 年問題逐漸暴露，比如在杭州的總部，想查詢湖州某個門店的實時交易量，基本不可能，跨網絡查詢和數據量大是難以解決的問題。

數據分發靠定期同步

比如客戶在 a 門店注冊的會員卡，很難去 b 門店消費，只能靠定期同步，把 a 門店的數據定期拷貝到 b 門店去，這其中存在很多問題，對消費者來說也非常麻煩。

故障時很難第一時間維護修復

我們不可能每個門店都派一名專業的維護人員，如果機器出了故障，只能打電話給總部的工程師，這種情況就很難做到第一時間趕到現場修復，這是很嚴重的問題。

單點故障容災困難

因為所有的業務都包含在一個進程里面，如果進程出現異常，也沒辦法把業務交給另一個進程處理。

升級困難

我們在浙江省有上百家門店，每一次升級都需要專業的運維人員把新代碼包部署到不同的機器上。

新業務部署在單機上沖擊巨大

舉個案例，2014 年雙十二，支付寶推出了使用支付寶錢包付款可以打 5 折的線下優惠活動，當時全國線下近百個品牌、2 萬多家門店都參與其中，世紀聯華也有參與，但是當天卻出現了大量消費者無法結賬在超市排起長隊的情況。

因為我們剛剛引入一個新的支付方式，所有的業務都在單個進程上，耦合度過高，當時大家集中結賬訪問量過大，導致支付出現問題，整個單機訪問無法進行下去，其他的業務模塊也因此受到影響，最后只能重啟機器。因為這個問題，世紀聯華開始嘗試做出新的改變。

2. 中央機房部署架構

單機最大問題是如果門店出現問題，相關工程師無法第一時間趕到現場，尤其是多個機器、多個門店同時出現問題的情況，這時最好的辦法是把所有機器集中在一起，做集中的數據修復、運維管理和軟件升級。 2014 年到 2018 年期間，世紀聯華逐漸把單機架構整個遷移到了中央機房。中央機房是自建的，做法就是把數據庫、交易系統、會員系統、商品管理全部拆分到多個進程當中。這樣一來，如果會員系統掛掉了還可以暫時匿名購買；商品管理臨時出問題但只要交易系統沒問題就還可以頂上。耦合一旦降低，對于整個門店的業務保障來說，有了很大的提升。

在這里我們做了一個 node 節點，node 節點連接中央機房的數據庫以及各個系統模塊。如果出現問題，只需要在中央機房做相關修復即可。除此以外，如果需要調整商品價格，也只需在中央機房上直接設置，然后同步到所有門店的 node 節點上就可以了。中央機房部署架構的改進和不足：

1）改進

問題可集中維護處理；
商品價格調整下發全部走網絡；
數據可集中查詢統計匯總。

2）不足

管理員需要掌控機器細節；
宕機斷網事件調查困難應急方案薄弱；
硬件升級成本高；
需要提前采購大量硬件備災；
軟件、系統批量部署成本高；
資源預算困難。

3. 全面上云

2016 年以后，隨著國內公共云的迅速發展，全面上云勢不可擋。在此期間，阿里云在技術上取得了許多突破與提升，例如 ECS 的對外發布。世紀聯華在 2018~2019 年期間，把自建機房中的各個系統模塊逐漸遷移到了公有云，整體架構沒有太大改變，因此遷移工作相對順利。全面上云的改進和不足：

1）改進

主要有以下三個方面：

不再需要關心網絡、操作系統的硬件細節

比如阿里云的 ECS 會提前做調度和預警，把用戶數據轉移并做多份數據的備災，防止磁盤壞掉的情況發生。

硬件升級快捷簡單

比如用戶使用的是 4 核的機器，當發現業務增長迅速需要做硬件升級時，就只需要做一個鏡像。比如在夜間做一個磁盤快照，重新申請一臺新機器，然后把快照恢復上去，就可以完成一鍵遷移。對世紀聯華來說，這是非常快捷的方式，對開發者來說也是比較好的體驗。

機器擴容時間大幅縮短

上面提到的是單機擴容，比如 4 核升到 8 核、16G 升到 32G 的內存。除此之外還有橫向的擴容，例如用戶交易系統的 API 接口，隨著業務的發展需要由原來的 2 臺機器擴到 8 臺機器，這種情況下用戶只需去申請機器，然后將鏡像擴展到不同的機器上即可。

2）不足

主要有以下六個方面：

資源預算困難

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

水平擴展

水平擴展對研發有較高的要求。比如數據是否要做到無狀態，無狀態的話水平擴展會比較容易，而如果是有狀態，數據可能就需要做緩存，這就會涉及到數據庫相關的問題，例如數據過期、一致性等。如果對這些了解不夠透徹，做水平擴展就會比較困難。

水位監控

許多開發者在水位監控上處理得并不完善，如果將各個業務系統混在一臺機器上，當遇到機器水位較高，想要快速排查問題并及時進行流控、拆分、臨時修復等就顯得尤為困難。

財務預算困難

與資源預算困難類似。

硬件升級成本高

要做到用戶無感無損升級，可能會涉及到連接上的處理與數據庫一致性的問題。如果多個模塊需要同時升級，還要注意數據結構的兼容問題。

數據庫單點故障

許多廠家將數據全部放在一個數據庫中，如果處理不妥當可能會造成單點故障。這就要做數據拆分，粗拆的話，需要注意事務和鎖相關的問題，效率會大打折扣；細拆的話，做查詢和排序時就會比較困難，給業務實現造成一定麻煩。

4. Serverless 的探索和嘗試

1）線上不可控業務上的預防

2019 年年中大促時，由于線上業務用戶訪問不可控，數據量過大，MySQL 單機訪問被打爆，導致了存儲數據庫出現問題，影響到了多個系統，造成了一定的損失。

此事件之后，世紀聯華就想直接把 MySQL 替換掉，這時我們發現阿里云有一款產品叫“表格存儲”，表格存儲最大的優點是用戶不需要關心訪問量和機器數的比例關系。只要訪問量擴大，后臺會自動擴容增擴機器，滿足高并發的數據讀取；在數據并發請求降低處于低峰期時，后臺就會將機器回收，用戶不再需要關心機器的數量及如何調動。

針對用戶流量不可控問題，世紀聯華引入了阿里云的產品“API 網關”，API 網關可以針對不同渠道商做管控發布及流量控制。比如發現微信渠道流量有異常，就可以借助 API 網關進行限流。另外計算也是一個非常重要的問題，世紀聯華經過探索發現阿里云的“函數計算”非常契合我們的業務場景。比如定時搶購、優惠券投放等活動造成巨大的 burst 沖擊，當發現計算資源不夠的時候再去買機器肯定是來不及的，而函數計算及時擴容的功能就很好地解決了這個問題。另外其數據觀測和異常報警功能，也吸引到了世紀聯華。世紀聯華將這三個產品相結合，替換掉了原來的會員查詢功能，最終得以成功渡過 2019 年的雙11 大促難關。