私は現在、楽しみのために (gRPC トレースをサポートする) トレース ツールを作成しようとしていますが、このアーキテクチャについて適切に考えているかどうかについて混乱していました。追跡ツールは、リクエストのワークフロー/ジャーニー全体を追跡します (ユーザーがボタンをクリックした瞬間から、リクエストが API ゲートウェイに送られ、マイクロサービス間を行き来するまで)。
アプリケーションが書店で、最大 2 つのマイクロサービス (おそらくアカウントと書籍) に分割されているとします。ユーザー インターフェイスがあり、ボタンをクリックすると、ユーザーは本をお気に入りに登録できるとします。この例を単純にするために、2 つのマイクロサービスのみを使用しています。
**Different parts of the Fake/Mock up application**
UI ->
nginx -> I wanted to use this as an API Gateway.
microservice 1 -> (Contains data for all Users of a bookstore)
microservice 2 -> (Contains data for all the books)
**私の目標は、そのリクエストを追跡する方法を見つけることです。したがって、リクエストがnginxに送信されると想像できます
懸念事項 #1:リクエストが nginx に送信されるとき、それは HTTP です。クールですが、要求がマイクロサービスに送信されるときは、grpc 呼び出し (または http2 経由) です。nginx は http リクエストを取得し、そのリクエストを http2 経由で送信できますか? これを正しく表現しているかどうかはわかりません。nginx plus が http2 をサポートしていることは知っています。grpc にも grpc ゲートウェイがあることも知っています。
懸念事項 2:コンテナー化。両方のマイクロサービスを個別にコンテナ化する必要がありますか、それとも Docker コンテナ全体をコンテナ化する必要がありますか。nginx と docker をリンクするのは簡単ですか?
懸念事項 3: gRPC リクエストをトレースする場合 (リクエストが実行される時間を調べる場合)、ミドルウェア ロガーまたはトレース API (opentracing、jaegar など) を使用することを検討しています。gRPC が要求を行うのにかかる時間を他にどのように把握すればよいでしょうか?
これらの懸念に対処できるかどうか、私の思考プロセスが正しいかどうか、このアーキテクチャが機能であるかどうか疑問に思っていました。