一、背景

隨著用戶量級(jí)的快速增長(zhǎng)，vivo 官方商城 v1.0 的單體架構(gòu)逐漸暴露出弊端：模塊愈發(fā)臃腫、開發(fā)效率低下、性能出現(xiàn)瓶頸、系統(tǒng)維護(hù)困難。

從2017年開始啟動(dòng)的 v2.0 架構(gòu)升級(jí)，基于業(yè)務(wù)模塊進(jìn)行垂直的系統(tǒng)物理拆分，拆分出來業(yè)務(wù)線各司其職，提供服務(wù)化的能力，共同支撐主站業(yè)務(wù)。

訂單模塊是電商系統(tǒng)的交易核心，不斷累積的數(shù)據(jù)即將達(dá)到單表存儲(chǔ)瓶頸，系統(tǒng)難以支撐新品發(fā)布和大促活動(dòng)期間的流量，服務(wù)化改造勢(shì)在必行。

本文將介紹 vivo 商城 訂單系統(tǒng)建設(shè)的過程中遇到的問題和解決方案，分享架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)。

二、系統(tǒng)架構(gòu)

將訂單模塊從商城拆分出來，獨(dú)立為訂單系統(tǒng)，使用獨(dú)立的數(shù)據(jù)庫(kù)，為商城相關(guān)系統(tǒng)提供訂單、支付、物流、售后等標(biāo)準(zhǔn)化服務(wù)。

系統(tǒng)架構(gòu)如下圖所示：

三、技術(shù)挑戰(zhàn)

3.1?數(shù)據(jù)量和高并發(fā)問題

首先面對(duì)的挑戰(zhàn)來自存儲(chǔ)系統(tǒng)：

• 數(shù)據(jù)量問題
  隨著歷史訂單不斷累積，MySQL中訂單表數(shù)據(jù)量已達(dá)千萬級(jí)。
  我們知道InnoDB存儲(chǔ)引擎的存儲(chǔ)結(jié)構(gòu)是B 樹，查找時(shí)間復(fù)雜度是O(log n)，因此當(dāng)數(shù)據(jù)總量n變大時(shí)，檢索速度必然會(huì)變慢， 不論如何加索引或者優(yōu)化都無法解決，只能想辦法減小單表數(shù)據(jù)量。
  數(shù)據(jù)量大的解決方案有：數(shù)據(jù)歸檔、分表

• 高并發(fā)問題
  商城業(yè)務(wù)處于高速發(fā)展期，下單量屢創(chuàng)新高，業(yè)務(wù)復(fù)雜度也在提升，應(yīng)用程序?qū)ySQL的訪問量越來越高。
  單機(jī)MySQL的處理能力是有限的，當(dāng)壓力過大時(shí)，所有請(qǐng)求的訪問速度都會(huì)下降，甚至有可能使數(shù)據(jù)庫(kù)宕機(jī)。
  并發(fā)量高的解決方案有：使用緩存、讀寫分離、分庫(kù)

下面對(duì)這些方案進(jìn)行簡(jiǎn)單描述：

• 數(shù)據(jù)歸檔
  
  訂單數(shù)據(jù)具備時(shí)間屬性，存在熱尾效應(yīng)，大部分情況下檢索的都是最近的訂單，而訂單表里卻存儲(chǔ)了大量使用頻率較低的老數(shù)據(jù)。
  
  那么就可以將新老數(shù)據(jù)分開存儲(chǔ)，將歷史訂單移入另一張表中，并對(duì)代碼中的查詢模塊做一些相應(yīng)改動(dòng)，便能有效解決數(shù)據(jù)量大的問題。

• 使用緩存
  使用Redis作為MySQL的前置緩存，可以擋住大部分的查詢請(qǐng)求，并降低響應(yīng)時(shí)延。
  緩存對(duì)商品系統(tǒng)這類與用戶關(guān)系不大的系統(tǒng)效果特別好，但對(duì)訂單系統(tǒng)而言，每個(gè)用戶的訂單數(shù)據(jù)都不一樣，緩存命中率不算高，效果不是太好。

