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

Question

[Kutuzov_ska]

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

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

Comments

[Василий Банников]

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

В этой ситуации nginx и будет выступать как гейтвей.

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

Можно, но нужно ли - зависит от конкретной задачи. На реббите вполне можно реализовать rpc и это будет надёжно.

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

Не стоит преждевременно плодить микросервисы. Но вообще можно и собственную базу, и общую, и с крудом, а можно круд отдельно.

Answer 1

[Roman K]

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

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

Comments

[Kutuzov_ska]

Не знаю почему, тут столько отметок нравится. Вижу что ответа на вопросы не получил, кроме как мнения и вопроса зачем оно вам? Какая у меня команда - причем здесь это вообще?

Хотелось бы по существу получить ответ. То что вы написали, у меня страха не вызвало.

Причем здесь большие - маленькие? Если мне надо написать микросервис авторизации и работы с пользователем, чтобы потом 10 наших проектов общались через него. И не загружать приложения дополнительной логикой. Если у нас есть несколько DevOps которые могут отвечать за CI/CD.

[vism]

Kutuzov_ska, тоже прожал, мне нравится.
Вопросы у вас слишком простые, для того, у кого не вызывает страх то, что написано в этом комментарии.
Я понял ваш вопрос так, что вы совсем не понимаете, ту сложность, которые дадут микросервисы, а вот в комментарии вам на это указали.

Вот у меня не вызывает проблем то, что вы спросили, но вызывает ужас то, что написал Roman Kitaev .
В первую очередь ужас вызывает то, где найти таких разработчиков в необходимом количестве, или сколько денег и времени займёт их обучение и переделки.
По моему мнению, только 5% из тех, кого принято называть синьорами программирования или девопса действительно умеют в микросервисах.

[shurshur]

Kutuzov_ska, вполне нормальные вещи он говорит. Не нужно использовать микросервисы "потому что эта модна". Нужно чётко представлять себе что, зачем и почему. Иначе ко всем другим проблемам разработки и сопровождения прибавится проблема обслуживания микросервисной архитектуры без какой-либо пользы от неё.

[Kutuzov_ska]

shurshur, vism, Похоже лыжи не едут. Можно по вопросам отвечать, а не о сложности микросервисной архитектуры? Нормальные вещи он говорит, я не спорю. Вопрос то в другом, я не мнение свое попросил высказать о "тут ваша технология", я не спрашивал, страшно ли и тяжело ли, делать ее. Я спросил 3 конкретных вопроса касающихся реализации. Человек будет искать информацию о микросервисах в русском сегменте, а ему в ответ - это тяжело, подумай...

[vism]

Kutuzov_ska, ну так оно и есть:) Микросервисы это не то, что нужно искать на таких форумах.
Надо книги читать и статьи, притом уровень вхождения такой, что надо знать очень много.
Конкретно ваши 3 вопроса, базовые. Это наталкивает на мысль, что нет базовых знаний, потому опытный человек сразу ....

Хм.. смысла дискутировать я думаю нет. Лыжи не едут :)

[shurshur]

Kutuzov_ska, человек, который будет искать информацию с нуля, сразу по ответам увидит, что вопрос в такой постановке никуда не годится, ну и сразу же примерит эту ситуацию на свои вопросы.

[Kutuzov_ska]

shurshur, в какой постановке у меня вопросы?

[shurshur]

Kutuzov_ska, в такой: "по книжке сервисы общаются по-английски, а почему нельзя по-французски?" Да какая вообще разница, как они общаются? Это не архитектурный вопрос.

[Kutuzov_ska]

shurshur, в чем их дилетанство?
В том, что мне интересно как лучше реализовать gateway? Или какой способ общения между микросервисами выбрать? Или про распределение баз данных?

Что вы устроили из этой архитектуры какой то культ? Это не более чем метод разработки и распределения кода по модулям. И общения между ними.

Похоже что "можно молодежно" - сменилось на профи которые, говорят да зачем. Причем если бы вы ими занимались, просто бы ответили на вопросы и все. Нет разводяд демагогию о необходимости, вопрос как то не так задал...

[Kutuzov_ska]

shurshur, я понял. Прошу больше не комментируйте, Saboteur уже сделал больше чем мы сейчас с вами

[shurshur]

Kutuzov_ska, как реализовать gateway - это вопрос примерно предпоследний. Ходить в nginx, envoy или напрямую в сервисы не самое существенно, тем более что делают и так, и сяк. Если пока ещё обсуждается, городить ли вообще микросервисы или нет, и в то же время начинаются вопросы о мелких деталях, допускающих разные способы реализации, то это уже явно не в ту степь мысли идут.

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

Answer 2

[Saboteur]

Микросервисы пишут не для того, чтобы просто переделать API.

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

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

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

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

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

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

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

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

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

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

Answer 3

[Орхан Гасанлы]

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

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

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

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

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

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

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

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

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