下圖是整個(gè)TOP當(dāng)前的一個(gè)組件結(jié)構(gòu)圖：

圖中，紅色虛線就是TOP的Skeleton。TOP當(dāng)前從業(yè)務(wù)模塊功能角度來(lái)劃分，可以分成三個(gè)層次：基礎(chǔ)平臺(tái)組件層，基礎(chǔ)業(yè)務(wù)組件層，普通業(yè)務(wù)組件層。基礎(chǔ)平臺(tái)組件層，傾向于平臺(tái)級(jí)別功能滿足及對(duì)平臺(tái)穩(wěn)定性，可用性的支持。基礎(chǔ)業(yè)務(wù)組件層，是介于平臺(tái)服務(wù)于普通業(yè)務(wù)服務(wù)之間的組件，部分利用了平臺(tái)基礎(chǔ)組件層的組件，來(lái)抽象出一層公用業(yè)務(wù)服務(wù)組件，為業(yè)務(wù)組件提供通用的基礎(chǔ)支持。

安全組件

安全組件主要從四個(gè)角色去考慮整體的安全策略及具體的實(shí)施方案，這四個(gè)角色是：用戶，應(yīng)用，平臺(tái)，服務(wù)。

平臺(tái)本身的安全主要是基于在大并發(fā)和大流量的情況下，保證平臺(tái)自身穩(wěn)定性和可用性，同時(shí)也要兼顧在平臺(tái)開(kāi)放的服務(wù)不相互干擾和影響。因此采取服務(wù)分流隔離機(jī)制，通過(guò)虛擬配置及軟負(fù)載方式將服務(wù)請(qǐng)求動(dòng)態(tài)分流和隔離，保證了服務(wù)之間相互的獨(dú)立性，同時(shí)也充分利用TOP的能力。頻率控制及流量控制除了保護(hù)TOP自身不受到攻擊，也為后端服務(wù)提供者作了天然的一個(gè)保護(hù)屏障，保證服務(wù)請(qǐng)求壓力可以在TOP上可控，防止流量直接壓倒服務(wù)提供者。用戶隱私安全在淘寶尤為重要，用戶信息的安全性也在淘寶開(kāi)放的過(guò)程中被放到了首位。在開(kāi)放平臺(tái)設(shè)計(jì)中，除了采用普通開(kāi)放平臺(tái)的認(rèn)證模式以外（OAuth類(lèi)似流程），還在服務(wù)調(diào)用過(guò)程中通過(guò)區(qū)分應(yīng)用角色來(lái)限制對(duì)于用戶信息的獲取和使用。同時(shí)針對(duì)不同的應(yīng)用類(lèi)型（插件，Web應(yīng)用，客戶端應(yīng)用，手機(jī)應(yīng)用）都有各自不同的用戶授權(quán)方式，保證用戶的知情權(quán)。App的安全其實(shí)也是為了保證對(duì)服務(wù)的請(qǐng)求及對(duì)用戶信息的獲取不被不法的應(yīng)用信息盜取者所利用，根據(jù)應(yīng)用角色及自己對(duì)于安全的需求，采取多種方式或者組合的方式來(lái)實(shí)現(xiàn)App信息的保密性，保護(hù)App自身安全，也保證了平臺(tái)服務(wù)的數(shù)據(jù)安全。服務(wù)安全指的是對(duì)于服務(wù)來(lái)說(shuō)分成了幾個(gè)層級(jí)，不同層級(jí)的服務(wù)對(duì)于安全級(jí)別的要求不同（不需要交驗(yàn)應(yīng)用身份，需要交驗(yàn)應(yīng)用身份，需要用戶授權(quán)，用戶可選擇授權(quán)等），在應(yīng)用訪問(wèn)服務(wù)的時(shí)候，就會(huì)需要根據(jù)服務(wù)級(jí)別的不同采用不同的訪問(wèn)控制流程。根據(jù)上述的四個(gè)角色對(duì)于安全的考慮，通過(guò)應(yīng)用角色的定義，服務(wù)虛擬組的編排，黑名單（頻率控制及流量控制），多模式用戶令牌等手段，形成了多種模式的安全控制流程。

服務(wù)路由組件

服務(wù)路由是開(kāi)放平臺(tái)最基本的功能，如果排除商業(yè)因素，那么對(duì)于TOP最基本上來(lái)看可以看作一個(gè)服務(wù)路由器，服務(wù)路由主要的功能如下圖展示：

服務(wù)路由組件需要支持多服務(wù)類(lèi)型的服務(wù)接入，不同服務(wù)類(lèi)型主要表現(xiàn)在兩個(gè)維度：1.服務(wù)對(duì)外的展現(xiàn)方式（REST OR RPC），這兩種形態(tài)的服務(wù)沒(méi)有任何好壞之分，只是根據(jù)各自的系統(tǒng)形態(tài)來(lái)選擇采用哪一種模式來(lái)對(duì)外暴露，RPC比較符合過(guò)去應(yīng)用開(kāi)放的風(fēng)格，REST比較適合面向資源的架構(gòu)。同時(shí)對(duì)于同步，異步，通知，大數(shù)據(jù)量的服務(wù)，都會(huì)有不同的接入方式和調(diào)用方式支持，滿足各種業(yè)務(wù)場(chǎng)景的需求。多通信協(xié)議支持，表示服務(wù)請(qǐng)求到了TOP以后，TOP負(fù)責(zé)將請(qǐng)求繼續(xù)發(fā)送給服務(wù)提供者，不論服務(wù)提供者采用什么方式和TOP交互，最終將得到的結(jié)果返回給客戶，服務(wù)調(diào)用者將會(huì)對(duì)后端的服務(wù)請(qǐng)求過(guò)程透明，同時(shí)可以使TOP很容易接入一些傳統(tǒng)遺留系統(tǒng)的服務(wù)，或者是對(duì)通信有特殊需求的服務(wù)。特性支持主要是會(huì)有對(duì)內(nèi)容的一些特殊處理，例如壓縮，在CS或者手機(jī)應(yīng)用交互過(guò)程中，就會(huì)需要對(duì)數(shù)據(jù)量有所壓縮，滿足業(yè)務(wù)需求。

監(jiān)控告警組件

下圖是監(jiān)控告警組件的基本功能圖

監(jiān)控和告警模塊在TOP中起到越來(lái)越重要的作用，訪問(wèn)量逐日膨脹，運(yùn)行期TOP是一個(gè)黑盒，無(wú)法知曉當(dāng)前系統(tǒng)實(shí)際的健康狀況，當(dāng)出現(xiàn)問(wèn)題以后比較難以定位。服務(wù)監(jiān)控主要是服務(wù)質(zhì)量（響應(yīng)時(shí)間），短時(shí)間段內(nèi)的服務(wù)請(qǐng)求峰值，和階段性的趨勢(shì)。系統(tǒng)和平臺(tái)主要是對(duì)底層基礎(chǔ)組件的監(jiān)控，同時(shí)及時(shí)地通知TOP負(fù)責(zé)人處理線上即將要發(fā)生的事情。對(duì)于應(yīng)用的監(jiān)控通常就是從客戶端和服務(wù)端兩面對(duì)于應(yīng)用當(dāng)前的情況作匯總分析。當(dāng)監(jiān)控發(fā)現(xiàn)異常以后，就交由告警部分按照一定的發(fā)送策略給相關(guān)的負(fù)責(zé)人，在第一時(shí)間將問(wèn)題解決。

日志組件

日志組件和其他系統(tǒng)的日志組件基本沒(méi)有太大的區(qū)別，只是在對(duì)于海量數(shù)據(jù)寫(xiě)出和獲取的方法做了優(yōu)化（例如異步分頁(yè)批量輸出等）。日志組件主要負(fù)責(zé)，打點(diǎn)，收集，分析，數(shù)據(jù)庫(kù)記錄，歸檔。

協(xié)議轉(zhuǎn)換組件

這里談到的協(xié)議轉(zhuǎn)換指的是對(duì)于請(qǐng)求和返回的協(xié)議，TOP可以做適配，來(lái)滿足服務(wù)調(diào)用者和服務(wù)發(fā)布者之間在服務(wù)協(xié)議失配的情況下還是能夠正常通信。當(dāng)前支持JSON,XML,Atom,二進(jìn)制協(xié)議之間的轉(zhuǎn)換，當(dāng)然轉(zhuǎn)換描述文檔將會(huì)配置在TOP。同時(shí)返回的數(shù)據(jù)內(nèi)容，也可以通過(guò)協(xié)議轉(zhuǎn)換，返回給客戶端常規(guī)的xml或者json類(lèi)型的數(shù)據(jù)。

服務(wù)流程化組件

服務(wù)流程化指的是將離散的服務(wù)通過(guò)流程描述文檔能夠虛擬的串聯(lián)成為一個(gè)新的服務(wù)，這樣更加適合調(diào)用者使用，同時(shí)將服務(wù)的一些內(nèi)部邏輯隱藏起來(lái)。這很類(lèi)似于SOA中的服務(wù)編排，同時(shí)也可以參看Yahoo的Pipe，那就是一種典型的服務(wù)串聯(lián)，同時(shí)還提供了方便的界面直接交由用戶通過(guò)手動(dòng)拖拉的方式來(lái)使用服務(wù)串聯(lián)。

服務(wù)流程化最大的特點(diǎn)就是將不同類(lèi)型的服務(wù)能夠根據(jù)業(yè)務(wù)場(chǎng)景的需求組合成簡(jiǎn)單的流程性服務(wù)，極大降低了服務(wù)開(kāi)發(fā)者由于對(duì)服務(wù)流程不熟悉而犯錯(cuò)的幾率，同時(shí)也為服務(wù)開(kāi)發(fā)者提高了開(kāi)發(fā)效率。

