Skip to main content

Архитектура Flaree

info

Перевод в процессе / Translation in progress. See русская версия.

Flaree — четырёхслойный modular monolith на .NET: backend живёт в одном solution'е, но поделён на строгие слои с односторонними зависимостями. HTTP-приложение (Flaree.Api) и фоновый хост (Flaree.Worker) собираются отдельно: API принимает запросы дашборда и публичные ingestion-эндпоинты, а воркеры выполняют мониторинг, уведомления и боты без HTTP-поверхности. Агент живёт у клиента и отправляет телеметрию в backend через stateless-gateway.

Четыре слоя backend'а​

Направление зависимостей жёстко одностороннее: Domain ← Application ← Infrastructure ← Api. Нарушения ловятся фитнес-тестами Flaree.ArchitectureTests (NetArchTest), которые гоняются в CI как gate на каждый MR.

  • Domain — POCO-модели агрегатов (Organization, Subscription, Component, ...), плановые лимиты и pure helpers. Ни от кого не зависит, без EF Core и MediatR.
  • Application — use-cases (MediatR Command/Query + handlers), pipeline-behaviors (Logging, Validation, Transaction-маркер) и абстракции (IAppDbContext, IPaymentGateway, IIngestQuotaPolicy, IFeatureLock, ...). Ничего не знает о конкретной БД или транспорте.
  • Infrastructure — EF Core (AppDbContext), Hangfire-джобы, Redis, MailKit, ASP.NET Identity, Telegram-боты, мониторинговые воркеры и реализации Application-абстракций.
  • Api — контроллеры, middleware и composition root (Flaree.Api/Program.cs, ~270 строк), который делает только AddApplication() + AddInfrastructure(configuration).

Flaree.Worker и типы воркеров​

Flaree.Worker — отдельный host без HTTP-эндпоинтов. Один бинарь, выбирающий набор BackgroundService-ов по переменной WORKER_TYPE: worker-monitor-http, worker-monitor-tcp, worker-monitor-heartbeat, worker-notif, worker-bots. В продакшне API никогда не тянет воркеры встроенно — это разные реплики за Caddy.

Рекурсивные задачи (RecurringJob.AddOrUpdate из Hangfire — биллинг, retention, дайджесты) регистрируются только в Flaree.Worker/Program.cs. Hangfire-дашборд в API работает в режиме read-only.

Observability-модули​

Четыре артефакта закрывают пайплайн телеметрии:

  • Modules.Logs — владеет LogSource и LogRule, запросы к ClickHouse и событийная оценка правил логов.
  • Modules.Metrics — владеет ComponentMetricBinding и MetricRule, материализованные views и оценка правил метрик (см. Правила).
  • Flaree.Ingestion — stateless gateway: авторизация агентского токена, проверка квот, push в Redis Streams. Без доменной логики.
  • agent/.../Otlp/Receiver — loopback OTLP/HTTP receiver на стороне агента (подробнее — OTLP).

Поток данных​