微服務架構中的錯誤傳播

Question

假設我有 3 個微服務 - A、B 和 C。

通過這些服務的通信模式如下所示： A -> B -> C 。

服務B和C可以拋出異常並向調用者返回 500。 在服務A中，我需要識別服務B或C是​​否拋出異常（返回 500）。 此類問題有哪些常見模式？ 我在想：

• 添加到B和C的響應的附加字段將表示導致問題的服務並通過服務傳播它，例如，如果服務C將返回 500，則該字段將被復制到服務B的響應並傳播到服務A 。 另一方面，如果服務B會引起問題，它會將此字段添加到其 500 響應中，其值表示服務B 。

• 通過異常類或錯誤消息識別哪個服務導致異常

兩種方法都有缺點 - 在第一種方法中，我必須處理將此字段附加到響應並將其從服務C通過服務B傳播到服務A ，如果它想將此行為添加到更多服務，則涉及大量代碼重復通過服務。 另一方面，在第二種方法的情況下，感覺不對。

您是否知道此類問題的任何模式或庫/框架？

Answer 1

對於這種典型問題，您必須使用斷路器模式 。 我建議您學習由Netflix團隊開發的Hysterix斷路器框架。 請點擊以下鏈接。

https://github.com/Netflix/Hystrix/wiki/How-it-Works

https://spring.io/guides/gs/circuit-breaker/

正如Turing85所評論的那樣，在調用服務b和服務c時不應影響服務A。

Answer 2

我和 Google 的其他人基於 Google 專有的 Java 服務框架為此開發了一個解決方案。

我可以用 HTTP 術語來描述它的最佳方式如下：

1. 該解決方案以Service Error Trace的形式在上游（在服務 A 中）提供錯誤源。
2. Service Error Trace類似於 Java 堆棧跟蹤，不同之處在於服務錯誤跟蹤包含代表錯誤傳播鏈而不是 Java 類和行號的服務/端點元組列表。
3. 每個服務都配備了負責構建此錯誤跟蹤的錯誤處理程序。 從頭開始創建它，或者將新的服務錯誤元素附加到跟蹤。 然后，處理程序使用響應端通道將這個錯誤推送到上游（在 HTTP 中，響應端通道類似於 HTTP 響應標頭）。
4. Service Error Trace中的第一項將是錯誤的來源。 錯誤的根源是我相信你所追求的。

希望能給您一些適合您用例的項目的想法！

M。