1. 最大限度地避免直接對生產系統進行人為操作最為妥善

1.1. 人為干預生產環境會導致問題

1.1.1. 把“無須擺弄”做到極致，就是“不可變”的基礎設施，因為那里根本就不存在供人擺弄的途徑

1.1.2. 如果系統需要大量手動操作來保持運行，那么管理員就必須養成始終記日志的習慣

1.1.3. 通過限制系統管理員登錄生產環境服務器的需求，鼓勵更好的運維紀律

1.2. 系統應該能夠在沒有人工干預的情況下，至少運行一個發布周期

1.2.1. 系統應在無須手動清理磁盤或每晚重新啟動的情況下，至少運行一個發布周期

1.2.2. 在發布周期中，那些從版本控制系統中持續部署的微服務，應該非常易于實作穩定部署

2. 存盤桶

2.1. 穩態模式表明，針對每個累積資源的機制，要相應存在另一個機制回收該資源

2.2. 隨著資料的累積，存盤桶會以一定的速率填滿

2.3. 存盤桶必須以相同或更快的速率清空資料，否則最侄訓溢位

2.4. 當該存盤桶溢位時，壞事會發生

2.4.1. 服務器停機

2.4.2. 資料庫變慢

2.4.3. 拋出錯誤資訊

2.4.4. 回應長

3. 資料清除

3.1. 資料清除總會被忽視

3.2. 計算資源總是有限的，因此不能無限制地持續增加消費

3.3. 資料增長最明顯的癥狀，就是資料庫服務器上的I/O速率穩步增加

3.4. 在恒定的系統負載下，也能看到延遲時間會增加

3.5. 資料清除的另一半作業，是確保在清除資料之后應用程式仍能正常作業，而這需要進行編程和測驗

3.6. DBA可以通過創建腳本清除資料，但他們不知道洗掉資料之后，應用程式會如何運轉

3.6.1. 為了保持邏輯完整性（特別是在使用物件關系映射工具時），應用程式需要清除自己的資料

4. 日志檔案

4.1. 不要無限量保留日志檔案

4.1.1. 如果日志檔案無限制地增大，最侄訓填滿其所在的檔案系統

4.2. 檔案系統空間耗盡之后的狀況就無從得知了

4.2.1. 最好的情況，就是日志檔案系統與任何關鍵資料存盤（例如事務）是分離的，而且應用程式代碼本身具有足夠的安全防護能力，用戶永遠不會意識到有任何錯誤發生

4.3. 最好一開始就避免一直往檔案系統里添加內容

4.3.1. 基于日志檔案的大小來配置日志檔案回轉

4.4. 日志對系統的明晰性有極大的幫助，確保所有的日志檔案都能被回轉使用，并最終被清除

4.5. 生產環境系統的日志檔案信噪比很糟糕

4.5.1. 最好能盡快將日志檔案從單個主機上移走，發送到集中式日志記錄服務器（例如Logstash），進而對其進行索引、搜索和監控

4.6. 多年保留日志

4.6.1. 單個機器不可能把日志保留這么長時間，大多數機器的壽命也不會這樣長

4.6.2. 最好的辦法是盡快從生產環境的機器中取出日志，將它們存盤在中央服務器上，并對其密切監視，防止篡改

4.6.3. 如果合規性要求保留，則在非生產服務器上執行

5. 記憶體中的快取

5.1. 記憶體中的快取可以加快應用程式的運行速度

5.2. 若不對記憶體中的快取加以控制，執行速度會降低

5.3. 低記憶體的狀態對穩定性和容量都是威脅

5.3.1. 需要限制快取可消耗的記憶體量

5.4. 如果快取鍵數量沒有上限，則必須限制快取大小，并且采用某種形式的快取失效機制

5.5. 定時重繪快取是最簡單的快取失效機制

5.5.1. 定時重繪快取能夠處理90%的情況

5.6. “最近最少使用”或作業集演算法

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/556162.html

標籤：架構設計

上一篇：微服務架構基本原理學習筆記（三）

