4               依賴管理

在大規模服務中，依賴管理這個話題通常得不到應有的關注。一般的準則是，對於小型元件和服務的依賴關係，對於判斷管理它們的複雜性來說，並不足以節約成本。在以下情況中，依賴關係存在重要意義：

1. 被依賴的元件在大小和複雜度上有重要價值；

2. 被依賴的服務在作為單一的中央例項時存在價值。

第一類的例子有儲存和一致性演算法（consensus algorithm）的實現。

第二類的例子包括身份和群組管理系統。這些系統的整體價值在於它們是一個單一且共享的實力，因此使用多例項來避免依賴關係就不是可選方案。假定要根據上面的標準判斷依賴關係，那麼用來管理它們的最佳實踐有：

4.1               為延遲做好準備。

為延遲做好準備。對外部元件的呼叫可能需要很長時間才能完成。不要讓一個元件或者服務中的延遲在完全不相關的領域中引發延遲；確保所有的互動都存在長度合適的超時時長，避免資源阻塞更長的時間。運營等冪性允許請求在超時後重啟，即便這些請求可能已經部分或完全完成。確保所有的重啟操作都得到報告，並給重啟操作設定界限，從而避免反覆故障的請求消耗更多的系統資源。

4.2              

網站的架構必須能防止層疊的故障，要總是“快速失敗（fail fast）”。當依賴服務出現故障時，把這些服務標註為停機，並停止使用這些服務，以避免執行緒因等待故障元件而阻塞。

4.3               使用已經交付的歷經考驗的元件。

使用已經交付的歷經考驗的元件。歷經考驗的技術通常總是要比大膽前衛地走在潮流尖端執行要好很多。穩定的軟體要優於新版本的早期，不管新特性如何有價值。這條原則也適用於硬體。批量生產的穩定硬體，往往要比從早期釋出的硬體所獲得的些許效能提升要有價值得多。

4.4               實現跨服務的監控和警報。

實現跨服務的監控和警報。如果服務中有一個附屬服務過載，那麼被依賴的服務就必須瞭解這個情況，並且如果服務無法自動備份，那麼必須傳送警報。如果運營部門無法快速地解決這個問題，那麼服務就得設計得能容易迅速地聯絡到兩個團隊的工程師。所有相關的團隊都應當在附屬團隊中安排工程聯絡人。

4.5               附屬服務需要同一個設計點。

附屬服務需要同一個設計點。附屬的服務和附屬元件的生產者至少必須遵循與所屬服務相同的SLA（服務水平協議）。

4.6               對元件解耦。

對元件解耦。在所有可能的地方保證在其他元件故障時，元件可以繼續執行，可能在一個降級的模式中。例如，比起在每一個連線上重新驗證，維護一個Session鍵值，並且無論連線狀況如何，每過N小時就重新整理這個鍵值會更好些。在重新建立連線時，只使用現有的Session 鍵值。這樣的話在驗證伺服器上的負載就會更加一致，而且也不會在臨時網路故障和相關事件之後的重新連線過程中出現登入高峰期的情況。