Комментарии 10
В статье это же, только более развернуто.
есть внятные описанные правила декомпозиции, проблемы озвученные в статье говорят об их игнорировании
Список правил в студию! А то многие всё ещё мучаются, попадётся какой-нибудь healthcare, и поди, нащупай там границы ответственности между микросервисами и прочий bounded context…
микросервисы это способ бороться с экспоненциально возрастающей сложностью
А поделитесь плиз какими-то пруфлинками этому утверждению. Мне совсем неочевидно каким образом распиливание одного процесса на несколько уменьшает сложность.
Весь интернет — один большой пруфлинк. Если бы существующие сайты и сервера разрабатывались не раздельно, а были частью монолита — интернета в текущем виде бы не существовало.
С микросервисами та же история — если один процесс удаётся распилить на несколько слабо связанных между собой — каждый их них разрабатывать действительно проще… а если они оказываются после распиливания сильно связаны — сложнее. В общем и целом уменьшение сложности здесь является следствием удачного разделения на слабосвязанные части, а уж как эти части оформлены — сетевыми сервисами, встроенными микросервисами внутри монолита, или просто отдельными модулями/библиотеками — не так принципиально. Просто когда это сетевые сервисы становится сложнее работать мимо его API напрямую с его БД, сложнее писать без документации API, без автоматизации выката, etc. — т.е. без всего такого, что внутри монолита обычно делать ленятся. И как следствие этой лени обычно получается так, что с микросервисами действительно нередко удаётся бороться со сложностью более успешно, чем без микросервисов.
Получается, вместо сложности 10 выходит 30=20(сервисы)+10(взаимодействия), как и написано в статье («разработка может обойтись вам примерно в 3 раза дороже, чем на монолите», в последнем абзаце). Но управлять 10 монолита уже нереально (невозможно добавить ещё одну, чтобы стало 11), тогда и делают микросервисы.
Согласнен что микросервисы ТРЕБУЮТ слабой связанности, что хорошо для управояемости. Для управлением слабой связанностью внутри монолита есть сборки, инкапсуляция, средства ЯП и огромное количество паттернов на выбор (конечно же IOC рулит). Т.е. разработчик в проекте с монолитом не должен работать со всеми модулями, у него и в монолите достаточно изоляции и средств её поддерживать. Если архитектор дисциплинирован то сложность моделей можно удерживать на тех же Ваших условных 2-3 единицах, не переходя на микросервисы.
"Размен экспонициалтной сложности?" По-моему не тем Вы зананимались 5 лет, и зря стесняетесь задавать вопросы. Готов утверждать что микросервисы имеют большую асимптотическую оценку сложности разработки. Может конечно не степенную но коэфициент при том же значении будет выше чем у монолита. Автор это затронул в части сложности отладки. Умножте на версионность модулей (разные версии на боевых и тестовых средах) и невозможность статического анализа кода всего решения и вот Вам повышенная(!) сложность разработки.
Пара слов в защиту монолита