(продолжение)

Также, когда количество команд растет, разделение ответственности между собственными приложениями микросервисами звучит удобно.

Вроде плюсы перечислили, но почему же микросервисы приносят нам боль?

1. Они сильно осложняют разработку и требуют более опытных специалистов, много сложных технологий для поддержания консистентности данных. Каждый сервис работает со своей базой данных, поэтому нужно писать много кода, чтоб предотвратить расхождение. Например возьмём некий маркетплейс и процесс покупки. В нем участвуют микросервисы заказа, оплаты, микросервис товарных остатков (на самом деле больше, но мы возьмём только небольшой участок). Сначала микросервис формирует заказ, передает микросервису оплаты по API запрос на списание денег, после списания денег ответ в микросервисе заказа запускает процесс подтверждения и данные летят в микросервис списания товарных остатков продавца. А теперь представим, что оплата списалась и возникла сетевая ошибка, данные не попали обратно в сервис заказа и товарного остатков. Деньги ушли, а покупка не подтвердилась. Неприятно, пользователи будут возмущены. Поэтому для таких случаев приходится писать много дополнительного сложного кода, например поддержку распределенных транзакций. В случае если где-то после оплаты произойдет ошибка, то вся покупка отменится, в том числе списание денег. Это очень базовый пример, но, думаю, доступный для понимания. Кроме того часто требуются специальные шины данных (очереди) для асинхронной обработки запросов, балансировщики нагрузки и много других вещей.

2. Из пункта 1 следует, что разрабатывать дольше. Нужно писать множество вещей, которые в случае монолита не потребуются. Поэтому делать прототип приложенияили стартап сразу на микросервисах - это моветон. Есть хороший подход "monolith first", который говорит нам, что всегда сначала надо писать монолит, потом, когда масштабируемости будет не хватать, разбивать на сервисы. Так будет и больше понимания, какой код выделить в отдельные приложения, так как монолит уже поработает и будет видно слабые места.

3. Разработка микросервисной архитектуры дороже. Потому что дольше и требует более опытной команды, а так же дополнительных команд архитекторов, аналитиков, которые синхронизируют между собой микросервисные команды.

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

Монолит плохо масштабируется на большие нагрузки, микросервисы сложны и дороги, что тогда делать? Делить монолит на сервисы покрупнее. Выделять только необходимое. Меньше приложений, меньше проблем. Выделять сервис, только когда есть кому делегировать ответственность за него. Не гнаться за приставкой "микро". Монолит, окружённый несколькими сервисами, которые внутри монолита будут бутылочным горлышком, а отдельными приложениями смогут масштабироваться.

Как эпилог, скажу цитату из одного из моих любимых фильмов Звёздные войны. Эпизод III. Месть ситхов: "Только ситхи все возводят в абсолют".

Склонность "пилить" микросервисы без необходимости и зрелости команды может сыграть с вашим проектом злую шутку.

#разработка #webdevelopment #softwaredevelopment #softwarearchitect #архитектураприложений #микросервисы #монолитная_архитектура #микросервисная_архитектура #web

Пост похож на байт на подписку в тг, хотя тема интересная Можете, пожалуйста, выложить полную историю в комментариях? Они не ограничены в количестве