Лекция_ТиМДКС_№14_Модульный_монолит+Микроядерная архитектура

1. Архитектурные стили: Модульный Монолит Микроядерная архитектура

2.

3.

4.

Два варианта классификации.
Первый вариант — классификация по способу организации кода: по техническим
или предметным соображениям.
Второй вариант — классификация по способу развертывания системы: в форме
единого целого или в виде набора модулей.

5.

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

6.

Ключевые особенности модульного монолита
Единая база кода и развёртывания. Всё приложение собирается и
запускается как один процесс, использует одну базу данных.
Чёткое разделение на модули. Код структурируется по бизнесдоменам (например, «Платежи», «Профили», «Отчёты»), а не по
техническим слоям.
Слабая связанность. Модули взаимодействуют через строго
определённые интерфейсы, минимизируя зависимости друг от
друга.
Инкапсуляция. Внутренняя реализация модуля скрыта, наружу
выставляется только контракт (API).
Гибкость для будущего. Такой монолит легко поддерживать, а при
необходимости — постепенно выделять модули в отдельные
микросервисы.

7.

8.

9.

Недостатки
Масштабировать можно только всё приложение целиком, а не
отдельные модули.
При плохой организации кода монолит может превратиться в
«большой ком грязи».
Ограничения по технологическому стеку (весь монолит — одна
технология).

10.

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

11.

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

12.

13.

14.

15.

16.

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

17.

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

18.

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

19.

Для каждого модуля в приложении нужно определить схему и набор
таблиц. Все данные, относящиеся к некоему моду-лю, будут храниться
только в таблицах этого модуля. Как видите, модульность можно
распространить на базу данных, разместив данные, принадлежащие
разным модулям, в раз-ных таблицах (и даже в разных схемах).

20.

Использование разных таблиц и разных схем позволяет отделить друг
от друга данные разных модулей, но при этом легко ошибиться и
случайно создать SQL-соединение таблиц, принадлежащих разным
модулям, тем самым вновь связав их!
Однако допускается хранить идентификаторы ID записей из таблиц
одного модуля в таблицах другого. Например, модуль заказов может
хранить ID «ингредиентов» рецептов в своих таблицах в
order_schema, и если ему понадобится информация об ингредиенте,
то он обратится к API модуля рецептов и передаст ему
соответствующий ID.
Прочтите еще раз! Это не на ссылка внешний ключ.

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

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

34.

Избегайте использовать прямое взаимодействие между
модулями, иначе есть риск стереть границы между
ними.
Каждый модуль должен иметь открытый API для
взаимодействия с другими модулями, но внутренняя
реализация модуля должна оставаться закрытой от
остального мира.
Отказ от прямого взаимодействия модулей позволяет
вносить изменения в их реализацию, не заботясь о
других модулях.

35.

Поддержание разделения монолита на модули требует
времени и усилий.
Управлять модульным монолитом можно с помощью
разных приемов. Например, некоторые языки имеют
встроенную поддержку модулей.
Еще один подход — физическое разделение кода на
отдельные подпроекты или даже разные репозитории.
Обычно этот подход предполагает использование
инструментов для объединения модулей при сборке
монолита.

36.

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

37.

38.

39.

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

40.

Преимущества
Гибкость и расширяемость: легко добавлять
новые функции без изменения ядра.
Изоляция: модули независимы друг от друга, что
снижает риск ошибок и упрощает тестирование.
Повторное использование: модули можно
использовать в разных проектах или версиях.
Простота поддержки: изменения локализованы в
отдельных модулях.

41.

Недостатки
Сложность проектирования: требуется тщательно
продумывать интерфейсы и контракты.
Производительность: взаимодействие через
интерфейсы может быть медленнее, чем прямой
вызов функций.
Сложность управления версиями: необходимо
контролировать совместимость модулей и ядра.

42.

Примеры использования
Операционные системы (например, QNX, MINIX),
где драйверы и сервисы реализованы как модули.
Среды разработки (например, Eclipse, Visual
Studio), где функциональность расширяется за счёт
плагинов.
Бизнес-приложения с возможностью подключения
дополнительных модулей (например, ERP-системы,
страховые приложения).

