Author:放翁（文初）
Date:2010/4/2
過(guò)年到現(xiàn)在還沒(méi)有更新過(guò)blog，就和年前說(shuō)的一樣，到了淘寶就要真的踏實(shí)做實(shí)事了（起碼Q3前）。和以前在阿軟不同的是現(xiàn)在更加關(guān)注產(chǎn)品的設(shè)計(jì)和實(shí)現(xiàn)，對(duì)于新技術(shù)的嘗試缺少了一些空間和時(shí)間。可以拿程序員對(duì)新技術(shù)的追求做個(gè)類比，就好比結(jié)婚前的浪漫，而到了你真的結(jié)婚有了家庭和小孩，那需要的是更多的責(zé)任感和務(wù)實(shí)的工作。當(dāng)然如果生活成為一種生存，那么就失去了意義，如何在責(zé)任和浪漫之間找到平衡點(diǎn)，是一個(gè)技術(shù)人員成長(zhǎng)的挑戰(zhàn)。我們不可能永遠(yuǎn)是一個(gè)長(zhǎng)不大的小孩，也不會(huì)是老氣橫秋的中年男人。有點(diǎn)廢話了，言歸正傳，談一下這年后短短的一個(gè)多月的工作心得，一點(diǎn)分享，一點(diǎn)記錄。
系統(tǒng)透明化
去年就加入了淘寶的虛擬小組（穩(wěn)定性小組），同時(shí)在開(kāi)放平臺(tái)團(tuán)隊(duì)內(nèi)最大的一個(gè)職責(zé)也是穩(wěn)定性。對(duì)于客戶來(lái)說(shuō)并不關(guān)心你的技術(shù)實(shí)現(xiàn)是如何fancy，對(duì)他來(lái)說(shuō)能夠快速、穩(wěn)定、方便的滿足他的需求就是一個(gè)好網(wǎng)站，一個(gè)好系統(tǒng)，一套好服務(wù)。因此穩(wěn)定，高效成為了淘寶主站和開(kāi)放平臺(tái)的根本。前兩天看了黃裳在infoq的一些關(guān)于淘寶技術(shù)展望的文章，就兩個(gè)字“實(shí)在”，沒(méi)有啥潮流的詞匯，沒(méi)有很炫的技術(shù)推薦，有的就是如何用最有效的手段滿足用戶需求。
記得在最近一次穩(wěn)定小組會(huì)議上大家談到了這些年發(fā)展帶來(lái)的問(wèn)題，其實(shí)我們?cè)诮鉀Q問(wèn)題的同時(shí)也在不斷地引入問(wèn)題，同時(shí)在規(guī)模化的驅(qū)使下，不斷地采用松耦合及去中心化的設(shè)計(jì)，但是帶來(lái)的問(wèn)題就是系統(tǒng)復(fù)雜度的不斷增加，同時(shí)系統(tǒng)間的交互和依賴也變得越來(lái)越復(fù)雜和混沌。我在Q1的工作計(jì)劃中，大部分的工作為了一個(gè)目標(biāo)：系統(tǒng)透明化。
系統(tǒng)透明化能夠?yàn)楹Ａ空?qǐng)求的系統(tǒng)帶來(lái)什么？
1． 實(shí)實(shí)在在的性能優(yōu)化。
2． 簡(jiǎn)單有效的問(wèn)題排查和定位。
3． 系統(tǒng)風(fēng)險(xiǎn)預(yù)警。
4． 有效地系統(tǒng)健康監(jiān)控和業(yè)務(wù)健康監(jiān)控。
過(guò)去我們總在線下做各種壓力測(cè)試，同時(shí)對(duì)于一些優(yōu)化策略也都是通過(guò)線下來(lái)驗(yàn)證，但是實(shí)際的業(yè)務(wù)場(chǎng)景往往會(huì)和具體的數(shù)據(jù)相關(guān)，而線下無(wú)法做到的就是數(shù)據(jù)模擬。在開(kāi)放平臺(tái)系統(tǒng)基礎(chǔ)框架重構(gòu)以后，首先是采用了管道鏈的插拔模式，直接通過(guò)對(duì)當(dāng)前運(yùn)行數(shù)據(jù)的在線分析就可以看出系統(tǒng)消耗的環(huán)節(jié)，同時(shí)加上控制臺(tái)對(duì)集群?jiǎn)闻_(tái)機(jī)器的配置推送，這樣比對(duì)兩臺(tái)不同處理策略的服務(wù)器就能夠很明顯看出性能優(yōu)化的效果以及后續(xù)的改進(jìn)點(diǎn)。舉個(gè)例子，在我們業(yè)務(wù)方需求中要求對(duì)某一部分業(yè)務(wù)數(shù)據(jù)去掉本地緩存，全部啟用純粹的集中式緩存，我們通過(guò)批次的關(guān)閉本地緩存，比對(duì)了自身系統(tǒng)和外部依賴系統(tǒng)的壓力增長(zhǎng)情況，當(dāng)3/4的機(jī)群機(jī)器采用純集中式緩存的時(shí)候，兩方服務(wù)器都出現(xiàn)了load較高的問(wèn)題，因此考慮采用更細(xì)粒度的業(yè)務(wù)數(shù)據(jù)來(lái)決定是否啟用本地緩存，滿足了用戶請(qǐng)求，同時(shí)也大大降低了雙方的壓力情況，同時(shí)由于業(yè)務(wù)數(shù)據(jù)配置可運(yùn)行期推送，因此隨著壓力的增大可以在線調(diào)整策略。
在新架構(gòu)上線后，發(fā)現(xiàn)運(yùn)行一段時(shí)間會(huì)有“內(nèi)存泄露”的問(wèn)題，64位機(jī)器最后3個(gè)G的內(nèi)存都被吃光。當(dāng)時(shí)就是擔(dān)心新架構(gòu)可能產(chǎn)生一些問(wèn)題，因此允許系統(tǒng)通過(guò)控制臺(tái)切換新老引擎。線上一臺(tái)新引擎的服務(wù)器跑了一段時(shí)候就把內(nèi)存dump出來(lái)，然后拖到線下分析，發(fā)現(xiàn)有大量的tomcat的Session被保存在Manager中沒(méi)有被釋放（1.7G），然后通過(guò)線下卸載管道做測(cè)試，最終發(fā)現(xiàn)是由于其中一個(gè)管道需要在運(yùn)行期獲取到spring的容器，去掉用了request.getsession().getContext方法，結(jié)果容器創(chuàng)建了有效期為30分鐘的session，對(duì)于平臺(tái)這么大的訪問(wèn)量，其實(shí)這種非內(nèi)存泄露的問(wèn)題，也足以使得高壓力下OOM。
透明化另一方面就是需要對(duì)依賴系統(tǒng)及自身的健康狀況有所了解。當(dāng)前TOP在這方面主要做的工作被定義成為免疫系統(tǒng)，其主要的職責(zé)
流程管道化
這些年一直都在談面向服務(wù)，模塊化，這些概念。但是就其目標(biāo)來(lái)說(shuō)，就是希望能夠讓設(shè)計(jì)者更多的考慮流程之間的松耦合，無(wú)依賴。因?yàn)橐坏┓?wù)之間沒(méi)有過(guò)多的依賴，服務(wù)本身沒(méi)有中間狀態(tài)，那么任務(wù)就可以并行處理，一旦并行處理，那么對(duì)于流程的關(guān)鍵路徑優(yōu)化就有很大的幫助。
下面是重構(gòu)前和重構(gòu)后的兩個(gè)流程對(duì)比：
老框架流程：
新框架流程：
具體的框架類圖如下：
看了以后，可能很多同學(xué)會(huì)說(shuō)，其實(shí)就那么簡(jiǎn)單一個(gè)設(shè)計(jì)么，但其實(shí)系統(tǒng)的設(shè)計(jì)目標(biāo)就是用簡(jiǎn)單的設(shè)計(jì)來(lái)滿足復(fù)雜的需求。其實(shí)對(duì)于開(kāi)放平臺(tái)來(lái)說(shuō)，再?gòu)?fù)雜的業(yè)務(wù)都是可以抽象成管道，同時(shí)大部分情況下都是無(wú)狀態(tài)的服務(wù)管道，基于業(yè)務(wù)的不同需求，管道的執(zhí)行會(huì)有所不同。
這里設(shè)計(jì)的幾個(gè)原則：
1. 管道之間無(wú)關(guān)聯(lián)性。管道與管道之間完全沒(méi)有任何關(guān)聯(lián)，因?yàn)樵诠艿揽磥?lái)就只有輸入和輸出的數(shù)據(jù)流，其他管道對(duì)于它來(lái)說(shuō)是透明的。獨(dú)立性降低業(yè)務(wù)耦合度，支持運(yùn)行期變更。
2. 管道之間通過(guò)上下文的方式交互數(shù)據(jù)，減少數(shù)據(jù)輸入帶來(lái)的適配依賴。
3. 業(yè)務(wù)處理權(quán)及流程中斷權(quán)交給管道，管道可以通過(guò)實(shí)現(xiàn)ignoreit來(lái)判斷是否要處理此次請(qǐng)求，也可以在IPipeResult中設(shè)置isBreakPipeChain來(lái)主動(dòng)中斷流程。（對(duì)于資源回收最好不要交給一個(gè)管道執(zhí)行，因?yàn)殡S時(shí)可能因?yàn)榱鞒讨袛喽鴽](méi)有被執(zhí)行到）
4. 管道設(shè)計(jì)盡量為無(wú)狀態(tài)，線程安全，便于擴(kuò)展，防止產(chǎn)生資源競(jìng)爭(zhēng)帶來(lái)的處理瓶頸。
5. 監(jiān)控管道執(zhí)行狀況，必要時(shí)自動(dòng)降級(jí)卸載管道，保護(hù)系統(tǒng)穩(wěn)定性。
早先考慮是否能夠啟動(dòng)線程池來(lái)執(zhí)行管道鏈，這么做的目標(biāo)是能夠控制超時(shí)執(zhí)行的管道鏈，避免系統(tǒng)的不穩(wěn)定性。但最大的問(wèn)題就是線程切換代價(jià)以及線程池的容量問(wèn)題，因此作罷，改為事后記錄降級(jí)處理。
安全還是安全
開(kāi)放平臺(tái)成立之初，就要面對(duì)著安全的問(wèn)題，主站有很多的約束和限制，但是開(kāi)放平臺(tái)成為淘寶對(duì)外的窗口，為了業(yè)務(wù)需要，作了必要的妥協(xié)，但是安全方面也是一直在抓的事情。最近就處理淘寶訪客應(yīng)用的問(wèn)題，有些軟件開(kāi)發(fā)者就利用302轉(zhuǎn)跳的方式，在商品或者店鋪的頁(yè)面上留痕跡，來(lái)獲取訪客信息，可謂用盡心思，封一個(gè)漏洞找一個(gè)漏洞。對(duì)于這種轉(zhuǎn)跳來(lái)獲取訪客信息，簡(jiǎn)單的處理就這些，禁止get請(qǐng)求（由于都是頁(yè)面圖片的get請(qǐng)求轉(zhuǎn)跳，因此無(wú)法簡(jiǎn)單的變成post請(qǐng)求），然后如果是post需要加上動(dòng)態(tài)會(huì)話碼的校驗(yàn)，最后在加上對(duì)于請(qǐng)求的refer檢查，來(lái)屏蔽這類的問(wèn)題。不過(guò)對(duì)于釣魚網(wǎng)站，真的沒(méi)有啥太好的處理方式，個(gè)人感覺(jué)最靠譜的就是寫瀏覽器的插件。
標(biāo)簽化開(kāi)放
開(kāi)放平臺(tái)現(xiàn)在都是數(shù)據(jù)服務(wù)開(kāi)放，很多場(chǎng)景下會(huì)有標(biāo)簽化開(kāi)放的需求。還是看圖說(shuō)話吧：
剩下的就是基于Map-Reduce的可配置分析引擎的優(yōu)化，當(dāng)前支持文件數(shù)據(jù)源和數(shù)據(jù)庫(kù)數(shù)據(jù)源，支持增量分析和離線一次性分析，分析模型運(yùn)行期可改變，提供實(shí)時(shí)的監(jiān)控預(yù)警。太晚了，最后貼一個(gè)開(kāi)放平臺(tái)的技術(shù)當(dāng)前總體架構(gòu)圖：
