Монолитная архитектура

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

Вначале был Монолит… 😀

Строительство монолита всегда было архитектурным стилем по умолчанию. Я имею в виду, что в самом начале у нас был один файл на приложение, затем у нас появились приложения с несколькими файлами, и только с 1990-х годов мы начали видеть приложения, состоящие из других приложений (хотя первые эксперименты были в 1980-х годах).

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

Модульная разработка программного обеспечения

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

Например, JAVA имеет видимость уровня класса default и public, где уровень default означает, что класс виден только в своем пакете (модуле). , а public означает, что класс виден внутри и вне своего пакета (модуля). Это позволяет нам определять, какие классы должны использоваться клиентами пакета.

Компонентная разработка программного обеспечения

Другой стиль модульности - это Компоненты. Как объяснялось в одном из моих предыдущих постов, Компоненты - это модули, созданные с учетом концепции предметной области. В идеале они представляют собой автономные приложения, которые можно использовать для создания составных приложений. Повторяющийся пример этого стиля - архитектура конвейеров и фильтров, широко используемая в системах Unix и позволяющая делать что-то вроде «ps -ef | grep php «. Другой пример - использование микросервисов в качестве компонентов составных приложений, таких как Netflix.

Этот стиль организации кода также существует уже давно, начиная с конца 1960-х годов, как и модульная разработка программного обеспечения.

Современный монолит

В настоящее время наличие монолитного архитектурного стиля просто означает, что весь код приложения развернут и запущен как единый процесс на одном узле. Мы предполагаем, что он использует модули и компоненты, хотя на самом деле это часто не так.

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

На сервере с одним узлом все модули в монолите собираются в один и тот же образ памяти, который запускается как единый процесс на одном узле. Связь осуществляется посредством стандартных вызовов процедур через тот же стек и кучу. Это единый образ в памяти, который делает приложение монолитным. Если вы запускаете модули в разных процессах, вы выполняете IPC. Поскольку модули попадают в разные границы процессов, вы начнете сталкиваться с проблемами распределенных вычислений. Это входит в территорию микросервисов. (Спасибо за отзыв, _dban_)

Этот стиль, хотя и имеет очень плохую репутацию, может очень хорошо работать даже для больших приложений. Он перестает быть достаточно хорошим только тогда, когда нам нужно:

• Независимая масштабируемость различных компонентов домена;
• Различные компоненты или модули должны быть написаны на разных языках программирования;
• Независимое развертывание, возможно, потому, что у нас скорость выпуска выше, чем конвейер развертывания может обработать для одной базы кода, что приводит к медленному развертыванию выпуска, так как необходимо дождаться развертывания других выпусков, или даже заставляя очередь развертывания расти быстрее, чем она потребляется.

На этом этапе нам нужно разделить наш монолит на разные приложения в архитектурном стиле SOA (подробнее об этом в следующем посте).

Антипаттерн: Большой шар грязи / Архитектура спагетти

«Большой комок грязи», AKA Spaghetti Architecture, является анти-шаблоном для этого стиля, где структура пакетов и отношения не являются явными, структурная сплоченность и инкапсуляция не существуют или минимальны, зависимости не подчиняются правилам, и это очень важно. сложно рассуждать о подсистемах, вносить изменения и рефакторинг. Система бывает непрозрачной, вязкой, хрупкой и жесткой: большой комок грязи !