Мессенджер как микросервисы: шина, event-service и независимые деплои
Второй курс трека: курс 1 довёл монолит до продакшена — этот учит его правильно ломать. Не «микросервисы ради микросервисов»: каждый этап переезда привязан к конкретной боли стадии 1, у каждого есть проверка и откат, а границы проведены по bounded contexts, а не по моде.
Целевая топология — четыре сервиса:
- user-service — Identity & Access: аккаунты, RS256 + JWKS, контакты;
- messenger-service — ядро домена: диалоги (direct + group в одном сервисе), сообщения, участники, outbox;
- event-service ×N — Realtime Delivery: WebSocket-соединения, fan-out, presence, насыщение кадров (enrichment);
- notification-worker — своя consumer group, правила «кого будить», Web Push.
Между ними — Redis Streams и версионированный конверт событий; на пути клиента нет ни одной распределённой транзакции.
Формат. Каждый модуль — работающий инкремент переезда: решение, контракт, код, проверки и откат. Теория границ (DDD-лайт) — только в первом модуле, дальше — инженерия. Восемь модулей, ~4–6 ч каждый; финал — защита ADR переезда.
Предусловия: курс «Мессенджер: P2P, группы и продакшен» целиком — стадия-1 монолит задеплоен, бойлерплейт развёрнут. Полезно, но не обязательно: модуль про консьюмеров Kafka — consumer group и лаг там те же, шина другая.
Boilerplate. Тот же монорепозиторий трека (boilerplate/): Go-бэкенд с
интерфейсом брокера events.Broker и outbox — именно этот шов станет первым
этапом переезда. Новый код курса — три новых сервиса и nginx-роутинг рядом с
монолитом; фронтенд не меняется вовсе, и это часть замысла: клиент не должен
заметить переезд.
Маршрут
| # | Модуль | Что делаем |
|---|---|---|
| 1 | Когда монолиту пора | боли стадии 1, bounded contexts, тест границы |
| 2 | Целевая топология | четыре сервиса, nginx, владение данными, матрица вызовов |
| 3 | user-service и JWKS | RS256, офлайн-валидация, каталог, миграция токенов |
| 4 | Конверт события | Published Language, recipients, версии, гарантии |
| 5 | event-service ×N | Streams + группа на реплику, presence, насыщение кадров |
| 6 | notification-worker | consumer group, правила пуша, идемпотентность, агрегация |
| 7 | Отказоустойчивость и нагрузка | рестарты, деградация Redis, SLO на лаги, 10k коннектов |
| 8 | Переезд по этапам | strangler: этапы 0–3, expand→contract, откат, ADR-защита |
Результат: вы умеете резать монолит по доменным границам, проектировать событийный контракт, который переживёт рост, держать realtime на N репликах — и проводить переезд так, что клиент его не замечает, а продакшен не замечает аварий.