我們有一個微服務體系結構，我們正在就如何向客戶端公開內部錯誤進行一些討論。通過微服務傳播錯誤的良好實踐
下面是一個例子：
讓我們假設我們有3個服務項目，服務A，B和C 當客戶端發送到服務，這是公衆的要求，該服務發送給服務B的請求向服務C發送一個請求（這是內部的，需要認證，但是憑證像環境變量一樣在內部存儲，而不是由客戶端發送）。
由於某種原因，B和C之間的通信收到401（可能是422,403或任何客戶端相關的錯誤），這意味着該請求未被授權。
類似的東西：
B和C之間的通信是內部的，用戶不知道這些服務。我應該公開發送401給客戶端的內部結構嗎？鑑於這不是客戶的錯？我應該送500嗎？
最好避免明確暴露500狀態，但在某些情況下是必要的。用戶與您的系統一起工作，而不是特別的服務，對他而言，它並不重要。內部系統實施可能會有所不同，但用戶交互可以保持不變。
讓我們來看一個例如電子商務服務，B計費服務和C計費網關。用戶通過A向B購買產品，B向B發送賬單請求並與C通信以執行交易。 B和C之間的401可能是由於不同的原因。如果只是內部配置問題（沒有更新密碼，過期證書等），這是一個內部系統錯誤，您需要告訴用戶服務現在不可用或類似的東西，而不是傳遞所有內部錯誤細節。在這種情況下，您可以使用5xx代碼。也許服務B可以向某種隊列發出請求，並告訴服務A，一切正常，您的請求將在稍後處理。但是，如果是因爲用戶試圖使用不良信用卡或沒有足夠的錢（未授權請求），則需要顯示正確的消息和4xx響應代碼。
一般來說，一項服務會公開資源，並且它背後有多少內部或外部服務，數據庫，數據源等都無關緊要。 B和C之間的401可能意味着B去D服務（C替代），而A服務根本不應該知道約401。所以，這取決於你需要向用戶公開什麼，以及你需要如何處理不同的情況。
你的圖表沒什麼意義。在呼叫所有內部服務之後，直到它成功返回給用戶，來電不是200。
如果B和C之間的認證是內部的（服務器到服務器認證），那麼你有一個內部錯誤，而502是一個理智的選擇來返回A.當然，你可能決定在服務器A重試，因爲你從B得到了502，但是它沒有意義，因爲它是一個過期的標記。因此，您可以決定將內部401s升級回A的策略。或者，您可能會發現在502錯誤響應主體中附加元數據有助於重試機制。無論如何，服務器 - 服務器認證不應該失敗，它是一個有效的電話。
因此，如果C的身份驗證正在處理用戶提供的令牌，那麼用戶的身份驗證在呼叫期間用完（很少發生，但會發生） - 在這種情況下，令牌應該在系統中的其他位置這個調用（可能在A的SSO調用中）。但事實並非如此，所以將401返回到應用程序中的任何地方重定向到登錄頁面。
如果不是用戶的錯誤，那麼5xx是正確的響應代碼範圍。 –
@OliverCharlesworth我同意你的觀點，我應該在內部記錄這個錯誤，並且不要向用戶公開任何信息嗎？你怎麼看？ –
這取決於。但通常認爲不好，以便向用戶公開內部錯誤細節（如堆棧跟蹤）（從UX和安全的角度來看）。最多有一些消息，如「500服務器錯誤 - 唯一的錯誤ID是123456」，它允許您將用戶與錯誤日誌中的ID關聯起來。 –