SS7 Routing Platform

200+ стран/операторов. ~1K SMS/сек × 70 операций на каждую = 70K RPS внутри системы. 99.9% uptime. 4 года в production.

70K RPS99.9% uptime4 года в production200+ операторов

Бизнес-задача

SMS-агрегатор работает с сотнями операторов по всему миру. Прямое подключение к SS7-сети дешевле, чем через SMPP-шлюзы, но требует сложной маршрутизации: выбрать оптимальный путь по цене, качеству и доступности.

Ключевая задача

SS7-протокол не позволяет отправить две SMS на один номер одновременно — вторая будет отброшена. При этом система должна держать тысячи параллельных отправок на разные номера. Решение: декомпозиция по MSISDN. Каждый номер — своя мини-очередь в Redis. Kafka распределяет нагрузку между потребителями. Один номер обрабатывается строго последовательно, разные номера — параллельно.

Архитектура

        ┌─────────────────┐
        │   API Gateway   │
        └────────┬────────┘
                 │
┌────────────────────────────────────────────────┐
│                     Kafka                        │
└──────┬──────────────────────────────────┬───────┘
       │                                  │
┌──────┴──────┐  gRPC streaming   ┌─────────────┴───────┐
│  sms-flow   │◀─────────────────▶│      smsc-api          │
│   (ядро)    │  bidirectional    │  (адаптер к оборуд.)  │
└──────┬──────┘                   └────────────────────┘
       │                                  │
┌──────┴──────┐                   ┌─────────────┴───────┐
│    Redis    │                   │   SS7 Equipment        │
└─────────────┘                   └────────────────────┘

Почему реактивный стек

SS7-операции (SRI, FWSM) занимают 2–16 секунд — это время ответа сети. Блокирующий ввод-вывод: 1000 параллельных запросов = 1000 потоков, каждый висит и ждёт. JVM не любит 10K+ потоков. WebFlux + Reactor Kafka + Reactive Redis + R2DBC. Неблокирующий ввод-вывод: поток отправляет запрос и переключается на другой. Обратное давление: если нижестоящий слой не справляется — автоматическое замедление вышестоящего. 1K SMS/сек × ~70 внутренних операций = 70K RPS. Стабильная работа без роста потоков.

Почему gRPC streaming

SS7-оборудование работает по проприетарному бинарному протоколу и требует специфичного окружения. smsc-api изолирует драйвер оборудования от бизнес-логики — можно обновлять/рестартить независимо. smsc-api отправляет запрос в SS7-сеть и ждёт ответа 2–16 секунд. HTTP запрос-ответ: либо таймаут, либо держать соединение открытым и блокировать поток. Двунаправленный стриминг. Запрос уходит, соединение живёт, ответ приходит асинхронно. sms-flow может отправить 1000 запросов и получать ответы в произвольном порядке по мере готовности.

Стратегия TTL (Redis)

Разные данные — разное время жизни. Это не «кэш ради кэша», а требования домена.

•SRI-ответ (16 сек): данные о местоположении абонента. Через минуту он может быть в другой соте
•FWSM-дедупликация (2–5 сек): защита от повторной отправки при retry
•Справочники MCC/MNC (60 сек): меняются редко, но должны обновляться без рестарта
•Ожидающие сообщения (72 часа): если абонент недоступен — ждём до 3 суток по стандарту

ClickHouse: аналитика

Аналитика доставки SMS. Миллиарды записей, мгновенный поиск по любому срезу: оператор, маршрут, время, статус.

Маршрутизация — 118 таблиц

Выбор маршрута — это комбинация факторов: страна + оператор + отправитель + время суток + текущая загрузка + история ошибок + цена. 118 таблиц — это схема для гибкой настройки менеджерами через админку. В рантайме JOIN-ов нет: конфигурация агрегируется в Redis-кэш с TTL, маршрутизация работает по данным в памяти.

•route_map: основные правила маршрутизации
•mcc_mnc: справочник стран/операторов (1500+ записей)
•blacklist/whitelist: блокировки по номерам, отправителям, GT
•ir21: данные роуминговых соглашений операторов
•job_*: журнал состояний длительных транзакций (saga log)

Технологии

Backend

Java 17Spring BootSpring WebFluxProject ReactorR2DBCReactor KafkagRPCLombok

Data

PostgreSQLClickHouseRedisApache KafkaLiquibase

Frontend

Vue 2VuexVue RouterBootstrap VueChart.jsAxios

Infra

DockerDocker ComposePrometheusGrafanaSonarQubeGitLab CI/CD

Моя роль

Архитектура с нуля, выбор стека, реализация 4 микросервисов, оптимизация под нагрузку. Принимал решения по всем техническим вопросам: от структуры БД до стратегии деплоя.

Спроектировал реактивную архитектуру для работы с долгими сетевыми операциями
Спроектировал gRPC-контракты для асинхронной работы с сетевым оборудованием
Настроил мониторинг: Prometheus + Grafana + custom dashboards

Обсудить похожий проект