Как организовать архитектуру взаимодействия микросервисов?

Question

[xhaskellx]

Коллеги, всем доброго дня!

Есть сферическая зачада сбацать бложик, используя микросервисный подход.
Бложик должен уметь:
1) регистрировать и авторизовывать пользователей
2) создавать/читать/редактировать посты
3) создавать/читать/редактировать комментарии к постам.

Решение я себе вижу так:
1) микросервис - аггрегатор - к нему идут все запросы от клиентов (браузер, мобилки, и тд). Далее он делает запросы к остальным микросервисам за данными (Aggregator)
2) микросервис для регистрации, хранения, авторизации пользователей. (User)
3) микросервис для работы с постами бложика (Post)
4) микросервис для работы с комментариями бложика (Comment)

Вопрос: как лучше организовать взаимодействие микросервисов между собой?

Мне на ум приходит примерно такая реализация:
- Пользователь, будучи залогинненым на бложике, заходит в свой блог. Aggregator принимает его запрос.
- Aggregator обращается к User для проверки авторизации и выборки ФИО текущего авторизованного пользователя
- Aggregator идет к Post для получения списка постов
- Post (или Aggregator?) идет к Comment для получения списка комментов по каждому посту
- Comment (или Aggregator?) опять идет к User для получения ФИО комментаторов

Но я не понимаю, как достичь максимальной атомарности и изолированности микросервисов. При падении одного из микросервисов это не должно класть все приложение - с микросервисами постов и комментариев мне все более-менее понятно, но меня сильно смущает сервис User, т.к. он участвует в авторизации и получаения ФИО авторов постов и комментаторов. Получается - это узкое место - при падении сервиса User отвалится все приложение:
1) нельзя авторизовать остальные сервисы
2) невозможно отобразить список постов или комментариев без ФИО их авторов.

Что посоветуете?

Answer 1

[Станислав Макаров]

Не нужно делать бложик на микросервисах, что для учебных целей, что для боевых.
Всё что вы описали о бложике - комменты, юзеры, посты - это всё достаточно сильно связанные данные, и их нет смысла обрабатывать в разных сервисах. В том решении, что вы предложили всё будет отлично, если заменить "микросервис" на "контроллер" (который из MVC), будет классическое решение учебной задачи.

Нужно придумать задачу, где сервисы будут более независимы друг от друга. Тогда и не будете мучаться чтобы понять, как сделать сервисы более автономными. В идеале любой сервис может продолжить свою работу, и реализовывать все или часть своих функций, если другие сервисы лежат. Хорошо например, если между сервисами А и Б взаимодействие реализовано через очередь сообщений - тогда упавший сервис Б после поднятия разгребёт эту очередь и выполнит всё то, что успел попросить у него сервис А пока Б лежал.

Об аутентификации можно тоже говорить много и долго, обычно чтобы жить некоторое время без сервиса аутентификации её делают по токенам (JWT например). Тогда целевой сервис сам может проверить, авторизован человек или нет.

Если уж так хочется бложик, то я бы оставил его в покое в виде самостоятельного сервиса, а в качестве других сервисов сделал бы:
- уведомления о новых комментариях/постах в мессенджер/почту (как раз хорошо будет через MQ общаться с основным сервисом);
- какую-нибудь аналитику элементарную, которая независимо собирается, например по посетителям, телеметрию короче;
- сервис автопостов - заказываешь пост с нужным содержимым на указанную дату и время, этот сервис пользуется API основного сервиса бложика и постит что-либо без вашего участия.

Вот уже что-то будет интересное. Обратите внимание, что пожалуй все из этих трёх сервисов могут работать без основного, и наоборот - основной сервис может класть сообщения в очередь для других сервисов (1-го и 2-го), и сервисы будут разгребать эту очередь пока работают.

Answer 2

[kn0ckn0ck]

1. реализовать сервис User таким образом, чтобы не было SPF
2. выбрать более адекватную задачу для подобной архитектуры

Comments

[bullock]

Что такое spf?

[kn0ckn0ck]

Single Point of Failure - единая точка отказа, особенность централизованных решений, которую иногда нужно правильно приготовить, чтобы снизить риски отказа

Answer 3

[grinat]

При таком подходе вся логика будет лежать в агрегаторе, а по факту все что он должен делать, это понять к кому запрос пришел и его туда послать, а тот сервис уже обработает. 3/4 это один сервис, а не два. 3/4 сам должен ходить к 2, иначе любая логика по проверке прав чуть отличная от userId!=autorizedUserId throw Forbidden() ляжет на агрегатор либо на 2. Если добавить еще фотогалерею, это уже будет еще один микросервис, в нем свои комменты и свои фото, за инфой об юзере он ходит тоже к 2. Тогда если накрывается 3/4, то работает фотогалерея, если накрывается фотогалереия, то работает 3/4. Если коммент отдельный сервис, то он если падает, падают все сотальные, плюс сложно обеспечить атомарность/целостность и т.п., поэтому у каждого сервиса они должны быть свои.