43.

44.

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

45.

46.

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

47.

Eclipse IDE
Eclipse IDE спроектирована как «чистое» микроядро, поддерживающее разные
языки и инструменты с помощью плагинов.
Приложение для страхования
Приложение для страхования реализует стандартные правила, но позволяет
настраивать их под местные условия, поэтому имеет средний уровень
функциональности без плагинов.
Браузер
Браузеры поддерживают плагины, но не используют их в своей работе.
Браузер прекрасно можно использовать и без плагинов, так что это явно не
микроядерная архитектура.

48.

49.

50.

Инкапсулированные и распределенные плагины
Ядро в микроядерной архитектуре — это то, к чему
подключаются плагины.
Подключение, как правило, реализуется через
интерфейс. Плагин реализует интерфейс, через
который ядро поддерживает компонент.
При использовании монолитной модели каждый
плагин реализуется как компонент, который
подключается к ядру через интерфейс.

51.

52.

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

53.

Как происходит фактический вызов, зависит от физической архитектуры. В
монолитных архитектурах плагины реализуются в том же технологическом стеке,
что и ядро, и развертываются как встроенные компоненты (в виде JAR-файлов для
Java, DLL-библиотек для .NET или GEM-библиотек для Ruby). В распределенных
архитектурах ядро может вызывать плагины синхронно или асинхронно. Кроме
того, разработчики не ограничены платформой ядра и могут писать плагины на
других языках.

54.

55.

Плагины взаимодействуют с ядром системы через установленный
интерфейс и, соответственно, могут коммуницировать друг с другом
«через» ядро. Например, именно так IDE Eclipse, поддерживающая
множество языков, позволяет инструментам (таким, как
компиляторы и отладчики) взаимодействовать.
Взаимодействие плагинов сопряжено с серьезными проблемами.
Вам понадобится согласовать контракты между ядром и плагинами,
что потребует управления версиями.
Чтобы осознать проблемы, связанные с взаимодействием плагинов,
мы должны рассмотреть два способа взаимодействия ядра с
плагинами.

56.

Контракты плагинов
Обычно взаимодействие плагинов организуется через
контракты (другое слово для обозначения интерфейса).
Коммуникация происходит исключительно между
плагинами и ядром. Чтобы сделать возможным
взаимодействие плагинов, ядро должно взять на себя роль
посредника. В примере ниже PluginA ничего не знает о
других плагинах и взаимодействует только с ядром.
Однако PluginX должен взаимодействовать с PluginY, и
эта коммуникация протекает через ядро системы.

57.

Плагины могут взаимодействовать друг с другом через
ядро системы. Но нужно ли это?

58.

59.

60.

61.

62.

63.

64.

65.

66.

67.

68.

69.

Ключевые моменты_8
Микроядерная архитектура дает структурированный способ работы
с настройками с помощью плагинов.
Микроядерная архитектура состоит из двух основных частей: ядра
и одного или нескольких плагинов.
Ядро системы содержит минимальную функциональность и редко
изменяется.
Плагины служат для настройки и/или расширения поведения
системы.

70.

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

71.

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

72.

Микроядерные монолиты имеют типичные ограничения, присущие всем
монолитам, такие как ограниченные масштабируемость и эластичность.
Распределенные
микроядерные
архитектуры
имеют
улучшенную
масштабируемость, используя несколько процессов и поддерживая
масштабируемые взаимодействия (события).
Микроядерные архитектуры хорошо подходят для систем, решающих часто
меняющиеся отдельные задачи.
Если ядро системы с микроядерной архитектурой часто меняется, то это
означает, что архитекторы выбрали неправильный архитектурный стиль или
неверно разделили работу.
Микроядерный стиль имеет широкое применение, например, в IDE, обработке
текста, инструментах сборки и развертывания, интеграции, приложениях для
страхования и утилизации электроники.