Author：放翁（文初）
Date: 2010/11/23
Email:fangweng@taobao.com
mblog: http://t.sina.com.cn/fangweng
blog: http://blog.csdn.net/cenwenchu79/
問題的誕生與思考：
一. 依賴之苦
做過不少業(yè)務(wù)系統(tǒng)，最痛苦，最無奈的就是性能和穩(wěn)定性依賴與外部系統(tǒng)處理能力和可用時間。而TOP是典型的Proxy模式，它自身的性能在傳統(tǒng)的Web容器處理模式下依賴與后端服務(wù)處理能力。
TOP在Web容器線程連接有限的情況下，最差的處理能力就是min(A,B,C)，也就是一個時刻的處理都是在處理最慢的系統(tǒng)的請求。因此產(chǎn)生這么幾個問題：a.通過壓力測試評估TOP自身的處理能力，并且來預(yù)估所需要的服務(wù)器容量將變得很不可靠。 b.可能由于某一個后端服務(wù)的不正常導(dǎo)致正常服務(wù)也無法通過TOP被外部訪問到，使得局部不可用演變成為整體不可用。
延展考慮，由于容器端線程不支持根據(jù)業(yè)務(wù)情況分配，因此無法實(shí)現(xiàn)靜態(tài)或者動態(tài)的線程資源按業(yè)務(wù)重要性或者服務(wù)健康狀況做調(diào)整，這樣對于一個集成了眾多重要程度不同，能力參差不齊的服務(wù)平臺來說很難最有效的將合理的資源傾向于重要且健康的服務(wù)。
二. 輪詢之苦
首先，耗時的業(yè)務(wù)處理，例如對于歷史訂單的數(shù)據(jù)查詢，后臺操作會消耗較多時間，而傳統(tǒng)請求是阻塞式的，因此超時設(shè)置成了一個難題，設(shè)置太大，傳統(tǒng)容器的連接資源有限，設(shè)置短了無法滿足業(yè)務(wù)需求，為今之計(jì)只能夠?qū)⒁粋€請求拆成兩個請求，一個是發(fā)起處理的通知請求，后面是輪詢獲取結(jié)果的請求。
其次，在業(yè)務(wù)系統(tǒng)設(shè)計(jì)中，或多或少的會有基于狀態(tài)變更事件來觸發(fā)事件處理的場景，淘寶的業(yè)務(wù)體系更是如此。買家和賣家分別是淘寶的兩個角色，相互之間的操作貫穿于整個交易主流程（下單，付款，發(fā)貨，確認(rèn)收貨），兩個角色之間是通過交易這個虛擬對象的狀態(tài)遷移來實(shí)現(xiàn)交互的，而狀態(tài)遷移的動作是由任何一方無預(yù)見性的實(shí)施的，因此做工具的應(yīng)用需要能夠接受到狀態(tài)變化事件通知，當(dāng)前只能通過應(yīng)用輪詢獲取數(shù)據(jù)來實(shí)現(xiàn)。
輪詢一方面使得開發(fā)者軟件設(shè)計(jì)復(fù)雜度高，自身系統(tǒng)消耗大（時間間隔設(shè)置，容錯機(jī)制等等），另一方面使得TOP服務(wù)器壓力增大，無效請求浪費(fèi)系統(tǒng)資源。
三. 容器資源之苦
有人會說輪詢這件事情干嗎不直接將數(shù)據(jù)推送過去，告知這些ISV，反正他們也都是B/S結(jié)構(gòu)，服務(wù)器提供回調(diào)地址就可以了。的卻這是最常見的Notify的模式，淘寶內(nèi)部也有一個Notify的中間件。但是在現(xiàn)在的網(wǎng)絡(luò)狀況下，主動推送數(shù)據(jù)到ISV的服務(wù)器上基本不靠譜，對方響應(yīng)速度的快慢直接影響到我們投遞這些數(shù)據(jù)需要多少服務(wù)器，投遞的策略如何？（如何處理失敗的投遞消息，重試機(jī)制如何），從這里可見容器連接池之苦。另一方面從第一個苦描述中可以看到，其實(shí)如果容器資源足夠多，那么就可以無限制放大入口，也就不會受之于后端的依賴系統(tǒng)處理能力，但今天大家看看自己傳統(tǒng)的Web應(yīng)用服務(wù)器（jboss,tomcat非apache,nginx）連接池配置的數(shù)字就知道這是不靠譜的。
技術(shù)背景概述：
管道化子任務(wù)切分：
我外婆以前是做白鐵加工的，做一個鍋?zhàn)踊拘枰@些步驟，每個步驟都需要一些工具，傳統(tǒng)最簡單的做法就是一個人做到底，然后工具都擺在身邊。（這也就是我們現(xiàn)在傳統(tǒng)容器的模式，從請求進(jìn)入到整個業(yè)務(wù)處理結(jié)束），要提高效率的做法如下：
1. 增加人手，依然采用一人處理到底的模式。在人和工具無限量的情況下是最簡單和行之有效的方式。
2. 切割流程，最大化資源利用率，每個子任務(wù)所需的資源不同，因此在完成子任務(wù)后就將資源共享給其他人而不是占用所有資源到整個流程結(jié)束。這種優(yōu)化帶來的最明顯的效果：
a) 輕量級子任務(wù)完成所需要消耗的資源最小化。（例如第一階段處理消耗時間很短，那么錘子和鉗子的需求量將會最小）
b) 重量級子任務(wù)能夠得到更多的資源和線程來處理。如果第一階段和第二階段本身資源消耗是相互影響的，比如第一階段資源分配消耗內(nèi)存，第二階段資源分配也消耗內(nèi)存，那么第一階段的資源占用少了以后，自然可以給第二階段資源分配提供了便利，其次如果總資源有限，第一階段也在等待資源的ready，那么此時的線程將會等待在第一階段的資源分配上，此時線程空消耗，但如果降低了第一階段的消耗，線程滿負(fù)荷運(yùn)作，則線程完成第一階段所有任務(wù)后可以支援第二階段的工作。
3. 當(dāng)子任務(wù)可以“降級”的情況下，分解任務(wù)，根據(jù)資源狀況來并行處理，并且適當(dāng)?shù)?#8220;丟棄”非關(guān)鍵子任務(wù)可以提高效率，增加穩(wěn)定性。
總體上來說，可以把原本一個任務(wù)拆成管道形式的子任務(wù)（管道化也就是每個子任務(wù)的上一個任務(wù)的輸出是當(dāng)前子任務(wù)的輸入），然后根據(jù)子任務(wù)的情況來選擇是否交由不同的線程并行化執(zhí)行。（這個判斷很簡單，子任務(wù)是否是有限資源且較輕量化的，子任務(wù)的資源占用多少是否會影響到其他任務(wù)的資源分配情況，如果這兩點(diǎn)都不成立，則保持簡單處理模式即可，最多可以將某一些子任務(wù)“降級”）
管道化的作用：1.將任務(wù)各個階段梳理清楚。（降低子任務(wù)之間的耦合度，為并行或異步處理提供基礎(chǔ)）。2.最大化資源利用率，便于流程整體優(yōu)化。
事件驅(qū)動模式：
事件驅(qū)動模式其實(shí)在設(shè)計(jì)中被大規(guī)模使用，思路概括起來就是：對象脫離線程，狀態(tài)脫離事務(wù)。回到第一個做鍋?zhàn)尤齻€流程的實(shí)例說明，也許在第二階段，某人拿起了一個已經(jīng)完成第一階段的半成品在等待第二階段的資源Ready，這時候如果他放下這個半成品，先去做已經(jīng)可以做工作的第一或者第三階段的半成品，然后等到另一個人做完后釋放第二階段資源時通知他時，他在去安排做第二階段的工作，那么效率會更高。
那么可以發(fā)現(xiàn)，管道化是從釋放資源被占用的角度去提升整體工作效率，而事件驅(qū)動模式是從分離工作實(shí)施者和工作資源的角度去提升工作實(shí)施者的工作效率。一個是工作者是有限而寶貴資源，一個是子任務(wù)在完成過程中所需資源是寶貴資源。
由此看來，事件驅(qū)動模式與管道模式不同，應(yīng)該是不需要有評判標(biāo)準(zhǔn)都可以實(shí)施的一種優(yōu)化策略。其實(shí)不然，事件驅(qū)動模式也有自己的弱點(diǎn)：1.設(shè)計(jì)復(fù)雜。（過于松耦合的結(jié)構(gòu)，使得原本事務(wù)中有順序的操作需要更多的檢查，容錯和調(diào)度）2.性能可能會受到影響。（線程上下文的切換，中間結(jié)果的拷貝）3.延時問題產(chǎn)生。對于事件的產(chǎn)生一種是主動推送，一種是輪詢，輪詢就牽涉到時間片大小的問題，在性能和及時性權(quán)衡的情況下最后得出合理的設(shè)置，但是對于整個事務(wù)來說一定是消耗了。
上面描述的兩個概念在后面的Web請求異步化處理及訂閱模式中都會用到，同時在支持Servlet3及Comet Streaming(Comet push)的容器整體架構(gòu)上都會被用到，優(yōu)劣上面做了簡單的描述，后面從業(yè)務(wù)架構(gòu)到系統(tǒng)架構(gòu)都會有最實(shí)在的設(shè)計(jì)說明。
業(yè)務(wù)架構(gòu)設(shè)計(jì)：
基于上述問題，通過兩步走來解決。首先采用支持打破傳統(tǒng)http request生命周期管理的Web容器（很多人說可以自己寫，其實(shí)Web容器寫起來并不是最麻煩的，如何做好兼容和照顧好每一個細(xì)節(jié)才是漫長發(fā)展的道路）。其次在容器新的線程生命周期管理基礎(chǔ)上封裝業(yè)務(wù)框架，為開發(fā)者屏蔽底層異步化和事件驅(qū)動模式帶來的復(fù)雜流程管理內(nèi)容。
待續(xù)...