Метод выявления архитектурной деградации в распределенных веб-системах на основе динамики структурных метрик

Современные распределенные веб-приложения, как правило, развиваются в условиях высокой изменчивости требований, коротких релизных циклов и постоянной эволюции [1] программной архитектуры. Использование CI/CD-практик и микро-сервисного подхода позволяет ускорить доставку функциональности, но одновременно порождает риски постепенной архитектурной деградации – ухудшения структуры системы, ее управляемости и сопровождаемости. В работе Романова В.Ю. [2] был сделан обзор и анализ объектно-ориентированных метрик.

Под архитектурной деградацией понимается накопление неблагоприятных изменений в архитектуре программной системы, приводящих к росту объема технического долга, усложнению связей между компонентами, нарушению модульности и снижению устойчивости при дальнейших изменениях [3]. Эти изменения, как правило, не фиксируются в явном виде и не сопровождаются сбоями, но со временем приводят к затруднениям в развитии, увеличению стоимости поддержки и снижению степени надежности.

На практике деградация архитектуры выявляется интуитивно или вручную, и зачастую лишь в моменты критических отказов или при необхо- димости масштабной реорганизации. Отсутствие формальных и автоматизированных подходов к мониторингу архитектурных трансформаций ограничивает возможности своевременного вмешательства и архитектурного контроля [4; 5].

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

приложение к новым требованиям. Применение этих подходов приобретает особую важность в условиях постоянно меняющихся технологий и быстро растущих требований к веб-приложениям, позволяя системам оставаться актуальными и производительными на протяжении длительного времени [6]. Целью настоящего исследования является разработка формализованной модели наблюдения за архитектурным состоянием распределенных веб-систем, позволяющей выявлять признаки деградации и определить точки архитектурного сдвига – моменты перехода к неустойчивым состояниям [7]. Критерии устойчивости системы базируются на оценке динамики внутренних параметров, что позволяет предсказывать момент потери стабильности [8].

Научная новизна работы заключается:

– в построении метамодели архитектурной деградации на основе временных рядов метрик;

– в введении количественных показателей архитектурной устойчивости;

– в экспериментальной валидации модели на реальных данных CI/CD-процессов.

Практическая значимость заключается в возможности внедрения полученных методов в системы архитектурного мониторинга, в архитектурные интерактивные аналитические панели (дашборды), а также в системы поддержки архитектурных решений. Успешное проектирование программных систем определяется большим количеством факторов. В статье [9] кратко рассмотрено понятие архитектуры программного обеспечения, а также целях введения данного понятия в процесс разработки. Кроме того, в работах [10–12] анализируются критерии для оценки качества построенной архитектуры. По мере того, как современные системы, требующие больших вычислительных мощностей, становятся все более масштабными, возникает необходимость в разработке схем обнаружения сбоев, которые помогут предотвратить дорогостоящие простои системы. Перспективным направлением в создании таких схем является использование легкодоступных измерений характеристик производительности системы, таких как среднее количество обработанных запросов и размер очереди в единицу времени [13–15].

Структурные метрики и архитектурная деградация

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

– рост сложности и связанности модулей;

– снижение модульности и повторное использование кода;

– усложнение тестирования и сопровождения;

– замедление внесения изменений;

– снижение надежности системы при масштабировании.

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

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

Таблица 1. Структурные метрики

Метрика	Описание
CBO (Coupling Between Objects)	Количество зависимостей между модулями/классами
LCOM (Lack of Cohesion in Methods)	Уровень связности внутри модуля
CC (Cyclomatic Complexity)	Количество линейно-независимых путей в коде
DIT (Depth of Inheritance Tree)	Глубина иерархии наследования
Fan-in/Fan-out	Количество входящих и исходящих зависимостей
Dependency Density (DD)	Отношение числа связей к количеству модулей
Architecture Volatility (AV)	Частота изменений архитектурных модулей во времени

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

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

– монотонный рост связности (CBO, DD);

– возрастающая сложность (CC);

– ухудшение связи между отдельными частями программного обеспечения (снижение когезии, LCOM);

– нестабильные участки архитектуры с высокой частотой изменений архитектурных модулей во времени.

Для анализа этих тенденций предлагается рассматривать метрики как временные ряды, собранные на базе регулярных измерений. Это позволяет выделить участки с ускоренным ростом нестабильности и точечно интерпретировать архитектурные риски.

Модель наблюдения и формализация архитектурного состояния

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

Обозначим архитектурное состояние системы в момент времени t как вектор:

A ( t ) = { ^т1 ( t ) , - , m i ( t ) , - , m n ( t ) } , где m i ( t ) - значение i- той структурной метрики в момент времени t;

n – число используемых метрик.

Эти значения могут собираться из инструментов статистического анализа кода, например, SonarQube.