計(jì)費(fèi)組件

當(dāng)前計(jì)費(fèi)模型主要是按流量收費(fèi)和插件分成兩種模式，因此計(jì)費(fèi)組件還比較簡(jiǎn)單，當(dāng)前就是基于日志做分析，未來(lái)會(huì)考慮在流量上的各種特殊模式（打包，優(yōu)惠等等）。

容器組件（TBML）

產(chǎn)生原因：

• 數(shù)據(jù)隱私性
• 開(kāi)發(fā)便利性
• 業(yè)務(wù)升級(jí)透明化
• 監(jiān)控全局化
• 開(kāi)發(fā)標(biāo)準(zhǔn)化

作用：

• 數(shù)據(jù)操作可控，保護(hù)終端用戶隱私（結(jié)合cookie和標(biāo)簽，控制ISV業(yè)務(wù)數(shù)據(jù)操作尺度，提高數(shù)據(jù)安全性）
• 提供標(biāo)準(zhǔn)業(yè)務(wù)流程標(biāo)簽，簡(jiǎn)化開(kāi)發(fā)者對(duì)于業(yè)務(wù)流程理解過(guò)程。
• 標(biāo)簽化接口方式，完成數(shù)據(jù)獲取和頁(yè)面渲染，后臺(tái)業(yè)務(wù)升級(jí)對(duì)ISV透明化。
• 標(biāo)簽獲取客戶端信息，將監(jiān)控?cái)U(kuò)展到整個(gè)業(yè)務(wù)請(qǐng)求過(guò)程。制定行業(yè)化標(biāo)簽庫(kù)，形成統(tǒng)一開(kāi)發(fā)標(biāo)準(zhǔn)。

TBML首先需要根據(jù)業(yè)務(wù)需求及場(chǎng)景定義出對(duì)應(yīng)的標(biāo)簽庫(kù)，也就是制定Taobao的標(biāo)簽標(biāo)準(zhǔn)，最簡(jiǎn)單的獲取用戶信息標(biāo)簽，到最復(fù)雜的業(yè)務(wù)操作流程標(biāo)簽都會(huì)成為標(biāo)簽庫(kù)中的一部分。同時(shí)在服務(wù)端需要有解釋引擎來(lái)翻譯標(biāo)簽，解釋引擎一方面需要去了解標(biāo)簽內(nèi)容和含義，同時(shí)需要請(qǐng)求后臺(tái)多個(gè)API，串聯(lián)成為流程化的服務(wù)，從應(yīng)用的輸入，得到最后的輸出，當(dāng)然期間也需要處理異常的情況。最后還需要關(guān)注的就是安全控制，在交驗(yàn)標(biāo)簽傳遞來(lái)的數(shù)據(jù)時(shí)，需要對(duì)數(shù)據(jù)作完整性及合法性的交驗(yàn)，防止通過(guò)標(biāo)簽數(shù)據(jù)的特殊性攻擊后臺(tái)服務(wù)接口。

TBQL組件

TBQL其實(shí)是一種服務(wù)調(diào)用的方式，也是通過(guò)一種程序員和開(kāi)發(fā)者習(xí)慣的方式，將對(duì)資源的REST請(qǐng)求轉(zhuǎn)換成一種類(lèi)似QL的請(qǐng)求，對(duì)于面向資源性的架構(gòu)體系來(lái)說(shuō)是十分有利的。同時(shí)對(duì)于API來(lái)說(shuō)，使用者會(huì)更加自然的去采用連接和過(guò)濾得方式得到需要的數(shù)據(jù)。

QL解釋引擎負(fù)責(zé)對(duì)于TBQL的翻譯工作，數(shù)據(jù)存儲(chǔ)的MetaData保存在數(shù)據(jù)庫(kù)中，可以指導(dǎo)QL解釋引擎翻譯。需要支持不同數(shù)據(jù)來(lái)源的連接和過(guò)濾，在獲得結(jié)果以后需要做格式轉(zhuǎn)換返回給服務(wù)調(diào)用者（通常就是xml）。與容器一樣，需要著重考慮安全性問(wèn)題，對(duì)于傳統(tǒng)的SQL注入就是典型攻擊QL系統(tǒng)的案例，需要謹(jǐn)慎處理解析中對(duì)于字符的翻譯工作。在流程中出現(xiàn)異常，需要制定策略來(lái)判斷是否直接返回錯(cuò)誤還是支持部分容錯(cuò)。

TOPID組件

TOPID組件有點(diǎn)類(lèi)似于Facebook的Connect，需要在淘寶和淘寶的合作開(kāi)發(fā)者之間建立起雙向的用戶互通的標(biāo)準(zhǔn)和流程，同時(shí)也為服務(wù)互通打好基礎(chǔ)，畢竟業(yè)務(wù)的互動(dòng)需要基于可以互通的用戶體系。