建站
咨詢
售后
建站咨詢
新聞中心
原則一：假設故障總會發(fā)生（Design with failure in mind）
在設計和實現(xiàn)大型互聯(lián)網(wǎng)在線應用時，架構(gòu)師必須考慮到系統(tǒng)各模塊、各應用服務器、各開源應用軟件的故障比率和失效的潛在原因。當服務的可用性（Availability）成為系統(tǒng)設計的首要目標時，尤其需要在設計階段就充分考慮如何在系統(tǒng)某部分發(fā)生故障時，仍然保持一定的服務可用性。一些基本的假設包括：
◆沒有Bug的軟件不存在，只是故障率高低不同，應優(yōu)先關(guān)注高故障率應用。
◆硬件總會發(fā)生故障，需要備份和冗余。
◆導致某應用崩潰的請求，如不能及時終止或被redirect，可能會導致所有服務器一個接一個的癱瘓。
◆構(gòu)建僅包括最簡單輸入輸出邏輯和固定輸出內(nèi)容的Dot 模式Server，以應對應用服務群大面積癱瘓或負載極限發(fā)生時的服務響應。
◆每次release正式升級前，在模擬生產(chǎn)環(huán)境的Staging環(huán)境運行版本測試
原則二：數(shù)據(jù)分區(qū)處理（Partition Your Data）
在分布式計算環(huán)境下，如何高效的處理海量數(shù)據(jù)？如何在Bug發(fā)生后更加容易的重新批處理？一個基本的設計原則就是分區(qū)（Partition），即將待處理信息按照生成節(jié)點、內(nèi)在一致性（Self Contain）、時間等因素進行分組，讓每個平行處理節(jié)點可盡量僅處理切分后的數(shù)據(jù)，而減少節(jié)點間的數(shù)據(jù)交換。分區(qū)的基本原則包括：
◆應用流量均衡Load Balance和數(shù)據(jù)分區(qū)結(jié)合
◆容易在分組內(nèi)進行再分區(qū)
◆減少分組數(shù)據(jù)之間的狀態(tài)依賴
◆減少數(shù)據(jù)中心之間的數(shù)據(jù)交換
原則三：冗余（Redundancy）
冗余幾乎是高可用系統(tǒng)設計的必然選擇，也是老生常談的話題，然而如何做到成本與效率的***平衡則是架構(gòu)設計考慮的重點?？梢詤⒖嫉慕?jīng)驗包括：
◆優(yōu)先減少單點故障。
◆單個應用可快速重啟恢復。
◆應用間減少啟動和運行依賴，盡量可獨立工作。
◆與其依賴熱備冗余，不如建立服務中斷后的快速恢復預案（依賴熱備系統(tǒng)，在實戰(zhàn)中總是很難理想地恢復全部服務）。
原則四：監(jiān)控，監(jiān)控，還是監(jiān)控（Monitor, monitor, monitor）
從應用部署到數(shù)據(jù)中心的***天開始，就要意識到，沒有人能夠7x24小時的盯著幾十個應用系統(tǒng)，近百個應用程序的運行狀態(tài)。有沒有down機，有沒有程序崩潰，有沒有數(shù)據(jù)庫死鎖，服務是否始終可用，這些不但是困擾工程師的問題，更是牽扯到客戶支持，乃至建立產(chǎn)品品牌的重要問題。如果你想"一切盡在掌握"，不想經(jīng)常（偶爾總是有的，因為未知故障總會發(fā)生）在凌晨被運營團隊的電話叫醒，那么趕快set up你的自動監(jiān)控系統(tǒng)，讓你的生活輕松起來吧。
至少有兩大類的Monitor群組需要建立起來：
從客戶角度：
◆服務的可用時間/失效時間
◆服務響應延遲
◆客戶累積服務次數(shù)
從系統(tǒng)容量角度：
◆各應用服務器的CPU/內(nèi)存/存儲負載統(tǒng)計
◆高峰與平均比（Peak to mean ratio）
◆應用服務失效/崩潰/延遲報警
◆應用服務自動恢復通知
◆數(shù)據(jù)同步延遲和失效警報
◆后臺日常處理日報/周報/月報，趨勢圖
原則五：保持簡捷（Keep It Simple Stupid, KISS）
傳統(tǒng)軟件開發(fā)中的變更管理是一個難題，在互聯(lián)網(wǎng)應用系統(tǒng)開發(fā)中變更則比過去更加頻繁，同時對產(chǎn)品質(zhì)量的要求則更高。面對這個難題，普遍的結(jié)論是，唯一不變的就是變化本身。然而實戰(zhàn)中，控制變化的規(guī)模和影響，仍然需要找出一些"以不變應萬變"的準則，這對于提高產(chǎn)品開發(fā)效率和保持高質(zhì)量至關(guān)重要。
分清"保持"與"非保持"內(nèi)容
◆業(yè)務需求總會變化，屬于"非保持"，架構(gòu)設計上充分考慮其變化，而非特化。
◆而軟件本身像一個不斷成長進化的生命，有自己的DNA。找到DNA，就找到了"保持"，例如設計的可擴展性，可維護性，可測試性。
簡單原則
◆代碼寫得越多，維護越復雜，需要不斷地通過重構(gòu)來簡化。
◆復雜的系統(tǒng)容易出錯，維護成本高，要避免設計單個復雜系統(tǒng)。
◆如果測試人員需要費九牛二虎之力才能理解"天才"的設計和實現(xiàn)，***拋棄它。否則有一天你會為測試覆蓋率難以提高，故障重現(xiàn)困難而沮喪。
原則六：即時架構(gòu)（Just in Time Architect）
即時架構(gòu)是在尋找***設計和資源限制之間所做出的實用選擇，此原則可能更加適用于快速變化的軟件開發(fā)領域，例如互聯(lián)網(wǎng)，而非嚴謹?shù)漠a(chǎn)品線軟件開發(fā)。"設計"和"重構(gòu)"成為每個版本開發(fā)周期中不斷重復的迭代步驟。
即時設計
◆在每個版本只有一個月的設計、開發(fā)和測試周期的約束下，要將基礎設施（Infrastructure）一次設計到***狀態(tài)是不可能的。
◆基礎架構(gòu)可滿足未來6個月至1年（視業(yè)務增長與投入的預測而定）應用的擴展要求即可。
即時重構(gòu)
◆知道何時、何處需要重構(gòu)是關(guān)鍵，提前籌劃，而不要臨陣磨槍。
◆要為重構(gòu)預留足夠的開發(fā)資源。在FreeWheel，新產(chǎn)品開發(fā)，現(xiàn)有產(chǎn)品維護和基礎架構(gòu)重構(gòu)的資源比例大約是25% : 50% : 25%.
◆重構(gòu)不是"推到重來"，每次重構(gòu)一部分要好得多，否則你的測試團隊負擔太重，會導致產(chǎn)品質(zhì)量波動。
以上是FreeWheel中國研發(fā)團隊在研發(fā)Monetization Rights Management，MRM在線視頻廣告平臺過程中的一些實戰(zhàn)經(jīng)驗分享，在QCon 2009 Beijing大會演講內(nèi)容基礎上部分整理。
【編輯推薦】
- 小規(guī)模低性能低流量網(wǎng)站架構(gòu)設計
- 大型網(wǎng)站架構(gòu)不得不考慮的10個問題
- 大中型網(wǎng)站架構(gòu)探秘
分享名稱：高性能、高流量互聯(lián)網(wǎng)應用架構(gòu)設計實戰(zhàn)原則
文章轉(zhuǎn)載：http://www.5511xx.com/article/codepji.html
