世紀聯華的 Serverless 之路

做者 | 朱鵬（旻蒼） 來源 | Serverless 公衆號

1、世紀聯華超市簡介

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 使得整個公司的開發效率獲得極大提升，成本大幅節省。

2、技術架構演進

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 大促難關。

2）Serverless 帶來的新曙光

• 快速迭代部署

Serverless 研發效率快、運維效率高、架構解耦。

• 高併發、高彈性

Serverless 不須要人工擴容和運維管控。

• 穩定、可靠、安全

Serverless 使搶購活動和大促的總體體驗都很是流暢。

• 數據、運營、成本控制

Serverless 提供了完整的運維觀測和報警監控功能，運維工程師能夠輕鬆不少；另外按使用資源計費，資源利用率可達 100%。

5. 函數計算 2.0 及 All in Serverless

• 曲線圖 1：相似 ECS 方案，曲線顯示有資源不足和資源浪費的狀況。

• 曲線圖 2：機器擴容，有延遲和偏差，須要提早操做，它的實時性和伸縮性都比較差。

• 曲線圖 3：函數計算 2.0 預留模式，有預留資源和彈性資源，能夠實時擴容。

• 資源管理層面：人工運維 → 雲平臺工具運維 → Serverless 免運維，實現徹底自動化。

• 資源利用率：預算採購低利用率 → 有限彈性高利用率 → Serverless 100% 資源利用率。

• 資源成本：固定成本支出 → 根據資源策略伸縮 → Serverless 根據業務策略適配。

2019 年 雙11 事後，世紀聯華快速上雲，將線上核心業務改造爲全 Serverless 架構的中臺模式，採用「函數計算+API 網關+OTS」做爲計算網絡存儲核心，彈性支撐平常和大促峯谷所需資源，輕鬆支撐 618 / 雙11 / 雙12 大促。

圖：2020 年 雙11 大促

2020 年 雙11 大促，世紀聯華線上業務實現 All in Serverless，上爲流量&時間的曲線圖，下爲調用延遲&時間的曲線圖。

圖：Serverless 助力世紀聯華降本提效

3、設計架構演進總結

從物理單機到 All in Serverless 的架構演進：

• 物理單機

  • 架構簡單
  • 高度耦合
  • 數據同步難
  • 升級困難
  • 沒法橫向擴容

• 自建機房

  • 統一維護升級
  • 數據同步統一
  • 系統部署困難
  • 硬件成本高
  • 非業務調查難
  • 臨時擴容

• 全面上雲

  • 硬件升級簡單
  • 擴容能力提高
  • 備災能力提高
  • 設計要求高
  • 監測告警原始
  • 數據庫單點
  • 流控問題

• Serverless 嘗試

  • 數據庫單點問題
  • 流控問題解決
  • 橫向擴容
  • 監控告警
  • 費用免預算
  • 部分延遲較大

• All in Serverless

  • 解耦
  • 冷啓動體驗提高
  • 研發效率提高
  • 成本費用降低

4、函數計算簡介

1. 阿里雲函數計算產品全景

函數計算是國內生態最完整、功能最豐富的 Serverless 產品，開發者一步上雲、一鍵 Serverless 化將成爲現實。

2. 業界發展趨勢

誰在使用函數計算？

做者簡介： 朱鵬，花名：旻蒼，函數計算一線技術專家，專一函數計算資源調度設計研發。

本文整理自【Serverless Live 系列直播】1 月 28 日場 直播回看連接：https://developer.aliyun.com/topic/serverless/practices

Serverless 電子書下載

本書亮點：

• 從架構演進開始，介紹 Serverless 架構及技術選型構建 Serverless 思惟；
• 瞭解業界流行的 Serverless 架構運行原理；
• 掌握 10 大 Serverless 真實落地案例，活學活用。

下載連接：https://developer.aliyun.com/topic/download?id=1128