經(jīng)歷了近三年的平臺發(fā)展，隨著業(yè)務量跳躍增長和開放尺度的不斷加大，問題隨之而來，開放平臺技術(shù)問題這個小短篇是想擺出問題，有些東西已經(jīng)起步，有些東西還是空白，有些東西做的粗糙，有些東西還處于想想。希望有類似問題的，有業(yè)余時間摻和的，有興趣加入一起搞的，歡迎隨時mail：fangweng@taobao.com 。開放平臺內(nèi)部將會有少量人各自負責一些內(nèi)容作為專題來做精做足。開放平臺團隊的優(yōu)勢是有業(yè)務試驗田(每天10多億的調(diào)用而且正在翻翻)，劣勢是時間要自己擠(不論你是業(yè)余還是團隊內(nèi))，我們有業(yè)務的壓力和其他創(chuàng)新的需求，而提出的這些技術(shù)問題當前是從系統(tǒng)技術(shù)角度談的，業(yè)務上的難點不提在這里了，廢話不多說。

　　Web容器：

　　省，快，穩(wěn)，新

　　1. 每天10億次的服務調(diào)用，如果能夠在讀取所有數(shù)據(jù)前攔截掉一些系統(tǒng)或業(yè)務校驗不通過錯誤請求，那么節(jié)省的上行帶寬和連接資源是一筆不小的財富。這僅僅只是省的一種方式，當前我們做了streaming Lazyparser。如何省的更多，還待在容器上做更多文章。

　　2. 測試過Jetty，tomcat，jbossweb3，終選擇了Jetty，不是因為jetty快，而是在類似于Servlet3的Continuation特性下我們妥協(xié)了部分性能的損失。但Jetty的底層卻有很大的機會去提升(特別是Jetty的框架可植入，給了我們很大的靈活性，Jetty的整體事件驅(qū)動模型是做的很不錯的)，所以如何讓容器更快，需要我們做更多的事。

　　3. 先看看下面的圖：

　　這是開放平臺后端的服務其中一部分處理時間統(tǒng)計，有快有慢，同時這些系統(tǒng)的容量規(guī)劃，發(fā)布時間和服務質(zhì)量都參差不齊，但開放平臺是一個對外的門戶，由于Http請求的同步性+容器管理線程生命周期，使得隔離單個服務不可用波及平臺，終導致后端服務都無法被訪問，需要改變傳統(tǒng)容器的請求處理方式。(假如A服務出現(xiàn)問題，同時3秒鐘為服務調(diào)用超時時間，如果一個應用服務器大500個容器線程，那么單機差情況1秒只能處理500/3個請求，這意味正常的后段服務由于得不到路由中轉(zhuǎn)也被外部認為不可用)，因此采用Jetty的Continuation模式，可以將容器線程池獨立出來處理連接，而業(yè)務處理交由后端業(yè)務線程池處理，而業(yè)務線程池可以根據(jù)業(yè)務優(yōu)先級設定一些預留和限制模型，即共享線程池，又限制線程池被獨占。當前我們做了：異步模型封裝+業(yè)務管道化+業(yè)務權(quán)重線程池，看下圖：(開放平臺的控制臺中權(quán)重線程池監(jiān)控和設置)