原則一：假設故障總會發生（Design with failure in mind）

在設計和實現大型互聯網在線應用時，架構師必須考慮到系統各模塊、各應用服務器、各開源應用軟件的故障比率和失效的潛在原因。當服務的可用性（Availability）成為系統設計的首要目標時，尤其需要在設計階段就充分考慮如何在系統某部分發生故障時，仍然保持一定的服務可用性。一些基本的假設包括：

◆沒有Bug的軟件不存在，只是故障率高低不同，應優先關注高故障率應用。

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

◆導致某應用崩潰的請求，如不能及時終止或被redirect，可能會導致所有服務器一個接一個的癱瘓。

◆構建僅包括最簡單輸入輸出邏輯和固定輸出內容的Dot 模式Server，以應對應用服務群大面積癱瘓或負載極限發生時的服務響應。

◆每次release正式升級前，在模擬生產環境的Staging環境運行版本測試

原則二：數據分區處理（Partition Your Data）

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

◆應用流量均衡Load Balance和數據分區結合

◆容易在分組內進行再分區

◆減少分組數據之間的狀態依賴

◆減少數據中心之間的數據交換

原則三：冗余（Redundancy）

冗余幾乎是高可用系統設計的必然選擇，也是老生常談的話題，然而如何做到成本與效率的***平衡則是架構設計考慮的重點。可以參考的經驗包括：

◆優先減少單點故障。

◆單個應用可快速重啟恢復。

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

◆與其依賴熱備冗余，不如建立服務中斷后的快速恢復預案（依賴熱備系統，在實戰中總是很難理想地恢復全部服務）。

原則四：監控，監控，還是監控（Monitor, monitor, monitor）

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

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

從客戶角度：

◆服務的可用時間/失效時間

◆服務響應延遲

◆客戶累積服務次數

從系統容量角度：

◆各應用服務器的CPU/內存/存儲負載統計

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

◆應用服務失效/崩潰/延遲報警

◆應用服務自動恢復通知

◆數據同步延遲和失效警報

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

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

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

分清"保持"與"非保持"內容

◆業務需求總會變化，屬于"非保持"，架構設計上充分考慮其變化，而非特化。

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

簡單原則

◆代碼寫得越多，維護越復雜，需要不斷地通過重構來簡化。

◆復雜的系統容易出錯，維護成本高，要避免設計單個復雜系統。

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

原則六：即時架構（Just in Time Architect）

即時架構是在尋找***設計和資源限制之間所做出的實用選擇，此原則可能更加適用于快速變化的軟件開發領域，例如互聯網，而非嚴謹的產品線軟件開發。"設計"和"重構"成為每個版本開發周期中不斷重復的迭代步驟。

即時設計

◆在每個版本只有一個月的設計、開發和測試周期的約束下，要將基礎設施（Infrastructure）一次設計到***狀態是不可能的。

◆基礎架構可滿足未來6個月至1年（視業務增長與投入的預測而定）應用的擴展要求即可。

即時重構

◆知道何時、何處需要重構是關鍵，提前籌劃，而不要臨陣磨槍。

◆要為重構預留足夠的開發資源。在FreeWheel，新產品開發，現有產品維護和基礎架構重構的資源比例大約是25% : 50% : 25%.

◆重構不是"推到重來"，每次重構一部分要好得多，否則你的測試團隊負擔太重，會導致產品質量波動。

以上是FreeWheel中國研發團隊在研發Monetization Rights Management，MRM在線視頻廣告平臺過程中的一些實戰經驗分享，在QCon 2009 Beijing大會演講內容基礎上部分整理。

【編輯推薦】

1. 小規模低性能低流量網站架構設計
2. 大型網站架構不得不考慮的10個問題
3. 大中型網站架構探秘