[TOC] ## 概述 現今很多應用程序都是 **數據密集型data-intensive**的，而非 **計算密集型compute-intensive**的。因此CPU很少成為這類應用的瓶頸，更大的問題通常來自數據量、數據復雜性、以及數據的變更速度。 數據型應用常見場景: * 存儲數據，以便自己或其他應用程序之后能再次找到 （**數據庫（database）**） * 記住開銷昂貴操作的結果，加快讀取速度（**緩存（cache）**） * 允許用戶按關鍵字搜索數據，或以各種方式對數據進行過濾（**搜索索引（search indexes）**） * 向其他進程發送消息，進行異步處理（**流處理（stream processing）**） * 定期處理累積的大批量數據（**批處理（batch processing）**） ## 可靠性（Reliability） 1. 注意**故障（fault）**不同于**失效（failure）**。**故障**通常定義為系統的一部分狀態偏離其標準，而**失效**則是系統作為一個整體停止向用戶提供服務 1. 故障的概率不可能降到零，因此最好設計容錯機制以防因**故障**而導致**失效** 在這類容錯系統中，通過故意觸發來**提高**故障率是有意義的,例如： - 在沒有警告的情況下隨機地殺死單個進程。許多高危漏洞實際上是由糟糕的錯誤處理導致的，因此我們可以通過故意引發故障來確保容錯機制不斷運行并接受考驗，從而提高故障自然發生時系統能正確處理的信心 - Netflix公司的*Chaos Monkey*就是這種方法的一個例子 ### 硬件故障 如:硬盤崩潰、內存出錯、機房斷電、有人拔錯網線 - 據報道稱，硬盤的**平均無故障時間（MTTF mean time to failure）**約為10到50年,因此從數學期望上講，在擁有10000個磁盤的存儲集群上，平均每天會有1個磁盤出故障 - ? 為了減少系統的故障率，第一反應通常都是增加單個硬件的冗余度，例如：磁盤可以組建RAID ### 軟件錯誤 * 接受特定的錯誤輸入，便導致所有應用服務器實例崩潰的BUG。例如2012年6月30日的閏秒，由于Linux內核中的一個錯誤，許多應用同時掛掉了。 * 失控進程會占用一些共享資源，包括CPU時間、內存、磁盤空間或網絡帶寬。 * 系統依賴的服務變慢，沒有響應，或者開始返回錯誤的響應。 * 級聯故障，一個組件中的小故障觸發另一個組件中的故障，進而觸發更多的故障【10】。 ### 人為錯誤 最好的系統會組合使用以下幾種辦法: * 以最小化犯錯機會的方式設計系統。例如，精心設計的抽象、API和管理后臺使做對事情更容易，搞砸事情更困難。但如果接口限制太多，人們就會忽略它們的好處而想辦法繞開。很難正確把握這種微妙的平衡。 * 將人們最容易犯錯的地方與可能導致失效的地方**解耦（decouple）**。特別是提供一個功能齊全的非生產環境**沙箱（sandbox）**，使人們可以在不影響真實用戶的情況下，使用真實數據安全地探索和實驗。 * 在各個層次進行徹底的測試【3】，從單元測試、全系統集成測試到手動測試。自動化測試易于理解，已經被廣泛使用，特別適合用來覆蓋正常情況中少見的**邊緣場景（corner case）**。 * 允許從人為錯誤中簡單快速地恢復，以最大限度地減少失效情況帶來的影響。 例如，快速回滾配置變更，分批發布新代碼（以便任何意外錯誤只影響一小部分用戶），并提供數據重算工具（以備舊的計算出錯）。 * 配置詳細和明確的監控，比如性能指標和錯誤率。 在其他工程學科中這指的是**遙測（telemetry）**。 （一旦火箭離開了地面，遙測技術對于跟蹤發生的事情和理解失敗是至關重要的。）監控可以向我們發出預警信號，并允許我們檢查是否有任何地方違反了假設和約束。當出現問題時，指標數據對于問題診斷是非常寶貴的。 * 良好的管理實踐與充分的培訓——一個復雜而重要的方面，但超出了本書的范圍。 ## 可擴展性（Scalability） 服務**降級（degradation）**的一個常見原因是負載增加 ?**可擴展性（Scalability）**是用來描述系統應對負載增長能力的術語 負載可以用一些稱為**負載參數（load parameters）**的數字來描述,參數的最佳選擇取決于系統架構，它可能是每秒向Web服務器發出的請求、數據庫中的讀寫比率、聊天室中同時活躍的用戶數量、緩存命中率或其他東西 ### 推特發文實例 方式一: - 發布推文時，只需將新推文插入全局推文集合即可,當一個用戶請求自己的主頁時間線時，首先查找他關注的所有人，查詢這些被關注用戶發布的推文并按時間順序合并, 編寫如下查詢 ``` SELECT tweets.*, users.* FROM tweets JOIN users ON tweets.sender_id = users.id JOIN follows ON follows.followee_id = users.id WHERE follows.follower_id = current_user ``` 方式二: - 為每個用戶的主頁時間線維護一個緩存。 當一個用戶發布推文時，查找所有關注該用戶的人，并將新的推文插入到每個主頁時間線緩存中 推特的第一個版本使用了方法1，但系統很難跟上主頁時間線查詢的負載。所以公司轉向了方法2，方法2的效果更好，因為發推頻率比查詢主頁時間線的頻率幾乎低了兩個數量級，所以在這種情況下，最好在寫入時做更多的工作，而在讀取時做更少的工作 然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線緩存每秒345k的寫入 推特最終方法 推特逐步轉向了兩種方法的混合。大多數用戶發的推文會被扇出寫入其粉絲主頁時間線緩存中。但是少數擁有海量粉絲的用戶（即名流）會被排除在外。當用戶讀取主頁時間線時，分別地獲取出該用戶所關注的每位名流的推文，再與用戶的主頁時間線緩存合并，如方法1所示。這種混合方法能始終如一地提供良好性能 ### 描述性能 - 對于Hadoop這樣的批處理系統，通常關心的是**吞吐量（throughput）**，即每秒可以處理的記錄數量，或者在特定規模數據集上運行作業的總時間。 - 對于在線系統，通常更重要的是服務的**響應時間（response time）**，即客戶端發送請求到接收響應之間的時間 ## 可維護性（Maintainability） 在設計之初就盡量考慮盡可能減少維護期間的痛苦，從而避免自己的軟件系統變成遺留系統。為此，我們將特別關注軟件系統的三個設計原則 - 可操作性（Operability） ? 便于運維團隊保持系統平穩運行。 - 簡單性（Simplicity） ? 從系統中消除盡可能多的復雜度（complexity），使新工程師也能輕松理解系統。（注意這和用戶接口的簡單性不一樣。） - 可演化性（evolability） ? 使工程師在未來能輕松地對系統進行更改，當需求變化時為新應用場景做適配。也稱為可擴展性（extensibility），可修改性（modifiability）或可塑性（plasticity）。 ### 可操作性 一個優秀運維團隊的典型職責如下 * 監控系統的運行狀況，并在服務狀態不佳時快速恢復服務 * 跟蹤問題的原因，例如系統故障或性能下降 * 及時更新軟件和平臺，比如安全補丁 * 了解系統間的相互作用，以便在異常變更造成損失前進行規避。 * 預測未來的問題，并在問題出現之前加以解決（例如，容量規劃） * 建立部署，配置、管理方面的良好實踐，編寫相應工具 * 執行復雜的維護任務，例如將應用程序從一個平臺遷移到另一個平臺 * 當配置變更時，維持系統的安全性 * 定義工作流程，使運維操作可預測，并保持生產環境穩定。 * 鐵打的營盤流水的兵，維持組織對系統的了解。 ### 簡單性 **復雜度(complexity)** 有各種可能的癥狀，例如：狀態空間激增、模塊間緊密耦合、糾結的依賴關系、不一致的命名和術語、解決性能問題的Hack、需要繞開的特例 簡化系統并不一定意味著減少功能；它也可以意味著消除 **額外的(accidental)** 的復雜度 Moseley和Marks把**額外復雜度**定義為：由具體實現中涌現，而非（從用戶視角看，系統所解決的）問題本身固有的復雜度 用于消除**額外復雜度**的最好工具之一是**抽象（abstraction）** 比起重復造很多輪子，重用抽象不僅更有效率，而且有助于開發高質量的軟件。抽象組件的質量改進將使所有使用它的應用受益 例如 1. 高級編程語言是一種抽象，隱藏了機器碼、CPU寄存器和系統調用。 2. SQL也是一種抽象，隱藏了復雜的磁盤/內存數據結構、來自其他客戶端的并發請求、崩潰后的不一致性 ### 可演化性