Комментарии 5
Очень поверхностно, хоть и верно.
Резать на микросервисы когда уже сформировалось г-но мамонта это не очень хороший паттерн. Отрезаем отрезаем и остаётся то же говно, которое уже не резрежешь.
Я щас склоняюсь к микроядерной (плагинной) архитектуре в CRM ERP like системах с богатыми агрегатами и сложными инвариантами. Изначально ядро минимальное. Дисциплина разработки не позволяет его усложнять, зато оно обозримое одним человеком. Всё второстепенное выносится наружу (плагины, DLL/so, микросервисы - как хотите): функционал без которого система ещё может использоваться (с плавной деградацией/устареванием данных и т.п.).
Таким образом, поддерживаются логическая верифицируемость и жёсткие контракты. Модуль / плагин / микросервис реализует контракт легко, через LLM.
То есть можете называть это микросервисами, но выбор между монолитным или распределенным деплоем, вопросы изоляции и восстановления после сбоя это вопрос к девопсам. А вопросы долгой жизни и развития приложения это не к девопсам а к software architect.
Если чуть подробнее про микроядерную событийную архитектуру. А будете её писать монолитом или микросервисами дело ваше.
Суть архитектуры
Ядро как State Machine: Ядро содержит только описание состояний сущностей и логику валидности переходов. Оно не инициирует действия, а определяет критерии (контракты фактов), при которых переход в следующее состояние допустим.
Плагины как провайдеры фактов: Вся функциональная сложность вынесена в модули, которые поставляют ядру подтверждения (факты) о выполнении условий. Ядро не знает как получен факт, оно проверяет только его наличие и валидность относительно контракта.
Управляемая деградация: Отсутствие или задержка факта от плагина не вызывает системный сбой. Объект просто остается в текущем состоянии или переходит в «режим ожидания/ручной обработки». Система сохраняет работоспособность Core-функций при отказе любого количества второстепенных модулей.
Разделение консистентности: Ядро обеспечивает жесткую синхронную консистентность только для критических инвариантов внутри своих границ. Все остальные связи реализуются через асинхронную событийную модель (Eventual Consistency), где время доставки факта не влияет на стабильность ядра.
Почему это LLM-friendly
Изоляция контекста (Context Window): Для реализации плагина LLM не нужно понимать всё устройство ERP. Ей достаточно предоставить:
Схему входного события от ядра.
Спецификацию выходного факта (контракт).
Описание конкретной задачи (например, «сходи в API Сбербанка и подтверди оплату»).
Формальная верификация: Ответ плагина это структурированный факт (JSON/Protobuf). Его легко проверить автоматическими тестами на соответствие схеме ядра. Если LLM ошибается в логике, ядро просто отвергает факт как невалидный, не нарушая свою целостность.
Чистота контрактов: Поскольку плагины общаются с ядром через факты, а не через общую память или БД, исключаются побочные эффекты. LLM генерирует «чистую» функцию-адаптер, которую легко заменить или перегенерировать при изменении внешнего API, не затрагивая архитектуру системы.
Декларативность: Вместо написания сложных процедурных цепочек, вы просите LLM реализовать конкретное «обещание». Это совпадает с сильной стороной LLM - генерацией кода по четким спецификациям в рамках ограниченной ответственности..
Согласен, без привязки к бизнес-границам микросервисы быстро превращаются в распределённый монолит.
Да не нужны микросервисы сами по себе. Важно поддерживать простоту ядра, это цель. А если бездумно отрезать от монолита всё что попало то ничего не получится: остаток сохранит весь хаос. Да ещё и на грабли распределенной архитектуры по полной программе.
Берут монолит, в котором всё переплетено. Отрезают кусок, делают из него сервис. Оставшийся монолит не стал проще — он стал тем же хаосом минус один кусок, плюс сетевой вызов туда, где этот кусок был. Повторяют. Через год имеют распределённый монолит, где хаос сохранился, но добавились сетевые задержки, partial failures, eventual consistency там где она не нужна, и необходимость координировать деплой двадцати сервисов.
Остаток не стал проще, потому что никто не определил, что является ядром и как поддерживать его минимальность и простоту
А, понял...
два принципиально разных подхода к управлению сложностью.
Статья: уменьши blast radius, чтобы изменения в одном модуле не требовали изменений в других модулях.
Мой подход: обеспечь верифицируемость.
Из минимизации blast radius не следует верифицируемость. А обратно, пожалуй, работает.
И для ERP like систем верифицируемость важнее.
Декомпозиция микросервисов: 5 паттернов против распределённого монолита