Комментарии 8
Получилось обо всем понемногу, но полезно, спасибо!
Добавлю, что когда встает вопрос, как проектировать новую систему, то чаще всего правильный ответ -- монолит, в первую очередь потому что сам вопрос возник.
Еще Фаулер лучше меня сформулировал, что если не знаешь, что собираешься делать, делай монолит:
https://martinfowler.com/bliki/MonolithFirst.html
Микросервисы можно проектировать сразу если в голове у архитектолра уже есть устойчивая картина как будет выглядеть конечная система, а это значит, что он дорлжен хорошо понимать требования к продукту (а чаще всего этого нет для новых продуктов) и у него должен быть опыт реализации подобных систем.
мне кажется, что ругая монолит (и превознося микросервисы) многие (сознательно?) оставляют "за рамками" вопрос о размере приложения и условиях его использования. И монолит далеко не всегда плохо и микросервисы далеко не всегда однозначно 'magic pill'. Современные браузеры (Chrome, Edge и т.д.), IDE (VS, Eclipse и т.д.), все приложения MS Office -- может это и не классика монолитостроения, но это никак и не микросервисы. Истина где-то бродит.
Ни разу не думал ругать монолит, более того, (см. коммент выше) - зачастую есть смысл начать с него, когда проектируешь приложение с нуля. Просто потому что, прототипировать таким образом заметно проще, да и сходу разбить приложение на независимые микросервисы задача далеко не самая тривиальная.
Но считаю, что сравнивать десктоп приложения с развесистыми веб-приложениями, особенно с высоконагруженными с моей точки зрения не корректно. Диалог "монолит vs микросервисы" больше актуален, когда речь заходит про распределенные веб-приложения.
И вообще, «монолит или микросервисы» — это неправильная постановка вопроса
Когда архитектор не знает ответа на вопрос он отвечает что это неправильная постановка вопроса.
Когда архитектор знает слишком много ответов на вопрос от отвечает "it depends".
От архитектора вообще есть толк в таком чёрно - белом мире?
Плюсы микросервисов очевидны: масштабируемость, независимая разработка, изоляция компонентов
Нету никаких абстрактных плюсов, применимых везде. Так огульно может говорить только тот кто видит только улетай класс приплетайте и технологий. Говорите конкретно: на PHP/node.js/python для программ с развитой бизнес логикой, которую можно разделить на домены. И ещё кое-какие частности вроде наличии специалистов губернии направления и квалификации, организационной структуры... В этом частном случае плюсы есть.
Для некоторых c#/java и программ с монолитной логикой плюсы настолько малы что и говорить о них нечего. Архитектор послушает про эти плюсы и покрутит пальцам у виска
Разброс значимости плюсов чрезвычайно велик: от важного до исчезающе малого.
Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.
Зачастую никогда, и получается over-engineered solution. Сам этим страдаю.
Совет: возьмите на вооружение парадигму проектирования на отказ. Исходите из того, что в любой момент что угодно может пойти не так. Сеть будет нестабильной, железо начнет падать, интеграции станут работать неправильно.
Можно погрязнуть в дублировании.
Такой подход использовали при программировании в "ящике", если кто еще помнит, что такое ящик. :)
Совет: возьмите на вооружение парадигму проектирования на отказ.
И как выразились выше получи оверинжиниред решение. Программирование такая штука, что практически всегда возможно один подход трансформировать в другой, достаточно изначально поставить более менее четкие границы.
Модульный монолит при достаточно небольшом оверхеде на изоляцию модулей открывает все двери для последующей реструктуризации и развертывания части модулей в отдельные compute инстансы для горизонтального масштабирования или же повышения отказоустойчивости системы.
Проектирование БД достаточно делать по такому же подходу - схема под модуль и изоляция схем; выделение ключей партиционирования и дисциплина в подходе к структурированию (в этом плане очень помогает опыт в работе с NoSQL БД типа DynamoDB, когда scan базы это практически всегда no-go, что вынуждает делать партиционирование грамотно, чтобы использовать query). В итоге за счёт небольших затрат ресурсов на поддержание этой дисциплины открываются двери для безболезненного шардирования, а репликация к БД подключается в пару кликов.
В итоге получая все плюсы монолита мы не закрываем двери для последующего масштабирования отдельных его модулей. Более того, получается более гранулярно контролировать, что имеет смысл вынести как отдельный сервис, а что окей оставить в монолите.
Большинство веб-сервисов по факту не нуждаются в каком-то сложном compute, если они не специализируются на обработке больших файлов или ai. Чаще всего это приложения, которые делают запросы в БД и именно на нее ложится основная загрузка и ее масштабированием нужно будет заниматься в первую очередь. Поэтому для таких приложений достаточно просто создать несколько инстансов монолита и не беспокоится, что есть некоторые модули, которые мало нагружены в рамках инстанса. Если ваше приложение поддерживает многопоточность или хотя бы асинхронность, то проблемы конкуретности основной бизнес логики уже должны быть решены. Останутся проблемы конкуретности инициализации некоторых модулей вроде job scheduler, но и они чаще всего уже решены на уровне библиотек.
Так инкрементально и путем наименьшего сопротивления можно придти к наилучшему для данной системы в данный момент времени результату. А если закладывать изначально железную отказоустойчивость, то львиная доля ресурса будет потрачена на инфраструктуру, которая может для бизнеса никак не окупиться.
Микросервисная архитектура: от монолита к гибкой системе (да, опять)