作者:李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次變遷與升級,我們總結到以下經驗:
閱讀更多 Java面經 的文章