下一篇：返回列表

讀發布！設計與部署穩定的分布式系統（第2版）筆記14_穩態

1. 最大限度地避免直接對生產系統進行人為操作最為妥善

1.1. 人為干預生產環境會導致問題

1.1.1. 把“無須擺弄”做到極致，就是“不可變”的基礎設施，因為那里根本就不存在供人擺弄的途徑

1.1.2. 如果系統需要大量手動操作來保持運行，那么管理員就必須養成始終記日志的習慣

1.1.3. 通過限制系統管理員登錄生產環境服務器的需求，鼓勵更好的運維紀律

1.2. 系統應該能夠在沒有人工干預的情況下，至少運行一個發布周期

1.2.1. 系統應在無須手動清理磁盤或每晚重新啟動的情況下，至少運行一個發布周期

1.2.2. 在發布周期中，那些從版本控制系統中持續部署的微服務，應該非常易于實作穩定部署

2. 存盤桶

2.1. 穩態模式表明，針對每個累積資源的機制，要相應存在另一個機制回收該資源

2.2. 隨著資料的累積，存盤桶會以一定的速率填滿

2.3. 存盤桶必須以相同或更快的速率清空資料，否則最侄訓溢位

2.4. 當該存盤桶溢位時，壞事會發生

2.4.1. 服務器停機

2.4.2. 資料庫變慢

2.4.3. 拋出錯誤資訊

2.4.4. 回應長

3. 資料清除

3.1. 資料清除總會被忽視

3.2. 計算資源總是有限的，因此不能無限制地持續增加消費

3.3. 資料增長最明顯的癥狀，就是資料庫服務器上的I/O速率穩步增加

3.4. 在恒定的系統負載下，也能看到延遲時間會增加

3.5. 資料清除的另一半作業，是確保在清除資料之后應用程式仍能正常作業，而這需要進行編程和測驗

3.6. DBA可以通過創建腳本清除資料，但他們不知道洗掉資料之后，應用程式會如何運轉

3.6.1. 為了保持邏輯完整性（特別是在使用物件關系映射工具時），應用程式需要清除自己的資料

4. 日志檔案

4.1. 不要無限量保留日志檔案

4.1.1. 如果日志檔案無限制地增大，最侄訓填滿其所在的檔案系統

4.2. 檔案系統空間耗盡之后的狀況就無從得知了

4.2.1. 最好的情況，就是日志檔案系統與任何關鍵資料存盤（例如事務）是分離的，而且應用程式代碼本身具有足夠的安全防護能力，用戶永遠不會意識到有任何錯誤發生

4.3. 最好一開始就避免一直往檔案系統里添加內容

4.3.1. 基于日志檔案的大小來配置日志檔案回轉

4.4. 日志對系統的明晰性有極大的幫助，確保所有的日志檔案都能被回轉使用，并最終被清除

4.5. 生產環境系統的日志檔案信噪比很糟糕

4.5.1. 最好能盡快將日志檔案從單個主機上移走，發送到集中式日志記錄服務器（例如Logstash），進而對其進行索引、搜索和監控

4.6. 多年保留日志

4.6.1. 單個機器不可能把日志保留這么長時間，大多數機器的壽命也不會這樣長

4.6.2. 最好的辦法是盡快從生產環境的機器中取出日志，將它們存盤在中央服務器上，并對其密切監視，防止篡改

4.6.3. 如果合規性要求保留，則在非生產服務器上執行

5. 記憶體中的快取

5.1. 記憶體中的快取可以加快應用程式的運行速度

5.2. 若不對記憶體中的快取加以控制，執行速度會降低

5.3. 低記憶體的狀態對穩定性和容量都是威脅

5.3.1. 需要限制快取可消耗的記憶體量

5.4. 如果快取鍵數量沒有上限，則必須限制快取大小，并且采用某種形式的快取失效機制

5.5. 定時重繪快取是最簡單的快取失效機制

5.5.1. 定時重繪快取能夠處理90%的情況

5.6. “最近最少使用”或作業集演算法