マイクロサービスアーキテクチャの他のサービスからのエラーメッセージの処理
当社は、数千のサービスを含むマイクロサービスアーキテクチャでアプリケーションを実行しています。 50以上のサービスと通信するバックエンドアプリケーション「X」に取り組んでいます。フロントエンドサービスは他のサービスでリクエストを実行するためにサービス「X」を呼び出します。
問題：
フロントエンドは、他のサービスで何かが失敗したときに、ユーザーフレンドリーなメッセージを表示したいと考えています。
- 他のサービスはユーザーフレンドリーなメッセージを返しません。いくつかあるため、他のチームに変更を依頼することはできません。
- そのような合意されたエラーコードはありません。他のサービスは文字列エラーメッセージを返します。現在、UIに渡されます。時々、エラーメッセージはポインタ参照です（悪いコード：/）
可能な解決策：
エラーメッセージ文字列を確認し、サービスにユーザーフレンドリーなメッセージへのマッピングを含めます。ただし、呼び出し先のサービスがエラーメッセージを変更した場合は、問題が発生する可能性があります。カスタムエラーマッピングが見つからない場合のデフォルトのエラーメッセージへのフォールバック。
スケーラブルで持続可能なソリューションに関する他のアイデアはありますか？ありがとう！
免責事項
当社は、数千のサービスを含むマイクロサービスアーキテクチャでアプリケーションを実行しています。 50以上のサービスと通信するバックエンドアプリケーション「X」に取り組んでいます。フロントエンドサービスは他のサービスでリクエストを実行するためにサービス「X」を呼び出します。
まず第一に、何千ものランダムなサービスは、アーキテクチャーをアーキテクチャーのようなマイクロサービスにすることはできません。それでも、「全体」の特定の感覚と、サービス間の少しの配置が必要です。ガイドラインまたは経験則。
「全体」内でバックエンドをコンテキスト化する
私は、あなたのバックエンドはgatewayでもproxyでもないと思います。独自のビジネスと明確に定義された境界のあるコンテキストがあると思います。したがって、他のサービスに関しては、バックエンドはfacadeです。
ファサードとして、実装の詳細（たとえば、リモートサービスとの統合など）を非表示にすることは、その責任の1つです。フロントエンド（したがって、エンドユーザー）の場合、信頼できる対話者はXのみであり、実装の詳細は外部レイヤーに到達しません。内部で何が起こっても、それはユーザーのビジネスではありません。
これは、問題が発生したことをユーザーに通知できないという意味ではありません。できますが、これらの詳細を抽象化します。リモートが失敗しているという感覚を与えません。正反対に、Xの何かが失敗しました。それだけです。
私たちは何千もの可能な統合（+50 atm）について話しているので、起こりうる異なるエラーの数は重要です。ひとつひとつをカスタムメッセージにマッピングすると、エンドユーザーは非常に多くの（そしてコンテキスト化されていない）情報に圧倒されます。すべてのエラーを少数のカスタムエラーにマッピングすると、情報にバイアスがかかり、問題を追跡して解決することが難しくなります。
私の意見では、エラーメッセージは、問題を修正するために私たちにできることがあるという感覚をユーザーに提供する必要があります。
それでも、エンドユーザーが内部で何が行われているのかを知りたい場合は、組織全体にとってより便利な方法が他にもあります。
説明責任
他のサービスはユーザーフレンドリーなメッセージを返しません。いくつかあるため、他のチームによる変更をリクエストすることはできません。合意されたエラーコードはありません。
他のサービスは文字列エラーメッセージを返します。現在、UIに渡されます。時々、エラーメッセージはポインタ参照です（悪いコード：/）
開発者としてのあなたの責任は、これらの議論を利害関係者に公開することです。それは説明責任の問題です。私の意見では、技術的リーダーシップの漏えいがあり、それは分散システムに関しては本当の問題です。
技術的な構想はありません。存在する場合、サービスは、システムをスケーラブルにし、サービス間の統合を容易にするために対処された経験則に基づいて実装されます。現在、サービスは「全体」への貢献の感覚なしに乱暴に表示されているように見えます。
私があなたに要求されたことを実行するように依頼された場合（そして私はときどきそうでした）、私は現在のアナーキーをユーザーフレンドリーなメッセージに変えることはXの範囲を超えているかと主張します。
少なくとも、「手を挙げなさい」、あなたの懸念を明らかにし、あなたの選択肢を明らかにし、説明責任のある人なら誰でも決定できるようにしましょう。
ソリューションを会社にとって価値あるものにする
エラーメッセージ文字列を確認し、サービスにユーザーフレンドリーなメッセージへのマッピングを含めます。ただし、呼び出し先のサービスがエラーメッセージを変更した場合は、問題が発生する可能性があります。カスタムエラーマッピングが見つからない場合のデフォルトのエラーメッセージへのフォールバック。
あなたが正しいです。それは弱い解決策です。中長期的にはもろくて非効率的です。
また、これらの文字列を変更すると、マッピングの屈折が必要になる可能性があるため、結合が発生すると思います。大きな改善ではありません。
スケーラブルで持続可能なソリューションに関する他のアイデアはありますか？
レポート。エラーを処理し、code/ticket/idを指定してレポートします。次に、フロントエンドがレポートを視覚化できるようにします。たとえば、レポートserviceへのリンクを共有します。
エラー。 <ユーザーフレンドリーで非常にデフォルトのエラーメッセージ>。詳細についてはlinkをたどってください
このようにして、必要な数のサービスを統合できます。そして、ランダムな文字列を処理して新しいランダムな、しかしユーザーフレンドリーな文字列に変換するオーバーヘッドから解放されます。
レポートサービスは残りのサービスで再利用できるため、IDを関連付けている場合は、ユーザーがエラーと原因をパノラマで確認できるようにする必要があります。分散アーキテクチャでは、トレーサビリティが非常に重要です。
その後、レポートサービスは、エラーXが発生した場合の対処方法について読みやすく有用な指示を提供するために必要なだけのマッピングで拡張できます。ここで文字列が変更されても問題はありません。私たちが持っているもの（ストア）は、レポートの最終状態です。
レポートサービスはパブリックAPI（つまりコントラクト）を公開するため、組織内のエラーを正規化する可能性への扉を開きます。
あなたの場合奇跡はありません。可能な解決策は、すでに提案した解決策のようです。
エラーメッセージ文字列を確認し、サービスにユーザーフレンドリーなメッセージへのマッピングを含めます。ただし、呼び出し先のサービスがエラーメッセージを変更した場合は、問題が発生する可能性があります。カスタムエラーマッピングが見つからない場合のデフォルトのエラーメッセージへのフォールバック。
APIがエラーメッセージを変更するのは問題ありませんif APIも何らかのエラーコードを返します。APIコンシューマは、エラーを追跡し、別のメッセージ（たとえば、メッセージ付き）。
フォールバックエラーを実行する前に、APIが返したメッセージのみをログに記録してください。おそらく、カスタムエラーの何らかのdeveloperMessageにAPIメッセージを追加して、ログを使用せずに問題を特定できるようにすることができます（APIが適切な情報を含むメッセージをスローしないことを確認してください）。
このサービスを実行しているチームとの通信チャネルがある場合は、APIを使用しようとしている別のチームと同じ問題である可能性があるため、問題を説明し、支援を求めてください。