應(yīng)用架構(gòu)設(shè)計(jì)“防火”經(jīng)驗(yàn)分享
Author : 岑文初(淘寶花名：放翁)
Email: fangweng@taobao.com
Blog: http://blog.csdn.net/cenwenchu79
Date: 2009-08-26
剛從阿軟到淘寶不久，現(xiàn)在主要負(fù)責(zé)TOP平臺(tái)的技術(shù)框架設(shè)計(jì)，同時(shí)要肩負(fù)“救火”和“防火”的工作，也需要培養(yǎng)團(tuán)隊(duì)的同學(xué)能夠有“防火”意識(shí)，減少“救火”次數(shù)，因此今天下午花了一點(diǎn)時(shí)間，也沒于寫任何的PPT，就直接將自己想的起來(lái)的一些自己認(rèn)為應(yīng)用架構(gòu)設(shè)計(jì)“防火”知識(shí)做了一下事例分享，這里也想記錄下來(lái)給更多的同學(xué)分享一下，當(dāng)然很多都是老生常談的常識(shí)，但是有時(shí)候不經(jīng)意就會(huì)忘記一些血的教訓(xùn)。
資源是有限的
著火點(diǎn)：
系統(tǒng)設(shè)計(jì)的時(shí)候總是估摸不到會(huì)有大數(shù)據(jù)量從遠(yuǎn)端傳輸過(guò)來(lái)（例如處理Http請(qǐng)求時(shí)，對(duì)于大附件內(nèi)容的處理，全部裝載到內(nèi)存，結(jié)果資源耗盡。從搜索引擎或者DB或者緩存里面拉數(shù)據(jù)，沒有分頁(yè)，結(jié)果內(nèi)存被吃盡。Socket無(wú)限建立連接，結(jié)果linux的文件句柄被耗盡。）
防火點(diǎn)：
對(duì)業(yè)務(wù)場(chǎng)景中資源的分配與申請(qǐng)需要做到上限控制，以及達(dá)到上限以后的邏輯處理（排隊(duì)，丟棄，告警）。可以采取一些滑動(dòng)窗口設(shè)計(jì)來(lái)將不需要過(guò)多處理的內(nèi)容分段直接送入下一個(gè)處理管道中。
依賴是未知的
著火點(diǎn)：
事務(wù)中嵌入對(duì)于第三方系統(tǒng)的請(qǐng)求（例如在數(shù)據(jù)庫(kù)操作時(shí)去發(fā)送郵件或者緩存獲取內(nèi)容，結(jié)果連接池資源被Hold，導(dǎo)致系統(tǒng)不可用）。默認(rèn)依賴系統(tǒng)會(huì)給出結(jié)果，如果出現(xiàn)異常就反復(fù)重試，結(jié)果對(duì)方被壓垮，自己也犧牲。
防火點(diǎn)：
對(duì)于第三方系統(tǒng)的依賴能夠異步的就采用異步方式，能夠從主流程中剝離的就剝離。同時(shí)設(shè)計(jì)好容錯(cuò)的機(jī)制，采用本地時(shí)效性緩存減少對(duì)對(duì)方的壓力和依賴。最重要的就是注意系統(tǒng)間的死鎖，申請(qǐng)了一套資源處理業(yè)務(wù)邏輯，結(jié)果由于遠(yuǎn)端系統(tǒng)的不可用，導(dǎo)致本地資源的無(wú)法釋放，最后擊垮自己系統(tǒng)。
線程安全與性能
著火點(diǎn)：
對(duì)于線程不安全的對(duì)象處理一定要小心，否則業(yè)務(wù)出現(xiàn)異常的地方其實(shí)已經(jīng)離設(shè)計(jì)出現(xiàn)問(wèn)題的地方十萬(wàn)八千里，問(wèn)題時(shí)常成為靈異問(wèn)題，解決只有靠經(jīng)驗(yàn)。
防火點(diǎn)：
首先對(duì)于自己設(shè)計(jì)的類和方法需要注釋是否是線程安全的。同時(shí)明確類的使用場(chǎng)景，對(duì)線程安全及高性能作判斷，因?yàn)椴捎镁€程安全的對(duì)象一定會(huì)有性能損耗。最近給同學(xué)寫的一個(gè)Http消息的Lazy獲取參數(shù)，就是線程不安全的類，但是這個(gè)類只會(huì)保存在ThreadLocal中，因此不存在問(wèn)題。很直觀的一點(diǎn)判斷是否線程安全，就看看你設(shè)計(jì)的類里面的成員變量在多線程操作時(shí)候是否會(huì)有并發(fā)問(wèn)題，例如一個(gè)普通的Map，多個(gè)線程操作就會(huì)導(dǎo)致結(jié)果的不可估量性。
資源釋放
著火點(diǎn)：
正常邏輯都會(huì)將IO流關(guān)閉，Socket關(guān)閉，但是異常拋出時(shí)候，沒有走到資源釋放的流程中，產(chǎn)生了資源泄露問(wèn)題。另外，資源中可能會(huì)有內(nèi)嵌資源，當(dāng)內(nèi)部資源被外部的對(duì)象引用，則釋放將不成功，內(nèi)部資源依然會(huì)泄露。一些需要顯式回收的資源（例如ThreadLocal），如果不回收，那么下次線程被操作系統(tǒng)重用，則會(huì)出現(xiàn)莫名其妙的問(wèn)題（Java的線程創(chuàng)建和使用依賴于操作系統(tǒng)的實(shí)現(xiàn)）。
防火點(diǎn)：
Finally的處理。需要釋放的資源要做深度檢查。需要顯式回收的資源要確保使用完畢以后被回收（異常情況也需要考慮）。
創(chuàng)建與復(fù)用
著火點(diǎn)：
在以前設(shè)計(jì)Cache客戶端的時(shí)候，有同學(xué)給我建議說(shuō)我對(duì)于字節(jié)數(shù)組利用可以采取復(fù)用的方式，這樣可以減少對(duì)象的申請(qǐng)。但是做了一下測(cè)試，這樣的重復(fù)利用其實(shí)效果不像想象的那么好，甚至還不如直接創(chuàng)建。
防火點(diǎn)：
Java的垃圾收集器已經(jīng)在性能上有了很大的提高，同時(shí)對(duì)于對(duì)象的復(fù)用需要考慮對(duì)象復(fù)用前的初始化或者是內(nèi)容重置，這些得成本及復(fù)雜度可能遠(yuǎn)遠(yuǎn)要高于復(fù)用帶來(lái)的優(yōu)勢(shì)，因此需要根據(jù)具體的業(yè)務(wù)場(chǎng)景選擇復(fù)用和創(chuàng)建。當(dāng)然對(duì)于稀缺資源采用池的方式是最好的。
字符串處理，日志級(jí)別的選擇
著火點(diǎn)：
這兩個(gè)是小問(wèn)題，但是會(huì)帶來(lái)大麻煩。首先字符串的累加是老生常談的問(wèn)題，但是很多新手不以為然，當(dāng)你是一個(gè)高速運(yùn)轉(zhuǎn)的系統(tǒng)時(shí)，你就會(huì)發(fā)現(xiàn)1ms的延時(shí)在上千萬(wàn)次調(diào)用下回被無(wú)限放大，10byte的申請(qǐng)，在上千萬(wàn)次的請(qǐng)求下會(huì)帶來(lái)GC多次的操作（帶來(lái)的短暫處理停滯直接影響系統(tǒng)的可用性）。日志級(jí)別的隨意性會(huì)導(dǎo)致線上環(huán)境日志迅速膨脹，出錯(cuò)難以查找，影響系統(tǒng)的效率。（log4j優(yōu)化的再好也是要寫文件的，雖然是異步刷頁(yè)）
防火點(diǎn)：
謹(jǐn)慎處理字符串拼接，選擇線程安全或者不安全的兩個(gè)StringBuilder和StringBuffer。日志盡量區(qū)分清楚，debug和Info，前者純粹調(diào)試，可以有海量信息，Info一般用于系統(tǒng)或者模塊的狀況報(bào)告。Warn通常不建議使用了。Error就把你需要的關(guān)鍵信息都打出來(lái)。附帶這里說(shuō)一下對(duì)于日期對(duì)象的處理，在傳輸和保存的過(guò)程中，建議都還是采用long型，可以很好的提高性能及滿足國(guó)際化的需求。
原子操作與并發(fā)控制
著火點(diǎn)：
對(duì)于本地的對(duì)象操作通常情況下通過(guò)鎖機(jī)制保證并發(fā)的一致性，當(dāng)在設(shè)計(jì)一個(gè)對(duì)于資源訪問(wèn)控制的策略時(shí)，例如集群應(yīng)用處理某人每天發(fā)送短信1000條，這時(shí)候計(jì)數(shù)器保存在遠(yuǎn)端的集中式緩存中，采用get和put方式就會(huì)有并發(fā)問(wèn)題，因?yàn)樵趹?yīng)用獲得到999這個(gè)計(jì)數(shù)器值的時(shí)候，也許正有10000個(gè)請(qǐng)求也獲得了這個(gè)值，這樣原有的控制就失效了。
防火點(diǎn)：
其實(shí)就是一個(gè)原子操作的支持，本地?cái)?shù)據(jù)可以通過(guò)鎖來(lái)達(dá)到原子操作，遠(yuǎn)程依賴就需要對(duì)方系統(tǒng)提供原子操作接口來(lái)實(shí)現(xiàn)高并發(fā)下的業(yè)務(wù)處理，例如Memcached Cache提供的incr 和decr。結(jié)合黑名單策略，計(jì)數(shù)器可以發(fā)揮很多用途，包括及時(shí)監(jiān)控告警等。
接口實(shí)現(xiàn)與松耦合
著火點(diǎn):
沒有接口提供，團(tuán)隊(duì)間合作困難，無(wú)法Mock，相互之間進(jìn)度影響很大。同時(shí)業(yè)務(wù)實(shí)現(xiàn)的修改直接影響業(yè)務(wù)調(diào)用方，使得雙方耦合性很強(qiáng)，系統(tǒng)不穩(wěn)定性被放大。
防火點(diǎn)：
對(duì)外提供的服務(wù)，或者模塊間交互的服務(wù)都需要接口化?？蚣苄源a需要在模塊載入時(shí)考慮是否需要接口化定義，以便在不同環(huán)境可以切換不同實(shí)現(xiàn)提供對(duì)特殊場(chǎng)景的支持，同時(shí)也可以將具體實(shí)現(xiàn)延后交給使用者實(shí)現(xiàn)，使得框架更加靈活。Jdk對(duì)于xml的解析就是最好的范例。
靈活性和性能和可維護(hù)性的折中
著火點(diǎn)：
最近看了一些同學(xué)的代碼，看到大量的使用了反射，攔截器等。但是在線上環(huán)境運(yùn)行過(guò)程中就發(fā)現(xiàn)對(duì)于一些攔截器的配置疏漏導(dǎo)致系統(tǒng)性能大幅度降低。對(duì)于幾十個(gè)spring文件，有誰(shuí)能夠很清楚和直觀的了解到這些看似靈活和無(wú)侵入性的設(shè)計(jì)。
防火點(diǎn)：
對(duì)于業(yè)務(wù)邏輯不復(fù)雜，同時(shí)場(chǎng)景不多變的流程采用簡(jiǎn)單的實(shí)現(xiàn)，不要追求花哨的靈活性，帶來(lái)的只會(huì)是可讀性，可維護(hù)性，可用性的降低。
要有分布式和并發(fā)的觀念，但是不要本末倒置
著火點(diǎn)：
有些同學(xué)在做設(shè)計(jì)的時(shí)候考慮的很清晰，但是就是沒有考慮集群部署的情況，結(jié)果系統(tǒng)上線以后出現(xiàn)了無(wú)法集群部署的問(wèn)題。并發(fā)情況的設(shè)計(jì)也一樣，僅僅在滿足業(yè)務(wù)需求以后，對(duì)于多用戶并發(fā)操作的考慮缺失，導(dǎo)致系統(tǒng)流程錯(cuò)誤。
防火點(diǎn)：
設(shè)計(jì)的時(shí)候需要適度考慮這些問(wèn)題，但是是在滿足現(xiàn)有業(yè)務(wù)邏輯的前提下，不要為了追求分布式而分布式。
便利性的函數(shù)與性能的沖突
著火點(diǎn)：
首先申明的是這點(diǎn)適用范圍有限（高速運(yùn)轉(zhuǎn)的模塊）。對(duì)于String,Date等對(duì)象的便利性函數(shù)，例如正則匹配，分割，Format等等其實(shí)都會(huì)有不少的性能損耗。例如你只是需要判斷文件名最后的后綴是否滿足需求，采用了正則匹配，結(jié)果發(fā)現(xiàn)性能在高速運(yùn)轉(zhuǎn)的情況下大大下降。
防火點(diǎn)：
高速運(yùn)轉(zhuǎn)的模塊盡量采用原始方式或者半原始方式。例如上面說(shuō)到的文件后綴，就用string的endwith來(lái)判斷。對(duì)于一些字符串的替換，能夠用字符串拼接就拼接。對(duì)于一些字節(jié)流的處理也可以自己根據(jù)需求來(lái)訂制的寫?？偟囊痪湓挘軌驖M足的就用最低成本的方法。
防止系統(tǒng)設(shè)計(jì)的完備性成為攻擊或者壓力的瓶頸
著火點(diǎn)：
在很多設(shè)計(jì)的時(shí)候，對(duì)于一些系統(tǒng)設(shè)計(jì)講究比較完美。例如對(duì)于對(duì)象的查詢會(huì)分本地緩存，集中緩存，DB三個(gè)階段。當(dāng)對(duì)方攻擊采用不存在的資源名稱時(shí)候，這種分階段的設(shè)計(jì)反而會(huì)增加系統(tǒng)負(fù)荷。
防火點(diǎn)：
簡(jiǎn)化流程的分支和層次，對(duì)于消耗性資源的訪問(wèn)盡量減少或者沒有（采用黑名單本地緩存或者集中緩存的方式），同時(shí)改Pull為Push方式，通過(guò)控制數(shù)據(jù)變更點(diǎn)來(lái)通知相關(guān)系統(tǒng)，而非輪詢獲取更新狀態(tài)。
多級(jí)緩存和異步緩解異構(gòu)系統(tǒng)的瓶頸
著火點(diǎn)：
有時(shí)候設(shè)計(jì)系統(tǒng)時(shí)，服務(wù)提供方向我們?cè)S諾說(shuō)對(duì)方系統(tǒng)如何高效和健壯，但是當(dāng)頻繁訪問(wèn)產(chǎn)生網(wǎng)絡(luò)風(fēng)暴的時(shí)候，我們發(fā)現(xiàn)原來(lái)帶寬和網(wǎng)絡(luò)IO本身都會(huì)成為瓶頸。
防火點(diǎn)：
對(duì)于第三方系統(tǒng)的依賴，要做到松耦合就要從流程的異步化來(lái)實(shí)現(xiàn)。同時(shí)通過(guò)緩存的使用來(lái)達(dá)到，系統(tǒng)的高效性和降低對(duì)于第三方系統(tǒng)的依賴程度。這樣可以大大降低系統(tǒng)的瓶頸。
運(yùn)行期白盒化，模塊可重置
著火點(diǎn)：
系統(tǒng)運(yùn)行起來(lái)以后就無(wú)法在知道內(nèi)部的狀態(tài)，也無(wú)法對(duì)問(wèn)題組件進(jìn)行單獨(dú)處理，造成線上環(huán)境的不可知性和無(wú)法部分修復(fù)。不得不停機(jī)重起和看日志。
防火點(diǎn)：
模塊設(shè)計(jì)過(guò)程中考慮運(yùn)行期可觀測(cè)和可重置，提高系統(tǒng)的模塊化程度及健壯性。
站在用戶角度設(shè)計(jì)接口，提升系統(tǒng)可用性
著火點(diǎn)：
總是從自身業(yè)務(wù)體系和架構(gòu)去考慮如何設(shè)計(jì)對(duì)外接口，但是發(fā)現(xiàn)最后用戶使用的很別扭，同時(shí)由于需求不能直接被滿足，會(huì)多次反復(fù)調(diào)用接口，導(dǎo)致自身系統(tǒng)的壓力增大。例如對(duì)于一個(gè)狀態(tài)的檢查接口，是否提供一個(gè)狀態(tài)變更通知接口就會(huì)極大降低輪詢的壓力
防火點(diǎn)：
需要從客戶角度考慮問(wèn)題，設(shè)計(jì)接口，防止需求和實(shí)現(xiàn)脫節(jié)，導(dǎo)致系統(tǒng)壓力增加。
懶惰有時(shí)候是件好事
著火點(diǎn):
業(yè)務(wù)流程中很多耗時(shí)的操作在流程編排方面沒有考慮清楚，當(dāng)耗時(shí)工作做完以后，發(fā)現(xiàn)不符合最基本的交驗(yàn)，這樣就會(huì)導(dǎo)致系統(tǒng)無(wú)謂的增加了開銷。對(duì)于需要申請(qǐng)的資源，考慮處理流程的階段，階段性申請(qǐng)要優(yōu)于一次申請(qǐng)（不過(guò)需要注意死鎖）。
防火點(diǎn):
流程編排需要合理性，盡量將耗時(shí)的工作放到合理的位置，同時(shí)做好基礎(chǔ)的防攻擊輕量前端屏障邏輯，提高系統(tǒng)的健壯性。
主流程和副流程隔離
著火點(diǎn)：
SIP早先的日志分析模塊中有分析日志，備份，發(fā)郵件，更新系統(tǒng)緩存，操作數(shù)據(jù)庫(kù)等多種操作，但是一股腦兒都被放到一個(gè)流程中，結(jié)果當(dāng)郵件沒有發(fā)成功導(dǎo)致整個(gè)流程的失敗。
防火點(diǎn)：
把真正的主流程梳理出來(lái)，同時(shí)對(duì)于一些副流程可以考慮采用后臺(tái)異步方式完成，提高系統(tǒng)穩(wěn)定性。
模塊間接口交互，控制資源直接操作入口
著火點(diǎn)：
對(duì)于數(shù)據(jù)庫(kù)中的資源任何模塊不區(qū)分范圍都可以訪問(wèn)，最后導(dǎo)致數(shù)據(jù)結(jié)構(gòu)變更困難，業(yè)務(wù)對(duì)象管理混亂，模塊無(wú)法剝離獨(dú)立。
防火點(diǎn)：
模塊化設(shè)計(jì)的基本思想，模塊間通過(guò)接口交互獲得其他模塊管轄的數(shù)據(jù)，接口方式屏蔽了對(duì)于后端實(shí)現(xiàn)及業(yè)務(wù)對(duì)象的依賴。
學(xué)習(xí)份外的事情，配置決定成敗
著火點(diǎn)：
沒有SA就高不定環(huán)境，也無(wú)法了解操作系統(tǒng)的配置與Web容器的配置對(duì)于應(yīng)用的影響。沒有DBA就無(wú)法確定如何寫SQL避免一些簡(jiǎn)單的耗時(shí)查詢。沒有測(cè)試同學(xué)就無(wú)法作壓力測(cè)試，無(wú)法了解當(dāng)前系統(tǒng)性能。
防火點(diǎn)：
多學(xué)多問(wèn)，多了解一些其他崗位的內(nèi)容，才能夠更加全面的掌握好架構(gòu)設(shè)計(jì)。
不要迷信
著火點(diǎn)：
總是看到新技術(shù)如何有優(yōu)點(diǎn)，但是看不到它的成熟度?？偸锹牭胶芏嘟?jīng)驗(yàn)之談，但是從來(lái)沒有真的比較過(guò)。結(jié)果就是別人說(shuō)什么就是什么，系統(tǒng)地穩(wěn)定性和可用性基于Google出來(lái)的結(jié)果。
防火點(diǎn)：
需要聽取各種意見和經(jīng)驗(yàn)，同時(shí)用測(cè)試結(jié)果說(shuō)明問(wèn)題的結(jié)果，看代碼說(shuō)明結(jié)果背后的問(wèn)題。這樣才會(huì)走得更加踏實(shí)，學(xué)的更加實(shí)際。其實(shí)技術(shù)發(fā)展來(lái)說(shuō)，真正的基礎(chǔ)性內(nèi)容還是有限的，而且各種技術(shù)都是觸類旁通。分布式，不論是文件系統(tǒng)，DB，緩存都會(huì)遇到分布式的共性問(wèn)題（負(fù)載均攤，容錯(cuò)，數(shù)據(jù)復(fù)制，動(dòng)態(tài)擴(kuò)容等等），在結(jié)合一些文件系統(tǒng)，DB，緩存的自身特質(zhì)。因此扎扎實(shí)實(shí)學(xué)好基礎(chǔ)，了解Http協(xié)議，了解七層通信協(xié)議，了解文件系統(tǒng)設(shè)計(jì)，了解MapReduce思路，了解結(jié)構(gòu)化，半結(jié)構(gòu)化（bigmap），非結(jié)構(gòu)化存儲(chǔ)的要點(diǎn)，就會(huì)不會(huì)讓自己迷失在技術(shù)宣傳中。
明天晚上去北京參加系統(tǒng)架構(gòu)師會(huì)議，到時(shí)候會(huì)和大家分享一下TOP的一些商業(yè)和技術(shù)上的心得，準(zhǔn)備得很倉(cāng)促，但是個(gè)人覺得分享就在于自己將自己知道的說(shuō)出來(lái)，時(shí)間不長(zhǎng)，45分鐘，能講的也不多，但是如果對(duì)于淘寶開放平臺(tái)有興趣的同學(xué)可以來(lái)聽一下。這里也算是做個(gè)廣告，不過(guò)不要期望過(guò)高，免得失望也大^_^。五年沒有來(lái)北京了，首都應(yīng)該也變化不小了。