Я на самом деле читаю множество статей, касающихся архитектуры микросервисов, но, похоже, они разбираются с вещами самым простым способом, не углубляясь в объяснения.
Чтобы объяснить вам мои вопросы, я покажу вам мою настоящую маленькую архитектуру:
Итак, вот что я хочу использовать. Прежде чем что-то делать технически, мне нужно больше теоретической информации.
Описание моего домена
У меня есть несколько клиентов на мобильных устройствах и в браузерах, которые могут подключаться к приложению, получать информацию о своих пользователях и получать информацию о том, что они купили.
В монолитном приложении я бы использовал эту архитектуру: - Уровень представления с 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 в данном конкретном случае?
Спасибо за продвижение
