你應(yīng)該在系統(tǒng)中實現(xiàn)適量的故障隔離,以便產(chǎn)生實際的股東回報。你也許接著會問:“好的,多謝,那你能告訴我如何做到這點嗎?'
遺憾的是,答案取決于你特定的需求、發(fā)展速度、不可用性以及造成系統(tǒng)不可用的原因、客戶對可用性的期望值、簽署的可用性承諾以及各種因素的組合,它們產(chǎn)生的組合數(shù)量巨大,以至于我們不能向你描述出你的環(huán)境究竟需要什么。
簡而言之,你可以應(yīng)用一-些簡單的原則來提高你的可擴(kuò)展性和可用性。這里我們介紹了一些對你進(jìn)行故障隔離來說最有用的原則。
方法1:把最賺錢的功能放入泳道
無論你做什么,都要確保把最能賺錢的功能正確地與故障和其他系統(tǒng)的需求約束隔離開來。如果你運營的是一個電子商務(wù)站點,那么這可能是點擊“購買”按鈕觸發(fā)的購買流程,也可能是處理信用卡時的結(jié)賬流程。如果你運營的是一個提供內(nèi)容的站點,通過專有的廣告發(fā)布系統(tǒng)賺錢,那么就要確保廣告發(fā)布系統(tǒng)的功能與系統(tǒng)其他一切功能分離開來。如果你的站點是靠日常的注冊費賺錢的,那么就要確保從注冊到開賬單的流程都被正確地故障隔離了。
你也許有一些次級流程也 與站點賺錢的功能緊密相關(guān),那么理所當(dāng)然應(yīng)該也考慮為它們施加泳道。例如,在一個電子商務(wù)站點中,可能需要把搜索和瀏覽功能都放入泳道。在一個提供內(nèi)容的站點中,可能需要把訪問流量最大的區(qū)域放在它們自己的一個或多個泳道中,以幫助需求和產(chǎn)能推測。社交網(wǎng)絡(luò)站點應(yīng)該為最常被訪問的個人信息頁面全部或部分創(chuàng)建泳道。
方法2:把最容易引發(fā)故障的功能放入泳道
如果你在不斷地執(zhí)行季度故障回顧會議(如第8章所述),你發(fā)現(xiàn)你站點中的某些組件在反復(fù)地引發(fā)故障,那么在將來的余量項目中,絕對應(yīng)該考慮這些組件,并且應(yīng)該把這些區(qū)域隔離起來。季度故障回顧會議的目的是從我們過去的錯誤中吸取教訓(xùn)。如果由需求造成的可用性問題反復(fù)發(fā)生,我們就應(yīng)該把這些區(qū)域隔離起來,以防它們影響產(chǎn)品或平臺的其他部分。
方法3:根據(jù)自然界限劃分泳道
在多租戶的SaaS系統(tǒng)中,這種方法尤其有用,這種系統(tǒng)通常需要沿著Z軸擴(kuò)展,需要最大可擴(kuò)展性的站點和平臺通常都必須依靠沿Z軸的分段進(jìn)行擴(kuò)展,而最常用的是按照客戶進(jìn)行劃分。雖然這種劃分通常首先是在架構(gòu)的存儲或數(shù)據(jù)庫層實現(xiàn)的,但是接下來,我們應(yīng)該為從請求到數(shù)據(jù)存儲或數(shù)據(jù)庫的所有組件都創(chuàng)建泳道。
你可以把系統(tǒng)設(shè)計為在一一條泳道中運營一個或多個“租戶”。 如果你的平臺適合這樣做,那就充 通常,多租戶意味著你試圖通過共享資源而提高成本效率。在許多情況下,這種方法意味著分利用這一點。 如果你的某個租戶非常忙,就給它單獨分配一個泳道。而如果你的大多數(shù)租戶對你的平臺的使用率都很低,那么可以把它們分配到一個泳道中。原理大致如此。
故障隔離的設(shè)計備忘錄故障隔離的架構(gòu)的設(shè)計原則如下:
原則1:什么都不能共享(即盡可能少共享)。一個泳道內(nèi)共享的東西越少,這個泳道的故障隔離性越好。
原則2:什么都不能跨過泳道邊界。絕對不能跨泳道邊界進(jìn)行通信,否則就是邊界劃分不正確。
原則3:在泳道內(nèi)交易。你不能為服務(wù)創(chuàng)建泳道,因為這些服務(wù)之間的通信違背了原則2。
設(shè)計故障隔離的架構(gòu)的方法如下:
方法1:把最賺錢的功能放入泳道。絕對不要讓你的收款機(jī)受其他系統(tǒng)拖累。
方法2:把最容易引發(fā)故障的功能放入泳道。找出反復(fù)發(fā)作的故障的原因,把它們隔離起來。
方法3:根據(jù)自然界限劃分泳道。按照客戶劃分是很好的泳道劃分方法。
雖然方法很多,但提高網(wǎng)站設(shè)計的可擴(kuò)展性同時又不致讓你的CFO心臟病發(fā)作的道路還很漫長。
本文地址:http://m.blackside-inc.com//article/3896.html