Оригинальный адрес:микросервисы.IO/patterns/mo…

описание сцены

Предположим, вы разрабатываете большое серверное корпоративное приложение со следующими требованиями:

Должны поддерживаться различные клиенты, в том числе: веб-браузеры, WAP-браузеры и собственные мобильные приложения.
Предоставлять общедоступные API для вызова
Обработка HTTP-запросов или сообщений и выполнение соответствующей бизнес-логики.
Доступ к базе данных, кэширование или сохранение данных ответов
Связь с другими системами для обмена необходимой информацией
Вернуть ответ HTTP, указав конкретный метод сериализации, такой как JSON, XML и т. д.
В соответствии с бизнес-логикой и функциями спроектируйте и разделите различные логические модули.

Такое приложение, как бы вы спроектировали архитектуру и развернули его?

Соображения

Это проект, разработанный командой, при этом независимая команда отвечает за
Члены команды меняются, и новые участники должны быстро приступить к работе.
Приложения должны быть простыми для понимания и изменения
Ожидайте непрерывную интеграцию и развертывание приложений
Приложения должны развертываться в нескольких экземплярах, чтобы соответствовать требованиям масштабируемости и доступности.
Хотите использовать относительно новые технологии (фреймворки, языки программирования и т.д.)

решение

использоватьМонолитная архитектура,Например:

Программа, запускаемая WAR-файлом Java.
Программа Rails или NodeJS с одним каталогом

Пример

Предположим, вы разрабатываете приложение для электронной коммерции, функции которого включают в себя получение заказов от клиентов (StoreFrontUI), проверку и поддержание остатков на складе (служба инвентаризации), проверку и поддержание доступных пользователям остатков (служба бухгалтерского учета), успешное размещение заказов и доставку (служба доставки). ) ). Это приложение разработано какмономерАрхитектурные приложения, такие как веб-приложения Java, состоят из одного файла WAR, работающего в веб-контейнере, таком как Tomcat. Приложения Rails состоят из одной иерархии каталогов на JRuby или Nginx, развернутых на Nginx или Tomcat. Несколько экземпляров можно развернуть за балансировщиком нагрузки для масштабирования и повышения доступности.

анализировать

Преимущества этого решения:

легко развиваться, текущая IDE в основном разработана в соответствии с разработкой одного приложения.
Простота развертывания, просто разверните файл или каталог в веб-контейнере.
Легко расширить, который можно масштабировать, развернув несколько экземпляров за балансировщиком нагрузки.

Однако по мере того, как продукт продолжает итерироваться, это монолитное приложение будет становиться все больше и больше, а также будет увеличиваться размер команды, у этой монолитной конструкции будут некоторые недостатки, и эти недостатки будут становиться все более и более серьезными:

Код монолитного приложения находится в одной кодовой базе, и эта кодовая база будет становиться все больше и больше, заставляя разработчиков чувствовать себя большими, особенно новичков в команде.Приложение будет сложно понять и модифицировать, следовательно, открытьволосы обычно замедляются. Кроме того,Без четких границ модулей модульность кода со временем становится все более размытой.. Кроме того, из-за того, что трудно понять, как правильно внедрять изменения, и, возможно, также необходимо обеспечить совместимость с ошибками из более старых версий, качество кода со временем ухудшается, постепенно превращаясь в гору дерьма.
IDE может вызвать стресс. Чем больше кодовая база, тем медленнее будет IDE.Как правило, IDE индексирует код и загружает его в память для интеллектуального завершения кода. Раздутый код замедлит работу IDE и снизит эффективность разработки.
Давление веб-контейнера увеличивается. Чем более раздута программа, тем дольше будет время запуска, что приведет к более медленной отладке кода и большему времени развертывания.
Непрерывное развертывание интеграции становится все сложнее и сложнее. Чтобы обновить компонент, необходимо повторно развернуть все приложение. Это приводит к тому, что весь бизнес, независимо от того, есть ли обновления или нет, будет затронут или нарушен. При этом время отката растет, если что-то пойдет не так. Следовательно, это ограничивает частое постоянное обновление программы.
Не гибкий для расширения. Различные бизнес-модули могут иметь разную нагрузку, и период высокого давления также может быть разным, но каждый раз расширение требует, чтобы все модули расширялись вместе, что приводит к потерям.
распространение ошибки. Если возникает проблема с одним модулем, вызывающая утечку памяти, это повлияет на весь бизнес.
Барьеры для разделения команды. Например, нам может понадобиться команда пользовательского интерфейса, команда бухгалтеров, группа инвентаризации и так далее. Проблема с монолитными приложениями заключается в том, что они не позволяют командам работать независимо. Команды должны координировать свои усилия по разработке и передислокации. Команде намного сложнее вносить изменения и обновлять производство.
Необходимость использовать один и тот же технологический стек в течение длительного времени. Монолитная архитектура заставляет вас придерживаться стека технологий (а в некоторых случаях и конкретной версии этой технологии), который вы выбираете в начале разработки. В случае монолитных приложений сложно постепенно внедрять новую технологию. Например, используемый вами фреймворк перестает обновляться или устарел, и сложно постепенно адаптировать новую реализацию фреймворка под монолитное приложение.