Для формального анализа деградации введем понятие архитектурной устойчивости S ( t ) как функции от производных метрик:

S ( t ) = 1 - n X ' = ,

dm ( t )

dt

Чем выше скорость изменения метрик, тем ниже устойчивость системы. Значение S (t)e[0,1] интерпретируется как степень сохранности структуры. Приняты следующие оценки:

S >  0,9 - архитектура стабильна;

0,7 <  S <  0,9 - нормальное состояние;

0,4 <  S <  0,7 - начало деградации;

0,4 <  S - архитектура не стабильна, риск нарушения функционирования.

Для практического применения производные берутся как разность метрик по временным шагам:

Введем понятие точки архитектурного сдвига t * , при которой суммарная норма изменений превышает порог s :

X n =J ^mi ( t * ) ^- m ( t * ^-Л t )l > ^s .        (1)

Это означает, что архитектура перешла в иное качественное состояние, и продолжение работы без реструктуризации приведет к росту технического долга. Порог s может быть эмпирически определен на основе истории проекта или установленных SLA на архитектурное качество.

Алгоритм мониторинга состояния архитектуры строится по следующей схеме:

• –    сбор метрик при каждом CI-билде (автоматический сбор метрик при каждом запуске сборочного процесса);

• -    построение вектора состояния A ( t ) ;

• -    оценка устойчивости S ( t ) ;

  – выявление точек сдвига t * , по выражению (1), если S <  S min .

Экспериментальное исследование

Экспериментальная часть направлена на проверку применимости предложенной модели архитектурного мониторинга в условиях протекания реальных CI/CD-процессов. Основные задачи:

• –    собрать метрики архитектуры в динамике;

• –    оценить устойчивость архитектуры на протяжении нескольких спринтов;

• – выявить участки с признаками деградации;

  – сопоставить эти участки с реальными архитектурными изменениями и трудностями сопровождения.

Для этого была реализована система сбора и анализа архитектурных метрик с периодичностью один раз в сутки на протяжении 60 дней.

Эксперимент проводился на трех действующих веб-проектах (таблица 2).

^dmi ( t ) dt

= т ( t )^{- m}i ( t -^д t ) ,

i = 1, n .

Во всех системах были включены автоматические сборы метрик: CBO, CC, LCOM, DD, AV.

Таблица 2. Исследуемые системы

Система	Технологии	Особенности
ServiceHub	Node.js, React, PostgreSQL	Микросервисная архитектура, высокая частота релизов
Edu	Django, Vue.js	Монолит с активной модульной декомпозицией
MetricsBoard	Go, TypeScript	Легковесный веб-инструмент, тестовая среда

Рисунок 1. Динамика архитектурных метрик и устойчивости

Результаты эксперимента приведены на рисунке 1.

В интервале [день 24–30] наблюдался резкий рост связности и сложности кода (CBO, CC). Устойчивость S(t) опустилась ниже 0,6 и была зафиксирована точка архитектурного сдвига.

Событие совпало с введением новых API-интеграций и расширением бизнес-логики без пересмотра архитектуры. В проекте Edu наблюдался медленный рост показателей AV и DD, связанный с накоплением нестабильных модулей. На 45-й день был проведен частичный рефакторинг, после чего устойчивость повысилась. Эксперимент показал, что:

– метрики могут использоваться как надежные индикаторы ухудшения архитектуры;

– временные ряды метрик дают основу для построения архитектурных сигналов;

– интеграция в CI/CD позволяет выявлять деградацию до появления критических дефектов.

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

Заключение

В настоящей работе предложен формализованный подход к выявлению архитектурной деградации в распределенных веб-системах на основе анализа динамики структурных метрик. Архитектура представляется как динамическое состояние, описываемое вектором наблюдаемых метрик, таких как CBO, CC, LCOM, плотность зависимостей и архитектурная изменчивость.

Это позволяет отслеживать эволюцию архитектуры в контексте CI/CD-практик.

Была введена метрика архитектурной устойчивости S ( t ) , отражающая степень стабильности архитектурной структуры. Также определено понятие точки архитектурного сдвига – момента резкого ухудшения метрик, указывающего на необходимость вмешательства со стороны архитекторов и инженеров.

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

– не координированными архитектурными изменениями;

– увеличением плотности зависимостей;

– ростом сложности кода.

На основе получаемых графиков можно выстраивать автоматизированные оповещения и архитектурные отчеты.

Основные выводы:

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

• 2.    Вектор метрик позволяет представить архитектурное состояние как объект наблюдения.

• 3.    Метрика устойчивости эффективно фиксирует моменты структурной нестабильности.

• 4.    Интеграция модели в CI/CD процессы повышает качество сопровождения и управляемость архитектуры.

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