Комментарии 52
И кто сказал что монолит медленный? Монолит то как раз изначально будет быстрее и дешевле в конечной эксплуатации (до некоторого предела железных серверов).
Надо четко понимать, что микросервисы — это огромные накладные расходы, но с возможностью масштабирования. Да и это масштабирование еще тоже надо запланировать и написать.
Ключевой элемент здесь — крупные, не до 10 разработчиков, а значительно больше. И хотя у таких компаний часто есть основной язык, он обычно не единственный.
По монолиту также согласен. Тут я упомянул «классическую» (утрированную) версию, которой пугают обычно менеджмент на питчингах микросервисов. Конечно, он таким может и не быть, если соответствующим образом его писать.
Надо четко понимать, что микросервисы — это огромные накладные расходы, но с возможностью масштабирования. Да и это масштабирование еще тоже надо запланировать и написать.
Тут важное замечаение — с возможностью гибкого масштабирования отдельных частей. Монолит тоже можно масштабировать просто развертывая больше одинаковых копий.
Плюс очень часто у приложения проблемы с БД, а они масштабируются практически одинакового у монолита и микросервисов (если при монолите тоже использовался разделение БД по бизнес-функциям, аналогичное микросервисам).
Конечно, классический монолит ничем не лучше. Он медленный, хранит у себя состояние, тяжело перерабатываем, не покрыт ни модульными, ни интеграционными тестами и т.д.
Это вот сильно утрированное понимание. И уже примерно в 2000 году так многие не делали — если вспомнить, то спецификация J2EE появилась в 1999 году, а OSGI — в 2000, и обе они, что характерно — про модули и разбиение проекта на них. Написать монолит, который не делится на модули — это вообще непрактично, а потому как правило приводит к неудаче, поэтому реальные большие приложения в общем-то монолитами обычно не являются. Они может и не делятся на сервисы снаружи (особенно если им не нужно масштабироваться), но все-таки состоят из них внутри.
J2EE которое сейчас уже Jakarta EE отличная идея но давайте проверим что с реализациями. Усложненность стандарта вызвало к жизни проект Spring который пользуется не меньшей а то и большей популярностью и по сути является компонентом подходом но в рамках монолита.
Сервер J2EE Reference implementation который прилагался к платформе для тестирования но не для продажи был взят под свое крыло Oracle, после чего стал называться GlassFish, разделился на enterpeise и common версии после вашего common версия с массой ошибок и несовместимость была фактически остановлена (кто бы сомневался)
То есть масштабировать путем создания кластеров J2EE серверов это под силу мегакорпорациям которые могут покупать enterprise версии платных серверов
А про масштабирование я вообще не упоминал, если на то пошло. Речь лишь о том, что сделать большой проект монолитом конечно можно на любой платформе, но уже лет 20 как есть много платформ, которые позволяют сделать в том числе и нормально. Из сервисов. Из небольших сервисов, я бы сказал.
— монолит со структурой function-first или MVC — так можно рости пока у вас 1-2 команды по 5-10 человек
— когда команд становится 5-10 штук, то начинаются конфликты и ростут блокировки. тогда выгодно переходить в монолит на модулях или монолит feature-first или компонентно-ориентированное программирование или DDD как вариант — чтобы команды работали каждый над своей частью системы и сильно не мешали друг другу
— когда команд становится 100 штук, а программистов под 1000, тогда выгодно начинать уходить в микросервисы
Конечно рост по количеству программистов не единственный критерий выхода в микросервисы. еще могут быть узкие горлышки, необходимость применять иные языки программирования и стеки, переиспользование функционала и т д.
Главное понимать что без веских причин усложнять не стоит. И усложнять систему стоит только тогда когда это решает реальные проблемы. Потому что это решение не бесплатно, затраты очень сильно увеличиваются, и потому выгода должна оказаться больше чем те затраты и проблемы которые придут в комплекте.
Решение выдуманных проблем на волне хайпа вокруг очередной модной технологии создает больше проблем чем решает их. О чем как я понял автор и говорит в данной статье.
Я так и не понял, где тут шаг назад? Микросервисы выбирают тогда, когда надо масштабирования разных кусочков приложения в разном объеме. То, что их (микросервисы) суют куда попало в каждое приложение — это совсем другой разговор, но никак не шаг назад
Микросервисы выбирают тогда, когда надо масштабирования разных кусочков приложения в разном объеме.
Можно масштабировать и монолиты… Как вертикально (покупая все более мощные сервера), так и горизонтально. С последним сложнее — т.к. монолит обычно хранит в себе какое-то состояние и просто второй инстанс (и далее) не прикрутить, но это вполне реальная задача. Касательно того, что при этом часть функционала монолита не будет задействована в каждом последующем кусочке… Ну, бывает. Но это может быть запросто дешевле, чем декомпозировать на микросервисы, которые никогда хайлоадом и не станут…
Микросервисы могут выручить, если вам нужно хранить персональные данные и делать это на разрешённых площадках может быть не выгодно. Тогда вся работа с пд выносится в микросервис.
Из-за непринятия разработчиками и менеджментом возможности существования гетерогенной системы, построенной на разных языках программирования, теряется возможность выбора подходящих инструментов для решения актуальных задач.
Ну откуда такие страшные мысли? Чего такого нельзя сделать на одном языке, но автор считает, можно сделать на другом? Откуда такое полнейшее непонимание сути понятия алгоритм?
Выбор языка — это экономическая задача. И хотя часто её решают на основе моды, это ни разу не отодвигает экономику с законного первого места. А аргументы из серии «а на модном языке я такое могу!!!» только подкрепляют уверенность в безумстве следующих за модой.
К сожалению, эти страшные мысли — это реальность для некоторых компаний, в которых работал. Если абстрагироваться от технических деталей, то конечно, практически можно реализовать любой алгоритм на любом ЯП (полном по Тьюрингу). Проблема в том, что тот самый единственный ЯП может быть субоптимален для реализации алгоритма.
Личный пример где микросервисная архитектура стала шагом вперёд: огромный индуский монолит 15 летней давности с визуал бейсиком и веб- формами. Что-то имплементить новое невыносимо, нужно фоловить существующую логику, найти девелоперов кто захочет в веб-формы и визуал бейсик сложно, а джуны даже незнают что это такое. Решение: создаём инфраструктуру для микро сервисов, инжектим ее ректальным методом в монолит и маленькими шажками для девелоперов но огромными шагами для проджек менеджеров в целом переносим мелкими фичами наш монолит на новый уровень, и всеми джунами любимый net core, с депенданси инджекшеном и юнит тестами.
Разбиение сложной системы на множество маленьких модулей снижает зависимость интегрального ее качества от квалификации проектировщиков, за счет дополнительных интерфейсных, конфигурационных итд издержек (которые, в свою очередь, хорошо детерминированы, и соответственно, могут быть гаратнированно выполнены с уровнем качества не ниже заданного специалистами калиброванной же квалификации).
Грубо говоря, сложная автоматизация может быть с высокой вероятностью сносно сделана индусскими микромодулями с применением стандартных процедур, но скорее всего, не будет качественно сделана монолитом индусского качества.
Соответственно, ожидать серебряной пули от микросервисов — то же самое, что ожидать чуда генерации энергии от трансформатора — он может всего лишь преобразовать прямоугольник напряжение * ток в другую пропорцию сторон, съев свою часть маржи для этого.
Все правильно говорите. Путем распила монолита на микросервисы мы энтропию никуда не убираем. Сложность перекочевывает с уровня приложения (взаимодействия классов и функций) на уровень инфраструктурный и начинает требовать обмазывания техническими решениями — начиная от каталога сервисов и кончая всякими сервис мэшами, эластиками и прочим. В этом есть и плюсы — мы получаем стандартизованные решения (каждый микросервис по сути шаблонен). Но стоимость владения только увеличивается. Я уж не говорю о том, что все эти трейсинги и пр. жрут вычислительные ресурсы как не в себя. Условно — это то же самое, что мы могли бы быстро посчитать какой-то алгоритм в процедурном стиле на си или намешать лапши из ООП на джаве и получить быстродействие в 10 раз хуже и системные требования в 10 раз больше.
Нужна ли компании масштабируемость?
Когда станет нужно, будет уже поздно
Нет. А может это будущее никогда и не наступит. Например, мы стартап.
Помните — "преждевременная оптимизация — корень всех зол"?
Начинать думать о масштабиррвание когда сервис лежит под хаброэффектом может оказаться фатальним для стартапа без лояльных пользователей. Проверено на практике. Команда была разогнана, проект закрыт.
Имхо, именно в таком мышлении кроется проблема технологического роста большинства стартапов. "Оптимизацию" тоже нужно уметь проводить: найти баланс между "масштабируемостью" и "преждевременностью" — большое искусство.
Если нужно постоянно работать с кодом целостной системы, можно использовать входящие в моду монорепозитории с системами сборки типа bazel. Гоняйте на всем проекте скрипты, модульные тесты, билд-инженеров ржавыми цепями, разработка спокойно ведется в этой монорепе по отдельным директориям с какой-нибудь системой контроля code-owner'ов, и все довольны.
Проблема в том, что монорепа тащит за собой необходимость использования дополнительного инструментария ) Если же все разбивать на "один репозиторий — один артефакт" — в целом, ты укладываешься в флоу, который предлагает гитхаб или гитлаб. И можно воспользоваться встроенными средствами. Ну, и еще отдельная боль — когда ты в энтерпрайзе и часть разработок отдана на сторону. В этом случае на каждого подрядчика нужно отдельную репу и возникает вопрос как синхриться, если ты подсел на монорепу (т.е. это не проблема-проблема, которая в принципе не решаема, но опять же — придется искать или разрабатывать какой-то тулинг, который этот вопрос закроет)
же все разбивать на "один репозиторий — один артефакт" — в целом, ты укладываешься в флоу, который предлагает гитхаб или гитлаб.
Но нужен дополнительный тулинг для синхронизации версий всех репозиториев для разворачивания, например, для тестирования интеграции пары сервисов.
И да, и нет. Да — действительно, если делать прям идеально, то такой тулинг нужен. Нет — в том смысле — что можно воспользоваться встроенными средствами гитлаба, создать отдельное мета-репо (ага, больше репо богу репозиториев) и в нем описать матрицу совместимости ) и поверх нее уже гонять тесты.
Ну вот для этого мета-репо (приедпочитаю термин "зонтичный") нужен какой-то тулинг, который будет по этой матрице совместимости актуализировать конкретное окружение. Баш-скрипты легко доходят до нескольких десятков строк на сервис и в какой-то момент становятся слабо поддерживаемыми, особенно если у самих сервисов процессы сборки и развертывания не стандартизированы.
Жирный плюс микросервисного подхода — масштабируемость.
Я бы даже сказал: «Независимая масштабируемость отдельных частей проекта». Пример. У нас магазин. Нагрузка неоднородная. В течении дня есть пики когда люди просто тыкают по страницам, если время когда много заказов, есть когда сильно используется поиск по каталогам, опять же маркетинговые фичи. Сервисы/Микросервисы позволяют масштабировать каждую фичу в отдельности. Нагружают пользователи запросами модуль оплаты, добавим ему ресурсов (оно само добавит). Ищут что-то, раскидываем поиск на дополнительные ноды. Когда всё было в монолите, так просто не смогли реализовать. Хотя старый код всё еще работает, решили его не растаскивать. Работает ведь.
Сервисы/Микросервисы позволяют масштабировать каждую фичу в отдельности. Нагружают пользователи запросами модуль оплаты, добавим ему ресурсов (оно само добавит).
только вот под капотом там полно работы, иначе:
https://habr.com/ru/post/509102/#comment_21801386
Плюс очень часто у приложения проблемы с БД, а они масштабируются практически одинакового у монолита и микросервисов (если при монолите тоже использовался разделение БД по бизнес-функциям, аналогичное микросервисам).
упираетесь в базу и приплыли.
Или — если у вас фиксированный пул ресурсов — уперлись в него и приплыли (но ради справедливости — внутри пула можете переназначать ресурсы как угодно)
Или — масштабируетесь, но не успеваете за нагрузкой. Прекрасный доклад на эту тему — https://www.youtube.com/watch?v=IpJgL-VRyaM
Короче — обычно, когда говорят о масштабировании — это buzzword, руко-водство и пускание пыли в глаза. Реже — это реально крутое техническое решение, которое реально выполняет задачи, позволяет экономить деньги и повышает стабильность.
В таком случае знанием о работе отдельных сервисов не обладает никто, кроме последнего человека, изменявшего их код.
Для этого случая есть спецификации, хотя их так не охота иногда писать
Микросервисы: шаг назад