在進行系統開發的過程中，由於業務的需要通常可能會形成「服務a>服務b>服務c>…>服務n」這樣的呼叫鏈，不同的業務場景對於服務的依賴是有強弱之分的。只有結合業務場景的需要，對服務間的依賴關係做出合理性的判定，才能基於這份依賴關係對服務限流、服務容量、服務報警、**影響範圍、服務發布順序等做出合理的評估，將系統的評估工作更加精細化，從而保證系統的穩定執行。避免因為系統的依賴問題，導致服務不可用，使用者體驗降低，企業資損等的可能。
強依賴：假定服務a依賴於服務b，服務b出現故障不可用時，服務a也不可用，通常服務a會返回錯誤資訊，我們稱這種依賴為強依賴。
通過下面的流程圖，我們來分析一下強弱依賴。從圖中可以看到，在服務a中呼叫了服務b和服務c，但是他們的處理邏輯是不一樣的。
1、呼叫服務b：如果呼叫成功，則接著呼叫服務c；如果呼叫失敗，則服務a直接結束。這種場景我們稱之為服務a強依賴於服務b。
2、呼叫服務c：不管呼叫成功還是失敗，服務a會接續執行後續邏輯處理。這種場景我們稱之為服務a弱依賴於服務c。
**實現樣例：
package org.learn.depend;
public
class
dependdemo
catch
(exception e)
system.out.
println
("it`s completed");
}catch
(exception e)
}public
void
serviceb()
public
void
servicec()
}
在電商場景中，下單服務對於庫存服務的依賴就屬於強依賴，下單時必須校驗是否有庫存，只有在庫存充足的情況下才可以下單。在庫存服務不可用時，我們無法確認是否有庫存，此時下單服務強依賴於庫存服務，在下單時應該返回庫存相關的錯誤資訊。
在電商場景中，下單服務對於簡訊提醒服務的依賴就屬於弱依賴。在簡訊提醒服務不可用時，依然可以進行正常下單，只是使用者沒有收到簡訊提醒，但不影響整個下單流程。此時下單服務弱依賴於簡訊提醒服務。
服務a強依賴於服務b，當服務b不可用時，服務a要對服務b進行流量保護，防止過大的流量導致系統奔潰。同時要保證服務a不能癱瘓，在服務b恢復可用時，服務a也可以及時恢復可用。比如服務b不可用時，服務a對服務b進行多次重試，導致服務b直接奔潰。由於重試導致服務a中存在大量的待處理請求，最終導致服務a奔潰。
一般建議對服務b做降級處理，根據請求超時時間、併發請求數、請求失敗數、請求返回的錯誤碼做降級處理。服務a返回統一的錯誤資訊。
服務a弱依賴與服務b，當服務b不可用時，服務a仍然可以正常執行，通常情況下我們將業務場景中的非必要服務作為弱依賴。在**的處理上，可以分為一下集中方式：
1、服務a的主流程不依賴服務b的返回結果。
該場景可以有兩種解決方式：
1）可以啟動單獨的執行緒進行服務b呼叫。
2）在當前執行緒中發訊息，在訊息消費執行緒中訪問服務b。
2、服務a的主流程依賴服務b的返回結果。
與強依賴處理有些類似，一般建議對服務b做降級處理，根據請求超時時間、併發請求數、請求失敗數、請求返回的錯誤碼做降級處理。同時使用預設值來代替服務b的返回結果，預設值的設定需要根據具體的業務場景進行分析。
在系統設計時一定要考慮系統的強弱依賴，著重注意一下幾點：
1、在系統設計時要全面分析系統的強弱依賴關係，在系統上線後可以通過工具採集線上流量進一步分析依賴關係。
2、在強弱依賴發生變換時，要充分評估此項變更的風險，避免資損。
3、針對強依賴的服務，需要制定良好的應急預案進行兜底，同時應該提供良好的使用者體驗。
服務治理 理論篇 一
呱呱樂是一家網際網路金融公司。主營現金貸 p2p理財 消費分期業務。公司現有技術人員800名，系統極其龐雜，每日穩定處理25w左右的訂單量，有搶購活動時，系統的qps query per second 峰值達到了3w。系統雖然龐雜，但在技術老大c哥的帶領下，服務的可靠性高達99.99 技術方面的成績...
Eureka的服務治理
位址如下 一 服務的註冊與發現 關係呼叫說明 二 eureka簡介 eureka是spring cloud netflix微服務套件中的一部分，可以與springboot構建的微服務很容易的整合起來。eureka包含了伺服器端和客戶端元件。伺服器端，也被稱作是服務註冊中心，用於提供服務的註冊與發現。...
基於Eureka的服務治理
一 服務的註冊與發現 關係呼叫說明 二 eureka簡介 eureka是spring cloud netflix微服務套件中的一部分，可以與springboot構建的微服務很容易的整合起來。eureka包含了伺服器端和客戶端元件。伺服器端，也被稱作是服務註冊中心，用於提供服務的註冊與發現。eurek...