Как понять микросервисы?

Сейчас встала задача переписать проект. Много разных сервисов и API с которыми должно общаться приложение, было принято решение проверить возможность, перейти на микро-сервисную архитектуру (скорее нам даже подойдут микро-монолиты). Но есть непонимания:

1. Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?
2. Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?
3. Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных? Как например в админке обращаться к пользователям, чтобы их добавить или заблокировать, я должен запрашивать пользователей с микросервиса? Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля?
  • Вопрос задан
  • 1648 просмотров
Пригласить эксперта
Ответы на вопрос 3
@deliro
Агрессивное программирование
Как понять микросервисы?

Прочитать соответствующую книгу (а лучше ещё парочку про 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 (пофиг, что нарушит, важнее то, что это починить будет сильно сложнее). Список можно продолжать долго.
Ответ написан
saboteur_kiev
@saboteur_kiev
software engineer
Микросервисы пишут не для того, чтобы просто переделать API.

Основной смысл микросервисов - выделить из вашего продукта компоненты, на которые идет большая нагрузка с тем, чтобы эти компоненты можно было легко горизонтально масштабировать.

А уже исходя из этой точки зрения:

1. Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?

А если нужно много экземпляров, будете одним nginx-ом раскидывать по 10 локейшенам? Микросервисы в современном мире предполагается запускать в докере на собственном легковесном веб-сервере (типа Jetty), поднимать нужное количество экземпляров и балансировать чем-нибудь на входе, но не по локейшенам.

2. Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?

РаббитMQ или kafka позволяют множеству экземпляров вашего сервиса обрабатывать сообщения, с гарантией того, что из очереди ничего не пропадет, и если какой-то экземпляр сдохнет, то этот запрос обработает другой экземпляр. Именно ждать ответ наверное не самое правильное, но это можно смотреть как вам удобнее - периодически опрашивать очередь, или настроить чтобы message service сам пушил по событию.

3. Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных? Как например в админке обращаться к пользователям, чтобы их добавить или заблокировать, я должен запрашивать пользователей с микросервиса? Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля?

Это как вы хотите. Если у вас очень много пользователей и авторизация тормозит, но можно сделать микросервис с авторизацией, сделать кластер базы данных с репликацией. Дальше можете балансировать пользователей и там уже решать как их раскидывать. Или база мощная и все экземпляры могут работать с кластером. Или делите базу на части, и раскидываете пользователей по алфавиту (база юзеров от A* до H*, база юзеров от I* до M*, по региону или как вам нравится).

Микросервисы нельзя писать до того как вы представите себе в голове общую архитектуру всего проекта, и какую проблему вы хотите решить.

Второй немаловажный плюс микросервисов - работать над небольшим микросервисом проще, чем над крупным монолитом. Упрощается его поддержка рефакторинг. То есть в конечном счете упрощается требования к квалификации программиста. Но усложняется общая архитектура проекта, то есть на сеньоров/техлидов нагрузка возрастает.
Ответ написан
Комментировать
azerphoenix
@azerphoenix
Java Software Engineer
Добрый день!
Прежде всего ответьте на один вопрос - какую именно проблему вы хотите решить переходом на микросервисную архитектуру. Обратите внимание, что обеспечивать ACID в микросервисной структуре сложнее, чем в монолитах. Также обслуживание микросервисов тоже сложнее. Если есть нагрузка на сервис, то не факт, что вам нужны микросервисы. Возможно, что вам нужна оптимизация сервиса или более производительное железо.

Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?

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

Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?

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

Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных?

Это зависит от вашей задачи. Да, может быть и своя БД. А может быть и нет.

Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля?

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы