高性能、高流量互聯網應用架構設計實戰原則
原則一：假設故障總會發生（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大會演講內容基礎上部分整理。
【編輯推薦】
