作者：李sir
來源：公眾號京東技術
B2B交易平臺部
以分銷、代銷業務為核心的B2B交易平臺，通過建立各級商家之間渠道通路的方式，賦能線上線下B用戶，併為其提供一站式採購、售賣的解決方案。
B2B業務介紹和業務發展
01
業務介紹
京東 B2B 業務的定位是讓各類型的企業都可以在京東的 B 平臺上進行採購、建立採購關係。
京東 B2B 的用戶群體主要分為 2 類，一類是大 B 用戶、另一類是小 B 用戶。比如聯通、移動公司跟京東建立的採購關係，就是 B 平臺的大 B 用戶；如果有一家小超市需要在京東 B 平臺上進行採購，那麼它就是 B 平臺的小 B 用戶。
京東 B 平臺需要支持各類型的用戶群，因此必須要有自己的業務系統做支撐，比如訂單、商品、價格、用戶、權限、審核等系統。
02
業務發展
從上圖可以看出，京東 B 平臺的發展分為3個階段：
1）第一階段（2014年）
B2B 浪潮開始興起，京東在2014年與聯通公司達成合作，意味著京東正式邁入B2B時代的大 B 行業。
2）第二階段（2015-2016年）
農村電商開始興起，線下門店積極順應互聯網的發展趨勢，將傳統的零售搬到了線上；在這個階段，京東成立新通路事業部開展此業務，從此京東正式邁入了小 B 行業。
3）第三階段（2017年至今）
在之前大、小 B 業務的基礎上，京東的 B2B 業務在2017年得到快速發展，完美應對這個階段產生的種種挑戰，併發量、數據量均成幾十倍的增長。
B2B技術架構演變
01
業務架構1.0
1）架構
從上圖可以看出，業務架構 1.0 分為 3 層：
業務層：主要是 B 平臺的所有業務線服務層：包含訂單、價格、商品、用戶等 SOA 服務系統存儲層：使用 mysq l數據庫進行存儲2）問題
在2014年初期，為了響應業務的發展，我們需要快速上線業務系統，採取的是縱向按業務線進行劃分，每一條業務線都有自己的業務層、服務層、存儲層，當有新的業務線接入的時候，還是以同樣的模式進行開發。
當來到第二階段的時候，這種架構面對了極大的挑戰，主要有以下幾個表現：
上述的表現反應出業務架構存在以下幾點問題：
服務問題服務之間零複用性，各個業務線的服務沒有抽取共享的服務，其實有80%都是相同的模式，沒有抽象。系統耦合系統之間的相互調用採用的 jsf 服務，全部是同步調用，調用鏈路很長，一個環節出問題會導致整個系統都出問題，沒有核心服務和非核心服務、沒有異步化服務。公用數據庫問題由於前期是按業務線進行劃分，在一個業務線上，核心服務的數據都存儲在一個數據庫上面。3）服務問題改進
4）測試方案
條件：新老服務的對外接口參數不變
5）系統耦合改進
系統耦合的問題，通過引入 jmq 消息中間件進行解決。消息無序的問題，採用樂觀鎖進行解決，主要是依靠數據的版本對比來解決。
6）數據庫改進
數據公用的問題，解決方案還是進行拆分：
第一步，將各個業務系統 SOA 服務的數據，單獨存儲在自己的數據庫，訂單有訂單專門的數據庫、商品有商品專門的數據庫，服務之間互相不受影響。第二步，在第一個步拆分後，有的業務數據量單表數量還是很大，需要對錶進行拆分，我們採用 jproxy（不支持分表）進行分庫，按業務的相關主鍵 id，進行 hash(id)%count（分庫數量），支持水平擴展。擴展：
還有那些分佈算法方式：ID 區間算法、時間區間熱點數據：二次 hash事務：弱化強一致性，採用消息的機制進行交互，實現最終一致性。垮庫查詢：分佈式查詢7）分佈式搜索
分佈式查詢，採用的是 elasticSearch 搜索進行支持，簡稱es。
消息同步才用 jmq 和 binlog如果 es 集群有問題，採用的方式是備份集群支持服務（數據有延遲風險）02
業務架構2.0
1）架構
在1.0的基礎上，做如下三點調整：
服務層抽取公共服務引入基礎層的工具存儲層分庫分表2）問題
2.0系統在2017年進入第三階段後，開始面臨以下兩個問題：
平臺化服務業務代碼臃腫個性化需求的重複開發3）思考
舉一個例子，我們現在有「訂單」、「價格」、「商品」服務，A 用戶需要訂單服務，B 用戶需要訂單、價格服務，C 用戶需要訂單、價格、商品服務。現在的做法是開發3套業務接口服務，底層的服務是通用的，但是業務層的代碼有重複開發、業務代碼臃腫的問題。
我們該怎麼做？
引入配置中心
對服務進行配置對頁面進行配置可以自定義插件服務4）組件
通過以上的思考，我們有了組件的思想，以後對外的服務都是可配置的。就像一個加工廠，對服務加工，就可以對外部業務進行使用。
03
業務架構3.0
3.0的版本主要是修改，包含服務層的抽取、業務和 SOA 分離，同時引入業務和工具組件。
總 結
B2B業務架構經過3次變遷與升級，我們總結到以下經驗：