京東 B2B 業務架構演變
來這裡找志同道合的小夥伴!
B2B交易平臺部
以分銷、代銷業務為核心的B2B交易平臺,通過建立各級商家之間渠道通路的方式,賦能線上線下B使用者,併為其提供一站式採購、售賣的解決方案。
B2B業務介紹和業務發展
0 1
業務介紹
京東 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技術架構演變
0 1
業務架構1.0
1)架構
從上 圖 可以看出,業務架構 1.0 分為 3 層 :
2)問題
在2014年初期,為了響應業務的發展,我們需要快速上線業務系統,採取的是縱向按業務線進行劃分,每一條業務線都有自己的業務層、服務層、儲存層,當有新的業務線接入的時候,還是以同樣的模式進行開發。
當來到第二階段的時候,這種架構面對了極大的挑戰,主要有以下幾個表現:
-
開發週期長,無法快速滿足業務要求
-
服務之間 的 相互影響,訂單和商品在一個數據庫,一個出問題,會影響別的服務
-
系統之間耦合度大
上述的表現反應出業務架構存在以下幾點問題:
-
服務問題
服務之間零複用性,各個業務線的服務沒有抽取共享的服務,其實有80%都是相同的模式,沒有抽象。
-
系統耦合
系統之間 的 相互呼叫採用的 jsf 服務,全部是同步呼叫,呼叫鏈路很長,一個環節出問題會導致整個系統都出問題,沒有核心服務和非核心服務、沒有非同步化服務。
-
公用資料庫問題
由於前期是按業務線進行劃分,在一個業務線上,核心服務的資料都儲存在一個數據庫上面。
3)服務問題改進
-
第一步拆分 , 將各個業務線的的服務拆分成小服務。
-
第二 步 拆分 , 組 合第一步抽取的服務,形成公共服務,以後所有業務線都請求這些公共服務,提高服務的複用性。
4)測試方案
-
配置(人工)
-
採集資料(自動)
-
分發請求(自動)
-
資料對比(自動)
-
核對(人工)
條件 :新老服務的對外介面引數不變
5)系統耦合改進
系統耦合的問題,通過引入 jmq 訊息中介軟體進行解決。訊息無序的問題,採用樂觀鎖進行解決,主要是依靠資料的版本對比來解決。
6)資料庫改進
資料公用的問題,解決方案還是進行拆分:
-
第一步 , 將各個業務系統 SOA 服務的資料,單獨儲存在自己的資料庫,訂單有訂單專門的資料庫、商品有商品專門的資料庫,服務之間互相不受影響。
-
第二步 , 在第一個步拆分後,有的業務資料量單表數量還是很大,需要對錶進行拆分,我們採用 jproxy(不支援分表)進行分庫,按業務的相關主鍵 id,進行 hash(id)%count(分庫數量),支援水平擴充套件。
擴充套件:
-
還有那些分佈演算法方式: ID 區間演算法、時間區間
-
熱點資料: 二次 hash
-
事務: 弱化強一致性,採用訊息的機制進行互動,實現最終一致性。
-
垮庫查詢:分散式查詢
7)分散式搜尋
分散式查詢,採用的是 elasticSearch 搜尋進行支援,簡稱es。
-
訊息同步才用 jmq 和 binlog
-
如果 es 叢集有問題,採用的方式是備份叢集支援服務(資料有延遲風險)
0 2
業務架構2.0
1)架構
在1.0的基礎上,做如下三點調整:
-
服務層抽取公共服務
-
引入基礎層的工具
-
儲存層分庫分表
2)問題
2.0系統在2017年進入第三階段後,開始面臨以下兩個問題:
-
平臺化服務業務程式碼臃腫
-
個性化需求的重複開發
3)思考
舉一個例子,我們現在有「訂單」、「價格」、「商品」服務, A 使用者需要訂單服務,B 使用者需要訂單、價格服務,C 使用者需要訂單、價格、商品服務。現在的做法是開發3套業務介面服務,底層的服務是通用的,但是業務層的程式碼有重複開發、業務程式碼臃腫的問題。
我們該怎麼做?
引入配置中心
-
對服務進行配置
-
對頁面進行配置
-
可以自定義外掛服務
4)元件
通過以上的思考,我們有了元件的思想,以後對外的服務都是可配置的。就像一個加工廠,對服務加工,就可以對外部業務進行使用。
03
業務架構3.0
3.0的版本主要是修改,包含服務層的抽取、業務和 SOA 分離,同時引入業務和工具元件。
總 結
B2B業務架構經過3次變遷與升級,我們總結到以下經驗:
------------------END ------------------
下面的內容同樣精彩
點選圖片即可閱讀
京東技術
---關注技術的公眾號
長按識別二維碼關注