Кратко, по существу — архитектурные и реализационные различия + когда что использовать.
1) Основная идея
- Observer: есть объект-наблюдаемый (Subject) и явный набор наблюдателей. Когда Subject меняется — он уведомляет своих наблюдателей напрямую. Пример: GUI-слушатели.
- Обозначения: наблюдаемый $S$, наблюдатели $O_1,O_2,\dots$.
- Publish–Subscribe: издатели публикуют события в канал/тему, посредник (broker) маршрутизирует сообщения подписчикам. Издатель не знает подписчиков; подписчики не знают издателей.
- Обозначения: издатель $P$, брокер $B$, подписчики $C_i$.
2) Архитектурные различия
- Связность:
- Observer: более тесная (publisher хранит ссылки на конкретные observers). Часто in-process.
- Pub-Sub: слабая/контекстная (publisher ↔ broker ↔ subscriber). Поддерживает физическое распределение.
- Топология:
- Observer: point-to-multipoint с прямыми ссылками.
- Pub-Sub: логическая шина/темы, часто многоуровневая, возможно с маршрутизацией, топиками и фильтрацией.
- Временные требования:
- Observer: обычно синхронные уведомления (callbacks) — низкая задержка, но блокирование возможно.
- Pub-Sub: чаще асинхронные (очереди, буферы), поддерживает отложенную доставку и повтор.
- Масштабируемость:
- Observer: хорошо для малого числа in-process подписчиков.
- Pub-Sub: масштабируется горизонтально, пригоден для распределённых систем.
- Надёжность и гарантии доставки:
- Observer: как правило "fire-and-forget" в памяти, без гарантий повторной доставки.
- Pub-Sub: брокеры дают уровни гарантий (at-least-once, at-most-once, exactly-once), персистентность, retry, ack.
3) Реализация — ключевые отличия
- Хранилище подписок:
- Observer: Subject содержит список ссылок/колбэков; регистрация/отписка — простые операции.
- Pub-Sub: брокер хранит темы/подписки, может поддерживать фильтры, селекторы, шаблоны (topic/*), ACL.
- Коммуникация:
- Observer: обычно вызов функции/метода (in-memory). Может быть pull (observer запрашивает состояние) или push (subject передаёт данные).
- Pub-Sub: сообщения сериализуются, отправляются по сети, используются протоколы (AMQP, MQTT, Kafka), возможны разделы (partitions), ретраи, трансакции.
- Жизненный цикл и утечки:
- Observer: риск утечек памяти, если не отписаться; часто используют weak references.
- Pub-Sub: управление подписками централизовано; отписка/TTL/ретеншн регулируется брокером.
- Функции брокера:
- Pub-Sub: маршрутизация, фильтрация, балансировка, persist, replay, мониторинг, безопасность.
- Observer: такой функционал отсутствует в базовой схеме.
- Производительность:
- Observer: низкая латентность, малая накладная (внутрипроцессная).
- Pub-Sub: более высокая накладная (сеть, сериализация), но высокая пропускная способность при правильной настройке.
4) Поведение уведомлений
- Порядок доставки:
- Observer: порядок определяется реализацией (обычно последовательные вызовы).
- Pub-Sub: порядок может не гарантироваться (зависит от брокера/partitioning).
- Фильтрация/селекция:
- Observer: можно реализовать вручную в Subject.
- Pub-Sub: поддерживает topic-based, content-based фильтрацию на стороне брокера.
5) Когда использовать Observer
- Простые in-process события (GUI, привязки данных, локальные модели).
- Низкая сложность, требование низкой задержки и минимальной инфраструктуры.
- Когда издатель и подписчик находятся в одном процессе/модуле и допустима тесная связность.
- Пример: MVC View слушает Model.
6) Когда использовать Publish–Subscribe
- Распределённые системы, микросервисы, интеграция между независимыми компонентами.
- Требуются асинхронность, масштабирование, устойчивость, повторная доставка, ретеншн событий, горячее подключение/отключение подписчиков.
- Нужны сложные правила маршрутизации/фильтрации, аудит/логирование, replay (Kafka).
- Пример: телеметрия, обработка событий бизнес-процессов, интеграция сервисов.
7) Практические соображения при выборе
- Требуемая область действия: in-process → Observer; межпроцесс/распределённая → Pub-Sub.
- Требования к гарантиям доставки и устойчивости: если нужны — Pub-Sub.
- Сложность и операционная нагрузка: Pub-Sub требует инфраструктуры (broker, ops).
- Задержка vs пропускная способность: Observer — минимальная задержка; Pub-Sub — высокая пропускная способность при компромиссе по задержке.
Короткая сводка: Observer — лёгкая, in-memory, прямая связь; Pub-Sub — инфраструктурная, слабо связанная, распределённая и надёжная. Выбирайте Observer для простых локальных сценариев, Pub-Sub для масштабируемых распределённых архитектур.