1. 工業機器人
1.1. 具有多層防護措施，防止對人員、機器和設施造成損害
1.2. 防護措施能限制機器人的動作和傳感器的感知
1.3. 機械臂的旋轉范圍會遠遠小于它可以達到的全部運動范圍
2. 自動化
2.1. 它更像是工業機器人
2.1.1. 掌握控制層感知系統的當前狀態
2.1.2. 將其與期望的狀態進行對比
2.1.3. 對系統施加影響，使當前狀態進入到期望狀態
2.2. 自動化系統并未簡單地按照人類管理員的意愿行事
2.2.1. 自動化平臺與管理員關于系統預期狀態的不同“信念”的沖突，引發了2016年8月11日鏈接聚合網站Reddit遭遇停機事故
2.2.2. 刻意的手動更改與自動化平臺之間的沖突
2.3. 自動化使得管理員能夠花費較少的努力進行大量的操作，這就是一個力量倍增器
2.4. 自動化系統面對兩套相互沖突的指令時，也會卡殼
2.5. 由自動化所引發的操作，需要花時間才能完成
2.5.1. 這段時間通常會比監控的時間間隔要長，因此請務必考慮到系統需要經過一些延遲后，才能對操作做出回應
3. 控制層
3.1. 控制層中的軟體主要管理基礎設施和應用程式，而不是直接交付用戶功能
3.1.1. 日志記錄
3.1.2. 監控
3.1.3. 調度程式
3.1.4. 擴展控制器
3.1.5. 負載均衡器
3.1.6. 配置管理
3.2. 基礎設施管理工具可以迅速對系統產生巨大的影響，要在其內部構建限制器和防護措施，防止其快速毀掉整個系統
3.3. 控制層軟體中實作類似工業機器人的防護措施
3.3.1. 如果軟體觀測器顯示系統中80%以上的部分不可用，那么與系統出問題相比，軟體觀測器出問題的可能性更大
3.3.1.1. 被隔離的節點無法正確地感知當前狀態
3.3.1.2. 控制系統會感知環境，但它們有可能被愚弄
3.3.2. 運用滯后原則
3.3.2.1. 快速啟動機器
3.3.2.2. 要慢慢關機
3.3.2.3. 啟動新機器要比關閉舊機器更安全
3.3.3. 當期望狀態與觀測狀態之間的差距很大時，要發出確認信號，這相當于工業機器人上的大型黃色旋轉警示燈在報警
3.3.4. 那些消耗資源的系統應該設計成有狀態的，從而檢測它們是否正在試圖啟動無限多個實體
3.3.5. 構建減速區域，緩解勢能
3.3.5.1. 控制層雖然每秒都能感知到系統已經過載，但它啟動一臺虛擬機處理負載需要花費5分鐘
3.3.5.2. 大量負載依然存在的情況下，要確保控制層不會在5分鐘內啟動300個虛擬機
4. 緩慢的回應
4.1. 通常由過度的需求引起
4.2. 爭著使用已經供不應求的資料庫連接，會使回應變慢，進而加劇這種爭用，導致惡性回圈
4.3. 記憶體泄漏經常表現為回應緩慢
4.3.1. 記憶體泄漏會導致垃圾收集器過度運行，從而引發回應緩慢
4.4. 低層級的低效協議會導致網路停頓，從而導致回應緩慢
4.5. 對網站來說，回應緩慢會招致更多的流量
4.5.1. 那些等待頁面回應的用戶，會頻繁地單擊重新加載按鈕，為已經過載的系統施加更多的流量
4.6. 緩慢的回應會將呼叫系統和被呼叫系統中的資源拖得動彈不得
4.6.1. 生成回應較慢比拒絕連接或回傳錯誤更糟
4.7. 緩慢的回應傾向于逐層向上傳播，并逐漸導致層疊失效
4.7.1. 一旦陷入回應緩慢，上游系統本身的處理速度也會隨之變慢，并且當回應時間超過其自身的超時時間時，會很容易引發穩定性問題
4.8. 快速回傳系統失效資訊，能使呼叫方的系統快速完成事務處理，最終成功或是系統失效，取決于應用程式的邏輯
4.9. 讓系統具備監控自身性能的能力，就能辨別其何時違背SLA
4.9.1. 系統能跟蹤自己的回應情況，那么就可以知道自己何時變慢
4.9.2. 系統平均回應時間超出系統所允許的時間時，可以考慮發送一個即時錯誤回應
4.9.3. 當平均回應時間超過呼叫方的超時時間時，應該發送這樣的回應
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/555885.html
標籤：架構設計
上一篇：讀發布！設計與部署穩定的分布式系統（第2版）筆記09_一窩蜂和容量
下一篇：返回列表