В настоящее время я пытаюсь создать инструмент трассировки для развлечения (который поддерживает трассировку 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: контейнеризация. Должен ли я помещать в контейнер оба микросервиса по отдельности, или мне придется помещать в контейнер весь контейнер докеров. Просто связать nginx и докер?
Проблема №3: при трассировке запросов gRPC (выясняя, сколько времени выполняется запрос) я подумываю использовать для этого средство ведения журнала промежуточного программного обеспечения или API трассировки (opentracing, jaegar и т. д.). . Как еще я мог бы выяснить, сколько времени требуется gRPC для выполнения запросов?
Мне было интересно, можно ли решить эти проблемы, верен ли мой мыслительный процесс и является ли эта архитектура особенностью.
