在進行系統開發的過程中，由於業務的需要通常可能會形成“服務A>服務B>服務C>…>服務N”這樣的調用鏈，不同的業務場景對於服務的依賴是有強弱之分的。只有結合業務場景的需要，對服務間的依賴關係做出合理性的判定，才能基於這份依賴關係對服務限流、服務容量、服務報警、代碼影響範圍、服務發佈順序等做出合理的評估，將系統的評估工作更加精細化，從而保證系統的穩定運行。避免因爲系統的依賴問題，導致服務不可用，用戶體驗降低，企業資損等的可能。
一、定義
強依賴：假定服務A依賴於服務B，服務B出現故障不可用時，服務A也不可用，通常服務A會返回錯誤信息，我們稱這種依賴爲強依賴。
弱依賴：假定服務A依賴於服務B，服務B出現故障不可用時，服務A仍然可用，通常服務A會返回正確信息，只是與服務B相關的信息會不返回或者做默認處理，我們稱這種依賴爲弱依賴。
通過下面的流程圖，我們來分析一下強弱依賴。從圖中可以看到，在服務A中調用了服務B和服務C，但是他們的處理邏輯是不一樣的。
1、調用服務B：如果調用成功，則接着調用服務C；如果調用失敗，則服務A直接結束。這種場景我們稱之爲服務A強依賴於服務B。
2、調用服務C：不管調用成功還是失敗，服務A會接續執行後續邏輯處理。這種場景我們稱之爲服務A弱依賴於服務C。
代碼實現樣例：
package org.learn.depend;
public class DependDemo {
public void serviceA(){
try {
System.out.println("it`s serviceA");
/// serviceA 強依賴於 serviceB
serviceB();
try {
/// serviceA 弱依賴於 serviceC
serviceC();
} catch (Exception e){
e.printStackTrace();
}
System.out.println("it`s completed");
} catch (Exception e){
e.printStackTrace();
}
}
public void serviceB(){
System.out.println("it`s serviceB");
}
public void serviceC(){
System.out.println("it`s 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、針對強依賴的服務，需要制定良好的應急預案進行兜底，同時應該提供良好的用戶體驗。
文章內容僅代表個人觀點，如有不正之處，歡迎批評指正，謝謝大家。