reversemind

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

· 4 мин чтения

#system design#архитектура#масштабируемость#микросервисы#бэкенд

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

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

1. Файл-серверная архитектура

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

  • Как работает: клиент запрашивает файл у сервера, сервер отправляет файл, клиент обрабатывает его локально.
  • Примеры: NAS (Samba, NFS), ранние СУБД с сырыми данными на клиенте.
  • Плюсы: простота, централизованное хранение, удобное резервное копирование.
  • Минусы: сервер становится узким местом при большом числе запросов, ограниченная масштабируемость, зависимость от сети.

Когда использовать: небольшие системы с ограниченным числом пользователей (корпоративные файловые хранилища).

2. Клиент-серверная архитектура

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

  • Как работает: клиент (браузер) отправляет запрос к серверу, сервер обрабатывает (вычисления, БД) и возвращает ответ (JSON, HTML).
  • Примеры: веб-приложения, мобильные приложения с REST/GraphQL API, банковские системы.
  • Плюсы: централизованная логика, оптимизация сервера, масштабируемость через балансировщики.
  • Минусы: сервер — потенциальное узкое место, задержки сети, требования к безопасности.

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

3. Peer-to-Peer (P2P)

Нет центрального сервера — все узлы равноправны и могут быть и клиентами, и серверами.

  • Как работает: узлы обмениваются данными напрямую (например, BitTorrent — скачивание и раздача частей файла).
  • Примеры: файлообмен (BitTorrent, eMule), блокчейн (Bitcoin, Ethereum), мессенджеры с прямой передачей.
  • Плюсы: устойчивость к сбоям, масштабируемость за счёт числа узлов, нет единой точки отказа.
  • Минусы: сложность управления и безопасности, производительность зависит от узлов, нужны механизмы консенсуса для целостности данных.

Когда использовать: децентрализованные системы (блокчейн, файлообменники).

Критерии информационных систем

Надежность (Reliability)

  • SLO — целевые показатели (например, 99.9% доступности).
  • SLA — договор с гарантиями и штрафами за нарушение.
  • SLI — измеримые индикаторы (процент успешных запросов).
  • Обеспечение: резервирование, обработка ошибок (graceful degradation), мониторинг и алерты (Prometheus).

Масштабируемость (Scalability)

  • Вертикальная: увеличение мощности одного сервера (CPU, RAM). Просто, но есть физические пределы.
  • Горизонтальная: добавление серверов. Требует распределённой архитектуры, но масштаб практически неограничен.
  • Инструменты: балансировщики (NGINX, ELB), шардинг, кэши (Redis, Memcached), микросервисы.

Stateless vs Stateful

  • Stateless: каждый запрос обрабатывается независимо, без хранения состояния на сервере. Удобно для масштабирования (любой сервер может обработать запрос). Пример: REST API для списка постов.
  • Stateful: сервер хранит состояние (сессии). Сложнее масштабировать — запросы нужно направлять к одному серверу. Управление: JWT, Redis для сессий, sticky sessions.

Производительность

  • Latency — время обработки одного запроса.
  • Throughput — количество запросов в единицу времени (rps).
  • Low-latency vs high-throughput: биржи требуют минимальной задержки, стриминг — высокой пропускной способности.
  • Оптимизация: кэширование, CDN, очереди (RabbitMQ), индексы и денормализация в БД.

Удобство сопровождения и безопасность

  • Сопровождение: чистый код, документация, модульная архитектура, тесты, CI/CD.
  • Безопасность: шифрование (TLS, AES), аутентификация и авторизация (OAuth, JWT), защита от DDoS и инъекций (WAF, валидация).

Высокая нагрузка и типы систем

Высокая нагрузка — не только про rps. 20 rps с тяжёлыми вычислениями (рендеринг 3D) могут быть сложнее 20 000 rps простых запросов (чтение из кэша). Важен характер нагрузки.

  • Data-Intensive: большие объёмы данных, хранение, поиск, фильтрация. Примеры: поисковики, соцсети, аналитика (Snowflake, BigQuery). Технологии: PostgreSQL, MongoDB, Cassandra, Redis, Elasticsearch.
  • Compute-Intensive: сложные вычисления (ML, рендеринг, симуляции). Примеры: TensorFlow, PyTorch, обработка видео. Технологии: GPU/TPU, CUDA, Apache Spark.
  • Read-Heavy vs Write-Heavy: для read-heavy — репликация и кэши; для write-heavy — очереди (Kafka), шардинг, Cassandra/DynamoDB.

Архитектура бэкенда: монолит и микросервисы

Монолит

Весь код (логика, БД, API) в одном приложении.

  • Плюсы: простота разработки и отладки, высокая производительность для low-latency (нет сетевых вызовов).
  • Минусы: сложно масштабировать отдельные части, изменение одной части затрагивает всю систему, трудности с внедрением новых технологий.

Когда использовать: стартапы, прототипы, системы с акцентом на минимальную задержку (например, финансовые приложения).

Микросервисы

Приложение разбито на независимые сервисы, каждый отвечает за свою задачу (оплата, уведомления и т.д.).

  • Плюсы: независимые релизы и масштабирование, сбой одного сервиса не роняет всё, разные языки и технологии.
  • Минусы: сетевые вызовы медленнее локальных и могут отваливаться, сложнее консистентность и тестирование, «зоопарк» технологий.

Когда использовать: крупные системы с высокой нагрузкой и большими командами.

Резюме: монолит — как одноэтажный дом, всё под рукой, но расширять сложно; микросервисы — как жилой комплекс с автономными блоками, но с необходимостью координации.