Проектирование архитектуры информационных систем

4.4 Понятие архитектуры и технологического стека

Архитектура информационной системы определяет фундаментальную организацию системы, ее основные элементы, обязанности, связи, принципы и значимые решения. Технологический стек представляет собой совокупность языков программирования, платформ, библиотек, систем управления базами данных, протоколов, инфраструктурных и эксплуатационных средств, используемых для реализации архитектуры. Архитектура и стек тесно связаны, но не тождественны. Архитектура отвечает на вопрос, как организована система, а технологический стек — какими средствами она реализована. Например, система может иметь слоистую архитектуру независимо от того, реализована ли она на Java,.NET или Python. Микросервисная архитектура может использовать разные языки и базы данных. Технологии не должны определять архитектуру без учета требований. Выбор Kubernetes не является основанием автоматически делить приложение на десятки сервисов. Сначала определяются задачи и архитектурные границы, затем выбираются подходящие средства. Архитектурный стиль описывает семейство систем с общими характеристиками. К распространенным стилям относятся многоуровневая архитектура, модульный монолит, микросервисы, событийно-ориентированная архитектура, клиент-серверная система, обработка через очередь и работника, бессерверная архитектура и архитектура обработки больших данных. Microsoft подчеркивает, что архитектурный стиль не требует определенной технологии, хотя некоторые технологии лучше соответствуют конкретному стилю.

4.4.1 Уровни технологического стека

В технологическом стеке можно выделить несколько условных уровней. Клиентский уровень включает веб-интерфейс, мобильное приложение, настольную программу или специализированное устройство. Здесь выбираются язык, пользовательская библиотека, средства управления состоянием и взаимодействия с сервером. Для веб-клиента могут использоваться HTML, CSS, JavaScript или TypeScript и библиотеки React, Angular или Vue. Выбор должен учитывать сложность интерфейса, компетенции команды, доступность компонентов и срок поддержки. Не каждое приложение требует тяжелой клиентской платформы. Для простой административной формы может быть достаточно серверной генерации страниц. Серверный уровень реализует прикладную логику, обработку запросов и правила предметной области. Возможны платформы Java и Spring,.NET, Node. js, Python, Go и другие технологии. Выбор языка определяется не только производительностью. Необходимо учитывать экосистему, библиотеки, специалистов, безопасность, тестируемость и сопровождение. Интеграционный уровень включает программные интерфейсы, брокеры сообщений, шлюзы и средства преобразования данных. Синхронное взаимодействие удобно, когда результат необходим немедленно. Асинхронное взаимодействие снижает временную связанность, но требует обработки повторов, порядка сообщений и временной несогласованности. Уровень данных включает операционные базы, кэш, поисковые индексы, файловые хранилища, аналитические платформы и средства потоковой обработки. Реляционная база подходит для структурированных данных и транзакций. Документное хранилище удобно для гибких структур. Графовая база используется при сложных отношениях. Поисковый индекс оптимизирован для текстового поиска. Не следует выбирать нереляционную базу только из-за ее популярности. Для финансовой операции строгая транзакционность может быть важнее горизонтального масштабирования. Инфраструктурный уровень включает физические серверы, виртуальные машины, контейнеры, облачные сервисы, сети и системы хранения. Модель развертывания может быть локальной, облачной или гибридной. Выбор определяется законодательством, безопасностью, стоимостью, доступностью и компетенциями. Уровень поставки включает систему контроля версий, сборку, тестирование, хранилище артефактов, развертывание и управление инфраструктурой. Уровень эксплуатации включает мониторинг, журналы, трассировку, управление инцидентами, резервное копирование и восстановление. Уровень безопасности проходит через весь стек. Он включает идентификацию, управление доступом, шифрование, секреты, анализ зависимостей, защиту сети и аудит. Безопасность нельзя реализовать одним отдельным продуктом. Она должна быть свойством архитектуры и процесса.

4.4.2 Критерии выбора технологического стека

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

4.4.3 Пример технологического стека

Для корпоративного веб-приложения может быть выбрана архитектура модульного монолита. Пользовательский интерфейс создается на TypeScript и React, серверная часть — на Java и Spring Boot, данные хранятся в PostgreSQL, для кэширования используется Redis, а интеграция с внешними системами выполняется через HTTP-интерфейсы и брокер сообщений. Приложение упаковывается в контейнерный образ. Для небольшой нагрузки оно может развертываться на нескольких виртуальных машинах без сложной оркестрации. Git используется для управления версиями, GitLab CI/CD — для сборки и тестирования, Terraform — для инфраструктуры, Ansible — для конфигурации, Prometheus и Grafana — для мониторинга. Этот пример не является универсальным рекомендуемым стеком. В другом проекте. NET и SQL Server могут лучше соответствовать существующей инфраструктуре. Для небольшой внутренней системы часть компонентов будет лишней. Важно, чтобы каждый элемент решал конкретную задачу. Если Redis не требуется для достижения показателей производительности, его добавление только усложнит систему.

4.4.4 Архитектура в гибкой разработке

Распространено ошибочное мнение, что Agile исключает предварительное архитектурное проектирование. Гибкая разработка отказывается не от архитектуры, а от попытки заранее детально спроектировать всю систему без обратной связи. На начальном этапе необходимо определить минимально достаточную архитектуру: границы системы, основные компоненты, критические данные, интеграции, безопасность и решения по самым опасным рискам. Некоторые решения должны приниматься заранее. Например, требования к размещению персональных данных, отказоустойчивости и взаимодействию с внешней системой могут определять базовую структуру. Другие решения можно отложить до появления информации. Преждевременный выбор технологии для гипотетической нагрузки создает лишнюю сложность. В гибкой архитектуре применяется понятие архитектурной основы, иногда называемой архитектурным заделом. Она включает технические возможности, необходимые для будущего развития. Например, если в следующих итерациях планируется подключение нескольких каналов уведомлений, архитектура должна предусмотреть расширяемый интерфейс, но не обязательно сразу реализовывать все каналы. Для проверки архитектурных гипотез применяются технические исследования и прототипы. Критический риск должен проверяться как можно раньше. Архитектурные решения фиксируются в записях решений. Документация развивается вместе с системой. Автоматические архитектурные проверки предотвращают постепенное разрушение структуры. Например, модуль предметной области не должен зависеть от пользовательского интерфейса.

