淘寶開放平臺簡介
51CTO年終策劃《開放平臺，你的選擇》
一、什么是淘寶開放平臺
淘寶開放平臺（Taobao Open Platform）是基于淘寶各類電子商務(wù)業(yè)務(wù)的開放平臺，提供外部合作伙伴參與服務(wù)淘寶用戶的各類原材料，例如API、賬號體系、數(shù)據(jù)安全等。她是大淘寶電子商務(wù)基礎(chǔ)服務(wù)的重要開放途徑，將推動各行各業(yè)定制、創(chuàng)新、進化，并最終促成新商業(yè)文明生態(tài)圈的建立。我們的使命是把淘寶網(wǎng)的商品、用戶、交易、物流等一系列電子商務(wù)基礎(chǔ)服務(wù)，像水、電、煤一樣輸送給有需要的商家、開發(fā)者、社區(qū)媒體和各行各業(yè)。
二、平臺特點
業(yè)務(wù)母體強大、商機無限：
淘寶開放平臺所依托的母體淘寶網(wǎng)，擁有注冊用戶數(shù)以億級的買家和上百萬賣家，每日近15億的交易額，淘寶會員需求的多樣性和淘寶業(yè)務(wù)需求的多樣性為各類合作伙伴提供了大量的商業(yè)機會。
開放規(guī)模大、程度深、限制少：
淘寶開放平臺為外部合作伙伴提供了極大的商業(yè)想象空間——截至2011年6月，對外開放的 API近300個，涵蓋了淘寶核心交易和各項垂直業(yè)務(wù)的主要流程，API日均調(diào)用量超過10億次/天。無論是從業(yè)務(wù)開放的廣度和深度，淘寶開放平臺都是國內(nèi)開放業(yè)務(wù)規(guī)模最大的開放平臺。同時，淘寶開放平臺形式自由——不限語言、不限平臺（支持瀏覽器、桌面）、不限使用場所（除了淘寶自身網(wǎng)站外，鼓勵和支持外部所有網(wǎng)站使用淘寶開放平臺服務(wù)）。
盈利模式清晰：
淘寶開放平臺為各類應(yīng)用提供了清晰的盈利模式，如應(yīng)用銷售分成、淘寶客成交抽傭、淘寶客工具分成、P4P廣告分成等，并且還會根據(jù)合作伙伴反饋，不斷提供更多更靈活的盈利模式，全力支持各合作伙伴不斷地成長和壯大。
合作形式豐富：
淘寶開放平臺是基于電子商務(wù)業(yè)務(wù)的綜合開放平臺，除了基本的流量平臺特點之外，還有豐富的電子商務(wù)業(yè)務(wù)。因此，將業(yè)務(wù)開放到盡可能多的領(lǐng)域是淘寶開放平臺的宗旨。目前，已經(jīng)為合作伙伴提供了10類以上的合作形式，包括商家系統(tǒng)、賣家應(yīng)用、買家應(yīng)用、淘寶客應(yīng)用、無線應(yīng)用等。
三、到 TOP 能做什么？
《大淘寶宣言》指出，合作伙伴是新商業(yè)文明中極其重要的新興力量，由各類合作伙伴組成的“大淘寶”生態(tài)系統(tǒng)也是新商業(yè)文明的主要結(jié)構(gòu)與功能單位。合作伙伴通過與經(jīng)營者、消費者及交易平臺的緊密合作，使經(jīng)營者的服務(wù)更高效、更專業(yè)、更經(jīng)濟，使消費者的購物更便捷、更愉悅、更完美。從淘寶開放平臺的特點來看，能支持的業(yè)務(wù)方向可以分成賣家服務(wù)和買家服務(wù)兩類，而具體實現(xiàn)的功能和服務(wù)類型非常多，這些只局限于各自的想象力。
無論您是第三方開發(fā)者（ISV）、傳統(tǒng)軟件廠商、行業(yè)型網(wǎng)站或者大商家，都能基于淘寶開放平臺找到適合自己的業(yè)務(wù)方向。
賣家服務(wù)：
我們提供的豐富API涵蓋淘寶各個核心業(yè)務(wù)流程，基于這些內(nèi)容可以為賣家提供各類應(yīng)用，解決店鋪管理、營銷推廣、數(shù)據(jù)分析等方面的問題。淘寶開放平臺還基于商家所需的電子商務(wù)后臺系統(tǒng)，提供解決方案。如果您是富有企業(yè)信息系統(tǒng)開發(fā)經(jīng)驗的傳統(tǒng)軟件廠商，您可以基于淘寶開放平臺為商家提供包括但不限于BI、ERP、DRP、CRM、SCM 等。淘寶開放平臺還為各種應(yīng)用提供了清晰的盈利模式。通過服務(wù)市場的應(yīng)用銷售分成、軟件直接銷售收入等獲得回報。
買家服務(wù)：
淘寶數(shù)億消費者，越來越需要各種個性化、專業(yè)化的服務(wù)，幫助他們方便地購物，以及解決各類生活服務(wù)需求。從導(dǎo)購、健康、娛樂、興趣、交友等方方面面，構(gòu)建自由的買家應(yīng)用。各個專業(yè)的類目，也吸引著各行業(yè)的專業(yè)團隊深入合作，為消費者打造最佳體驗，而通過導(dǎo)購交易成交抽傭，已經(jīng)成為一種有效的盈利模式。
#p#
淘寶開放平臺（TaoBao Open Platform，簡稱TOP）的整個架構(gòu)體系是組件化體系架構(gòu)，可以是很少的幾個基礎(chǔ)組件構(gòu)成的Skeleton，也可以是融入了商業(yè)想象的Amazing Architecture。這里就通過對于這些組件的羅列，描述出在TOP這個大體系中，各個組件所處的地位及作用。TOP的“兵器譜”是在現(xiàn)階段商業(yè)需求及平臺非業(yè)務(wù)性需求指導(dǎo)下形成的，未來TOP將繼續(xù)發(fā)展，“兵器譜”也會不斷演進。
下圖是整個TOP當前的一個組件結(jié)構(gòu)圖：
圖中，紅色虛線就是TOP的Skeleton。TOP當前從業(yè)務(wù)模塊功能角度來劃分，可以分成三個層次：基礎(chǔ)平臺組件層，基礎(chǔ)業(yè)務(wù)組件層，普通業(yè)務(wù)組件層。基礎(chǔ)平臺組件層，傾向于平臺級別功能滿足及對平臺穩(wěn)定性，可用性的支持。基礎(chǔ)業(yè)務(wù)組件層，是介于平臺服務(wù)于普通業(yè)務(wù)服務(wù)之間的組件，部分利用了平臺基礎(chǔ)組件層的組件，來抽象出一層公用業(yè)務(wù)服務(wù)組件，為業(yè)務(wù)組件提供通用的基礎(chǔ)支持。
安全組件
安全組件主要從四個角色去考慮整體的安全策略及具體的實施方案，這四個角色是：用戶，應(yīng)用，平臺，服務(wù)。
平臺本身的安全主要是基于在大并發(fā)和大流量的情況下，保證平臺自身穩(wěn)定性和可用性，同時也要兼顧在平臺開放的服務(wù)不相互干擾和影響。因此采取服務(wù)分流隔離機制，通過虛擬配置及軟負載方式將服務(wù)請求動態(tài)分流和隔離，保證了服務(wù)之間相互的獨立性，同時也充分利用TOP的能力。頻率控制及流量控制除了保護TOP自身不受到攻擊，也為后端服務(wù)提供者作了天然的一個保護屏障，保證服務(wù)請求壓力可以在TOP上可控，防止流量直接壓倒服務(wù)提供者。用戶隱私安全在淘寶尤為重要，用戶信息的安全性也在淘寶開放的過程中被放到了首位。在開放平臺設(shè)計中，除了采用普通開放平臺的認證模式以外（OAuth類似流程），還在服務(wù)調(diào)用過程中通過區(qū)分應(yīng)用角色來限制對于用戶信息的獲取和使用。同時針對不同的應(yīng)用類型（插件，Web應(yīng)用，客戶端應(yīng)用，手機應(yīng)用）都有各自不同的用戶授權(quán)方式，保證用戶的知情權(quán)。App的安全其實也是為了保證對服務(wù)的請求及對用戶信息的獲取不被不法的應(yīng)用信息盜取者所利用，根據(jù)應(yīng)用角色及自己對于安全的需求，采取多種方式或者組合的方式來實現(xiàn)App信息的保密性，保護App自身安全，也保證了平臺服務(wù)的數(shù)據(jù)安全。服務(wù)安全指的是對于服務(wù)來說分成了幾個層級，不同層級的服務(wù)對于安全級別的要求不同（不需要交驗應(yīng)用身份，需要交驗應(yīng)用身份，需要用戶授權(quán)，用戶可選擇授權(quán)等），在應(yīng)用訪問服務(wù)的時候，就會需要根據(jù)服務(wù)級別的不同采用不同的訪問控制流程。根據(jù)上述的四個角色對于安全的考慮，通過應(yīng)用角色的定義，服務(wù)虛擬組的編排，黑名單（頻率控制及流量控制），多模式用戶令牌等手段，形成了多種模式的安全控制流程。
服務(wù)路由組件
服務(wù)路由是開放平臺最基本的功能，如果排除商業(yè)因素，那么對于TOP最基本上來看可以看作一個服務(wù)路由器，服務(wù)路由主要的功能如下圖展示：
服務(wù)路由組件需要支持多服務(wù)類型的服務(wù)接入，不同服務(wù)類型主要表現(xiàn)在兩個維度：1.服務(wù)對外的展現(xiàn)方式（REST OR RPC），這兩種形態(tài)的服務(wù)沒有任何好壞之分，只是根據(jù)各自的系統(tǒng)形態(tài)來選擇采用哪一種模式來對外暴露，RPC比較符合過去應(yīng)用開放的風格，REST比較適合面向資源的架構(gòu)。同時對于同步，異步，通知，大數(shù)據(jù)量的服務(wù)，都會有不同的接入方式和調(diào)用方式支持，滿足各種業(yè)務(wù)場景的需求。多通信協(xié)議支持，表示服務(wù)請求到了TOP以后，TOP負責將請求繼續(xù)發(fā)送給服務(wù)提供者，不論服務(wù)提供者采用什么方式和TOP交互，最終將得到的結(jié)果返回給客戶，服務(wù)調(diào)用者將會對后端的服務(wù)請求過程透明，同時可以使TOP很容易接入一些傳統(tǒng)遺留系統(tǒng)的服務(wù)，或者是對通信有特殊需求的服務(wù)。特性支持主要是會有對內(nèi)容的一些特殊處理，例如壓縮，在CS或者手機應(yīng)用交互過程中，就會需要對數(shù)據(jù)量有所壓縮，滿足業(yè)務(wù)需求。
監(jiān)控告警組件
下圖是監(jiān)控告警組件的基本功能圖
監(jiān)控和告警模塊在TOP中起到越來越重要的作用，訪問量逐日膨脹，運行期TOP是一個黑盒，無法知曉當前系統(tǒng)實際的健康狀況，當出現(xiàn)問題以后比較難以定位。服務(wù)監(jiān)控主要是服務(wù)質(zhì)量（響應(yīng)時間），短時間段內(nèi)的服務(wù)請求峰值，和階段性的趨勢。系統(tǒng)和平臺主要是對底層基礎(chǔ)組件的監(jiān)控，同時及時地通知TOP負責人處理線上即將要發(fā)生的事情。對于應(yīng)用的監(jiān)控通常就是從客戶端和服務(wù)端兩面對于應(yīng)用當前的情況作匯總分析。當監(jiān)控發(fā)現(xiàn)異常以后，就交由告警部分按照一定的發(fā)送策略給相關(guān)的負責人，在第一時間將問題解決。
日志組件
日志組件和其他系統(tǒng)的日志組件基本沒有太大的區(qū)別，只是在對于海量數(shù)據(jù)寫出和獲取的方法做了優(yōu)化（例如異步分頁批量輸出等）。日志組件主要負責，打點，收集，分析，數(shù)據(jù)庫記錄，歸檔。
協(xié)議轉(zhuǎn)換組件
這里談到的協(xié)議轉(zhuǎn)換指的是對于請求和返回的協(xié)議，TOP可以做適配，來滿足服務(wù)調(diào)用者和服務(wù)發(fā)布者之間在服務(wù)協(xié)議失配的情況下還是能夠正常通信。當前支持JSON,XML,Atom,二進制協(xié)議之間的轉(zhuǎn)換，當然轉(zhuǎn)換描述文檔將會配置在TOP。同時返回的數(shù)據(jù)內(nèi)容，也可以通過協(xié)議轉(zhuǎn)換，返回給客戶端常規(guī)的xml或者json類型的數(shù)據(jù)。
服務(wù)流程化組件
服務(wù)流程化指的是將離散的服務(wù)通過流程描述文檔能夠虛擬的串聯(lián)成為一個新的服務(wù)，這樣更加適合調(diào)用者使用，同時將服務(wù)的一些內(nèi)部邏輯隱藏起來。這很類似于SOA中的服務(wù)編排，同時也可以參看Yahoo的Pipe，那就是一種典型的服務(wù)串聯(lián)，同時還提供了方便的界面直接交由用戶通過手動拖拉的方式來使用服務(wù)串聯(lián)。
服務(wù)流程化最大的特點就是將不同類型的服務(wù)能夠根據(jù)業(yè)務(wù)場景的需求組合成簡單的流程性服務(wù)，極大降低了服務(wù)開發(fā)者由于對服務(wù)流程不熟悉而犯錯的幾率，同時也為服務(wù)開發(fā)者提高了開發(fā)效率。
計費組件
當前計費模型主要是按流量收費和插件分成兩種模式，因此計費組件還比較簡單，當前就是基于日志做分析，未來會考慮在流量上的各種特殊模式（打包，優(yōu)惠等等）。
容器組件（TBML）
產(chǎn)生原因：
- 數(shù)據(jù)隱私性
- 開發(fā)便利性
- 業(yè)務(wù)升級透明化
- 監(jiān)控全局化
- 開發(fā)標準化
作用：
- 數(shù)據(jù)操作可控，保護終端用戶隱私（結(jié)合cookie和標簽，控制ISV業(yè)務(wù)數(shù)據(jù)操作尺度，提高數(shù)據(jù)安全性）
- 提供標準業(yè)務(wù)流程標簽，簡化開發(fā)者對于業(yè)務(wù)流程理解過程。
- 標簽化接口方式，完成數(shù)據(jù)獲取和頁面渲染，后臺業(yè)務(wù)升級對ISV透明化。
- 標簽獲取客戶端信息，將監(jiān)控擴展到整個業(yè)務(wù)請求過程。制定行業(yè)化標簽庫，形成統(tǒng)一開發(fā)標準。
TBML首先需要根據(jù)業(yè)務(wù)需求及場景定義出對應(yīng)的標簽庫，也就是制定Taobao的標簽標準，最簡單的獲取用戶信息標簽，到最復(fù)雜的業(yè)務(wù)操作流程標簽都會成為標簽庫中的一部分。同時在服務(wù)端需要有解釋引擎來翻譯標簽，解釋引擎一方面需要去了解標簽內(nèi)容和含義，同時需要請求后臺多個API，串聯(lián)成為流程化的服務(wù)，從應(yīng)用的輸入，得到最后的輸出，當然期間也需要處理異常的情況。最后還需要關(guān)注的就是安全控制，在交驗標簽傳遞來的數(shù)據(jù)時，需要對數(shù)據(jù)作完整性及合法性的交驗，防止通過標簽數(shù)據(jù)的特殊性攻擊后臺服務(wù)接口。
TBQL組件
TBQL其實是一種服務(wù)調(diào)用的方式，也是通過一種程序員和開發(fā)者習(xí)慣的方式，將對資源的REST請求轉(zhuǎn)換成一種類似QL的請求，對于面向資源性的架構(gòu)體系來說是十分有利的。同時對于API來說，使用者會更加自然的去采用連接和過濾得方式得到需要的數(shù)據(jù)。
QL解釋引擎負責對于TBQL的翻譯工作，數(shù)據(jù)存儲的MetaData保存在數(shù)據(jù)庫中，可以指導(dǎo)QL解釋引擎翻譯。需要支持不同數(shù)據(jù)來源的連接和過濾，在獲得結(jié)果以后需要做格式轉(zhuǎn)換返回給服務(wù)調(diào)用者（通常就是xml）。與容器一樣，需要著重考慮安全性問題，對于傳統(tǒng)的SQL注入就是典型攻擊QL系統(tǒng)的案例，需要謹慎處理解析中對于字符的翻譯工作。在流程中出現(xiàn)異常，需要制定策略來判斷是否直接返回錯誤還是支持部分容錯。
TOPID組件
TOPID組件有點類似于Facebook的Connect，需要在淘寶和淘寶的合作開發(fā)者之間建立起雙向的用戶互通的標準和流程，同時也為服務(wù)互通打好基礎(chǔ)，畢竟業(yè)務(wù)的互動需要基于可以互通的用戶體系。
