淘寶技術架構分享

一,淘寶技術架構

 1.UIC: 用戶中心(User Interface Center),提供所有用戶信息相關的讀寫服務,如基本信息,擴展信息,社區信息,買賣家信用等級等等。
淘寶現在有兩類賣家B 和C,這是通過在用戶身上打不同的標籤實現的,我們這次的無名良品賣家也是通過在用戶身上打特殊的標籤來區別於淘寶
已有的B 和C類賣家。淘寶的TOP平臺已經開放了大部分的UIC接口。
 2.IC:商品中心(Item Center),提供所有商品信息的讀寫服務,比如新發商品,修改商品,刪除商品,前後臺讀取商品相關信息等等,IC 是
淘寶比較心的服務模塊,有專門的產品線負責這塊內容,IC相關接口在TOP中佔的比重也比較大。
3.SC:店鋪中心(Shop Center),類似中文站的旺鋪,不過淘寶的SC不提供頁面級應用,提供的都是些遠程的服務化的接口,提供店鋪相關信
息的讀寫操作。 如:開通店鋪,店鋪首頁,及detail頁面店鋪相關信息獲取,如店內類目,主營,店鋪名稱,店鋪級別:如普通,旺鋪,拓展版,
旗艦版等等。裝修相關的業務是SC中佔比重較大的一塊,現在慢慢的獨立爲一個新的服務化中心DC(design center),很多的前臺應用已經通過直
接使用DC提供的服務化接口直接去裝修相關的信息。
ABTN

4.TC:交易中心(Trade Center),提供從創建交易到確認收貨的正 向交易流程服務,也提供從申請退款到退款完成的反向交易流程服務.
5.PC:促銷中心(Promotion Center),提供促銷產品的訂購,續費,查詢,使用相關的服務化接口,如:訂購和使用旺鋪,滿就送,限時秒
殺,相冊,店鋪統計工具等等。

6.Forest:淘寶類目體系:提供淘寶前後臺類目的讀寫操作,以及前後臺類目的關聯操作。
7.Tair:淘寶的分佈式緩存方案,和中文站的Memcached 很像。其實也是對memcached 的二次封裝加入了淘寶的一些個性化需求。
8.TFS:淘寶分佈式文件存儲方案(TB File System),專門用戶處理靜態資源存儲的方案,淘寶所有的靜態資源,如圖片,HTML 頁面,文本
文件,頁面大段的文本內容如:產品描述,都是通過TFS存儲的。具體設計和優缺點會在下面詳細介紹。
9.TDBM:淘寶DB 管理中心(TB DB Manager), 淘寶數據庫管理中心,提供統一的數據讀寫操作,具體設計在下面詳細介紹。
10.RC:評價中心(Rate center),提供評價相關信息的讀寫服務,如評價詳情,DSR 評分等信息的寫度服務。
 11.HSF:淘寶的遠程服務調用框架和平臺的Dubbo功能類似,不過部署方式上有較大差異,所有的服務接口都通過對應的註冊中心(config
center)獲取。  

 2.淘寶服務化架構:

用戶

淘寶用戶分兩類:買家和賣家,不過很多的賣家也會在淘寶買東西,所以他們既是賣家也是買家,因此最好是按照用戶行爲分:賣家行爲和買家行爲。買賣家行爲都會涉及的系統包括:店鋪,商城,交易,商品,社區等等。涉及到的功能有較大差異:
客戶(賣和買)
店鋪 商城 社區 商品 交易 無線 無名良品 前臺系統:直接和用戶打交道,它們依賴於各種心業務中心提供的服務化接口,淘寶服務 化 做的比較早,相對B2B來說比較成熟,這種高度服務化的方式有三點好處:

(1)搭建新應用很敏捷,所需要做的就是:整理業務流à 組裝服務化接口à 渲染頁面

(2)增強應用健壯性,只要保證服務化接口的穩定性容災性,前臺應用調用基本都不會有大的故障

(3)服務化接口把類似的業務接口抽象的很純粹,使得性能觀察和優化更有針對性,更專注!
SC[店鋪中心]DC[裝修中心 ]
TC[交易中心]UIC[用戶中心 ]
RC[評價中心]
PC[促銷中心]
Forest[類目體系]
IC[商品中心]
HSF[遠程調用框架]

Tair[分佈式 cache]

TDBM[數據庫管理]

TFS[分佈式存儲]

Config[註冊中心]
基礎服務:提供最基礎的共享服務,這些服務中心提供的功能基本與業務無關。 基本上這些服務在B2B都有,只是名字不一而已,大體的功能也類似,不過實現方 式有差異,會在下面具體做介紹。
商城搜索集市搜索 SPU搜索 實時搜索
搜索服務:提供前臺和後臺系統搜索服務

