i_alakey29 авг в 10:15

Распилили монолит на 6 сервисов — и случайно собрали распределённый монолит: где мы ошиблись с границами

Средний

14 мин

8.7K

Анализ и проектирование систем * Java * Высоконагруженные системы * Микросервисы * Проектирование и рефакторинг *

Кейс

+11

Комментарии 9

Vicollel 29 авг в 15:28

Если вы делаете микросервисы которые ходят в одну базу данных, то это не микросервисы. Вы сколько угодно можете пилить монолиты на микросервисы по любым границам, если не умеете разрабатывать db per service и делать общение между сервисами через шину, то вы не распиливаете на микросервисы, а просто рефакторите. И скорее всего делаете хуже чем было.

Я так понял вы вообще не очень понимаете для чего были придуманы микросервисы и решили пилить их просто по приколу. У вас три человека в команде, в то время как микросервисы создавались для независимой разработки между командами.

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

Femistoklov 30 авг в 03:59

Единственное что они дают, это независимость команд и независимость стека.

Наверно, главное всё-таки - масштабируемость/реплицируемость (на всякий случай для зануд, я говорю не о том, что монолит нельзя горизонтально масштабировать).

ris58h 30 авг в 13:09

Начали за здравие...

Vicollel 30 авг в 07:38

Масштабируют не микросервис или монолит, а отдельные тяжелые таски, которые отлично масштабируются, потому что изначально их пишут так, чтобы они масштабировались. Я вообще не понял зачем вы это написали. Микросервис сам по себе не делает сервис масштабируемым, то есть если вы запилили микросервис, то это не значит, что вы теперь в деплойменте можете поставить replicas: 10 и у вас все полетит в 10 раз быстрее или начнет тянуть в 10 раз больше rps.

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

i_alakey 30 авг в 08:29

Так статья ровно об этом и есть: настоящих микросервисов у нас не получилось — получился распределённый монолит, это прямо в заголовке. Общая БД и схема под общим движком — один из тех самых косяков с границами, про которые текст.

Про «по приколу» — распил был не нашим решением, а задачей от менеджмента (это в первом абзаце), и вывод у меня как раз ваш: для команды из трёх человек это было преждевременно. Про производительность/экономию нигде не написано, что микросервисы их дают, — наоборот. Так что, кажется, мы об одном и том же.

Про db-per-service согласен — стоило вынести отдельным явным пунктом. Спасибо.

Vicollel 30 авг в 14:26

Этот мой коммент был ответом господину Femistoklov, но я ошибся веткой.

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