讀釋出！設計與部署穩定的分布式系統（第2版）筆記28_控制層上

1. 控制層囊括所有在背景運作的成功處理生産負載的軟體和服務

1.1. 處理使用者生産資料的那些軟體，就是生産軟體

1.2. 主要工作是管理其他軟體的軟體，就是控制層

1.3. 工具和問題之間存在着重疊和空白，并不是每個工具組合都能協同工作，不存在能解決所有問題的萬能軟體包

1.4. 在內建工具時要耗費巨大的精力，進行大量的實驗，經曆無數的錯誤

2. 适合的控制層工具

2.1. 當考慮控制層時，請記住其中的每一部分都是可選的

2.1.1. 有了日志記錄和監控這些控制層選項，就有助于開展事後分析、事故恢複和缺陷發現等工作

2.1.2. 沒有這些選項，上述工作将花費更長的時間，甚至根本沒有辦法完成

2.2. 控制層越先進，其實作和運維的成本就越高

2.3. 控制層中的每個工具都有持續的運維成本

2.3.1. 将持續的運維成本看作權衡固定成本與可變成本

2.3.1.1. 專職運維人員的固定成本

2.3.1.2. 部署加速、事故恢複和服務整備等可變成本

2.4. 2007年

2.4.1. 記錄日志和監控幾乎是一個商業化的市場

2.5. 如今

2.5.1. 這個市場幾乎是開源的

2.5.2. 最困難的問題變成了如何從所有精良的開源軟體中選擇一個自己滿意的工具

2.6. 不要誤以為必須安裝所有工具

2.6.1. 控制層工具的發展日新月異，要持續評估不同解決方案的開銷和難度

3. 機械效益

3.1. 機械效益指人類可以依靠簡單機器增強自身力量

3.1.1. 阿基米德說過：“給我一個支點，我能撬動地球。”

3.2. 既能幫大忙，也能幫倒忙

3.2.1. 強大的杠杆作用使人花很少的力量就能做出巨大的改變

3.3. 運作得太快也有問題

3.3.1. 無論怎樣，一旦關閉的執行個體數量超過了總伺服器容量的50%，自動化工具就應該停下來，進而使人們能夠确認移除容量确實是正确的行為

4. 平台和生态系統

4.1. 監控團隊應該能夠幫助相關人員響應應用程式告警

4.2. 監控團隊不會進行監控，而會幫助其他人實作自行監控

4.3. 一種從占有某個領域向為客戶提供服務的思維轉變。

4.4. 監控團隊提供了一個開發團隊可以使用的接口，并負責編寫接口的實作細節，而且在持續支援其接口協定的過程中，可以随時改變實作細節

4.5. 監控團隊隻負責實作相關工具，讓其客戶通過這些工具實作自身的監控器

4.6. 平台團隊的資料庫管理者主要負責保持資料庫健康運作，資料庫管理者要確定資料庫具有足夠的容量

4.6.1. 資料庫管理者應該關注建立高性能和高穩定的平台

4.7. 資料模型的設計工作則由應用程式團隊負責

4.7.1. 一個應用程式能很輕易地做出有害的模式變更，進而影響其他資料庫消費者

4.7.2. 使用基于SQL的RDBMS要求我們為每個服務配置設定一個單獨的實體資料庫

4.8. 平台團隊的目标是為客戶賦能

5. 開發環境就是生産環境

5.1. 如果你的開發伺服器鏡像是一個帶有已知配置的全新虛拟機，那就太棒了

5.2. 如果QA環境和生産環境能由同一個自動化工具建立，并且QA環境存有經過匿名化處理的一周以來的生産環境使用者資料樣本，那麼你就繼續保持吧

5.3. 開發人員完成工作所需的工具、服務和環境，應該以生産級别的SLA對待

5.4. 開發平台就是創造軟體這項工作的生産環境

6. 整個系統的明晰性

6.1. 當網絡規模較大時，“部分系統故障”也是正常的運維狀态

6.2. 即使是網絡規模較小的場景，在一切都沒有運作的情況下，系統也應該能夠繼續“存活”一段時間

6.3. 真實使用者監控

6.3.1. real-user monitoring，也可稱其為RUM

6.3.2. 判斷使用者體驗的最佳方式是直接測量

6.4. New Relic或Datadog等服務

6.5. AppDynamics或CA公司的APM

6.6. 3個優勢

6.6.1. 能快速啟動，無須建構基礎設施或配置監控軟體，很有可能在一小時内就開始收集資料了

6.6.2. 能為各種技術提供代理軟體和連接配接器，這使所有監控內建到一處更加容易

