vivo?全球商城：億級訂單中心架構設計與實踐
[導讀]一、背景隨著用戶量級的快速增長，vivo官方商城v1.0的單體架構逐漸暴露出弊端：模塊愈發(fā)臃腫、開發(fā)效率低下、性能出現瓶頸、系統維護困難。從2017年開始啟動的v2.0架構升級，基于業(yè)務模塊進行垂直的系統物理拆分，拆分出來業(yè)務線各司其職，提供服務化的能力，共同支撐主站業(yè)務。訂單模...
一、背景
隨著用戶量級的快速增長，vivo 官方商城 v1.0 的單體架構逐漸暴露出弊端：模塊愈發(fā)臃腫、開發(fā)效率低下、性能出現瓶頸、系統維護困難。
從2017年開始啟動的 v2.0 架構升級，基于業(yè)務模塊進行垂直的系統物理拆分，拆分出來業(yè)務線各司其職，提供服務化的能力，共同支撐主站業(yè)務。
訂單模塊是電商系統的交易核心，不斷累積的數據即將達到單表存儲瓶頸，系統難以支撐新品發(fā)布和大促活動期間的流量，服務化改造勢在必行。
本文將介紹 vivo 商城 訂單系統建設的過程中遇到的問題和解決方案，分享架構設計經驗。
二、系統架構
將訂單模塊從商城拆分出來，獨立為訂單系統，使用獨立的數據庫，為商城相關系統提供訂單、支付、物流、售后等標準化服務。
系統架構如下圖所示：
三、技術挑戰(zhàn)
3.1?數據量和高并發(fā)問題
首先面對的挑戰(zhàn)來自存儲系統：
下面對這些方案進行簡單描述：
我們綜合考慮了改造成本、效果和對現有業(yè)務的影響，決定直接使用最后一招：分庫分表
3.2 分庫分表技術選型
分庫分表的技術選型主要從這幾個方向考慮：
參考之前項目經驗，并與公司中間件團隊溝通后，采用了開源的 Sharding-JDBC 方案?，F已更名為Sharding-Sphere。
3.2.1 分庫分表策略
結合業(yè)務特性，選取用戶標識作為分片鍵，通過計算用戶標識的哈希值再取模來得到用戶訂單數據的庫表編號.
假設共有n個庫，每個庫有m張表，
則庫表編號的計算方式為：- 庫序號：Hash(userId) / m % n
- 表序號：Hash(userId) % m
路由過程如下圖所示：
3.2.2?分庫分表的局限性和應對方案
分庫分表解決了數據量和并發(fā)問題，但它會極大限制數據庫的查詢能力，有一些之前很簡單的關聯查詢，在分庫分表之后可能就沒法實現了，那就需要單獨對這些Sharding-JDBC不支持的SQL進行改寫。
除此之外，還遇到了這些挑戰(zhàn)：
（1）全局唯一ID設計
分庫分表后，數據庫自增主鍵不再全局唯一，不能作為訂單號來使用，但很多內部系統間的交互接口只有訂單號，沒有用戶標識這個分片鍵，如何用訂單號來找到對應的庫表呢？
原來，我們在生成訂單號時，就將庫表編號隱含在其中了。這樣就能在沒有用戶標識的場景下，從訂單號中獲取庫表編號。
（2）歷史訂單號沒有隱含庫表信息
用一張表單獨存儲歷史訂單號和用戶標識的映射關系，隨著時間推移，這些訂單逐漸不在系統間交互，就慢慢不再被用到。
（3）管理后臺需要根據各種篩選條件，分頁查詢所有滿足條件的訂單
將訂單數據冗余存儲在搜索引擎Elasticsearch中，僅用于后臺查詢。
3.3 怎么做 MySQL 到 ES 的數據同步
上面說到為了便于管理后臺的查詢，我們將訂單數據冗余存儲在Elasticsearch中，那么，如何在MySQL的訂單數據變更后，同步到ES中呢？
這里要考慮的是數據同步的時效性和一致性、對業(yè)務代碼侵入小、不影響服務本身的性能等。
其中BinLog方案比較通用，但實現起來也較為復雜，我們最終選用的是MQ方案。
因為ES數據只在管理后臺使用，對數據可靠性和同步實時性的要求不是特別高。
考慮到宕機和消息丟失等極端情況，在后臺增加了按某些條件手動同步ES數據的功能來進行補償。
3.4 如何安全地更換數據庫
如何將數據從原來的單實例數據庫遷移到新的數據庫集群，也是一大技術挑戰(zhàn)
不但要確保數據的正確性，還要保證每執(zhí)行一個步驟后，一旦出現問題，能快速地回滾到上一個步驟。
我們考慮了停機遷移和不停機遷移的兩種方案：
（1）不停機遷移方案：
（2）停機遷移方案：
考慮到不停機方案的改造成本較高，而夜間停機方案的業(yè)務損失并不大，最終選用的是停機遷移方案。
3.5 分布式事務問題
電商的交易流程中，分布式事務是一個經典問題，比如：
我們是如何保證微服務架構下數據的一致性呢？
不同業(yè)務場景對數據一致性的要求不同，業(yè)界的主流方案中，用于解決強一致性的有兩階段提交(2PC)、三階段提交(3PC)，解決最終一致性的有TCC、本地消息、事務消息和最大努力通知等。
這里不對上述方案進行詳細的描述，介紹一下我們正在使用的本地消息表方案：在本地事務中將要執(zhí)行的異步操作記錄在消息表中，如果執(zhí)行失敗，可以通過定時任務來補償。
下圖以訂單完成后通知積分系統贈送積分為例。
3.6 系統安全和穩(wěn)定性
3.7? 踩過的坑
采用MQ消費的方式同步數據庫的訂單相關數據到ES中，遇到的寫入數據不是訂單最新數據問題
下圖左邊是原方案：
在消費訂單數據同步的MQ時，如果線程A在先執(zhí)行，查出數據，這時候訂單數據被更新了，線程B開始執(zhí)行同步操作，查出訂單數據后先于線程A一步寫入ES中，線程A執(zhí)行寫入時就會將線程B寫入的數據覆蓋，導致ES中的訂單數據不是最新的。
解決方案是在查詢訂單數據時加行鎖，整個業(yè)務執(zhí)行在事務中，執(zhí)行完成后再執(zhí)行下一個線程。
sharding-jdbc 分組后排序分頁查詢出所有數據問題
示例：select a ?from ?temp group by a，b order by a ?desc limit 1,10。
執(zhí)行是Sharding-jdbc里group by 和 order by 字段和順序不一致是將10置為Integer.MAX_VALUE, 導致分頁查詢失效。
隨著用戶量級的快速增長，vivo 官方商城 v1.0 的單體架構逐漸暴露出弊端：模塊愈發(fā)臃腫、開發(fā)效率低下、性能出現瓶頸、系統維護困難。
從2017年開始啟動的 v2.0 架構升級，基于業(yè)務模塊進行垂直的系統物理拆分，拆分出來業(yè)務線各司其職，提供服務化的能力，共同支撐主站業(yè)務。
訂單模塊是電商系統的交易核心，不斷累積的數據即將達到單表存儲瓶頸，系統難以支撐新品發(fā)布和大促活動期間的流量，服務化改造勢在必行。
本文將介紹 vivo 商城 訂單系統建設的過程中遇到的問題和解決方案，分享架構設計經驗。
二、系統架構
將訂單模塊從商城拆分出來，獨立為訂單系統，使用獨立的數據庫，為商城相關系統提供訂單、支付、物流、售后等標準化服務。
系統架構如下圖所示：
三、技術挑戰(zhàn)
3.1?數據量和高并發(fā)問題
首先面對的挑戰(zhàn)來自存儲系統：
- 數據量問題隨著歷史訂單不斷累積，MySQL中訂單表數據量已達千萬級。我們知道InnoDB存儲引擎的存儲結構是B 樹，查找時間復雜度是O(log n)，因此當數據總量n變大時，檢索速度必然會變慢， 不論如何加索引或者優(yōu)化都無法解決，只能想辦法減小單表數據量。數據量大的解決方案有：數據歸檔、分表
- 高并發(fā)問題商城業(yè)務處于高速發(fā)展期，下單量屢創(chuàng)新高，業(yè)務復雜度也在提升，應用程序對MySQL的訪問量越來越高。單機MySQL的處理能力是有限的，當壓力過大時，所有請求的訪問速度都會下降，甚至有可能使數據庫宕機。并發(fā)量高的解決方案有：使用緩存、讀寫分離、分庫
下面對這些方案進行簡單描述：
- 數據歸檔
訂單數據具備時間屬性，存在熱尾效應，大部分情況下檢索的都是最近的訂單，而訂單表里卻存儲了大量使用頻率較低的老數據。
那么就可以將新老數據分開存儲，將歷史訂單移入另一張表中，并對代碼中的查詢模塊做一些相應改動，便能有效解決數據量大的問題。
- 使用緩存使用Redis作為MySQL的前置緩存，可以擋住大部分的查詢請求，并降低響應時延。緩存對商品系統這類與用戶關系不大的系統效果特別好，但對訂單系統而言，每個用戶的訂單數據都不一樣，緩存命中率不算高，效果不是太好。
- 讀寫分離主庫負責執(zhí)行數據更新請求，然后將數據變更實時同步到所有從庫，用多個從庫來分擔查詢請求。
但訂單數據的更新操作較多，下單高峰時主庫的壓力依然沒有得到解決。且存在主從同步延遲，正常情況下延遲非常小，不超過1ms，但也會導致在某一個時刻的主從數據不一致。那就需要對所有受影響的業(yè)務場景進行兼容處理，可能會做一些妥協，比如下單成功后先跳轉到一個下單成功頁，用戶手動點擊查看訂單后才能看到這筆訂單。
- 分庫分庫又包含垂直分庫和水平分庫。
① 水平分庫：把同一個表的數據按一定規(guī)則拆到不同的數據庫中，每個庫可以放在不同的服務器上。② 垂直分庫：按照業(yè)務將表進行分類，分布到不同的數據庫上面，每個庫可以放在不同的服務器上，它的核心理念是專庫專用。
- 分表分表又包含垂直分表和水平分表。①?水平分表：在同一個數據庫內，把一個表的數據按一定規(guī)則拆到多個表中。②?垂直分表：將一個表按照字段分成多表，每個表存儲其中一部分字段。
我們綜合考慮了改造成本、效果和對現有業(yè)務的影響，決定直接使用最后一招：分庫分表
3.2 分庫分表技術選型
分庫分表的技術選型主要從這幾個方向考慮：
- 客戶端sdk開源方案
- 中間件proxy開源方案
- 公司中間件團隊提供的自研框架
- 自己動手造輪子
參考之前項目經驗，并與公司中間件團隊溝通后，采用了開源的 Sharding-JDBC 方案?，F已更名為Sharding-Sphere。
- Github：https://github.com/sharding-sphere/
- 文檔：官方文檔比較粗糙，但是網上資料、源碼解析、demo比較豐富
- 社區(qū)：活躍
- 特點：jar包方式提供，屬于client端分片，支持xa事務
3.2.1 分庫分表策略
結合業(yè)務特性，選取用戶標識作為分片鍵，通過計算用戶標識的哈希值再取模來得到用戶訂單數據的庫表編號.
假設共有n個庫，每個庫有m張表，
則庫表編號的計算方式為：- 庫序號：Hash(userId) / m % n
- 表序號：Hash(userId) % m
路由過程如下圖所示：
3.2.2?分庫分表的局限性和應對方案
分庫分表解決了數據量和并發(fā)問題，但它會極大限制數據庫的查詢能力，有一些之前很簡單的關聯查詢，在分庫分表之后可能就沒法實現了，那就需要單獨對這些Sharding-JDBC不支持的SQL進行改寫。
除此之外，還遇到了這些挑戰(zhàn)：
（1）全局唯一ID設計
分庫分表后，數據庫自增主鍵不再全局唯一，不能作為訂單號來使用，但很多內部系統間的交互接口只有訂單號，沒有用戶標識這個分片鍵，如何用訂單號來找到對應的庫表呢？
原來，我們在生成訂單號時，就將庫表編號隱含在其中了。這樣就能在沒有用戶標識的場景下，從訂單號中獲取庫表編號。
（2）歷史訂單號沒有隱含庫表信息
用一張表單獨存儲歷史訂單號和用戶標識的映射關系，隨著時間推移，這些訂單逐漸不在系統間交互，就慢慢不再被用到。
（3）管理后臺需要根據各種篩選條件，分頁查詢所有滿足條件的訂單
將訂單數據冗余存儲在搜索引擎Elasticsearch中，僅用于后臺查詢。
3.3 怎么做 MySQL 到 ES 的數據同步
上面說到為了便于管理后臺的查詢，我們將訂單數據冗余存儲在Elasticsearch中，那么，如何在MySQL的訂單數據變更后，同步到ES中呢？
這里要考慮的是數據同步的時效性和一致性、對業(yè)務代碼侵入小、不影響服務本身的性能等。
- MQ方案ES更新服務作為消費者，接收訂單變更MQ消息后對ES進行更新
- Binlog方案ES更新服務借助canal等開源項目，把自己偽裝成MySQL的從節(jié)點，接收Binlog并解析得到實時的數據變更信息，然后根據這個變更信息去更新ES。
其中BinLog方案比較通用，但實現起來也較為復雜，我們最終選用的是MQ方案。
因為ES數據只在管理后臺使用，對數據可靠性和同步實時性的要求不是特別高。
考慮到宕機和消息丟失等極端情況，在后臺增加了按某些條件手動同步ES數據的功能來進行補償。
3.4 如何安全地更換數據庫
如何將數據從原來的單實例數據庫遷移到新的數據庫集群，也是一大技術挑戰(zhàn)
不但要確保數據的正確性，還要保證每執(zhí)行一個步驟后，一旦出現問題，能快速地回滾到上一個步驟。
我們考慮了停機遷移和不停機遷移的兩種方案：
（1）不停機遷移方案：
- 把舊庫的數據復制到新庫中，上線一個同步程序，使用 Binlog等方案實時同步舊庫數據到新庫。
- 上線雙寫訂單新舊庫服務，只讀寫舊庫。
- 開啟雙寫，同時停止同步程序，開啟對比補償程序，確保新庫數據和舊庫一致。
- 逐步將讀請求切到新庫上。
- 讀寫都切換到新庫上，對比補償程序確保舊庫數據和新庫一致。
- 下線舊庫，下線訂單雙寫功能，下線同步程序和對比補償程序。
（2）停機遷移方案：
- 上線新訂單系統，執(zhí)行遷移程序將兩個月之前的訂單同步到新庫，并對數據進行稽核。
- 將商城V1應用停機，確保舊庫數據不再變化。
- 執(zhí)行遷移程序，將第一步未遷移的訂單同步到新庫并進行稽核。
- 上線商城V2應用，開始測試驗證，如果失敗則回退到商城V1應用（新訂單系統有雙寫舊庫的開關）。
考慮到不停機方案的改造成本較高，而夜間停機方案的業(yè)務損失并不大，最終選用的是停機遷移方案。
3.5 分布式事務問題
電商的交易流程中，分布式事務是一個經典問題，比如：
- 用戶支付成功后，需要通知發(fā)貨系統給用戶發(fā)貨。
- 用戶確認收貨后，需要通知積分系統給用戶發(fā)放購物獎勵的積分。
我們是如何保證微服務架構下數據的一致性呢？
不同業(yè)務場景對數據一致性的要求不同，業(yè)界的主流方案中，用于解決強一致性的有兩階段提交(2PC)、三階段提交(3PC)，解決最終一致性的有TCC、本地消息、事務消息和最大努力通知等。
這里不對上述方案進行詳細的描述，介紹一下我們正在使用的本地消息表方案：在本地事務中將要執(zhí)行的異步操作記錄在消息表中，如果執(zhí)行失敗，可以通過定時任務來補償。
下圖以訂單完成后通知積分系統贈送積分為例。
3.6 系統安全和穩(wěn)定性
- 網絡隔離只有極少數第三方接口可通過外網訪問，且都會驗證簽名，內部系統交互使用內網域名和RPC接口。
- 并發(fā)鎖任何訂單更新操作之前，會通過數據庫行級鎖加以限制，防止出現并發(fā)更新。
- 冪等性所有接口均具備冪等性，不用擔心對方網絡超時重試所造成的影響。
- 熔斷使用Hystrix組件，對外部系統的實時調用添加熔斷保護，防止某個系統故障的影響擴大到整個分布式系統中。
- 監(jiān)控和告警通過配置日志平臺的錯誤日志報警、調用鏈的服務分析告警，再加上公司各中間件和基礎組件的監(jiān)控告警功能，讓我們能夠能夠第一時間發(fā)現系統異常。
3.7? 踩過的坑
采用MQ消費的方式同步數據庫的訂單相關數據到ES中，遇到的寫入數據不是訂單最新數據問題
下圖左邊是原方案：
在消費訂單數據同步的MQ時，如果線程A在先執(zhí)行，查出數據，這時候訂單數據被更新了，線程B開始執(zhí)行同步操作，查出訂單數據后先于線程A一步寫入ES中，線程A執(zhí)行寫入時就會將線程B寫入的數據覆蓋，導致ES中的訂單數據不是最新的。
解決方案是在查詢訂單數據時加行鎖，整個業(yè)務執(zhí)行在事務中，執(zhí)行完成后再執(zhí)行下一個線程。
sharding-jdbc 分組后排序分頁查詢出所有數據問題
示例：select a ?from ?temp group by a，b order by a ?desc limit 1,10。
執(zhí)行是Sharding-jdbc里group by 和 order by 字段和順序不一致是將10置為Integer.MAX_VALUE, 導致分頁查詢失效。
io.shardingsphere.core.routing.router.sharding.ParsingSQLRouter#processLimit
private void processLimit(final List boolean isNeedFetchAll = (!selectStatement.getGroupByItems().isEmpty() || !selectStatement.getAggregationSelectItems().isEmpty()) 
下載文檔