• 讀寫分離
  主庫(kù)負(fù)責(zé)執(zhí)行數(shù)據(jù)更新請(qǐng)求，然后將數(shù)據(jù)變更實(shí)時(shí)同步到所有從庫(kù)，用多個(gè)從庫(kù)來分擔(dān)查詢請(qǐng)求。
  
  但訂單數(shù)據(jù)的更新操作較多，下單高峰時(shí)主庫(kù)的壓力依然沒有得到解決。且存在主從同步延遲，正常情況下延遲非常小，不超過1ms，但也會(huì)導(dǎo)致在某一個(gè)時(shí)刻的主從數(shù)據(jù)不一致。
  那就需要對(duì)所有受影響的業(yè)務(wù)場(chǎng)景進(jìn)行兼容處理，可能會(huì)做一些妥協(xié)，比如下單成功后先跳轉(zhuǎn)到一個(gè)下單成功頁(yè)，用戶手動(dòng)點(diǎn)擊查看訂單后才能看到這筆訂單。

• 分庫(kù)
  分庫(kù)又包含垂直分庫(kù)和水平分庫(kù)。
  
  ① 水平分庫(kù)：把同一個(gè)表的數(shù)據(jù)按一定規(guī)則拆到不同的數(shù)據(jù)庫(kù)中，每個(gè)庫(kù)可以放在不同的服務(wù)器上。
  ② 垂直分庫(kù)：按照業(yè)務(wù)將表進(jìn)行分類，分布到不同的數(shù)據(jù)庫(kù)上面，每個(gè)庫(kù)可以放在不同的服務(wù)器上，它的核心理念是專庫(kù)專用。

• 分表
  分表又包含垂直分表和水平分表。
  ①?水平分表：在同一個(gè)數(shù)據(jù)庫(kù)內(nèi)，把一個(gè)表的數(shù)據(jù)按一定規(guī)則拆到多個(gè)表中。
  ②?垂直分表：將一個(gè)表按照字段分成多表，每個(gè)表存儲(chǔ)其中一部分字段。

我們綜合考慮了改造成本、效果和對(duì)現(xiàn)有業(yè)務(wù)的影響，決定直接使用最后一招：分庫(kù)分表

3.2 分庫(kù)分表技術(shù)選型

分庫(kù)分表的技術(shù)選型主要從這幾個(gè)方向考慮：

1. 客戶端sdk開源方案

2. 中間件proxy開源方案

3. 公司中間件團(tuán)隊(duì)提供的自研框架

4. 自己動(dòng)手造輪子

參考之前項(xiàng)目經(jīng)驗(yàn)，并與公司中間件團(tuán)隊(duì)溝通后，采用了開源的 Sharding-JDBC 方案?，F(xiàn)已更名為Sharding-Sphere。

• Github：
  https://github.com/sharding-sphere/

• 文檔：官方文檔比較粗糙，但是網(wǎng)上資料、源碼解析、demo比較豐富

• 社區(qū)：活躍

• 特點(diǎn)：jar包方式提供，屬于client端分片，支持xa事務(wù)

3.2.1 分庫(kù)分表策略

結(jié)合業(yè)務(wù)特性，選取用戶標(biāo)識(shí)作為分片鍵，通過計(jì)算用戶標(biāo)識(shí)的哈希值再取模來得到用戶訂單數(shù)據(jù)的庫(kù)表編號(hào).

假設(shè)共有n個(gè)庫(kù)，每個(gè)庫(kù)有m張表，

則庫(kù)表編號(hào)的計(jì)算方式為：

- 庫(kù)序號(hào)：Hash(userId) / m % n

- 表序號(hào)：Hash(userId) % m

路由過程如下圖所示：

3.2.2?分庫(kù)分表的局限性和應(yīng)對(duì)方案

分庫(kù)分表解決了數(shù)據(jù)量和并發(fā)問題，但它會(huì)極大限制數(shù)據(jù)庫(kù)的查詢能力，有一些之前很簡(jiǎn)單的關(guān)聯(lián)查詢，在分庫(kù)分表之后可能就沒法實(shí)現(xiàn)了，那就需要單獨(dú)對(duì)這些Sharding-JDBC不支持的SQL進(jìn)行改寫。

除此之外，還遇到了這些挑戰(zhàn)：

（1）全局唯一ID設(shè)計(jì)

分庫(kù)分表后，數(shù)據(jù)庫(kù)自增主鍵不再全局唯一，不能作為訂單號(hào)來使用，但很多內(nèi)部系統(tǒng)間的交互接口只有訂單號(hào)，沒有用戶標(biāo)識(shí)這個(gè)分片鍵，如何用訂單號(hào)來找到對(duì)應(yīng)的庫(kù)表呢？

