Аннотация
ВВЕДЕНИЕ 4
1 Постановка задачи и анализ предметной области 5
1.1 Практическая значимость 5
1.2 Проблема 5
1.3 Цель и задачи работы 6
1.4 Микросервисная архитектура 7
1.5 Контейнеризация и оркестрация 8
1.5.1 Контейнеры 8
1.5.2 Оркестрация контейнеров 9
1.5.3 Стратегии обновления контейнеров 10
1.5.4 Проблемы при обновлении контейнеров 11
1.6 Балансировка нагрузки 12
1.6.2 «Липкая» балансировка (session affinity) 13
1.7 WebSocket соединение 13
1.7.1 Что такое WebSocket соединение? 13
1.7.2 Основные характеристики WebSocket соединения 14
1.7.3 Обобщенное описание принципа работы 14
1.7.5 Возможности и ограничения WebSocket соединений 15
2 Анализ, моделирование и реализация решения 16
2.1 Существующие подходы к решению проблемы 16
2.1.1 Вариант 1: Переподключение на стороне клиента с загрузкой
пропущенных сообщений из базы данных 16
2.1.2 Вариант 2: Централизованный WebSocket прокси 18
2.1.3 Вариант 3: Переподключение на стороне клиента с загрузкой
пропущенных сообщений из журнала брокера 21
2.1.4 Сравнительная таблица 23
2.1.5 Выбор решения 24
2.2 Проектирование 25
2.2.1 Варианты использования 25
2.2.3 ER диаграмма 28
2.2.6 Процесс восстановления соединения 36
2.2.7 Процесс загрузки пропущенных сообщений 39
3 Анализ результатов и выводы 41
ЗАКЛЮЧЕНИЕ 42
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ 43
Современные веб-приложения всё чаще используют постоянные соединения между клиентом и сервером для обеспечения взаимодействия в реальном времени. Такие соединения, как правило, реализуются через протокол WebSocket, который позволяет организовать двустороннюю передачу данных без постоянных повторных запросов. Это особенно важно для систем, в которых критично своевременное получение информации - например, в мессенджерах, торговых терминалах, онлайн-редакторах и других интерактивных сервисах.
Параллельно с этим широкое распространение получили архитектурные подходы, ориентированные на микросервисы и контейнеризацию. Благодаря использованию оркестраторов, таких как Docker Swarm и Kubernetes, стало возможным регулярно и автоматически обновлять серверные компоненты без остановки всей системы. Однако в таких архитектурах возникает проблема: при обновлении контейнеров, к которым подключены клиенты, WebSocket- соединения обрываются, что может привести к потере данных и ухудшению пользовательского опыта.
Задача обеспечения устойчивости WebSocket-соединения в условиях динамического обновления серверных компонентов остается актуальной. Важно не только минимизировать время восстановления соединения, но и гарантировать доставку всех сообщений, отправленных во время его отсутствия.
Данная работа направлена на исследование возможных решений этой проблемы и реализацию прототипа, демонстрирующего устойчивую архитектуру, способную сохранить или корректно восстановить WebSocket- соединение при горячем обновлении контейнеров в микросервисной среде.
В ходе выполнения выпускной квалификационной работы достигнута поставленная цель - разработан подход, обеспечивающий непрерывную работу WebSocket-соединений при «горячем» обновлении контейнеров в микросервисной архитектуре.
Сначала была проведена аналитическая часть: изучены три существующих класса решений (клиент-БД, централизованный WS-прокси, брокер с журналом), выявлены их ограничения и критерии применимости. На основании сравнительного анализа сформулированы требования к собственной системе и обоснован выбор гибридного варианта «Redis Pub/Sub + PostgreSQL».
На этапе проектирования построена полная UML-модель: диаграмма компонентов, диаграммы последовательностей для доставки и восстановления сообщений, а также ER-модель хранилища. Выбран стек технологий: серверное приложение реализовано на Go [15], что обеспечило высокую пропускную способность и естественную конкурентность обработки тысяч одновременных соединений. Клиентская часть выполнена на TypeScript [16] + Svelte [14], что позволило создать реактивный интерфейс с минимальным весом бандла.
Инфраструктура включает PostgreSQL в роли базы данных, Redis Pub/Sub [12] в роли брокера сообщений, Nginx [9] в роли балансировщика HTTP и WS трафика. Все компоненты упакованы в Docker-образы и развернуты под управлением Docker Swarm.
Итогом работы стал мессенджер, демонстрирующий, что задача сохранения WebSocket-каналов при обновлении контейнеров может быть решена без внедрения сложных инфраструктурных решений и без вреда для пользовательского опыта.
