GH GambleHub

Сигналы между узлами

1) Понятие сигнала

Сигнал — минимальная единица смысловой коммуникации в сети: событие, запрос, подтверждение, статус, лимит, политика. В отличие от «сырого» пакета, сигнал имеет семантику (тип, схема, контекст, инварианты) и гарантии (доставка, порядок, идемпотентность).
Цели: снизить связанность сервисов, ускорить реакцию на изменения, сделать сеть управляемой и наблюдаемой.

2) Таксономия сигналов

Событийные (Event): факты о произошедшем (Created, Updated, Settled, Slashed).
Командные (Command): намерение выполнить действие (Mint, Pause, RotateKey).
Запрос-ответ (Query/Reply): получение состояния/агрегаций.
Состояние (State Snapshot): периодические снимки (лимиты, квоты, конфиги).
Алерты/Инциденты (Alert): отклонения, деградации, нарушения SLA.
治理/Политики (Governance/Policy): параметры тарифов, лимитов, версий.
Кросс-доменные (X-Chain/X-Domain): переноса прав/сообщений между цепями/зонами доверия.

Каждый класс фиксируется схемой (ID версии, обязательные поля, инварианты).

3) Модель сообщения

Минимальный состав:
  • `signal_id` (ULID), `causality_id` (trace/span), `ts`, `ttl`
  • `type` (namespace:version), `schema_hash`
  • `producer_id`, `domain`, `auth_proof` (подпись/VC/ZK)
  • `qos` (класс), `retries`, `attempt`
  • `payload` (CBOR/JSON/ProtoBuf), `crc`
  • `idempotency_key` (по бизнес-сущности)

4) QoS и классы доставки

Q0 Fire-and-Forget: без подтверждений (telemetry, метрики).
Q1 At-Least-Once: ретраи, дедуп на приемнике, идемпотентность.
Q2 Exactly-Once (эффективная): идемпотентная запись + дедуп + транзакционная outbox/inbox.
Q3 Ordered: сохранение порядка по ключу партиции (keyed partitioning).
Q4 Priority/Deadline: приоритеты и дедлайны (EDF/LLF) для критичных команд.

Решение: по умолчанию Q1+идемпотентность; Q3 — для потоков с причинностью; Q4 — для аварий/治理.

5) Порядок, причинность и идемпотентность

Ключи причинности: `aggregate_id`, `version`, `prev_hash`.
Outbox/InBox-паттерн: транзакционная фиксация события и отправка.
Идемпотентные хендлеры: сохранение `idempotency_key` в «seen table» + upsert.
Reconciliation: периодические сверки снапшотов и логов (repair jobs).
Лимиты ретраев/TTL: защита от «вечных» повторов и дрейфа состояния.

6) Контроль потока и backpressure

Квоты и токены: leaky/bucket, rate-limit по типам/потребителям.
Договор по частоте/размеру: batch size, window, max-in-flight.
Drop/Degrade-политики: обзорная телеметрия при перегрузке; важные Q4 не дропать.
Справедливость: WFQ/DRR-планирование по очередям.
Адаптивность: PID-контроллеры: рост задержки → уменьшить окно.

7) Транспорт и шина

Локальная шина событий: Kafka/Pulsar/NATS/Redis Streams — партиционирование по ключам.
Синхронные запросы: gRPC/HTTP2 для Query/Reply, тайм-ауты и Circuit Breakers.
Кросс-доменные каналы: IBC/CCIP-подобные слои, релейеры с залогами, доказуемые подтверждения.
Edge/POP: локальные буферы и ретрансляция в core.

8) Безопасность сигналов

Аутентификация: mTLS/OIDC для S2S; подписанные сообщения (EdDSA/secp256k1).
Авторизация: ABAC/RBAC на топики и типы сигналов; RNFT-права/лимиты.
Целостность: хеши/мерклизации батчей, неизменяемые журналы.
Конфиденциальность: поля в ZK/шифрование полей (FPE для частичных утечек).
Анти-фрод: поведенческие сигнатуры, «медовый» трафик, стохастические проверки.

9) Наблюдаемость и трассировка

Корреляция: trace-id/span-id в каждом сигнале, сквозные лейблы.
Метрики: p50/p95 latency по типам, success rate, timeout/reties %, DLQ depth, consumer lag.
Логи политики: кто, когда, что сменил (治理/лимиты), подписи и диффы конфигов.
Алертинги: SLO-бюджеты ошибок; синтетические пробы для критичных маршрутов.
DLQ/Replay: мертвые очереди, reprocess с защитой от дублей.

10) Схемы и версионирование

Schema Registry: эволюция полей (back/forward compatible), semver типов.
Feature flags: постепенная активация полей/логики.
Контракты совместимости: тесты «старая продюсер ↔ новый консюмер» и наоборот.
Миграции: dual-write/dual-read, зеркальные топики, sunset-планы.

11) Политики ретраев и дедупликации

