Проблемы с архитектурой gRP C (gRP C, nginx, docker) - PullRequest
Новая
       149

Проблемы с архитектурой gRP C (gRP C, nginx, docker)

0 голосов
/ 13 июля 2020

В настоящее время я пытаюсь создать инструмент трассировки для развлечения (который поддерживает трассировку gRP C) и не понимал, правильно ли я думал об этой архитектуре. Инструмент трассировки отслеживает весь рабочий процесс / путь запроса (с момента, когда пользователь нажимает кнопку, до момента, когда запрос переходит на шлюз 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. Круто, но когда запрос отправляется в микросервис, это вызов grp c (или по http2). Может ли nginx получить HTTP-запрос, а затем отправить этот запрос по http2 ...? Не уверен, правильно ли я это формулирую. Я знаю, что nginx plus поддерживает http2. Я также знаю, что grp c также имеет шлюз grp c.

Проблема № 2: Контейнеризация. Должен ли я помещать в контейнер оба микросервиса по отдельности, или мне придется поместить в контейнер весь контейнер docker. Легко ли связать nginx и docker?

Проблема №3: ​​ При отслеживании запросов gRP C (выяснение, сколько времени выполняется запрос), я ' m рассматривает возможность использования для этого средства ведения журнала промежуточного программного обеспечения или API трассировки (opentracing, jaegar и др. c.). Как еще я мог бы выяснить, сколько времени требуется gRP C для выполнения запросов?

Мне было интересно, можно ли решить эти проблемы, правильно ли мой мыслительный процесс и является ли эта архитектура функцией .

1 Ответ

0 голосов
/ 13 июля 2020

Большинство отраслевых решений реализованы поверх решения для оркестрации контейнеров (Kubernetes, Docker Swarm и др. c). Обычно не рекомендуется «помещать в контейнеры» и самостоятельно управлять обратным прокси. Обратный прокси-сервер должен знать обо всех состояниях контейнеров (путем подключения к оркестратору) и динамически обновлять свою конфигурацию при создании, сбое или перемещении контейнера (из-за того, что машина выходит из строя). Kubernetes обрабатывает GRP C, используя сети me sh. Пожалуйста, взгляните на kubernetes service me sh. Если вы решили использовать Traefik и Docker Swarm, проверьте traefik h2 c support . В заключение рассмотрим более современные альтернативы Nginx, если вы хотите сбалансировать нагрузку GRP C.

...