Author：文初
Email：wenchu.cenwc@alibaba-inc.com
Blog：http://blog.csdn.net/cenwenchu79
問題凸現(xiàn)：
年關(guān)到了，商家忙著促銷，網(wǎng)站忙著推廣，阿里軟件的服務(wù)集成平臺(tái)也面臨第一次多方大規(guī)模的壓力考驗(yàn)，根據(jù)5.3版本的壓力測試結(jié)果，估算了一下現(xiàn)有的推廣會(huì)帶來的壓力，基本上確定了服務(wù)集成平臺(tái)年底不需要擴(kuò)容。SA為了保險(xiǎn)起見還是通過請求方式來做定時(shí)的心跳檢測，保證服務(wù)集成平臺(tái)的可靠性。結(jié)果旺旺推廣開始的第一天，SA的報(bào)警短信就在幾個(gè)忙時(shí)段不停的發(fā)告警，但是察看生產(chǎn)環(huán)境的服務(wù)器狀況以及應(yīng)用狀況也看不出有什么問題，開始懷疑是否告警機(jī)制不是很合理。但幾日的訪問記錄統(tǒng)計(jì)報(bào)告看過以后，發(fā)現(xiàn)了幾個(gè)問題，首先由于推廣是在IM登錄時(shí)段集中式的推廣，因此高峰期比較集中，壓力也很大，而告警發(fā)生的也是那些時(shí)候，再則，發(fā)現(xiàn)那些推廣使用的API的處理時(shí)間比較長，同時(shí)還有一些出現(xiàn)了問題，這幾天除了服務(wù)集成平臺(tái)告警以外，那些API服務(wù)器也在告警，因此可以看出問題應(yīng)該是由于API提供商響應(yīng)速度慢而拖累了服務(wù)集成平臺(tái)的處理能力，監(jiān)控機(jī)制在高峰情況下沒有得到及時(shí)的響應(yīng)，就認(rèn)為是服務(wù)器已經(jīng)處于無效狀態(tài)。其實(shí)這類問題在我們現(xiàn)在的應(yīng)用體系架構(gòu)中常常出現(xiàn)，現(xiàn)在很少有純粹“封閉式”應(yīng)用，對DB的依賴，對存儲(chǔ)的依賴，對第三方系統(tǒng)的依賴等等。這也讓我回憶到就是前一陣子參加的安全會(huì)議中，騰迅的安全技術(shù)團(tuán)隊(duì)的負(fù)責(zé)人說起關(guān)于安全現(xiàn)在最大的問題就在于第三方合作安全的不受控而引發(fā)安全潛在影響。Web應(yīng)用未嘗不是，從最基本的事務(wù)處理要小粒度，不要包含第三方依賴到事務(wù)中，到心跳檢測，容錯(cuò)方案的制定，都已經(jīng)讓我們對這方面的問題有所注意。但是往往這類問題不是局部設(shè)計(jì)可以看到的，如果沒有一個(gè)總體架構(gòu)設(shè)計(jì)者對于全局的把握以及協(xié)調(diào)和防范，那么問題出現(xiàn)并且?guī)淼挠绊憣?huì)很大。
早先對于服務(wù)集成平臺(tái)的壓力測試主要是在ISP服務(wù)“基本正常”的情況下做的，但是這次問題的暴露就要求我們對于這種第三方依賴出現(xiàn)邊界問題需要做出一些措施或者改進(jìn)的設(shè)計(jì)。
問題分析以及解決方案：
問題原因：
1． Http請求處理的阻塞方式。
2． 后端服務(wù)處理時(shí)間過長，服務(wù)質(zhì)量不穩(wěn)定。
3． Web Container接受請求線程資源有限。
解決方案：
1． 改阻塞方式為非阻塞方式處理請求。
2． 設(shè)置后端超時(shí)時(shí)間，主動(dòng)斷開連接，回收資源。
3． 修改容器配置，增加線程池大小以及等待隊(duì)列長度。
解決方案一是最難做到的，后面的篇幅講描述對于這方面技術(shù)的探索。
解決方案二比較容易，允許各個(gè)ISP設(shè)置自己API容許的最大超時(shí)時(shí)間。
解決方案三Tomcat，JBoss在Connector中有兩個(gè)參數(shù)配置（maxThreads和acceptCount）可以做調(diào)整。
第一個(gè)方案其實(shí)和Jdk1.5支持的NIO就是一種想法，只是我們在Socket中都已經(jīng)采用了，而在Http請求處理中要依賴于Web Container開發(fā)商的實(shí)現(xiàn)所以至今還沒有被廣泛應(yīng)用，不過在開源社區(qū)已經(jīng)有用Mina實(shí)現(xiàn)的Http協(xié)議處理的框架，但是現(xiàn)在的Web應(yīng)用高效的Web請求處理僅僅是很小的一方面，還有很多類似于安全，緩存，監(jiān)控等等附加功能也占據(jù)著很重要的地位。
Servlet 3規(guī)范經(jīng)過快一年的推廣，已經(jīng)被各大Web Container廠商所接受，Tomcat6、JBoss5、Jetty7都宣稱自己對Servlet3作了較好的支持，而在Servlet3中最廣為關(guān)注的一個(gè)特性就是異步服務(wù)處理Servlet（Async Servlet），這點(diǎn)也是解決我目前面臨問題的最好的手段。
Servlet 3 與服務(wù)異步處理：
Servlet 3主要的新特性分成四部分：內(nèi)嵌式的使用模式，Annotation的支持，Async Servlet的支持，安全提升。內(nèi)嵌式的使用很早就在Jetty中被實(shí)現(xiàn)，也成為Jetty的優(yōu)勢之一，Annotation也只能說是錦上添花的部分，安全暫時(shí)沒有怎么用到，最關(guān)心的還是Async Servlet部分。Async Servlet到底是什么樣的概念，這里就大致描述一下在Servlet3規(guī)范中的介紹：
1. 支持 Comet（彗星）。最早期Http請求就是無狀態(tài)的請求和響應(yīng)，所有的數(shù)據(jù)一次性在請求后返回給客戶端由客戶端渲染。后來發(fā)展到AJAX，頁面的請求和渲染由全局變成了局部。而Comet適合事件驅(qū)動(dòng)的 Web 應(yīng)用和對交互性和實(shí)時(shí)性要求很強(qiáng)的應(yīng)用，通過建立客戶端和服務(wù)端的長連接通道，在一次請求后可以主動(dòng)推送服務(wù)端數(shù)據(jù)的變更情況到客戶端。長連接建立的策略有兩種：Http Streaming和Http Long Polling。前者客戶端打開一個(gè)單一的與服務(wù)器端的 HTTP 持久連接。服務(wù)器通過此連接把數(shù)據(jù)發(fā)送過來，客戶端增量的處理它們。后者由客戶端向服務(wù)器端發(fā)出請求并打開一個(gè)連接。這個(gè)連接只有在收到服務(wù)器端的數(shù)據(jù)之后才會(huì)關(guān)閉。服務(wù)器端發(fā)送完數(shù)據(jù)之后，就立即關(guān)閉連接。客戶端則馬上再打開一個(gè)新的連接，等待下一次的數(shù)據(jù)。
2. 支持Suspending a request。通過在ServletRequest中增加suspend,resume,complete將Http請求處理的block模式轉(zhuǎn)變成為not block模式，同時(shí)支持對于狀態(tài)的查詢（suspend,resume,timeout）。
3. 請求處理過程中支持事件機(jī)制。響應(yīng)也支持狀態(tài)查詢。
圖 異步服務(wù)請求基本流程
現(xiàn)實(shí)中的異步服務(wù)處理：
Tomcat 的異步服務(wù)處理
這里使用的是Tomcat 6.0.14版本。在Tomcat中對于異步處理描述在Advanced IO中作了說明，主要分成兩部分：Comet的支持和異步輸出。
Comet的支持作用分成兩部分：請求讀數(shù)據(jù)的非阻塞，響應(yīng)處理的異步執(zhí)行。前者可以防止在大流量數(shù)據(jù)上傳時(shí)在傳輸過程中信道空閑等待的資源浪費(fèi)，后者用于在處理請求時(shí)，依賴于第三方或者本身處理比較耗時(shí)的情況下，懸掛起請求處理線程，提高請求處理能力，完成處理后異步輸出結(jié)果。
Servlet不再是原來對于幾個(gè)標(biāo)準(zhǔn)的Http請求類型的方法實(shí)現(xiàn)，而是對于事件響應(yīng)的處理。Comet定義了4個(gè)基礎(chǔ)的事件：
1．EventType.BEGIN：客戶端建立起連接時(shí)激發(fā)的事件，可以用于資源初始化。
2．EventType.READ：有數(shù)據(jù)可以被讀入的事件。（熟悉NIO的事件模式應(yīng)該可以了解）
3．EventType.END：請求處理結(jié)束時(shí)激發(fā)的事件，可以用于資源清理。
4．EventType.ERROR：當(dāng)請求處理出現(xiàn)問題時(shí)激發(fā)的事件。（IO異常，超時(shí)等）
還有一些子事件類型，例如超時(shí)就屬于ERROR的子事件類型，可以在事件處理中更加精確的定位事件類型。
必需的配置：在server.xml中配置如下（紅色部分）：
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443" />
實(shí)際代碼范例如下：
//CometProcessor接口必需被實(shí)現(xiàn)，一旦實(shí)現(xiàn)以后，則該Servlet在配置好以后不會(huì)再調(diào)用service,get,post等方法的實(shí)現(xiàn)。
publicclass SIPCometTomcatServlet extends HttpServlet implementsCometProcessor
{
@Override
//事件處理響應(yīng)方法實(shí)現(xiàn)
publicvoid event(CometEvent event) throws IOException, ServletException
{
if (event.getEventType() == CometEvent.EventType.BEGIN)
{
//設(shè)置事件超時(shí)時(shí)間
event.setTimeout(10 * 1000);
//另起線程處理后臺(tái)工作，異步返回結(jié)果，事件響應(yīng)將不等待后臺(tái)處理直接返回
new Handler(event.getHttpServletRequest(),event.getHttpServletResponse()).start();
}
elseif (event.getEventType() == CometEvent.EventType.ERROR)
{
//結(jié)束事件，回收request,response資源
event.close();
}
elseif (event.getEventType() == CometEvent.EventType.END)
{
event.close();
}
}
//另起一個(gè)線程異步處理請求。
class Handler extends java.lang.Thread
{
private HttpServletResponse response;
private HttpServletRequest request;
public Handler(HttpServletRequest request,HttpServletResponse response)
{
this.response = response;
this.request = request;
}
@Override
publicvoid run()
{
try
{
String id;
id = request.getParameter("id");
if (id == null)
id = "no id";
Thread.sleep(5000);
PrintWriter pw = response.getWriter();
pw.write(id);
pw.flush();
} catch (Exception e)
{
e.printStackTrace();
}
}
}
}
使用的一些總結(jié)：
1. 事件響應(yīng)框架將服務(wù)的請求由完整的一次服務(wù)處理切割成為細(xì)粒度的多事件處理，為請求多階段并行處理提供了框架基礎(chǔ)。
2. Event對象在事件處理方法結(jié)束后就被回收了，但是request和response在事件處理完以后還可以繼續(xù)使用，因此可以看出原來的阻塞式的方式已經(jīng)可以通過事件的切分成為非阻塞的方式。
3. 沒有提供Servlet3中描述suspend,resume,complete方法，無法主動(dòng)控制request的異步處理。上面的代碼可以看出我只使用了Begin方法啟動(dòng)了一個(gè)線程，但是由于無法主動(dòng)地結(jié)束請求，因此在向客戶端返回?cái)?shù)據(jù)以后還要等到超時(shí)才會(huì)結(jié)束這次會(huì)話。（看了Tomcat的代碼，也想模仿close的動(dòng)作但是由于它使用了protected無法獲取封裝的request對象，因此無法釋放資源）。當(dāng)然也可以通過客戶端配合，由客戶端主動(dòng)發(fā)起再次的數(shù)據(jù)傳輸激發(fā)READ事件來結(jié)束會(huì)話。這么做對客戶端的依賴比較強(qiáng)，同時(shí)也增加了客戶端的處理復(fù)雜度。
4. Tomcat支持異步輸出：在APR或者NIO的模式下，Tomcat支持在系統(tǒng)壓力增大的時(shí)候，支持異步回寫大文件數(shù)據(jù)。
總體上來說實(shí)現(xiàn)了部分對于Comet的支持，但是沒有對異步服務(wù)流程作很好的支持，無法在開發(fā)中使用（簡單順暢的使用）。
JBoss的異步服務(wù)處理
JBoss 4.2.3版本配置和使用與Tomcat6類似，沒有什么差異。
JBoss 5剛剛發(fā)布了RC版本，對于異步服務(wù)處理作了很大的改動(dòng)，與Tomcat配置很不同這里具體的說一下JBoss5中的異步服務(wù)使用。
JBoss5已經(jīng)將Tomcat中的Http11NioProtocol給刪除了，取而代之的是JBoss自己的servlet包內(nèi)增加了一個(gè)HttpEventServlet接口，這個(gè)接口和Tomcat的CometProcessor類似。
首先，必須配置JBoss內(nèi)置的Web容器為APR模式，也就是配置jbossweb.sar下面的server.xml中Connector 如下：
<Connector protocol="org.apache.coyote.http11.Http11AprProtocol" port="8080" address="${jboss.bind.address}"
connectionTimeout="2000" redirectPort="8443" />
其次異步服務(wù)處理的Servlet必須實(shí)現(xiàn)HttpEventServlet接口，接口只有一個(gè)方法，就是事件處理方法：public void event(HttpEvent event)。事件定義與Tomcat稍有不同，在BEGIN,ERROR,READ,END基礎(chǔ)上增加了TIMEOUT,EOF,EVENT,WRITE四個(gè)事件，同時(shí)去掉了SubType。
1． TIMEOUT其實(shí)是從原來的Error的SubType分離出來的，這個(gè)方法是在最后一次處理事件到當(dāng)前時(shí)間超過設(shè)定的超時(shí)時(shí)間而被激發(fā)的，同時(shí)TIMEOUT被激發(fā)并不會(huì)關(guān)閉請求處理流程，必須顯示調(diào)用事件的close方法才會(huì)結(jié)束會(huì)話。
2． EOF事件將會(huì)在客戶端主動(dòng)斷連的情況下被觸發(fā)，就好比IE窗口在請求過程中被關(guān)閉就會(huì)被觸發(fā)。
3． EVENT事件在事件對象被調(diào)用resume的時(shí)候被激發(fā)，按照原意應(yīng)該最好可以附帶上一些自定義信息來做一些工作，但是我自己使用過程中還沒有發(fā)現(xiàn)有什么好的辦法可以在事件中附帶信息到事件處理中。
4． WRITE方法在調(diào)用isWriteReady方法時(shí)被激發(fā)，可以在網(wǎng)絡(luò)出現(xiàn)問題或者繁忙的時(shí)候異步等待輸出。
再則，JBoss的事件對象還支持幾個(gè)方法來實(shí)現(xiàn)異步處理以及Comet機(jī)制，方法如下：
1.close方法：表示一次請求處理的結(jié)束，會(huì)告知客戶端沒有數(shù)據(jù)返回了，同時(shí)也會(huì)激發(fā)END事件。
2.setTimeout方法：設(shè)置連接超時(shí)時(shí)間（單位毫秒），計(jì)算超時(shí)是從最近的事件處理時(shí)間開始記錄的，如果發(fā)生超時(shí)，則會(huì)激發(fā)TIMEOUT事件。
3.isReadReady方法：如果連接有數(shù)據(jù)可以讀取則返回true，如果這個(gè)方法返回false，servlet還試圖去讀去數(shù)據(jù)，則會(huì)阻塞。
4.isWriteReady方法：如果返回true，則連接可以無阻塞的寫出數(shù)據(jù)，如果返回false，servlet必須停止寫數(shù)據(jù)，如果強(qiáng)制寫出，則可能會(huì)發(fā)生IO錯(cuò)誤或者會(huì)采用異步輸出。當(dāng)客戶端的輸出通道可用以后，則會(huì)激發(fā)write事件。
5.suspend方法：suspend連接處理線程直到timeout發(fā)生或者resume被調(diào)用，實(shí)際上意味著servlet在suspend以后不再收到READ事件，READ事件將會(huì)在后臺(tái)被不斷的激發(fā)，除非被suspend.
6.resume方法：會(huì)激發(fā)event事件，可以利用這個(gè)方法來結(jié)束異步處理。同時(shí)也可以激活因?yàn)閟uspend停止的read事件，同時(shí)也可以在resume以后再調(diào)用suspend方法。注意，這里未必是要求必須先suspend以后再resume。
7.event,request,response在事件響應(yīng)過程中都可以被使用，但是線程不安全，同時(shí)在調(diào)用了close以后，request,response資源會(huì)被釋放，可以通過對event對象做同步來保證線程安全的問題。當(dāng)READ事件和END事件都發(fā)生的時(shí)候，首先會(huì)完成READ事件，然后再去完成END。
具體的實(shí)現(xiàn)代碼：
publicclass SIPCometJBossServlet extends HttpServlet implementsHttpEventServlet
{
@Override
publicvoid event(HttpEvent event) throws IOException, ServletException
{
switch (event.getType())
{
//will be called at the beginning of the processing of the connection
caseBEGIN:
{
event.setTimeout(100 * 1000);//設(shè)置超時(shí)時(shí)間
//event.suspend();//resume之前不必要一定使用suspend
new Handler(event).start();
break;
}
//Error will be called by the container in the case
//where an IO exception or a similar unrecoverable error occurs
caseERROR:
{
event.close();
break;
}
//End may be called to end the processing of the request
caseEND:
{
//event.close();//可以寫也可以不寫，因?yàn)檫M(jìn)入這個(gè)方法也就是調(diào)用了close方法，起碼暫時(shí)還不知道有其他什么入口
break;
}
//This indicates that input data is available,
//and that at least one read call can be made without blocking
caseREAD:
{
break;
}
//The connection timed out according to the timeout value which has been set
//,but the connection will not be closed unless the servlet uses the close method of the event
caseTIMEOUT:
{
event.close();//如果不主動(dòng)關(guān)閉，Timeout方法會(huì)被循環(huán)調(diào)用，會(huì)話不會(huì)結(jié)束
break;
}
//The end of file of the input has been reached, and no further data is available
caseEOF:
{
event.close();
break;
}
//Event will be called by the container after the resume() method is called,
//during which any operation can be performed, including closing the connection using the close() method.
caseEVENT:
{
event.close();//作為resume方法調(diào)用后主動(dòng)釋放連接資源的一種手段
break;
}
//Write is sent if the servlet is using the isWriteReady method
caseWRITE:
{
break;
}
}
}
class Handler extends java.lang.Thread
{
private HttpEvent event;//event的生命周期已經(jīng)不限制于事件處理方法，因此隨時(shí)可以關(guān)閉請求處理
private HttpServletResponse response;
private HttpServletRequest request;
public Handler(HttpEvent event)
{
this.event = event;
this.response = event.getHttpServletResponse();
this.request = event.getHttpServletRequest();
}
@Override
publicvoid run()
{
try
{
String id;
id = request.getParameter("id");
if (id == null)
id = "no id";
Thread.sleep(5000);
//危險(xiǎn)！！！其實(shí)event,response,request都是線程不安全的，因此此時(shí)可能response已經(jīng)被釋放，需要同步住event的對象來操作，效率可能會(huì)降低
PrintWriter pw = response.getWriter();
pw.write(id);
pw.flush();
event.resume();//發(fā)送結(jié)束調(diào)用resume方法，進(jìn)入event方法，結(jié)束請求處理
} catch (Exception e)
{
e.printStackTrace();
}
}
}
}
使用總結(jié)：
1. 對于Servlet描述的異步服務(wù)處理有了較好的支持。
2. 事件方法比較豐富，但是對于可定義事件支持不夠完善。
3. 對象并發(fā)控制需要開發(fā)者自己設(shè)計(jì)，權(quán)衡多線程處理的高效以及資源爭奪的消耗。
下面對異步服務(wù)處理Servlet和普通Servlet做了一下簡單的性能測試。
首先我原本想用ab來做一下簡單的壓力測試即可，但是ab好像對于apr模式下的測試支持的不好，一壓就報(bào)錯(cuò)（apr_poll: The timeout specified has expired (70007)），也可能是自己不會(huì)用吧，因此就自己寫了一段測試代碼來做測試。
測試場景如下：
兩類Servlet都可以設(shè)置處理時(shí)Hold的時(shí)間，來達(dá)到消耗連接數(shù)的目的。測試客戶端可以設(shè)置并發(fā)多少用戶，每個(gè)用戶發(fā)起多少次請求。下表就是測試的結(jié)果：
這里設(shè)置的是Servlet都hold1秒鐘，APR啟動(dòng)時(shí)配置的最大連接數(shù)為默認(rèn)的200個(gè)。
|
客戶端設(shè)置
|
普通Servlet總耗時(shí)(ms)
|
異步Servlet總耗時(shí)(ms)
|
普通Servlet單個(gè)線程耗時(shí)(ms)
|
異步Servlet單個(gè)線程耗時(shí)(ms)
|
|
100并發(fā)線程，每個(gè)線程執(zhí)行1次請求
|
263866
|
274430
|
2638
|
2744
|
|
300并發(fā)線程，每個(gè)線程執(zhí)行1次請求
|
550718
|
617082
|
1835
|
2056
|
|
100并發(fā)線程，每個(gè)線程執(zhí)行10次請求
|
1087747
|
1207920
|
10877
|
12079
|
|
300并發(fā)線程，每個(gè)線程執(zhí)行10次請求
|
retrying request,connect reject
|
5193644
|
retrying request,connect reject
|
17312
|
從上表可以看出，就純粹從處理效率來說，采用事件處理方式在線程切換過程中存在著一定的損失，但是就我們使用異步請求處理的本意來看，對于在高并發(fā)下對后端依賴無法避免的性能損耗情況下，異步請求解決了連接耗盡的問題。
最后在來看我在測試過程中用JProfiler來截取的一些線程創(chuàng)建和使用狀況：
上圖是最初的線程創(chuàng)建情況，還沒有任何請求被發(fā)送到服務(wù)端，因此線程池也沒有開任何一個(gè)連接。
這是普通的Servlet在壓力測試下的線程狀況，線程就開到了200最大值，圖中由于程序來Hold請求處理線程出現(xiàn)了紅色阻塞和黃色等待，同時(shí)客戶端已經(jīng)開始出現(xiàn)拒絕連接的錯(cuò)誤。下圖就是錯(cuò)誤的截圖：
上圖是異步服務(wù)處理Servlet在壓力測試開始的情況，可以發(fā)現(xiàn)它的http線程還是200，但是其他事件處理線程在不斷增長。下圖已經(jīng)增長到了3000多個(gè)線程。（這里需要注意的就是這種異步處理資源申請沒有設(shè)置上限，因此對于資源消耗來說也是比較大的，同時(shí)要防范攻擊性請求造成服務(wù)端垮掉）
上圖是壓力測試結(jié)束以后，異步服務(wù)事件處理線程都被釋放恢復(fù)到了初始狀態(tài)。
后語:
多線程、分布式計(jì)算、erlang其實(shí)這些編程方式、框架設(shè)計(jì)、語言都在實(shí)現(xiàn)這一個(gè)理論，那就是分而治之，多線程是站在單應(yīng)用的角度去考慮解決方案，分布式計(jì)算是在多機(jī)協(xié)作考慮解決方案，erlang在單機(jī)多處理器的角度去考慮解決方案。但彼此的理念都是一樣，將能夠分割的不相關(guān)聯(lián)的獨(dú)立任務(wù)并行處理，最終實(shí)現(xiàn)最優(yōu)化的處理效果。
對于服務(wù)集成平臺(tái)是否采用這種技術(shù)，我自己還沒有最終的決定，首先就如上面的測試結(jié)果來看，有的還是有失的，其次這種并發(fā)異步處理帶來的多線程維護(hù)控制復(fù)雜度，也需要考慮到成本中。Jetty的開發(fā)者對于是否將異步服務(wù)處理Servlet來交由開發(fā)者控制而不是容器本身來控制表示出了反對意見，的卻將這樣復(fù)雜的控制交給開發(fā)者來處理會(huì)增加開發(fā)者的學(xué)習(xí)成本以及維護(hù)成本。