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