Комментарии 10
Повторю здесь свой комментарий
Я наконец то понял что такое микросервисы
Я мало работал с микросервисами и точно не видел когда их нужно сотни и тысячи.
Я представляю себе процесс их появления в таком количестве так:
бизнес постоянно требует быстрых решений, команды наскоро пилят функционал и перебегают на следующий проект. Старый код превращается в легаси - он вроде как работает, но как именно - уже никто не помнит. Причём, силы на документирование тоже тратить никто не хочет потому что это в 95% сервис который будет не нужен через месяц. Например, 100500й ad-hoc отчёт, выгрузка, источник данных. Собственно, это огромная куча мусора. Поэтому минимум попыток выйти из стадии говна и палок, максимум изоляции кода, изоляции команд разработчиков, аналитиков, требований, документации. Вот этот почти не используемый хлам, который страшно выкинуть и называют легаси. Микросервисы это куча хлама, который раскидали по отдельным шкафам.
Вопросы масштабирования тут далеко не на первом месте.
С другой стороны, ИТ это способ для бизнеса познать себя и мир, способ для экспериментов, тренажерный зал.
Бизнес придумал что-то, что устареет через пару месяцев, ad-hoc функционал. Требования сформулированы плохо, реализовано на скорую руку, как сопровождать неясно, ведь требования неясны а бизнес контекст уже ушёл. Но сервис ещё может понадобиться и поэтому его не гасят. Если посмотреть долю чистого, долго живущего, часто используемого функционала то доля мала.
Где те тёмные щели где они размножаются
Финтех и аналитика
Контекст: Бизнесу нужны отчёты, дашборды и интеграции с новыми источниками данных. Часто это разовые задачи, но данные продолжают течь, отчёты могут понадобиться.
Пример: Ad-hoc сервис для выгрузки транзакций для налоговой или анализа поведения клиентов, который потом забывают выключить.
Почему микросервисы?: Удобно для изоляции источников данных, но без документации и тестов это превращается в чёрный ящик.
E-commerce и ритейл
Контекст: Постоянные кампании, скидки, интеграции с новыми партнёрами. Всё нужно «вчера», а требования меняются на ходу.
Пример: Выгрузка данных для очередной акции «Чёрная пятница» или интеграция с новым поставщиком, который через три месяца уходит.
Почему микросервисы?: Позволяют быстро пилить временные решения, но никто не чистит за собой, и система обрастает легаси
Замечу, что микросервисы это ещё и куча разнотипного хлама. Однотипный бы давно превратили в шаблоны.
Однобокое суждение, типа монолит - хорошо, микросервисы плохо. Возможно вы видели это в какой-то компании из 5-10 разработчиков, которые посчитали что микросервисы серебряная пуля и щас решит все проблемы. У меня, кстати, был такой опыт.
Проблема в том, что по мере роста приложения вы неизбежно столкнетесь с проблемой, что ваш монолит надо разделять иначе получится комок грязи. Например, представьте, что у вас 100 разработчиков и каждый со своими идеями, как они там не будут мешаться друг другу. Да и логики там будет столько, что ее невозможно удержать в голове одному человеку. В статье предлагается решение разделения - модульный монолит, что и есть по сути микросервисы, только в другой обёртке. Модуль=микросервис, вам точно также надо хорошо продумать какую доменную область выносить в отдельный модуль(микросервис), чтобы не получить большую связанность. Точно также как в микросервисах у вас за каждый модуль будут отвечать определенная команда и при взаимодействии друг с другом у них будут возникать сложности, т.к контекст друга они не знают да и цели у них разные. Модульный монолит хранится в одном репозитории? Ок, вам никто не мешает создать моно репозиторий и хранить в нем все ваши микросервисы. Подытожив хочется сказать, сказать, что серебряной пули нет у каждого решения свои плюсы и минусы, какое выбрать зависит от конкретной ситуации
Только что в другой теме написал.
Дублирую
Какие бывают доводы:
Требования к безопасности. Например, платежи почти всегда это отдельный модуль.
Уже есть несколько модулей, унаследованных или закупленных
Много команд разработки, сложности в их координации. Обычно, это играет роль при масштабе от 10 команд от 10 человек каждая. И только при условии что предметная область хорошо известна, не меняется. Иначе, изменение границ домена ведёт к большой переделке. Monolith first это не просто так придумали.
Чертов легаси, который надо сопровождать, но его никто не понимает
Мультитехнологические команды
Высокие требования к масштабированию (ага, не тянет на 100 ядерном сервере) или требования к географической распределенности
Ещё CI/ CD когда один из модулей меняется несколько раз в день. Но это решаемо и дешевле. Разве что если бизнес создаёт огромный поток ad-hoc нешаблонных задач, которые не будут развиваться, а команды перекинут через пару месяцев на другие галеры. Такой мусор, действительно, стоит изолировать в виде отдельного сервиса, чтобы стоял и не мешал никому.
Всё. Желание команды потренироваться это плохой довод.
ваш монолит надо разделять иначе получится комок грязи. Например, представьте, что у вас 100 разработчиков и каждый со своими идеями, как они там не будут мешаться друг другу
Для 100 человек согласен. Хотя, строгая иерархия при водопадной модели в скажем разработке Oracle RDBMS и монолит всё равно работает.
А для меньшего количества человек ну это должен быть совсем хаос и анархия, либо совсем разные подразделения вплоть до разных юр лиц.
серебряной пули нет у каждого решения свои плюсы и минусы
И очень редко решение хорошо обоснованно, оптимально
Только что в другой теме написал.
Дублирую
Вообще не понял, что вы хотите сказать и как это связано с моим комментарием.
Хотя, строгая иерархия при водопадной модели в скажем разработке Oracle RDBMS и монолит всё равно работает.
Какая вообще связь между моделью разработки и архитектурой приложения? Это всё равно что сказать, что dependency injection хорошо работает если команда работает с 9 до 18 вечера. А еще и карго-культ в придачу, в компании X используют монолит, значит и мы будем. Ну а в компании Y используют микросервисы, как быть тогда? Может всё-таки провести анализ плюсов минусов у того и другого подхода и сопоставить с целями нашего приложения и принять решение?
Для 100 человек согласен. А для меньшего количества человек ну это должен быть совсем хаос и анархия, либо совсем разные подразделения вплоть до разных юр лиц.
Должен быть только здравый смысл в принятии того или иного решения, всё. У вас например 2 команды, одна на python, другая на c#. Вы же не будете одну выгонять и писать всё только на python, лишь бы монолит был?
Oracle RDBMS вообще не монолит - изменения кучи вещей не приводят к необходимости тотальной перекомпиляции - добавление почти всего, изменения тела пакетов и т.д.
Для всего остального есть Edition-Based Redefinition.
Монолит - это когда для КАЖДОГО изменения надо пересобирать весь проект, без альтернативы . Видел 1 раз в жизни, это был jar на несколько гигов.
Да никому не нужны ваши микросервисы. Тем более, что это просто вид орг струкруты не более. Все эти сказки про сервис контракты и баундариз, велосити, бла бла бла. делайте нормальный сервис и не ебите мозги. И никто нихочет ничего разделять. Эта сказка в основном от круптых CSP, которым на каждое действие дай накрутить по 1005000 апи колов.
С микросевисами бизнес получает иллюзию контроля. Всегда есть команда, ответственная за конкретный функционал. Начальник всегда знает, кого пинать. И у команды нет отмазок про более приоритетные задачи от других заказчиков. Они обслуживают одну функцию, которая нужна одному заказчику.
Да, в итоге бизнес платит на порядки больше. Ну и что? Бюджет одобрен сверху, о чём беспокоиться? Плюс начальник большого подразделения очень рад повышению зарплаты и в целом значимости с ростом количества подчинённых.
А чисто технически перезапускающийся сервис не кладёт всю систему, потому что сообщения для него тихо лежат в очереди и ждут завершения перезапуска. Команду на перезапуск дать легко - известно кому её дать и известно, что система продолжит работать, даже если сервис сбойнёт, ведь какое-то время сообщения будут копиться в очереди. Ну а если сообщения обработаны некорректно, то есть возможность обработать повторно, после фикса проблемы сервиса, хотя это ещё добавляет избыточность.
Общий принцип - если не умеем сделать качественно, то хотя бы пробуем повысить полезность за счёт многократного дублирования элементов.
Пока издержки ниже субъективной оценки руководством приемлемой цены - микросервисам быть. Чем больше бизнес, тем проще переложить издержки на клиентов. Остальные бегемоты точно такие же тупые, значит конкурентное давление среды можно игнорировать.
На десяток миллиардов рублей в год можно нанять несколько тысяч лоботрясов. При оборотах в сотни миллиардов (и более) это не проблема. Поэтому избыточность живее всех живых. Вниз тоже масштабируется, просто уменьшают количество сервисов, мол мы же ещё маленькие - все довольны, всем всё понятно.
Давайте (не) разрушим монолит. Часть 1