4.4.5 Эволюционная архитектура

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

4.4.6 Взаимосвязь архитектуры и DevOps

Архитектура определяет возможность независимой разработки, тестирования и выпуска. Если изменение одного модуля требует полной пересборки и длительной проверки всей системы, непрерывная поставка затрудняется. DORA отмечает, что технические и организационные структуры с более слабой связанностью поддерживают способность к непрерывной поставке. Микросервисы могут обеспечить независимый выпуск, но увеличивают сложность сети, данных и наблюдаемости. Успешная микросервисная архитектура требует зрелых DevOps-практик. Microsoft также указывает, что микросервисы требуют развитых инженерных и эксплуатационных возможностей. Модульный монолит часто позволяет начать с более простой эксплуатации и сохранить внутренние границы. Сервисы следует выделять при наличии конкретной причины: независимого масштабирования, отдельного жизненного цикла, требований безопасности или организационной автономии. Событийно-ориентированная архитектура ослабляет прямую связанность отправителей и получателей, но создает проблемы доставки, порядка и согласованности. DevOps должен учитываться при проектировании архитектуры. Необходимо заранее определить развертывание, конфигурацию, мониторинг, отказоустойчивость, обновление и восстановление. Система, которую невозможно удобно эксплуатировать, не является завершенным архитектурным решением.

4.4.7 Интегрированный пример применения методологий

Рассматривается проект создания информационной системы управления заявками технического обслуживания предприятия. На первом этапе проводится Lean-анализ потока. Устанавливается, что заявка несколько дней ожидает ручного распределения, информация дублируется, а исполнители не видят приоритет. Команда создает карту потока и определяет основную потерю — ожидание назначения. Цель продукта заключается в сокращении времени от регистрации заявки до начала работы. Для организации разработки используется Scrum. Владелец продукта формирует бэклог, включающий регистрацию заявки, классификацию, назначение, уведомление, контроль срока и отчетность. Первый спринт создает минимальную функцию регистрации и просмотра. На обзоре пользователи показывают, что необходима возможность приложить фотографию оборудования. Бэклог уточняется. Внутри спринта используется Kanban-доска со стадиями анализа, разработки, проверки и готовности. Для разработки и проверки устанавливаются ограничения незавершенной работы. Архитектура первоначально строится как модульный монолит. Выделяются модули заявок, пользователей, оборудования и уведомлений. Используется реляционная база данных. Интерфейс описывается в OpenAPI. Архитектурные схемы создаются по модели C4. Решения фиксируются в записях архитектурных решений. Исходный код и инфраструктура хранятся в Git. После каждого изменения запускаются сборка, модульные и интеграционные тесты, анализ качества и проверка зависимостей. Контейнерный образ публикуется в реестре и автоматически развертывается в тестовой среде. После подтверждения версия передается в промышленную среду. Инфраструктура описывается Terraform, конфигурация — Ansible. Метрики и журналы передаются в систему наблюдаемости. После внедрения Kanban используется для сопровождения. Анализ времени цикла показывает, что задачи долго ожидают проверки. Команда автоматизирует часть тестов и меняет ограничение незавершенной работы. DevSecOps-проверки контролируют зависимости, секреты и контейнерные образы. Эксплуатационная информация поступает в бэклог продукта. Таким образом, Lean определяет ценность и потери, Scrum организует итерационную разработку, Kanban управляет потоком, DevOps обеспечивает автоматизированную поставку и эксплуатацию, а архитектура и технологический стек создают техническую основу системы.

4.4.8 Основные принципы комплексного применения методологий

Методологии не должны применяться механически. Необходимо понимать проблему, которую решает каждый подход. Lean используется для анализа ценности и потока. Agile обеспечивает адаптацию к изменениям. Scrum создает ритм эмпирического управления продуктом. Kanban управляет непрерывным потоком и ограничивает перегрузку. DevOps объединяет создание и эксплуатацию. DevSecOps интегрирует безопасность. GitOps обеспечивает декларативное управление средой. MLOps охватывает жизненный цикл моделей. Архитектура должна поддерживать выбранный процесс. Частые изменения требуют модульности, автоматических тестов и воспроизводимой инфраструктуры. Технологический стек должен выбираться по требованиям и способности организации сопровождать решение, а не по моде. Инструменты должны поддерживать поток и прослеживаемость. Их количество не является показателем зрелости. Хорошо организованный простой конвейер полезнее большого набора плохо интегрированных продуктов. Метрики должны использоваться для улучшения системы, а не для давления на отдельных сотрудников. Документация должна быть достаточной, актуальной и связанной с реальной системой. Архитектурная схема, не обновлявшаяся несколько лет, создает ложное представление. Гибкость не означает отказ от качества. Чем быстрее выполняются изменения, тем выше требования к автоматизации, безопасности, архитектуре и дисциплине. Качественная методология проектирования информационной системы формирует непрерывный цикл: выявление потребности, определение ценности, проектирование, реализация, автоматическая проверка, выпуск, наблюдение за эксплуатацией и последующее улучшение. Такой цикл позволяет системе развиваться вместе с потребностями пользователей, сохраняя управляемость, надежность и архитектурную целостность.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.