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

1. 配置服務

1.1. 配置服務本身就是分布式資料庫

1.1.1. 像ZooKeeper和etcd這樣的配置服務

1.1.2. 受CAP定理和亞光速通信的限制

1.1.3. 可實作容量擴充，但不具備資源可伸縮性

1.1.4. 也會遭受相同的網絡創傷

1.2. 資訊并不僅僅從服務流向用戶端執行個體，執行個體也可以向服務報告其版本号（或送出SHA算法）和節點辨別符

1.3. 每次寫入配置服務，都必須經曆某種共識機制才能生效

1.4. 確定執行個體可以在沒有配置服務的情況下啟動

1.5. 確定執行個體在配置服務無法通路時不會停止工作

1.6. 確定配置服務的某個被網絡分隔的節點不具備關閉整個系統的能力

1.7. 要跨地理區域進行複制

2. 環境整備和部署服務

2.1. 部署是運維工作中的必經環節，是連接配接開發和生産的橋梁

2.2. 部署工具本身應該配備一個部署包庫

2.3. 對一些組織來說，部署就是DevOps

2.4. 推式部署工具

2.4.1. 使用SSH或其他代理工具，是以中央伺服器可以連接配接到目标機器上來運作腳本

2.4.2. 這些目标機器事先并不知道自己的角色，伺服器會統一将角色配置設定給它們

2.4.3. 對于長壽命的虛拟機甚至實體主機，推式部署工具就可以更簡單地進行設定和管理

2.5. 拉式部署工具

2.5.1. 特别适用于資源可擴充的場景

2.5.2. 拉式部署工具更依賴各台機器了解自己的角色

2.5.3. 機器上的軟體可以通路配置服務擷取有關其角色的最新資訊

2.6. 用于生産環境的建構包需要使用已知來源的程式庫，在一台“幹幹淨淨”的伺服器上運作

2.7. 可重複的建構工作非常重要，要確定在機器上可以運作的代碼在生産環境中也能運作

2.8. 任何廣泛使用的伺服器軟體都可用作攻擊武器，包括建構伺服器，諸如Jenkins、Bamboo或GoCD

2.8.1. 建構系統本身的插件是直接從網上下載下傳的

2.9. 金絲雀部署是建構工具需要完成的一項重要工作

2.9.1. “金絲雀”指一小組執行個體，它們率先獲得了系統的新版本

2.9.2. 在一段時間内，運作新版本的執行個體會與運作舊版本的執行個體共存

2.9.3. 如果金絲雀執行個體行為異常，或者其度量名額一直很低，那麼該建構就不會推送給剩餘的執行個體安裝

2.10. 金絲雀部署的目的就是在建構包到達使用者之前，拒絕其中糟糕的建構包

3. 指令與控制

3.1. 隻有當執行個體需要花費很長時間才能做好運作前的準備工作時，實時控制才有必要

3.2. 控制點

3.2.1. 重置斷路器

3.2.2. 調整連接配接池大小和逾時

3.2.3. 禁用特定的出站內建

3.2.4. 重新加載配置

3.2.5. 開始或停止接收負載

3.2.6. 特性開關

3.3. 開發人員不相信運維人員能正确地部署軟體并運作腳本

3.4. 運維人員不允許開發人員登入到生産機器更新資料庫模式

3.5. 這個信任的破裂本身就是一個需要解決的問題

3.5.1. 絕對不要在生産代碼中建構一個自我毀滅“按鈕”

3.5.2. 許多服務會采取公開一些控制的方法來更新資料庫模式，或者删除并重新設定所有資料

3.6. 重新整理緩存按鈕，這也是非常危險的

3.7. 指令隊列

3.7.1. 一個共享的消息隊列或釋出-訂閱總線，所有的執行個體都可以監聽

3.7.2. 有了指令隊列，一窩蜂效應就更容易發生了

3.7.3. 為每個執行個體添加一個随機的延遲時間，讓它們能夠分散地執行指令，這是避免一窩蜂效應的好方法

3.8. Watir或RoboForm這樣的圖形使用者界面測試工具

3.9. 對生産環境中長期的運維工作來說，圖形使用者界面是糟糕的管理界面。長期運維的最佳界面是指令行

3.10. 所有建構的軟體要麼必須維護，要麼被迫抛棄

3.11. 要選擇那些适合團隊規模和工作負載規模的工具

3.12. 可以從系統可見性開始，使用日志記錄、跟蹤和度量名額來建立明晰性

3.13. 當面對更大或更動态的系統時，可以使用配置、整備和部署服務來獲得杠杆作用

3.14. 一旦系統（在某種程度上）穩定下來，并且問題顯露出來，就要建立控制機制，這樣就能進行更精确的控制，而不僅僅是重新配置和重新啟動執行個體

3.15. 相比那些高度動态的環境，部署到長壽命機器上的大型系統從控制機制中受益更多

4. 平台廠商

4.1. 相對于雲供應商，平台能夠提供一個與之不同的特性——位置無關性

4.2. Kubernetes、Apache Mesos、Cloud Foundry以及Docker的Swarm Mode

4.3. 既然已經在平台上花了大價錢，就應該充分加以利用

4.3.1. 不要嘗試在它外面再包裝一層API，或自己提供一套腳本

5. 工具清單

5.1. 日志收集和搜尋

5.2. 度量名額收集和可視化

5.3. 部署

5.4. 配置服務

5.5. 執行個體安置位置

5.6. 執行個體和系統可視化

5.7. 排程

5.8. IP位址、覆寫網絡、防火牆和路由管理

5.9. 自動擴充控制器

5.10. ⑩告警和通知

6. 要點

6.1. 每個解決方案都會帶來新問題。随着系統容量的水準擴充和垂直擴充，我們幾乎将一切虛拟化了

6.2. 一旦知道整個系統發生了什麼，就能采取幹預措施

6.3. 需要了解自動化讓所有事情都運作得更快帶來的問題

6.3.1. 自動化缺乏人的判斷力，是以當出錯時，錯誤會發展得很快，這就需要我們在自動化中建立安全機制