Проверка работоспособности маршрута в настройке микросервиса (ish) за AWS ALB - PullRequest
Новая
       7

Проверка работоспособности маршрута в настройке микросервиса (ish) за AWS ALB

0 голосов
/ 06 июня 2018

Как назвать маршруты проверки работоспособности между несколькими службами за ALB?

Я перенес свой API и базу данных на AWS.Перед перемещением я разделил свой монолитный REST API на четыре службы:

  1. публичный API (к которому подключаются приложения и веб-сайты)
  2. административный API (для веб-сайта администратора)
  3. API обмена сообщениями (сервер веб-сокетов для связи с приложениями в режиме реального времени)
  4. работников (процессоры задач на основе очередей)

Я сейчас пытаюсь выяснить хорошую организацию маршрутов,Сначала были созданы два субдомена, api.mydomain.com и www.mydomain.com.

Я направил субдомен api в мой ALB, который маршрутизировал трафик только на основе пути, например:

  • "/ sockets" -> messaging-api
  • "/ admin" -> admin-api
  • "/" -> public-api

Сейчас я пытаюсь реализовать проверки здоровья маршрутов.Я хотел бы назвать их "/ здоровье".Но проверки здоровья должны быть направлены на каждую целевую группу.Поскольку ALB использует только маршруты, основанные на пути, я не могу иметь / health более чем на одном сервере.

Возможные решения:

1.Разделите службы по поддоменам

Я мог бы создать поддомен для каждой службы, например: - api.mydomain.com - sockets.mydomain.com - admin.mydomain.com

С помощью этой настройки я могиметь / здоровье в каждой службе без коллизий.

2.Разделяйте маршруты проверки работоспособности с помощью названия

. Я могу назвать маршрут проверки работоспособности по-разному для каждой службы, например:

  • api.mydomain.com / health-public-api
  • api.mydomain.com / health-messaging-api
  • api.mydomain.com / health-admin-api

Предложения?

Оба вышеперечисленныхРешения кажутся жизнеспособными, но я хотел бы знать, может ли одно из решений укусить меня позже, когда, например, будет добавлено больше сервисов, или когда я добавлю API GraphQL позже.

edit:

Я столкнулся с одним недостатком решения # 1.Мой локальный dev-enviromnemt настроен с docker образом для каждой службы и nginx для маршрутизации запросов.Кроме того, я использую ngrok , чтобы получить доступ к среде разработки из Интернета.

Я думаю, что было бы трудно решить разделение служб в зависимости от поддоменов, но мне действительно не нужны маршруты / health в среде dev, поэтому я думаю, что могу просто притвориться, что их там нет.

1 Ответ

0 голосов
/ 09 июня 2018

Отвечая на мой собственный вопрос в качестве документации и, возможно, некоторого вклада другим.

tl; dr: я выбрал третий вариант, разделяя все сервисы через первый уровень пути.Основное отличие от моей предыдущей структуры состоит в том, что мой основной API (он же public-api) переместился из корневого каталога в подпуть с именем / app .Я также переименовал его в app-api .

  • api.mydomain.com / app / ..
  • api.mydomain.com / admin / ..
  • api.mydomain.com / сокеты / ..
  • api.mydomain.com / auth / ..
  • www.mydomain.com /..

Это решение дает мне несколько плюсов и никаких минусов (я думаю).

Плюсы:

  • Простая маршрутизация запроса как в ALB, так и в локальной среде разработчика через nginx без дополнительной работы, необходимой для субдоменов SNI
  • , очень четко отделяет api от веб-сайтов
  • / маршруты работоспособности получают уникальные имена по умолчанию, поскольку они живут по разным путям.
  • приложения (веб-сайты и смартфоны) могут использовать общий URL-адрес api (api.mydomain.com/) и по-прежнему обращаться ко всем службам, т. е.им не нужно хранить несколько по-разному инициализированных подключений Axios.Не важно, но все же ..

Я также решил сделать / здоровье чуть более перспективным и стандартизировать следующую структуру в каждой службе.

  • api.mydomain.com / имя_службы / health
  • api.mydomain.com / имя_службы / health / is-up
  • api.mydomain.com / имя_сервера / health / готово

up = отвечать на запросы, ready = все зависимости подключены (т. Е. Базы данных и т. Д.)

  • / здоровье возвращает статус 200 вместе с объектом json, описывающим готовность.

  • / health / is-up отвечает 200 или ничего (т. Е. Вообще недоступен))

  • / health / is-ready отвечает 200, если все зависимости готовы, в противном случае 500.

целевые группы в AWS будут использовать / готова к проверкам работоспособности, но сейчас это то же самое, что и / is-up, так как я еще не реализовал тесты готовности.

...