原來，我們?cè)谏捎唵翁?hào)時(shí)，就將庫(kù)表編號(hào)隱含在其中了。這樣就能在沒有用戶標(biāo)識(shí)的場(chǎng)景下，從訂單號(hào)中獲取庫(kù)表編號(hào)。

（2）歷史訂單號(hào)沒有隱含庫(kù)表信息

用一張表單獨(dú)存儲(chǔ)歷史訂單號(hào)和用戶標(biāo)識(shí)的映射關(guān)系，隨著時(shí)間推移，這些訂單逐漸不在系統(tǒng)間交互，就慢慢不再被用到。

（3）管理后臺(tái)需要根據(jù)各種篩選條件，分頁(yè)查詢所有滿足條件的訂單

將訂單數(shù)據(jù)冗余存儲(chǔ)在搜索引擎Elasticsearch中，僅用于后臺(tái)查詢。

3.3 怎么做 MySQL 到 ES 的數(shù)據(jù)同步

上面說到為了便于管理后臺(tái)的查詢，我們將訂單數(shù)據(jù)冗余存儲(chǔ)在Elasticsearch中，那么，如何在MySQL的訂單數(shù)據(jù)變更后，同步到ES中呢？

這里要考慮的是數(shù)據(jù)同步的時(shí)效性和一致性、對(duì)業(yè)務(wù)代碼侵入小、不影響服務(wù)本身的性能等。

• MQ方案
  ES更新服務(wù)作為消費(fèi)者，接收訂單變更MQ消息后對(duì)ES進(jìn)行更新

• Binlog方案
  ES更新服務(wù)借助canal等開源項(xiàng)目，把自己偽裝成MySQL的從節(jié)點(diǎn)，接收Binlog并解析得到實(shí)時(shí)的數(shù)據(jù)變更信息，然后根據(jù)這個(gè)變更信息去更新ES。

其中BinLog方案比較通用，但實(shí)現(xiàn)起來也較為復(fù)雜，我們最終選用的是MQ方案。

因?yàn)镋S數(shù)據(jù)只在管理后臺(tái)使用，對(duì)數(shù)據(jù)可靠性和同步實(shí)時(shí)性的要求不是特別高。

考慮到宕機(jī)和消息丟失等極端情況，在后臺(tái)增加了按某些條件手動(dòng)同步ES數(shù)據(jù)的功能來進(jìn)行補(bǔ)償。

3.4 如何安全地更換數(shù)據(jù)庫(kù)

如何將數(shù)據(jù)從原來的單實(shí)例數(shù)據(jù)庫(kù)遷移到新的數(shù)據(jù)庫(kù)集群，也是一大技術(shù)挑戰(zhàn)

不但要確保數(shù)據(jù)的正確性，還要保證每執(zhí)行一個(gè)步驟后，一旦出現(xiàn)問題，能快速地回滾到上一個(gè)步驟。

我們考慮了停機(jī)遷移和不停機(jī)遷移的兩種方案：

（1）不停機(jī)遷移方案：

• 把舊庫(kù)的數(shù)據(jù)復(fù)制到新庫(kù)中，上線一個(gè)同步程序，使用 Binlog等方案實(shí)時(shí)同步舊庫(kù)數(shù)據(jù)到新庫(kù)。

• 上線雙寫訂單新舊庫(kù)服務(wù)，只讀寫舊庫(kù)。

• 開啟雙寫，同時(shí)停止同步程序，開啟對(duì)比補(bǔ)償程序，確保新庫(kù)數(shù)據(jù)和舊庫(kù)一致。

• 逐步將讀請(qǐng)求切到新庫(kù)上。

• 讀寫都切換到新庫(kù)上，對(duì)比補(bǔ)償程序確保舊庫(kù)數(shù)據(jù)和新庫(kù)一致。

• 下線舊庫(kù)，下線訂單雙寫功能，下線同步程序和對(duì)比補(bǔ)償程序。

（2）停機(jī)遷移方案：

• 上線新訂單系統(tǒng)，執(zhí)行遷移程序?qū)蓚€(gè)月之前的訂單同步到新庫(kù)，并對(duì)數(shù)據(jù)進(jìn)行稽核。

• 將商城V1應(yīng)用停機(jī)，確保舊庫(kù)數(shù)據(jù)不再變化。

• 執(zhí)行遷移程序，將第一步未遷移的訂單同步到新庫(kù)并進(jìn)行稽核。

