原則一：假設(shè)故障總會發(fā)生（Design with failure in mind）

在設(shè)計和實現(xiàn)大型互聯(lián)網(wǎng)在線應(yīng)用時，架構(gòu)師必須考慮到系統(tǒng)各模塊、各應(yīng)用服務(wù)器、各開源應(yīng)用軟件的故障比率和失效的潛在原因。當(dāng)服務(wù)的可用性（Availability）成為系統(tǒng)設(shè)計的首要目標(biāo)時，尤其需要在設(shè)計階段就充分考慮如何在系統(tǒng)某部分發(fā)生故障時，仍然保持一定的服務(wù)可用性。一些基本的假設(shè)包括：

◆沒有Bug的軟件不存在，只是故障率高低不同，應(yīng)優(yōu)先關(guān)注高故障率應(yīng)用。

◆硬件總會發(fā)生故障，需要備份和冗余。

◆導(dǎo)致某應(yīng)用崩潰的請求，如不能及時終止或被redirect，可能會導(dǎo)致所有服務(wù)器一個接一個的癱瘓。

◆構(gòu)建僅包括最簡單輸入輸出邏輯和固定輸出內(nèi)容的Dot 模式Server，以應(yīng)對應(yīng)用服務(wù)群大面積癱瘓或負載極限發(fā)生時的服務(wù)響應(yīng)。

◆每次release正式升級前，在模擬生產(chǎn)環(huán)境的Staging環(huán)境運行版本測試

原則二：數(shù)據(jù)分區(qū)處理（Partition Your Data）

在分布式計算環(huán)境下，如何高效的處理海量數(shù)據(jù)？如何在Bug發(fā)生后更加容易的重新批處理？一個基本的設(shè)計原則就是分區(qū)（Partition），即將待處理信息按照生成節(jié)點、內(nèi)在一致性（Self Contain）、時間等因素進行分組，讓每個平行處理節(jié)點可盡量僅處理切分后的數(shù)據(jù)，而減少節(jié)點間的數(shù)據(jù)交換。分區(qū)的基本原則包括：

◆應(yīng)用流量均衡Load Balance和數(shù)據(jù)分區(qū)結(jié)合

◆容易在分組內(nèi)進行再分區(qū)

◆減少分組數(shù)據(jù)之間的狀態(tài)依賴

◆減少數(shù)據(jù)中心之間的數(shù)據(jù)交換

原則三：冗余（Redundancy）

冗余幾乎是高可用系統(tǒng)設(shè)計的必然選擇，也是老生常談的話題，然而如何做到成本與效率的***平衡則是架構(gòu)設(shè)計考慮的重點?？梢詤⒖嫉慕?jīng)驗包括：

◆優(yōu)先減少單點故障。

◆單個應(yīng)用可快速重啟恢復(fù)。

◆應(yīng)用間減少啟動和運行依賴，盡量可獨立工作。

◆與其依賴熱備冗余，不如建立服務(wù)中斷后的快速恢復(fù)預(yù)案（依賴熱備系統(tǒng)，在實戰(zhàn)中總是很難理想地恢復(fù)全部服務(wù)）。

原則四：監(jiān)控，監(jiān)控，還是監(jiān)控（Monitor, monitor, monitor）

從應(yīng)用部署到數(shù)據(jù)中心的***天開始，就要意識到，沒有人能夠7x24小時的盯著幾十個應(yīng)用系統(tǒng)，近百個應(yīng)用程序的運行狀態(tài)。有沒有down機，有沒有程序崩潰，有沒有數(shù)據(jù)庫死鎖，服務(wù)是否始終可用，這些不但是困擾工程師的問題，更是牽扯到客戶支持，乃至建立產(chǎn)品品牌的重要問題。如果你想"一切盡在掌握"，不想經(jīng)常（偶爾總是有的，因為未知故障總會發(fā)生）在凌晨被運營團隊的電話叫醒，那么趕快set up你的自動監(jiān)控系統(tǒng)，讓你的生活輕松起來吧。

至少有兩大類的Monitor群組需要建立起來：

從客戶角度：

◆服務(wù)的可用時間/失效時間

◆服務(wù)響應(yīng)延遲

