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

　　Web容器：

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

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

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

　　3. 先看看下面的圖：

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