Как понять микросервисы?
Как понять микросервисы?
Прочитать соответствующую книгу (а лучше ещё парочку про DDD или хотя бы посмотреть этот доклад)

Затем ответить на несколько вопросов:
1. Почему вы решили, что микросервисы что-то вам дадут?
2. Есть ли у вас настоящие причины для микросервисной архитектуры? (А именно: зоопарк технологий с невозможностью написать 99% на одном языке; более тысячи разработчиков; сложность выкатки монолита в виде часов прогонов CI/CD — тестов, билда, деплоя, стопоров выкатки в виде кучи проблем из-за разработчиков; вы такие же большие как гугл, убер, амазон и т.п.). Или вам просто нравится модное слово "микросервисы"?

Не получится создать хорошую микросервисную архитектуру без умения создать хороший модульный монолит. В этом случае вы получите не только все проблемы плохого монолита: высокая связанность, каскадные падения, долгий CI/CD; но и все проблемы микросервисов: их надо оркестрировать (у вас же есть команда, которая будет поддерживать инфраструктуру?); каждому микросервису нужно своё CI/CD (и хорошее); сеть может (и будет) лагать и обрываться; длительность запросов увеличится на порядок(ки) (особенно если выбрать какой-нибудь JSON-RPC over HTTP); нужно предусмотреть failover strategy (например, идемпотентные ретраи. Вы же уже знаете про correlation id, саги и что делать, если прилетел network error на запрос в другой сервис "списать 10 баксов"?) и circuit breakers; трейсы и логи, которые не пришлось бы искать по сотням .log файлов от каждого сервиса; бизнес-логика расползётся по разным микросервисам и нарушит SRP (пофиг, что нарушит, важнее то, что это починить будет сильно сложнее). Список можно продолжать долго.
Добрый день!
Прежде всего ответьте на один вопрос - какую именно проблему вы хотите решить переходом на микросервисную архитектуру. Обратите внимание, что обеспечивать ACID в микросервисной структуре сложнее, чем в монолитах. Также обслуживание микросервисов тоже сложнее. Если есть нагрузка на сервис, то не факт, что вам нужны микросервисы. Возможно, что вам нужна оптимизация сервиса или более производительное железо.

Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?
Например, в случае с Spring API Gateway в нем есть балансировщик. Балансировщик помогает снижать нагрузку с микросервиса, если у вас имеются несколько копий, то каждый раз запросы идут на разные копии. Также gateway удобен тем, что клиент не беспокоится о том, на какой эндпоинт нужно отправлять запрос. Возможно, что у вас несколько копий одного сервиса и то какой из них должен ответить на запрос клиента, самого клиента это не касается.

Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?
Можно и через RabbitMQ. А так например, Spring API Gateway использует асинхронные запросы (Spring Webflux) для реализации данной задачи.

Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных?
Это зависит от вашей задачи. Да, может быть и своя БД. А может быть и нет.

Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля? 
Опять-таки зависит от вашей задачи, от нагрузки и т.д. Возможно, что регистрация, авторизация и сброс пароля будут отдельными микросервисами. А возможно, что User CRUD будет одним микросервисом.