Свойства гибкой и масштабируемой ИТ-инфраструктуры: ликбез по базовым концепциям и основные критерии оценки

AI решения инструменты кейсы карьера +7 (495) 204-14-33 Стать клиентом Свойства гибкой и масштабируемой ИТ-инфраструктуры: ликбез по базовым концепциям и основные критерии оценки 19.7.2024 В этой статье разберем понятия, которые лежат в основе понимания гибкой и масштабируемой IT-архитектуры: связанность, связность и инкапсуляция ошибок. Расскажем, как несоблюдение правил связности и связанности приводит к возникновению монолитов и сложно поддерживаемых архитектур. В конце статьи — ссылка на экспресс-тест, который поможет вам определить, является ли ваша ИТ-архитектура монолитной. Время на прочтение: 6 мин. Способ и логика взаимодействия элементов внутри ИТ-инфраструктуры наделяет ее определенными свойствами. Например, масштабируемостью и гибкостью или наоборот — неповоротливостью и уязвимостью к ошибкам.

Понимание этих свойств и корреляций – ключ к грамотному выбору конкретных подходов и инструментов для интеграций. В противном случае, компания рискует стать заложником инструмента — например внедрить ESB -слой для упрощения интеграций, но при этом так и не преодолеть ограничения старого-доброго монолита. Поэтому в этой статье разберем теоретическую базу: понятия связности, связанности модулей и инкапсуляцию. А еще предложим конкретные критерии для оценки гибкости ИТ-инфраструктуры и стресс-тест для проверки своего контура на монолит. Связанность, связность и инкапсуляция в микросервисной архитектуре Микросервисы позволяют обновлять и запускать отдельные функции. Например, систему управления пользователями или модуль обработки платежей без влияния на другие части приложения. Чтобы построить работающую микросервисную архитектуру, надо четко определить границы модулей.

В контексте качества границ микросервисов существует три основных концепции: 1. Связанность (coupling) — мера того, насколько взаимозависимы разные подпрограммы или модули. Другими словами, способ и степень взаимозависимости между программными модулями внутри отдельно взятой ИТ-архитектуры. Связанность бывает сильной (high coupling) и слабой (low/loose coupling). Сильная связанность (high coupling) означает высокую зависимость между модулями, что усложняет их понимание, изменение и тестирование. Воспринимается как серьезный недостаток системы, а еще является одним из характерных свойств монолитных систем. Слабая связанность (low coupling) — состояние системы, когда изменения в одном модуле не требуют изменений в другом. Слабо связанный сервис имеет необходимый минимум сведений о сервисах, с которыми ему приходится работать и отвечает только за свои данные в общем контексте.

Слабо связанный сервис обладает тремя главными свойствами: Малое число зависимостей между подсистемами (модулями) Слабая зависимость одного модуля от изменений в другом модуле. Легкость повторного использования подсистем. 2. Связность (cohesion) — степень взаимосвязанности элементов внутри модуля: то, насколько задачи, выполняемые одним программным модулем, связаны друг с другом. Как и со связанностью, выделяют два уровня связности: Сильная связность (high cohesion) — состояние, когда обязанности компонентов внутри одного модуля хорошо согласованы между собой и он не выполняет огромных объемов работы. В отличие от сильной связанности (где речь идет о связанности разных модулей), сильная связность внутри одного модуля — позитивный признак. Слабая связность (low cohesion) — состояние, когда один модуль выполняет много разнородных функций или несвязанных между собой обязанностей.

Это свойство модуля приводит к следующим проблемам: Трудность понимания Сложность при повторном использовании Сложность поддержки Ненадежность, постоянная подверженность изменениям Понятия связанности и связности тесно переплетены. Связанность представляет отношения между объектами через границы модулей. Связность же применима к отношениям между функциональными объектами внутри границ модуля. Эти два понятия важно не путать. В этой статье мы фокусируемся на категории связанности как индикатора гибкой ИТ-архитектуры. Идеальный вариант — сочетание слабой связанности между модулями сервиса и сильной связности между компонентами внутри модуля. То есть, когда модуль имеет небольшое число внешних связей и отвечает за решение близких по смыслу задач. ‍ 3. Инкапсуляция — это скрытие деталей реализации внутри микросервиса.

Эти детали как бы помещают в капсулу, чтобы их нельзя было повредить извне. Идея в том, пользоваться только теми данными, которые доступны, и не лезть внутрь. То есть, сервису должно быть известно минимум контекста и данных о другом сервисе, с которым он общается. И пользоваться он должен только тем, что по умолчанию доступно. Например, Дэвид Парнас, канадский информатик и один из создателей концепции модульности в ПО, рассматривал связи между сервисами, как предположения, которые они делают друг о друге. Чем меньше таких предположений, тем легче изменить изменить одну часть сервиса, не затрагивая другую. Снижение количества связей и информации сервисов друг от друге позволяет ускорить разработку, сделать сервис более прозрачным и гибким. Что все это значит на практике и причем тут общий контекст? Прежде чем переходить от сложной теории к практике, введем категорию контекста.

