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

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

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

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

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

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

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

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

Вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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