Microservice, реестр служб, шлюз API и обмен данными

Я на самом деле читаю множество статей, касающихся архитектуры микросервисов, но, похоже, они разбираются с вещами самым простым способом, не углубляясь в объяснения.

Чтобы объяснить вам мои вопросы, я покажу вам мою настоящую маленькую архитектуру:

enter image description here

Итак, вот что я хочу использовать. Прежде чем что-то делать технически, мне нужно больше теоретической информации.

Описание моего домена

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

В монолитном приложении я бы использовал эту архитектуру: - Уровень представления с Mobile/Angular-Ember - Бизнес-уровень с REST API с NGINX перед ним - DAL со стандартной базой данных MySQL - Масштабируемость будет применяться только по оси X

Я хочу использовать микросервисную архитектуру в этом случае, потому что она "доменная масштабируемая" и действительно гибкая (и, конечно, больше узнать об этом).

На схеме в каждой службе есть единственный URL-адрес HTTP, предоставляемый соответствующим API.

Вопросы

a/ В потоке (1) "мобильный" отправляет запрос http на http://myDomain.or/auth.

На мой взгляд, APIGateway может запросить стандартный реестр служб (Eureka, ZooKeeper или что-то еще), чтобы определить, доступен ли AuthSrv и может ли он получить свой сетевой адрес. Затем ApiGateway может запросить AuthSrv и ответить на сервер

Это хороший способ заставить это работать? Нет ли проблемы с задержкой при работе с машинами X для доступа к данным?

b/ Flux (2) консультируется с реестром сервисов. Как может реестр служб понять, что все запросы на /auth, даже для дочерних URL-адресов, например /auth/other (если он был выставлен), связаны с этим сервисом по этому адресу ip: port?

c/ Поток (3) показывает, что в реестре служб есть доступный AuthSrv. (3-бис) показывает другое: AuthSrv недоступен. В небольшом приложении мы можем признать, что когда-то теряем несоответствие, но в большой системе, где сотни сервисов связаны, как мы можем справиться с дефицитом сервисов?

d/ В другом посте я спрашивал, как сохранить платежную информацию, потому что она относится к пользователю, из другого сервиса и другой базы данных.

В стандартной архитектуре я бы имел:

{
   billingInformations:{...},
   billingUser:ObjectId("userId")
}

В микросервисной архитектуре кто-то рекомендовал использовать:

{
    billingInformations:{...},
    billingUser:"/user/12365" // URL corresponding the the user Resource in the other service
}

Это лучший способ справиться с "обменом данными между службами", а не соединять службы?

e/ Когда я должен предпочесть использование протокола AMQP вместо протокола HTTP в данном конкретном случае?

Спасибо за продвижение

Ответы

Ответ 1

а/

Нет. Реестры сервисов, такие как Zookeeper, хранятся в памяти, гарантируя высокую пропускную способность и низкую задержку.

б/

В реестрах служб, таких как Zookeeper, вы можете сделать путь к файловой системе, например, регистрации услуг. Например /App 1/Service1 и/App1/Service2

с/

Не совсем понятно, в чем проблема.

д/

Образец, рекомендованный кем-то, представляет собой шаблон HATEOAS, который рекомендуется для ответа API.

е/

AMQP требуется только тогда, когда требуется связь между службами. Никогда не следует напрямую обращаться к API другой службы непосредственно из одной службы.

ИЗМЕНИТЬ

с/

В этом случае вам нужно реализовать резервную логику. Например, если услуга недоступна, время ожидания или какой-либо другой отказ, необходимо предпринять некоторые действия. Такие инструменты, как Netflix Hystrix, помогают достичь этого.

е/

Схема связи должна быть симметричной, несимметричной. Как показано ниже, enter image description here

Этот шаблон позволит развязать связь между микросервисами, обеспечивая гибкость.