• 上線商城V2應(yīng)用，開始測(cè)試驗(yàn)證，如果失敗則回退到商城V1應(yīng)用（新訂單系統(tǒng)有雙寫舊庫(kù)的開關(guān)）。

考慮到不停機(jī)方案的改造成本較高，而夜間停機(jī)方案的業(yè)務(wù)損失并不大，最終選用的是停機(jī)遷移方案。

3.5 分布式事務(wù)問題

電商的交易流程中，分布式事務(wù)是一個(gè)經(jīng)典問題，比如：

• 用戶支付成功后，需要通知發(fā)貨系統(tǒng)給用戶發(fā)貨。

• 用戶確認(rèn)收貨后，需要通知積分系統(tǒng)給用戶發(fā)放購(gòu)物獎(jiǎng)勵(lì)的積分。

我們是如何保證微服務(wù)架構(gòu)下數(shù)據(jù)的一致性呢？

不同業(yè)務(wù)場(chǎng)景對(duì)數(shù)據(jù)一致性的要求不同，業(yè)界的主流方案中，用于解決強(qiáng)一致性的有兩階段提交(2PC)、三階段提交(3PC)，解決最終一致性的有TCC、本地消息、事務(wù)消息和最大努力通知等。

這里不對(duì)上述方案進(jìn)行詳細(xì)的描述，介紹一下我們正在使用的本地消息表方案：在本地事務(wù)中將要執(zhí)行的異步操作記錄在消息表中，如果執(zhí)行失敗，可以通過定時(shí)任務(wù)來補(bǔ)償。

下圖以訂單完成后通知積分系統(tǒng)贈(zèng)送積分為例。

3.6 系統(tǒng)安全和穩(wěn)定性

• 網(wǎng)絡(luò)隔離
  只有極少數(shù)第三方接口可通過外網(wǎng)訪問，且都會(huì)驗(yàn)證簽名，內(nèi)部系統(tǒng)交互使用內(nèi)網(wǎng)域名和RPC接口。

• 并發(fā)鎖
  任何訂單更新操作之前，會(huì)通過數(shù)據(jù)庫(kù)行級(jí)鎖加以限制，防止出現(xiàn)并發(fā)更新。

• 冪等性
  所有接口均具備冪等性，不用擔(dān)心對(duì)方網(wǎng)絡(luò)超時(shí)重試所造成的影響。

• 熔斷
  使用Hystrix組件，對(duì)外部系統(tǒng)的實(shí)時(shí)調(diào)用添加熔斷保護(hù)，防止某個(gè)系統(tǒng)故障的影響擴(kuò)大到整個(gè)分布式系統(tǒng)中。

• 監(jiān)控和告警
  通過配置日志平臺(tái)的錯(cuò)誤日志報(bào)警、調(diào)用鏈的服務(wù)分析告警，再加上公司各中間件和基礎(chǔ)組件的監(jiān)控告警功能，讓我們能夠能夠第一時(shí)間發(fā)現(xiàn)系統(tǒng)異常。

3.7? 踩過的坑

采用MQ消費(fèi)的方式同步數(shù)據(jù)庫(kù)的訂單相關(guān)數(shù)據(jù)到ES中，遇到的寫入數(shù)據(jù)不是訂單最新數(shù)據(jù)問題

下圖左邊是原方案：

在消費(fèi)訂單數(shù)據(jù)同步的MQ時(shí)，如果線程A在先執(zhí)行，查出數(shù)據(jù)，這時(shí)候訂單數(shù)據(jù)被更新了，線程B開始執(zhí)行同步操作，查出訂單數(shù)據(jù)后先于線程A一步寫入ES中，線程A執(zhí)行寫入時(shí)就會(huì)將線程B寫入的數(shù)據(jù)覆蓋，導(dǎo)致ES中的訂單數(shù)據(jù)不是最新的。

解決方案是在查詢訂單數(shù)據(jù)時(shí)加行鎖，整個(gè)業(yè)務(wù)執(zhí)行在事務(wù)中，執(zhí)行完成后再執(zhí)行下一個(gè)線程。

sharding-jdbc 分組后排序分頁(yè)查詢出所有數(shù)據(jù)問題

示例：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, 導(dǎo)致分頁(yè)查詢失效。

io.shardingsphere.core.routing.router.sharding.ParsingSQLRouter#processLimit
private void processLimit(final List