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

　　Web容器：

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

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

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

　　3. 先看看下面的圖：

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