文章來源地址http://www.zghlxwxcb.cn/news/detail-629803.html

1.?配置服務

1.1.?配置服務本身就是分布式數據庫

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

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

1.1.3.?可實現容量擴展，但不具備資源可伸縮性

1.1.4.?也會遭受相同的網絡創(chuàng)傷

1.2.?信息并不僅僅從服務流向客戶端實例，實例也可以向服務報告其版本號（或提交SHA算法）和節(jié)點標識符

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

1.4.?確保實例可以在沒有配置服務的情況下啟動

1.5.?確保實例在配置服務無法訪問時不會停止工作

1.6.?確保配置服務的某個被網絡分隔的節(jié)點不具備關閉整個系統(tǒng)的能力

1.7.?要跨地理區(qū)域進行復制

2.?環(huán)境整備和部署服務

2.1.?部署是運維工作中的必經環(huán)節(jié)，是連接開發(fā)和生產的橋梁

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

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

2.4.?推式部署工具

2.4.1.?使用SSH或其他代理工具，因此中央服務器可以連接到目標機器上來運行腳本

2.4.2.?這些目標機器事先并不知道自己的角色，服務器會統(tǒng)一將角色分配給它們

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

2.5.?拉式部署工具

2.5.1.?特別適用于資源可擴展的場景

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

2.5.3.?機器上的軟件可以訪問配置服務獲取有關其角色的最新信息

2.6.?用于生產環(huán)境的構建包需要使用已知來源的程序庫，在一臺“干干凈凈”的服務器上運行

2.7.?可重復的構建工作非常重要，要確保在機器上可以運行的代碼在生產環(huán)境中也能運行

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

2.8.1.?構建系統(tǒng)本身的插件是直接從網上下載的

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

2.9.1.?“金絲雀”指一小組實例，它們率先獲得了系統(tǒng)的新版本

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.?開發(fā)人員不相信運維人員能正確地部署軟件并運行腳本

3.4.?運維人員不允許開發(fā)人員登錄到生產機器更新數據庫模式

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

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

3.5.2.?許多服務會采取公開一些控制的方法來更新數據庫模式，或者刪除并重新設置所有數據

3.6.?刷新緩存按鈕，這也是非常危險的

3.7.?命令隊列

3.7.1.?一個共享的消息隊列或發(fā)布-訂閱總線，所有的實例都可以監(jiān)聽

3.7.2.?有了命令隊列，一窩蜂效應就更容易發(fā)生了

3.7.3.?為每個實例添加一個隨機的延遲時間，讓它們能夠分散地執(zhí)行命令，這是避免一窩蜂效應的好方法

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

3.9.?對生產環(huán)境中長期的運維工作來說，圖形用戶界面是糟糕的管理界面。長期運維的最佳界面是命令行

3.10.?所有構建的軟件要么必須維護，要么被迫拋棄

3.11.?要選擇那些適合團隊規(guī)模和工作負載規(guī)模的工具

3.12.?可以從系統(tǒng)可見性開始，使用日志記錄、跟蹤和度量指標來創(chuàng)建明晰性

3.13.?當面對更大或更動態(tài)的系統(tǒng)時，可以使用配置、整備和部署服務來獲得杠桿作用

3.14.?一旦系統(tǒng)（在某種程度上）穩(wěn)定下來，并且問題顯露出來，就要建立控制機制，這樣就能進行更精確的控制，而不僅僅是重新配置和重新啟動實例

3.15.?相比那些高度動態(tài)的環(huán)境，部署到長壽命機器上的大型系統(tǒng)從控制機制中受益更多

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.?實例和系統(tǒng)可視化

5.7.?調度

5.8.?IP地址、覆蓋網絡、防火墻和路由管理

5.9.?自動擴展控制器

5.10.?⑩告警和通知

6.?要點

6.1.?每個解決方案都會帶來新問題。隨著系統(tǒng)容量的水平擴展和垂直擴展，我們幾乎將一切虛擬化了

6.2.?一旦知道整個系統(tǒng)發(fā)生了什么，就能采取干預措施

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

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

到了這里，關于讀發(fā)布！設計與部署穩(wěn)定的分布式系統(tǒng)（第2版）筆記29_控制層下的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！