Поэтому в первой статье я расскажу, что же такое модульный монолит в моём понимании. В таком контексте я хотел бы начать серию статей об архитектуре модульного монолита, и делаю это по нескольким https://deveducation.com/ причинам. Ещё больше историй о микросервисных проектах, которые выбрали Yandex Cloud, вы найдете на нашем сайте. Приложения создаются в виде набора небольших сервисов, а не цельной программы.

В левой части схемы мы видим модуль с большим количеством зависимостей и явно не можем назвать его независимым. С другой стороны, на правой диаграмме ситуация отличается — зависимостей у модуля меньше. Конечно, модуль не может быть абсолютно независимым, тогда бы вообще отсутствовали интеграции с другими модулями системы.

В чем плюсы монолитного подхода?

Благодаря механизму Service discovery сервисы могут находить друг друга и обмениваться информацией о доступности и настройках. В микросервисной архитектуре используют Service discovery для автоматической конфигурации сервисов, обнаружения и разрешения зависимостей между ними. Благодаря SD сервисы могут автоматически адаптироваться к изменениям в конфигурации или при добавлении новых сервисов. По сравнению с монолитом, принципы SOA позволили сократить срок выхода на рынок бизнес-приложений, облегчить их дальнейшее обслуживание и улучшить адаптивность.

Монолитная архитектура — это традиционная модель разработки программного обеспечения, в которой одна база кода используется для выполнения нескольких бизнес-функций. Все программные компоненты монолитной системы взаимозависимы из-за использования встроенных механизмов обмена данными внутри системы. Модификация монолитной архитектуры возможна лишь частично и занимает много времени, поскольку даже небольшие изменения затрагивают большие области базы кода. Напротив, архитектурный подход на основе микросервисов подразумевает, что программное обеспечение состоит из небольших независимых компонентов (сервисов).

Ключевые отличия монолитной архитектуры от микросервисов

При масштабировании монолитных приложений возникает целый ряд проблем. Монолитная архитектура объединяет все функциональные возможности в одной базе кода, поэтому масштабировать при изменении требований придется все приложение сразу. Это приводит к нерациональному использованию ресурсов, поскольку не все части приложения работают на пиковой мощности. Связь между микросервисами — это связь без сохранения состояния, где каждая пара запроса и ответа независима. Далее в этом руководстве по микросервисам Java мы узнаем о разнице между микросервисами и монолитной архитектурой.

• Если ваш продукт значительно усложняется, появляется много нового функционала, то микросервисная архитектура поможет вам более эффективно управлять различными частями приложения.
• Базовая база данных одинакова, и все модули используют одну и ту же базу данных для всех операций.
• Необходимо масштабировать все приложение, даже если увеличится нагрузка только на некоторые функциональные области.
• Представьте себе современный город с множеством обособленных зданий, каждое из которых используется для определенной цели.
• Внутри монолита коммуникация между компонентами может происходить напрямую, без использования удаленного вызова процедур (RPC) или межпроцессного взаимодействия (IPC).
• У каждого из них своя логика, база данных, язык кода, а взаимодействуют они через сеть по протоколонезависимой технологии.

Термин «микро» относится к размеру микросервиса – он должен быть удобным в управлении одной командой разработчиков (5-10 специалистов). В данной методологии большие приложения делятся на крошечные независимые блоки. Как правило, переход позволяет бизнесу масштабироваться и упрощает внедрение нового функционала. Достаточно определиться с тем, какой сервис именно сейчас наиболее актуален для бизнеса.

Микросервисы или монолит. Какую архитектуру выбрать при разработке сложного приложения для крупного бизнеса

Это облегчит задачу, если вы когда-нибудь решите разделить свой монолит на несколько сервисов. Высокие темпы изменений и высокая сложность могут быть факторами, которые заставляют выбрать архитектуру микросервиса. Микросервисы не привязаны к технологии, используемой в других сервисах.

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

Микросервисы в значительной степени получили свое название из-за того, что сервисы здесь меньше, чем в монолитной среде. В целом небольшие «монолитные» приложения легко масштабируются до определенного момента. Когда он небольшой, его просто держать в руках и наматывать на него другие нитки разных цветов и разного микросервисная архитектура состава — все происходит легко и быстро. Но настает такой момент, когда клубок в руках уже не удержать и тем более не посчитать, сколько в нем ниток и каких они цветов. И чтобы с этим всем как-то разобраться, придется клубок перематывать и при этом делить его на более мелкие клубки по цветам ниток.

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