6.6.3. 儀表盤和可視化界面往往比開源替代方案設計得更精美

6.6.4. 商業服務，需要支付訂閱費

6.7. 開源工具

6.7.1. 要投入人力和基礎設施等相對隐性的成本

6.8. 經濟價值高于技術價值

6.8.1. 大多數軟體則是為了創造經濟價值而存在

6.8.2. 成本也會源自運維工作量

6.8.2.1. 軟體越難以運維，人們在運維上所花費的時間就越多

6.8.3. 成本源自平台和運作時系統

6.8.3.1. 有些語言能讓程式員快速程式設計，但需要更多執行個體處理特定的工作負載（這樣就增加了成本）

6.8.4. 監控、日志收集、告警和儀表盤等手段的經濟價值，其實是高于其技術價值的

6.9. 日志和統計資訊

6.9.1. 日志收集器能以推或拉的模式進行工作

6.9.2. 推模式意味着執行個體能在網絡上推送日志，此時通常使用曆史悠久的syslog協定

6.9.3. 推模式對容器非常有用，它們無須額外儲存狀态，且通常沒有本地存儲

6.9.4. 使用拉模式，那麼收集器就在中央計算機上運作，且能連接配接所有已知主機進而遠端複制日志，服務隻将其日志寫入本地檔案

6.9.5. 僅将所有日志儲存在一台主機上，就已經小有成就了

6.9.6. Splunk在當今日志索引領域占據主導地位

6.9.7. 由Elasticsearch、Logstash和Kibana組成的“三駕馬車”則是另一組流行的工具

6.9.8. 度量名額

6.9.8.1. 大多數度量名額資料庫會對最近的樣本進行細粒度的度量

6.9.8.2. 随着樣本變老，它們會将樣本聚合到越來越大的時間跨度

6.9.8.2.1. 今天的網卡錯誤率能以秒為機關查閱

6.9.8.2.2. 如果要查閱過去7天的錯誤率，則最細能以分鐘為機關查閱

6.9.8.2.3. 如果要查閱7天之前的，則最細僅能以小時為機關查閱

6.9.8.2.4. 好處

6.9.8.2.4.1. 節省不少磁盤空間

6.9.8.2.4.2. 讓長時間跨度的查詢成為可能

6.10. 監控點

6.10.1. 流量訓示

6.10.1.1. 頁面請求量、頁面請求總數、事務計數、并發會話數

6.10.2. 每種類型的業務交易

6.10.2.1. 已處理的業務交易數量、被終止的業務交易數量、所創造的業務價值（以元為機關）、事務持續時長、業務轉化率、業務完成率

6.10.3. 使用者

6.10.3.1. 使用者群分析或分類、使用者使用技術的偏好、注冊使用者百分比、使用者數量、使用模式、使用中遇到的錯誤數量、登入成功數量、登入失敗數量

6.10.4. 資源池健康狀況

6.10.4.1. 是否處于啟用狀态、總資源數量（适用于連接配接池、worker線程池和其他所有資源池）、檢出資源的數量、高水位線、所建立的資源數量、所銷毀的資源數量、資源檢出的總次數、等待某資源而被阻塞的線程數量、某線程被阻塞等待的次數

6.10.5. 資料庫連接配接健康狀況

6.10.5.1. 抛出的SQLException數量、查詢數量、查詢的平均響應時間

6.10.6. 資料消費量

6.10.6.1. 用于展示的實體或行的數量、資料在記憶體和磁盤中的占用量

6.10.7. 內建點健康狀況

6.10.7.1. 斷路器狀态、逾時次數、請求數量、平均響應時間、良好響應數量、網絡錯誤數量、協定錯誤數量、應用程式錯誤數量、遠端端點的實際IP位址、目前并發請求數、并發請求高水位線

6.10.8. 緩存健康狀況

6.10.8.1. 緩存項數量、緩存所占記憶體量、緩存命中率、垃圾收集器重新整理的緩存項數量、緩存配置的上限、緩存項建立所用時間

6.10.9. 隐含的時間條件“最近n分鐘”或“自上次複位以後”

6.10.10. 要衡量系統連續的度量名額的标稱範圍，“用某時間段的平均值加上或減去兩個标準差”不失為一個實用的經驗法則

6.10.11. 不存在适用于所有組織的正确度量時間段

6.10.11.1. 對零售商來說，強烈地關注在“每年最忙一周”裡所得到的度量名額

6.10.11.2. 如旅遊、花卉和體育，與通路流量最相關的度量往往發生在節假日或重大活動期間