◆客戶累積服務(wù)次數(shù)

從系統(tǒng)容量角度：

◆各應(yīng)用服務(wù)器的CPU/內(nèi)存/存儲負載統(tǒng)計

◆高峰與平均比（Peak to mean ratio）

◆應(yīng)用服務(wù)失效/崩潰/延遲報警

◆應(yīng)用服務(wù)自動恢復(fù)通知

◆數(shù)據(jù)同步延遲和失效警報

◆后臺日常處理日報/周報/月報，趨勢圖

原則五：保持簡捷（Keep It Simple Stupid, KISS）

傳統(tǒng)軟件開發(fā)中的變更管理是一個難題，在互聯(lián)網(wǎng)應(yīng)用系統(tǒng)開發(fā)中變更則比過去更加頻繁，同時對產(chǎn)品質(zhì)量的要求則更高。面對這個難題，普遍的結(jié)論是，唯一不變的就是變化本身。然而實戰(zhàn)中，控制變化的規(guī)模和影響，仍然需要找出一些"以不變應(yīng)萬變"的準則，這對于提高產(chǎn)品開發(fā)效率和保持高質(zhì)量至關(guān)重要。

分清"保持"與"非保持"內(nèi)容

◆業(yè)務(wù)需求總會變化，屬于"非保持"，架構(gòu)設(shè)計上充分考慮其變化，而非特化。

◆而軟件本身像一個不斷成長進化的生命，有自己的DNA。找到DNA，就找到了"保持"，例如設(shè)計的可擴展性，可維護性，可測試性。

簡單原則

◆代碼寫得越多，維護越復(fù)雜，需要不斷地通過重構(gòu)來簡化。

◆復(fù)雜的系統(tǒng)容易出錯，維護成本高，要避免設(shè)計單個復(fù)雜系統(tǒng)。

◆如果測試人員需要費九牛二虎之力才能理解"天才"的設(shè)計和實現(xiàn)，***拋棄它。否則有一天你會為測試覆蓋率難以提高，故障重現(xiàn)困難而沮喪。

原則六：即時架構(gòu)（Just in Time Architect）

即時架構(gòu)是在尋找***設(shè)計和資源限制之間所做出的實用選擇，此原則可能更加適用于快速變化的軟件開發(fā)領(lǐng)域，例如互聯(lián)網(wǎng)，而非嚴謹?shù)漠a(chǎn)品線軟件開發(fā)。"設(shè)計"和"重構(gòu)"成為每個版本開發(fā)周期中不斷重復(fù)的迭代步驟。

即時設(shè)計

◆在每個版本只有一個月的設(shè)計、開發(fā)和測試周期的約束下，要將基礎(chǔ)設(shè)施（Infrastructure）一次設(shè)計到***狀態(tài)是不可能的。

◆基礎(chǔ)架構(gòu)可滿足未來6個月至1年（視業(yè)務(wù)增長與投入的預(yù)測而定）應(yīng)用的擴展要求即可。

即時重構(gòu)

◆知道何時、何處需要重構(gòu)是關(guān)鍵，提前籌劃，而不要臨陣磨槍。

◆要為重構(gòu)預(yù)留足夠的開發(fā)資源。在FreeWheel，新產(chǎn)品開發(fā)，現(xiàn)有產(chǎn)品維護和基礎(chǔ)架構(gòu)重構(gòu)的資源比例大約是25% : 50% : 25%.

◆重構(gòu)不是"推到重來"，每次重構(gòu)一部分要好得多，否則你的測試團隊負擔(dān)太重，會導(dǎo)致產(chǎn)品質(zhì)量波動。

以上是FreeWheel中國研發(fā)團隊在研發(fā)Monetization Rights Management，MRM在線視頻廣告平臺過程中的一些實戰(zhàn)經(jīng)驗分享，在QCon 2009 Beijing大會演講內(nèi)容基礎(chǔ)上部分整理。

【編輯推薦】

1. 小規(guī)模低性能低流量網(wǎng)站架構(gòu)設(shè)計
2. 大型網(wǎng)站架構(gòu)不得不考慮的10個問題
3. 大中型網(wǎng)站架構(gòu)探秘