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

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

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

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

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

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

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

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