經歷了近三年的平臺發展，隨著業務量跳躍增長和開放尺度的不斷加大，問題隨之而來，開放平臺技術問題這個小短篇是想擺出問題，有些東西已經起步，有些東西還是空白，有些東西做的粗糙，有些東西還處于想想。希望有類似問題的，有業余時間摻和的，有興趣加入一起搞的，歡迎隨時mail：fangweng@taobao.com 。開放平臺內部將會有少量人各自負責一些內容作為專題來做精做足。開放平臺團隊的優勢是有業務試驗田(每天10多億的調用而且正在翻翻)，劣勢是時間要自己擠(不論你是業余還是團隊內)，我們有業務的壓力和其他創新的需求，而提出的這些技術問題當前是從系統技術角度談的，業務上的難點不提在這里了，廢話不多說。
Web容器：
省，快，穩，新
1. 每天10億次的服務調用，如果能夠在讀取所有數據前攔截掉一些系統或業務校驗不通過錯誤請求，那么節省的上行帶寬和連接資源是一筆不小的財富。這僅僅只是省的一種方式，當前我們做了streaming Lazyparser。如何省的更多，還待在容器上做更多文章。
2. 測試過Jetty，tomcat，jbossweb3，終選擇了Jetty，不是因為jetty快，而是在類似于Servlet3的Continuation特性下我們妥協了部分性能的損失。但Jetty的底層卻有很大的機會去提升(特別是Jetty的框架可植入，給了我們很大的靈活性，Jetty的整體事件驅動模型是做的很不錯的)，所以如何讓容器更快，需要我們做更多的事。
3. 先看看下面的圖：
這是開放平臺后端的服務其中一部分處理時間統計，有快有慢，同時這些系統的容量規劃，發布時間和服務質量都參差不齊，但開放平臺是一個對外的門戶，由于Http請求的同步性+容器管理線程生命周期，使得隔離單個服務不可用波及平臺，終導致后端服務都無法被訪問，需要改變傳統容器的請求處理方式。(假如A服務出現問題，同時3秒鐘為服務調用超時時間，如果一個應用服務器大500個容器線程，那么單機差情況1秒只能處理500/3個請求，這意味正常的后段服務由于得不到路由中轉也被外部認為不可用)，因此采用Jetty的Continuation模式，可以將容器線程池獨立出來處理連接，而業務處理交由后端業務線程池處理，而業務線程池可以根據業務優先級設定一些預留和限制模型，即共享線程池，又限制線程池被獨占。當前我們做了：異步模型封裝+業務管道化+業務權重線程池，看下圖：(開放平臺的控制臺中權重線程池監控和設置)
