京東 B2B 業(yè)務(wù)架構(gòu)演進解密

點擊“開發(fā)者技術(shù)前線”，選擇“星標??”

讓一部分開發(fā)者看到未來

京東 B2B 業(yè)務(wù)的定位是讓各類型的企業(yè)都可以在京東的 B 平臺上進行采購、建立采購關(guān)系。

京東 B2B 的用戶群體主要分為 2 類，一類是大 B 用戶、另一類是小 B 用戶。比如聯(lián)通、移動公司跟京東建立的采購關(guān)系，就是 B 平臺的大 B 用戶；如果有一家小超市需要在京東 B 平臺上進行采購，那么它就是 B 平臺的小 B 用戶。

京東 B 平臺需要支持各類型的用戶群，因此必須要有自己的業(yè)務(wù)系統(tǒng)做支撐，比如訂單、商品、價格、用戶、權(quán)限、審核等系統(tǒng)。

從上圖可以看出，京東 B 平臺的發(fā)展分為3個階段：

1）第一階段（2014年）

B2B 浪潮開始興起，京東在2014年與聯(lián)通公司達成合作，意味著京東正式邁入B2B時代的大 B 行業(yè)。

2）第二階段（2015-2016年）

農(nóng)村電商開始興起，線下門店積極順應(yīng)互聯(lián)網(wǎng)的發(fā)展趨勢，將傳統(tǒng)的零售搬到了線上；在這個階段，京東成立新通路事業(yè)部開展此業(yè)務(wù)，從此京東正式邁入了小 B 行業(yè)。

3）第三階段（2017年至今）

在之前大、小 B 業(yè)務(wù)的基礎(chǔ)上，京東的 B2B 業(yè)務(wù)在2017年得到快速發(fā)展，完美應(yīng)對這個階段產(chǎn)生的種種挑戰(zhàn)，并發(fā)量、數(shù)據(jù)量均成幾十倍的增長。

1）架構(gòu)

從上圖可以看出，業(yè)務(wù)架構(gòu) 1.0 分為 3 層：

• 業(yè)務(wù)層：主要是 B 平臺的所有業(yè)務(wù)線

• 服務(wù)層：包含訂單、價格、商品、用戶等 SOA 服務(wù)系統(tǒng)

• 存儲層：使用 mysq l數(shù)據(jù)庫進行存儲

2）問題

在2014年初期，為了響應(yīng)業(yè)務(wù)的發(fā)展，我們需要快速上線業(yè)務(wù)系統(tǒng)，采取的是縱向按業(yè)務(wù)線進行劃分，每一條業(yè)務(wù)線都有自己的業(yè)務(wù)層、服務(wù)層、存儲層，當有新的業(yè)務(wù)線接入的時候，還是以同樣的模式進行開發(fā)。

當來到第二階段的時候，這種架構(gòu)面對了極大的挑戰(zhàn)，主要有以下幾個表現(xiàn)：

• 開發(fā)周期長，無法快速滿足業(yè)務(wù)要求

• 服務(wù)之間的相互影響，訂單和商品在一個數(shù)據(jù)庫，一個出問題，會影響別的服務(wù)

• 系統(tǒng)之間耦合度大

上述的表現(xiàn)反應(yīng)出業(yè)務(wù)架構(gòu)存在以下幾點問題：

• 服務(wù)問題

  服務(wù)之間零復(fù)用性，各個業(yè)務(wù)線的服務(wù)沒有抽取共享的服務(wù)，其實有80%都是相同的模式，沒有抽象。

• 系統(tǒng)耦合

  系統(tǒng)之間的相互調(diào)用采用的 jsf 服務(wù)，全部是同步調(diào)用，調(diào)用鏈路很長，一個環(huán)節(jié)出問題會導致整個系統(tǒng)都出問題，沒有核心服務(wù)和非核心服務(wù)、沒有異步化服務(wù)。

• 公用數(shù)據(jù)庫問題

  由于前期是按業(yè)務(wù)線進行劃分，在一個業(yè)務(wù)線上，核心服務(wù)的數(shù)據(jù)都存儲在一個數(shù)據(jù)庫上面。

3）服務(wù)問題改進

• 第一步拆分，將各個業(yè)務(wù)線的的服務(wù)拆分成小服務(wù)。

