京東 B2B 業務架構演變

京東 · 發表 2018-11-03 08:28:54

摘要：來這裡找志同道合的小夥伴！ B2B交易平臺部以分銷、代銷業務為核心的B2B交易平臺，通過建立各級商家之間渠道通路的方式，賦能線上線下B使用者，併為其提供一站式採購、售賣的解決方案。 B2B業務介紹和業務發展 0 1 業務介紹京東 B2B 業務的...

來這裡找志同道合的小夥伴！

以分銷、代銷業務為核心的B2B交易平臺，通過建立各級商家之間渠道通路的方式，賦能線上線下B使用者，併為其提供一站式採購、售賣的解決方案。

B2B業務介紹和業務發展

0 1

業務介紹

京東 B2B 業務的定位是讓各型別的企業都可以在京東的 B 平臺上進行採購、建立採購關係。

京東 B2B 的使用者群體主要分為 2 類，一類是大 B 使用者、另一類是小 B 使用者。比如聯通、移動公司跟京東建立的採購關係，就是 B 平臺的大 B 使用者；如果有一家小超市需要在京東 B 平臺上進行採購，那麼它就是 B 平臺的小 B 使用者。

京東 B 平臺需要支援各型別的使用者群，因此必須要有自己的業務系統做支撐，比如訂單、商品、價格、使用者、許可權、稽核等系統。

業務發展

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

1） 第一階段（2014年）

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

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

農村電商開始興起，線下門店積極順應網際網路的發展趨勢，將傳統的零售搬到了線上；在這個階段，京東成立新通路事業部開展此業務，從此京東正式邁入了小 B 行業。

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

在之前大、小 B 業務的基礎上，京東的 B2B 業務在2017年得到快速發展，完美應對這個階段產生的種種挑戰，併發量、資料量均成幾十倍的增長。

B2B技術架構演變

0 1

業務架構1.0

1）架構

從上圖可以看出，業務架構 1.0 分為 3 層：

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

當來到第二階段的時候，這種架構面對了極大的挑戰，主要有以下幾個表現：

上述的表現反應出業務架構存在以下幾點問題：

服務問題

服務之間零複用性，各個業務線的服務沒有抽取共享的服務，其實有80%都是相同的模式，沒有抽象。
系統耦合

系統之間的相互呼叫採用的 jsf 服務，全部是同步呼叫，呼叫鏈路很長，一個環節出問題會導致整個系統都出問題，沒有核心服務和非核心服務、沒有非同步化服務。
公用資料庫問題

由於前期是按業務線進行劃分，在一個業務線上，核心服務的資料都儲存在一個數據庫上面。

條件：新老服務的對外介面引數不變

系統耦合的問題，通過引入 jmq 訊息中介軟體進行解決。訊息無序的問題，採用樂觀鎖進行解決，主要是依靠資料的版本對比來解決。

資料公用的問題，解決方案還是進行拆分：

第一步，將各個業務系統 SOA 服務的資料，單獨儲存在自己的資料庫，訂單有訂單專門的資料庫、商品有商品專門的資料庫，服務之間互相不受影響。
第二步 ，在第一個步拆分後，有的業務資料量單表數量還是很大，需要對錶進行拆分，我們採用 jproxy（不支援分表）進行分庫，按業務的相關主鍵 id，進行 hash(id)%count（分庫數量），支援水平擴充套件。