Netflix TechBlog | Medium на русском
Подписаться
Построение топологии сервисов в масштабе: архитектура, проблемы и извлеченные уроки
Netflix разработала карту зависимостей сервисов в реальном времени, чтобы помочь инженерам в устранении неполадок и понимании их распределенной архитектуры. Система объединяет сетевые потоки eBPF, метрики IPC и распределенное трассирование в независимые слои графа. Хотя первоначальная версия работала локально, в производственной среде выявились значительные проблемы с масштабированием, включая отставание потребителей Kafka и проблемы с памятью.Основным архитектурным решением стал подход, ориентированный на потоковую передачу, обеспечивающий обновления топологии практически в реальном времени вместо ежечасной пакетной обработки. Это было критически важно для реагирования на инциденты и мониторинга событий в реальном времени. Для обработки миллионов записей потоков в секунду без потери данных система использует реактивные потоки с обратным давлением, сигнализируя вышестоящим компонентам замедлиться, когда нижестоящие системы перегружены. Это обеспечивает плавное снижение производительности, а не сбои или потерю данных.Архитектура использует многослойную конструкцию с физической изоляцией хранилища для сетевых, IPC и трассировочных слоев, что позволяет проводить независимую оптимизацию. Прием данных в сетевом слое основан на трехэтапном распределенном конвейере агрегации. Этап 1 выполняет первоначальную агрегацию из Kafka, Этап 2 разрешает сетевые посредники (такие как балансировщики нагрузки) в прямые зависимости на уровне приложений, а Этап 3 выполняет окончательную агрегацию, обогащение внешними данными и сохранение в графовой базе данных.Трехэтапный конвейер стал критическим развитием по сравнению с первоначальной двухэтапной конструкцией, которая страдала от "горячих узлов" из-за концентрации данных во время разрешения посредников и обогащения. Разделение этих обязанностей между тремя этапами распределяет рабочую нагрузку, предотвращая узкие места. Server-Sent Events (SSE) заменили gRPC для межэтапной связи из-за накладных расходов на производительность gRPC, которые потребляли чрезмерное количество ЦП и памяти в масштабе.