1.來源:數據主要來自上面的心業務服務接口,由業務接口通過tddl(淘寶的數據庫分庫架構類似 B2B的corba)同步數據到DB(oracle&mysql),然後dump數據到搜索。

2.去處:包括兩方面:前臺—集市搜索,spu搜索,商城搜索,社區搜索等 後臺--crm實時搜索,類目List等
核心業務服務:提供各種心業務模塊的服務化接口,接口按使用方式分兩類:

(1)通過HSF方式調用的遠程服務化接口

(2)通過定期推送服務端數據文件到客戶端的CS調用 圖中:藍色標註的系統的部分接口使用第二中方式調用,其他系統基本都是基於HSF方式的遠程調用。
….
(1)賣家行爲:主要定位在個人後臺,且主要定位在後臺的“我是賣家”TAB 頁下的功能,包括:店鋪管理,商品管理,訂單管理,服務訂
購和使用,廣告系統,社區發帖,淘寶客等等,前臺瀏覽相對使用較少。

(2)買家行爲:集中在前臺:店鋪瀏覽,寶貝的瀏覽,社區瀏覽等比重較大,買家後臺功能主要定位在後臺的“我是買家”Tab 頁下,包括拍
商品,付款,確認,退款,評價,社區互動等。
產品:淘寶對產品定義和 B2B 有差別,淘寶的業務拆分較細,服務化做的較成熟,所以前臺應用對應的業務非常純粹,如 Detail 系統可
能就一個 detail 頁面,無數據庫連接,所有數據來自底層的各種服務化中心,功能專一邏輯清晰純粹,不過也正因爲這,淘寶的一個產品
可能是分佈在多個應用系統中,單個應用很難稱爲一個產品。
淘寶更喜歡用產品線的概念,往往是一個團隊負責一條產品線,跨幾個功能純粹的應用, 如:商品線 交易線 店鋪線 江湖線 商城線等。

二.淘寶服務化進程

 羅馬非一日建成,上面看到的相對成熟的服務化中心也是在淘寶業在務發展過程中不斷的遇到問題,解決問題的過程中沉澱下來的,下面給
大家簡單圖示下淘寶的服務化進程:  
  I.最初的淘寶應用架構狀況:業務高度耦合,不同的功能模塊基本都糅合在一個系統中,錯綜複雜,很有exodus2當初的味道啊!

2 II.隨着業務發展,抽提部分核心業務之後的狀態

對前臺業務做了切分,抽提了部分核心業務成爲獨立的服務化提供中心。不過抽提的
業務較少,這個階段缺少對不同層的針對性優化,比如監控,容災,事務等等

 III.大規模使用HSF服務化相對成熟之後的狀況

前端應用高度分化,拆分成一個個功能單一的應用系統,後端服務化接口也劃分的較
細同時針對不同業務和具體的技術實現做個性化優化,增強了各個節點的健壯性,高效性。

  通過上面的幾張圖可以明顯的看出服務化給整個系統架構帶來的好處: 

(1) 應用間的耦合降低,在服務化接口成熟的情況下,擴展新的業務需求變得方便,主要就是一個組合服務化接口的過程。
(2) 開發人員可以專心關注業務,而不用考慮分佈式領域中的各種細節技術,例如遠程通訊、性能損耗、調用的透明化、同步/異步調
用方式的實現等等問題。
(3) 各個系統負責的業務更純粹,方便做針對新的性能調優和功能改進:如容災性,併發,監控等方面的優化。這種針對性有助於增強
系統的高性能,高健壯。

三,淘寶服務化利器--HSF
  前臺應用和心業務層由於和業務結合比較緊密,篇幅限制這裏就不展開講了,後續會有針對各個細節業務和技術的分享,下面主要說說服務化
中最重要的基礎技術架構:HSF(淘寶遠程服務調用框架),並附實例做說說它們的使用方式。

(1) HSF是神馬? [High-Speed Service Framework] 淘寶的高速遠程調用框架,類似中文站的 Dubbo,基於 Mina 框架開發,它是淘寶應用從集中式走入
大型分佈式的基礎支撐。使開發人員無需過多的關注應用是集中式的,還是分佈式的,可以更加專注於應用的業務需求的實現,這些純技術
的需求都由HSF 來解決。

(2)HSF的系統架構       I. HSF交互場景圖
客戶端(消費端)從配置中心獲取服務端地址列表—>和服務端建立連接開始遠程調用—>服務端更新通過 notify(類似 B2B 的 naplio)
系統通知客戶端。服務端和客戶端都有對應的監控中心,實時監控服務狀態。客戶端,配置中心,服務端,notify,之間的通信都是通過TB Remotion
API 去搞定的。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章