TOP是淘寶開放平臺的英文縮寫，同時也有頂級優質的英文含義。TOP的整個架構體系是組件化體系架構，可以是很少的幾個基礎組件構成的Skeleton，也可以是融入了商業想像的Amazing Architecture。這裡就通過對於這些組件的羅列，描述出在TOP這個大體系中，各個組件所處的地位及作用。TOP的兵器譜是在現階段商業需求及平臺非業務性需求指導下形成的，未來TOP將繼續發展，兵器譜也會不斷演進。
下圖是整個TOP當前的一個組件結構圖：
圖中，紅色虛線就是TOP的Skeleton。TOP當前從業務模塊功能角度來劃分，可以分成三個層次：基礎平臺組件層，基礎業務組件層，普通業務組件層。基礎平臺組件層，傾向於平臺級別功能滿足及對平臺穩定性，可用性的支持。基礎業務組件層，是介於平臺服務於普通業務服務之間的組件，部分利用了平臺基礎組件層的組件，來抽象出一層公用業務服務組件，為業務組件提供通用的基礎支持。
安全組件：
安全組件主要從四個角色去考慮整體的安全策略及具體的實施方案，這四個角色是：用戶，應用，平臺，服務。
平臺本身的安全主要是基於在大並發和大流量的情況下，保證平臺自身穩定性和可用性，同時也要兼顧在平臺開放的服務不相互幹擾和影響。因此採取服務分流隔離機制，通過虛擬配置及軟負載方式將服務請求動態分流和隔離，保證了服務之間相互的獨立性，同時也充分利用TOP的能力。頻率控制及流量控制除了保護TOP自身不受到攻擊，也為後端服務提供者作了天然的一個保護屏障，保證服務請求壓力可以在TOP上可控，防止流量直接壓倒服務提供者。用戶隱私安全在淘寶尤為重要，用戶信息的安全性也在淘寶開放的過程中被放到了首位。在開放平臺設計中，除了採用普通開放平臺的認證模式以外（OAuth類似流程），還在服務調用過程中通過區分應用角色來限制對於用戶信息的獲取和使用。同時針對不同的應用類型（插件，Web應用，客戶端應用，手機應用）都有各自不同的用戶授權方式，保證用戶的知情權。App的安全其實也是為了保證對服務的請求及對用戶信息的獲取不被不法的應用信息盜取者所利用，根據應用角色及自己對於安全的需求，採取多種方式或者組合的方式來實現App信息的保密性，保護App自身安全，也保證了平臺服務的數據安全。服務安全指的是對於服務來說分成了幾個層級，不同層級的服務對於安全級別的要求不同（不需要交驗應用身份，需要交驗應用身份，需要用戶授權，用戶可選擇授權等），在應用訪問服務的時候，就會需要根據服務級別的不同採用不同的訪問控制流程。根據上述的四個角色對於安全的考慮，通過應用角色的定義，服務虛擬組的編排，黑名單（頻率控制及流量控制），多模式用戶令牌等手段，形成了多種模式的安全控制流程。
服務路由組件：
服務路由是開放平臺最基本的功能，如果排除商業因素，那麼對於TOP最基本上來看可以看作一個服務路由器，服務路由主要的功能如下圖展示：
服務路由組件需要支持多服務類型的服務接入，不同服務類型主要表現在兩個維度：1.服務對外的展現方式（REST OR RPC），這兩種形態的服務沒有任何好壞之分，只是根據各自的系統形態來選擇採用哪一種模式來對外暴露，RPC比較符合過去應用開放的風格，REST比較適合面向資源的架構。同時對於同步，異步，通知，大數據量的服務，都會有不同的接入方式和調用方式支持，滿足各種業務場景的需求。多通信協議支持，表示服務請求到了TOP以後，TOP負責將請求繼續發送給服務提供者，不論服務提供者採用什麼方式和TOP交互，最終將得到的結果返回給客戶，服務調用者將會對後端的服務請求過程透明，同時可以使TOP很容易接入一些傳統遺留系統的服務，或者是對通信有特殊需求的服務。特性支持主要是會有對內容的一些特殊處理，例如壓縮，在CS或者手機應用交互過程中，就會需要對數據量有所壓縮，滿足業務需求。
監控告警組件：
下圖是監控告警組件的基本功能圖：
監控和告警模塊在TOP中起到越來越重要的作用，訪問量逐日膨脹，運行期TOP是一個黑盒，無法知曉當前系統實際的健康狀況，當出現問題以後比較難以定位。服務監控主要是服務質量（響應時間），短時間段內的服務請求峰值，和階段性的趨勢。系統和平臺主要是對底層基礎組件的監控，同時及時地通知TOP負責人處理線上即將要發生的事情。對於應用的監控通常就是從客戶端和服務端兩面對於應用當前的情況作匯總分析。當監控發現異常以後，就交由告警部分按照一定的發送策略給相關的負責人，在第一時間將問題解決。
日誌組件：
日誌組件和其他系統的日誌組件基本沒有太大的區別，只是在對於海量數據寫出和獲取的方法做了優化（例如異步分頁批量輸出等）。日誌組件主要負責，打點，收集，分析，資料庫記錄，歸檔。
協議轉換組件：
這裡談到的協議轉換指的是對於請求和返回的協議，TOP可以做適配，來滿足服務調用者和服務發布者之間在服務協議失配的情況下還是能夠正常通信。當前支持JSON,XML,Atom,二進位協議之間的轉換，當然轉換描述文檔將會配置在TOP。同時返回的數據內容，也可以通過協議轉換，返回給客戶端常規的xml或者json類型的數據。
服務流程化組件：
服務流程化指的是將離散的服務通過流程描述文檔能夠虛擬的串聯成為一個新的服務，這樣更加適合調用者使用，同時將服務的一些內部邏輯隱藏起來。這很類似於SOA中的服務編排，同時也可以參看Yahoo的Pipe，那就是一種典型的服務串聯，同時還提供了方便的界面直接交由用戶通過手動拖拉的方式來使用服務串聯。
服務流程化最大的特點就是將不同類型的服務能夠根據業務場景的需求組合成簡單的流程性服務，極大降低了服務開發者由於對服務流程不熟悉而犯錯的機率，同時也為服務開發者提高了開發效率。
計費組件：
當前計費模型主要是按流量收費和插件分成兩種模式，因此計費組件還比較簡單，當前就是基於日誌做分析，未來會考慮在流量上的各種特殊模式（打包，優惠等等）。
容器組件（TBML）：
產生原因：
1.數據隱私性
2.開發便利性
3.業務升級透明化
4.監控全局化
5.開發標準化
作用
1.數據操作可控，保護終端用戶隱私（結合cookie和標籤，控制ISV業務數據操作尺度，提高數據安全性）
2.提供標準業務流程標籤，簡化開發者對於業務流程理解過程。
3.標籤化接口方式，完成數據獲取和頁面渲染，後臺業務升級對ISV透明化。
4.標籤獲取客戶端信息，將監控擴展到整個業務請求過程。制定行業化標籤庫，形成統一開發標準
TBML首先需要根據業務需求及場景定義出對應的標籤庫，也就是制定Taobao的標籤標準，最簡單的獲取用戶信息標籤，到最複雜的業務操作流程標籤都會成為標籤庫中的一部分。同時在服務端需要有解釋引擎來翻譯標籤，解釋引擎一方面需要去了解標籤內容和含義，同時需要請求後臺多個API，串聯成為流程化的服務，從應用的輸入，得到最後的輸出，當然期間也需要處理異常的情況。最後還需要關注的就是安全控制，在交驗標籤傳遞來的數據時，需要對數據作完整性及合法性的交驗，防止通過標籤數據的特殊性攻擊後臺服務接口。
TBQL組件：
TBQL其實是一種服務調用的方式，也是通過一種程式設計師和開發者習慣的方式，將對資源的REST請求轉換成一種類似QL的請求，對於面向資源性的架構體系來說是十分有利的。同時對於API來說，使用者會更加自然的去採用連接和過濾得方式得到需要的數據。
QL解釋引擎負責對於TBQL的翻譯工作，數據存儲的MetaData保存在資料庫中，可以指導QL解釋引擎翻譯。需要支持不同數據來源的連接和過濾，在獲得結果以後需要做格式轉換返回給服務調用者（通常就是xml）。與容器一樣，需要著重考慮安全性問題，對於傳統的SQL注入就是典型攻擊QL系統的案例，需要謹慎處理解析中對於字符的翻譯工作。在流程中出現異常，需要制定策略來判斷是否直接返回錯誤還是支持部分容錯。
TOPID組件：
TOPID組件有點類似於Facebook的Connect，需要在淘寶和淘寶的合作開發者之間建立起雙向的用戶互通的標準和流程，同時也為服務互通打好基礎，畢竟業務的互動需要基於可以互通的用戶體系。
以上僅僅只是簡單的羅列了一下TOP技術體系架構中的一些組件化的內容，同時在這些組件的背後有著更多的基礎性項目的支持，例如統一配置中心對於系統動態擴容的支持，分布式緩存對於監控告警的支持，分布式文件系統對於海量小文件保存和獲取的支持等等。同時以上每一個模塊都有各自特殊的定製和優化，例如路由模塊就需要有Lazy的服務參數解析模式來提高處理性能，安全體系中需要有動態密鑰機制來保證高安全性等等。
TOP從萌芽走向成熟，不論從技術架構還是商業規劃都處於不斷摸索和改進的過程，當前的技術體系僅僅是現階段的一個需求縮影，未來在市場不斷成熟，開發者不斷介入和反饋的情況下，TOP會走得更快更遠，TOP的兵器譜會更加豐富，更加出彩。
Author：放翁（文初）
Email：fangweng@taobao.com
Blog：http://blog.csdn.net/cenwenchu79
延伸閱讀：
淘寶開放平臺開發指南之快速入門
淘寶開放平臺開發指南之熟悉API族
淘寶TOP開放平臺開發指南之API是如何誕生的
淘寶開放平臺TOP開發指南之解密TOP的認證授權機制（一）
淘寶開放平臺開發指南之淘寶動力開發者持續盈利的魔力
淘寶開放平臺開發指南之TOP的盈利模式
淘寶開放平臺開發指南之解密TOP服務分流與隔離