ローカルでのマイクロサービスの開発とデバッグ
ユースケース：
私はマイクロサービスベースのアーキテクチャに取り組んでおり、開発しているローカルマシンでマイクロサービスをデバッグする方法（IDEがアタッチされている））をどのようにデバッグするのだろうと思っています。
問題：
今日までは、Webプラットフォーム全体に対していくつかのマイクロサービス（〜4〜7）しかありませんでした。単一のプラットフォームをデバッグするには、ドッキングされていないすべてのマイクロサービスを開始し、デバッグ対象のマイクロサービスにブレークポイントを設定するだけでした。
しかし、私のプラットフォームはより複雑になりました。これですべてのマイクロサービスをドッキングしました。Filebeat（Elasticによって作成されたツールで、基本的にはDocker出力をLogstashに転送します）、Prometheus + Grafana、zipkin（パフォーマンスモニタリング）、 RabbitMQなど。ご覧のとおり、プラットフォーム全体をデバッグするには、かなりの数のDockerコンテナーを実行する必要があります。
私の質問：
IDEが他のサービスに依存している場合、デバッグしたい新しいマイクロサービスの開発をどのように処理しますか？
これは、あなたが説明するような複雑な設定に対して私が行うことです。
マイクロサービスを作成するときは常に、そのマイクロサービスのクライアントを同じインターフェイスに作成します。統合サービスに対してクライアントをテストし、トラフィックを記録します。
次に、応答を取得するためにサービスを呼び出す代わりに、以前に記録したトラフィックで満たされたファイルをロードする、模擬クライアントを記述します。
これで、最初の依存関係を持つ次のマイクロサービスは、テストで実際の依存関係の代わりにモッククライアントを使用できます。
記録されたデータを使用すると、実際のサービスから新しい応答をすばやく生成して、テストケースに適合させることができます。または、本番環境のバグを特定したログに記録された応答を使用することもできます。
IDE）で新しいテストケースを記述してサービスをデバッグできるようになりました。すべての依存サービスをセットアップする必要はありません。
マイクロサービスが適切に設計されている場合、各サービスはビジネス機能を満たします。これは、ユーザーストーリーのコレクションと受け入れ基準によって記述されます。これらのユーザーストーリーと許容基準は、サービスレベルでテストする必要があります。したがって、すべてのサービスストーリーをカバーするテストを作成し、残りを模擬します。これは、単一のサービスを開発およびデバッグするのに十分なはずです。
すべてのサービスが意味のあることを行うために他の多くのサービスを必要とするためか、このアプローチが有効ではないと思われる場合は、サービスが小さすぎるか、正しく分割されていないかを検討する必要があります。このアプローチを適用する必要があるかもしれませんが、単一のサービスを実行する代わりに2または3を実行しますが、システム全体または多くのサービスを実行することはありません。それはおそらく私の考えでは悪いデザインを意味するでしょう。