Ретраи: экспоненциальная задержка + джиттер, максимум попыток, quarantine после порога.
Дедуп: хранение последних `N` ключей на партицию или bloom-фильтры; TTL записей.
Анти-шторм: групповые ACK/NACK, coalescing событий (debounce/aggregate).

12) SLA/SLO для сигналов

Пример целевых SLO (по классу):
  • Q4: p95 ≤ 200 мс, успешность ≥ 99.99%, DLQ = 0, MTTR инцидента ≤ 15 мин.
  • Q3: p95 ≤ 500 мс, успешность ≥ 99.9%, нарушение порядка ≤ 10⁻⁶/сообщение.
  • Q1: успешность ≥ 99.5% за окно T, p95 ≤ 1–2 с.

Error budget: перерасход → авто-скачивание скоростей, включение приоритетов, фич-флаг деградации.

13) Кросс-цепные сигналы (мультичейн)

Доказательства событий: light-client/state proofs вместо «доверия к релееру».
Финальность: учет задержек финализации домена, временные замки (challenge period).
Экономические гарантии: S-залог релееров, слэшинги за ложные подтверждения.
Идемпотентность X-Domain: глобальный `x_msg_id`, таблицы seen на обоих концах.
Политики выхода: стоп-краны, лимиты объема/времени, ручной кворум при атаках.

14) Анти-коллюзия и злоупотребления

Сигналы-подделки: strong auth + поведенческий детектор аномалий.
Реплей-атаки: nonce/TTL и однократные ключи.
Коллюзия производителей: корреляционный аудит, слепые выборки, штрафы за систематическую ошибку.
Фарминг событий: тарификация по качеству (Q-класс), rate limits по сущности.

15) Плейбук внедрения

1. Картирование доменов и типов сигналов. Определить критичность (Q-класс), владельцев, схемы.
2. Выбор транспорта и топик-архитектуры. Партиционирование по ключам причинности.
3. Определение SLO/SLA. Бюджеты ошибок, алерты, аварийные процедуры.
4. Security-by-default. Подписи, mTLS, ABAC, ключевая ротация.
5. Идемпотентность и дедуп. Outbox/InBox, seen-tables, TTL.
6. Backpressure. Квоты, окна, приоритеты, дашборды лагов.
7. Schema Registry & версионирование. Контракты совместимости, тестовые матрицы.
8. Наблюдаемость. Трассировка E2E, синтетические пробы, DLQ/Replay.
9. Пилот и game-days. Инцидентные тренировки, реплей реальных логов.
10. Масштабирование. X-domain, лимиты, стоп-краны, публичные пост-мортемы.

16) Метрики и дашборды

Производительность: latency p50/p95/p99, throughput, consumer lag, in-flight.
Надежность: success rate, retry %, DLQ depth, duplicate ratio.
Порядок: out-of-order %, reordering distance.
Экономика: стоимость обработки/сообщение, маржа по классу, штрафы/стимулы.
Безопасность: rate подозрительных сигналов, фолс-позитив/негатив.
治理: скорость раскатки схем/политик, доля успешных апгрейдов без отката.

17) Шаблоны контрактов/сервисов

Signal Gateway: валидация, аутентификация, нормализация, приоритизация.
Schema Registry: хранение/валидация схем, совместимость.
Signal Router: маршрутизация по типу/домену, QoS-классы, rate limits.
Idempotency Store: ключи, TTL, дедуп.
DLQ/Replay Service: карантин, отложенная обработка, реплей по окнам.
X-Domain Relay: доказательства, залоги, слэшинг, финальность.
Policy Hub: управление лимитами/конфигами, аудит изменений.

18) Чек-лист прод-готовности

  • Определены классы QoS и SLO для всех типов сигналов
  • Включены подписи, mTLS, ротация ключей, ABAC
  • Настроены outbox/inbox, идемпотентные хендлеры, дедуп
  • Реализованы rate limits, backpressure, приоритеты
  • Введен Schema Registry, тесты совместимости, миг-планы
  • Доступны дашборды: latency/lag/DLQ, алерты по бюджетам ошибок
  • Отработаны инциденты (game-days), реплей, пост-мортемы
  • Для X-domain включены доказательства, залоги и стоп-краны

19) Глоссарий

QoS: класс гарантий доставки/приоритета.
Idempotency: повторное выполнение без побочных эффектов.
Backpressure: механизмы, ограничивающие нагрузку при перегрузке.
DLQ: «мертвая» очередь для неуспешной обработки.
Trace/Span: идентификаторы сквозной трассировки.
X-Domain/X-Chain: кросс-доменные/кросс-цепные маршруты сигналов.

Итог: правильно спроектированные сигналы — это «нервная система» сети. Стандартизовав схемы, гарантии, безопасность и наблюдаемость, экосистема получает предсказуемую доставку, устойчивость к сбоям и управляемую эволюцию без скрытых связей и ручных костылей.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

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