以分銷、代銷業(yè)務(wù)為核心的B2B交易平臺，通過建立各級商家之間渠道通路的方式，賦能線上線下B用戶，并為其提供一站式采購、售賣的解決方案。
B2B業(yè)務(wù)介紹和業(yè)務(wù)發(fā)展
01
業(yè)務(wù)介紹
京東 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)。
02
業(yè)務(wù)發(fā)展
從上圖可以看出，京東 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ù)量均成幾十倍的增長。
B2B技術(shù)架構(gòu)演變
01
業(yè)務(wù)架構(gòu)1.0
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é)出問題會導(dǎo)致整個系統(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ù)有延遲風(fēng)險）
02業(yè)務(wù)架構(gòu)2.0
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ù)?，F(xiàn)在的做法是開發(fā)3套業(yè)務(wù)接口服務(wù)，底層的服務(wù)是通用的，但是業(yè)務(wù)層的代碼有重復(fù)開發(fā)、業(yè)務(wù)代碼臃腫的問題。
我們該怎么做？
引入配置中心
對服務(wù)進行配置
對頁面進行配置
可以自定義插件服務(wù)
4）組件
通過以上的思考，我們有了組件的思想，以后對外的服務(wù)都是可配置的。就像一個加工廠，對服務(wù)加工，就可以對外部業(yè)務(wù)進行使用。
03
業(yè)務(wù)架構(gòu)3.0
3.0的版本主要是修改，包含服務(wù)層的抽取、業(yè)務(wù)和 SOA 分離，同時引入業(yè)務(wù)和工具組件。
總 結(jié)
B2B業(yè)務(wù)架構(gòu)經(jīng)過3次變遷與升級，我們總結(jié)到以下經(jīng)驗：