• 第二步拆分，組合第一步抽取的服務(wù)，形成公共服務(wù)，以后所有業(yè)務(wù)線都請求這些公共服務(wù)，提高服務(wù)的復(fù)用性。

4）測試方案

• 配置（人工）

• 采集數(shù)據(jù)（自動）

• 分發(fā)請求（自動）

• 數(shù)據(jù)對比（自動）

• 核對（人工）

條件：新老服務(wù)的對外接口參數(shù)不變

5）系統(tǒng)耦合改進

系統(tǒng)耦合的問題，通過引入 jmq 消息中間件進行解決。消息無序的問題，采用樂觀鎖進行解決，主要是依靠數(shù)據(jù)的版本對比來解決。

6）數(shù)據(jù)庫改進

數(shù)據(jù)公用的問題，解決方案還是進行拆分：

• 第一步，將各個業(yè)務(wù)系統(tǒng) SOA 服務(wù)的數(shù)據(jù)，單獨存儲在自己的數(shù)據(jù)庫，訂單有訂單專門的數(shù)據(jù)庫、商品有商品專門的數(shù)據(jù)庫，服務(wù)之間互相不受影響。

• 第二步，在第一個步拆分后，有的業(yè)務(wù)數(shù)據(jù)量單表數(shù)量還是很大，需要對表進行拆分，我們采用 jproxy（不支持分表）進行分庫，按業(yè)務(wù)的相關(guān)主鍵 id，進行 hash(id)%count（分庫數(shù)量），支持水平擴展。

擴展：

• 還有那些分布算法方式：ID 區(qū)間算法、時間區(qū)間

• 熱點數(shù)據(jù)：二次 hash

• 事務(wù)：弱化強一致性，采用消息的機制進行交互，實現(xiàn)最終一致性。

• 垮庫查詢：分布式查詢

7）分布式搜索

分布式查詢，采用的是 elasticSearch 搜索進行支持，簡稱es。

• 消息同步才用?jmq 和?binlog

• 如果 es 集群有問題，采用的方式是備份集群支持服務(wù)（數(shù)據(jù)有延遲風險）

1）架構(gòu)

在1.0的基礎(chǔ)上，做如下三點調(diào)整：

• 服務(wù)層抽取公共服務(wù)

• 引入基礎(chǔ)層的工具

• 存儲層分庫分表

2）問題

2.0系統(tǒng)在2017年進入第三階段后，開始面臨以下兩個問題：

• 平臺化服務(wù)業(yè)務(wù)代碼臃腫

• 個性化需求的重復(fù)開發(fā)

3）思考

?

舉一個例子，我們現(xiàn)在有「訂單」、「價格」、「商品」服務(wù)，A 用戶需要訂單服務(wù)，B 用戶需要訂單、價格服務(wù)，C 用戶需要訂單、價格、商品服務(wù)。現(xiàn)在的做法是開發(fā)3套業(yè)務(wù)接口服務(wù)，底層的服務(wù)是通用的，但是業(yè)務(wù)層的代碼有重復(fù)開發(fā)、業(yè)務(wù)代碼臃腫的問題。

我們該怎么做？

引入配置中心

• 對服務(wù)進行配置

• 對頁面進行配置

• 可以自定義插件服務(wù)

4）組件

通過以上的思考，我們有了組件的思想，以后對外的服務(wù)都是可配置的。就像一個加工廠，對服務(wù)加工，就可以對外部業(yè)務(wù)進行使用。

?

3.0的版本主要是修改，包含服務(wù)層的抽取、業(yè)務(wù)和 SOA 分離，同時引入業(yè)務(wù)和工具組件。

B2B業(yè)務(wù)架構(gòu)經(jīng)過3次變遷與升級，我們總結(jié)到以下經(jīng)驗：

點擊下方圖片即可閱讀

選擇”開發(fā)者技術(shù)前線?“星標??，內(nèi)容一觸即達。點擊原文更多驚喜！
開發(fā)者技術(shù)前線?匯集技術(shù)前線快訊和關(guān)注行業(yè)趨勢，大廠干貨，是開發(fā)者經(jīng)歷和成長的優(yōu)秀指南。
歷史推薦

支付寶 App架構(gòu)的原理與實戰(zhàn)
淘寶高并發(fā)分布式架構(gòu)演進之路
阿里巴巴微服務(wù)架構(gòu)的四大金剛利器
為什么阿里巴巴不建議boolean類型變量用isXXX？
點個在看，月薪幾萬!