Жизненный цикл и адресация

Входящие запросы

В Rockstat построен на микросервисах (бошка не варит напишу потом) Рассмотрим пример:

SDK или какой-либо внешний инструмент/сервис отправляют .
Front service принимает все входящие запросы, проверяет их, добавляет метаданные, после чего они становятся событиями event.
К событию будет добавлена информация о способе его получения и контексте. Также каждое событие имеет ключ маршрутизации, по которому сервисы определяют нужно его обрабатывать или нет. Пример in.gen.track.page - входящий запрос общего типа generic, который финально должен быть обработан сервисом track и название события для этого сервиса page (просмотр страницы). Самого сервиса с названием track не существует, в этом нет необходимости. Но по этой метке другие смогут определить что это за событие.
Обогатитель события (которое было запросом) enricher. Front знает список сервисов (получает от Director service), которые хотят участвовать в обогащении событий с определённым ключом. Например, для ключа in.gen.track.page найдутся сервисы MaxMind ip2geo, Sypex ip2geo, UserAgent parser. Все они получат событие и на основе его содержимого сгенерируют свои дополнения. Они произведут определение географической точки на основе ip адреса, а также на основе User-Agent определят какие устройство, операционная система и браузер использовались. Результаты будут отправлены обратно в Front, где будут дописаны к данным события. /// Продолжение ниже ///

Следующим этапом происходит передача события основному обработчику (handler). Эта роль отвечает за принятие действий на основе полученного события. На основе полученных данных handler может отправить обратно в браузер сигнал или данные, может написать кому-то через чат-бота или послать письмо, или попросту передать сигнал в другой сервис. Можно даже в реальном времени использовать модели машинного обучения, например, рассчитать вероятность похождения на следующий этап воронки или попадания в CHURN.
Следом за handler, событие передается сразу всем слушателям listener. Они выполняют операции записи в базу данных, стриминга данных в другие системы, пассивного подсчета статистики и тп. К ним относятся входящие в базовый комплект сервисы ClickHouse Writer и Send Mixpanel, по названию которых легко понять, за что они отвечают. Кстати, они получают все-все входящие данные и сохраняют/отправляют их, так что нет необходимости об этом заботиться.
Начинается фаза ответа. Front учитывает параметры возвращенные handler (если вернул), и параметры входящих данных, на основе которых выбирает как именно нужно ответить: вернуть данные в JSON формате или вернуть 1x1 gif пиксель, или произвести HTTP Redirect на другой адрес. Это нужно, например, для обработки логики Cookie-Sync, где пиксель должен сделать редирект на сторонний пиксель, тот допишет свой User-ID и вернет обратно, при это нужно уже просто показать пиксель и сохранить данные сопоставления.
Изначальный инициатор запроса получил ответ, на этом цикл обработки завершается

Адресация

Все входящие запросы попадают в микросервис Front, а он передает дальше, а куда именно, он понимает на основе ключа, по которому эти данные пришли. Ключ имеет формат aa.bb.cc.dd, где:

aa: направление in/out, что означает входящие/исходящие
bb: типа запроса, сейчас почти везде используется тип generic
cc: название сервиса, обычно туда указывают название сервиса, который сгенерировал эти данные или название сервиса получателя этих данных
dd: название действия или операции, этого сервиса.

Пример: in.gen.track.page

Преобразование http путей в ключи

Для входящих данных ключ не указывается, при получении данных, его самостоятельно строит сервис Front. Делает он это на основе сегментов адреса, куда пришел запрос. Первый сегмент - это сервис, второй - это название действия. Формат такой: https://yourdomain/{service}/{name}, пример:

https://поддомен.вашдомен/appmetrika/install -> `in.gen.appmetrika.install`

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

Преобразование структур в ключи

Если данные передаются самостоятельно, удобнее передавать сервис и название действия вместе со всем остальным. В этом случае будут использованы параметры service и name. Например, запросу:

{
  "service": "track",
  "name": "page",
  "data": {},
  "projectId": 1627632140,
  "uid": "6410748886712844288",
  "user": {
    "gaId": "2039255293.1537236640",
    "ymId": "1537242940246737376",
    "ts": 1537243840171,
  //....

будет присвоен ключ in.gen.track.page