В разработке ПО есть два контекста — контекст приложения и контекст предприятия. Сервис-ориентированная архитектура, микросервисная архитектура и монолитная архитектура построены вокруг контекста. Например, заказы в контекстах CRM-системы и интернет-магазина (e-shop) — разные вещи. Атрибуты заказа в CRM-системе и интернет-магазине отличаются: Для контекста предприятия о заказе важно знать только ограниченный набор параметров — например, идентификатор, клиента и сумму. Все остальные атрибуты CRM-системы контексту предприятия не нужны. Чтобы объяснить, чем отличаются сильная и слабая связанность на практике, рассмотрим два варианта обмена информацией между CRM и интернет-магазином. Для обмена данными CRM и интернет-магазин должны понимать друг друга.

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

Быстрая масштабируемость. ‍Слабосвязанную систему легко масштабировать и добавлять новые сервисы — другие системы не знают о том, что вы добавили что-то в общий контекст и продолжают управлять своим бэклогом самостоятельно. В сильно связанной или монолитной архитектуре быстро наступает момент, когда разработчики оказываются перегруженными бесконечными доработками интеграции, кросс-командным тестированием, выгрузками заказов и т.д. Но все равно что-то продолжает работать не так, и в какой-то момент изменения становятся еще и экономически невыгодными. Например, в 2001 году Amazon столкнулся с подобной ситуацией→, когда их монолитная архитектура стала причиной больших задержек в выпуске новых фич и трудностей в управлении изменениями.

В итоге, переход на микросервисы улучшил масштабируемость и скорость разработки, хотя и потребовал от Amazon значительных инвестиций в инфраструктуру и управление. 2. Отказоустойчивость. ‍В слабо связанной интеграции все ошибки инкапсулированы за счет небольшого количества связей между сервисами. При отказе какого-то одного потока, все остальные продолжают работать как обычно. При этом система без проблем справляется даже с пиковыми нагрузками. 3. Простота мониторинга и высокая скорость решения инцидентов. ‍В сильно связанных системах мониторингом и решением инцидентов занимается супер-синьор, часто перегруженный, так как только он может разобраться в спагетти-связях→ между сервисами и найти источник ошибки. В слабо связанных системах мониторинг осуществляется просто — его можно делегировать техподдержке. А еще можно настроить автоматические алерты на превышение каких-то параметров. 4.

Высокая скорость изменений. ‍Доработка любого из сервисов никак не скажется на работе всех остальных, а новые потоки данных можно запускать быстро. Компании со слабо связанной архитектурой быстрее внедряют новые сервисы. Чем быстрее внедряются инновации, тем меньше упущенная выгода. По оценкам экспертов, более 80% компаний в мире уже используют микросервисы→, чтобы повысить шансы на победу в конкурентной гонке. 5. Актуальность данных в системах. ‍Тут возвращаемся к понятию общего контекста и примеру с CRM-системой и интернет-магазином в рамках одного предприятия. В монолитных системах каждый запрос от одной системы другой нужно переводить в собственный контекст. Это приводит к ошибкам в данных, потерям и неточностям. В слабосвязанных контурах такой проблемы нет, потому что каждая система отвечает только за передачу своих данных в общий контекст. 6.

Защита от вендорлока (привязки к поставщику). Наличие интеграций у конкретного из сервисов с какими-то другими не является препятствием для замены или доработки конкретного сервиса. А интеграцию можно делегировать не только команде разработки внешнего сервиса или вендору, но и любому разработчику и подрядчику. Пройдите экспресс-тест IT-архитектуры Узнайте, у вас монолит или слабо связанная архитектура Пройти тест Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Оглавление Связанность, связность и инкапсуляция в микросервисной архитектуре Что все это значит на практике и причем тут общий контекст?

Главные признаки слабо связанной архитектуры Другие статьи Смотреть все 1С Управление ERP возможности и преимущества для бизнеса 4/9/2025 Подробнее Кейсы по внедрению Talend в enterprise-проекты: мировой опыт 15/1/2021 Подробнее AI трансформация — ключ к масштабируемому росту, автоматизации процессов и инновациям в бизнесе и разработке 29/8/2025 Подробнее Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта Ок Давайте обсудим ваш проект С вами свяжутся персональные менеджеры clients@kt.team Email: @kt_team_it Telegram: О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул.

40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными →