Архитектурный надзор и анализ трейсов в Авито

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

Проблемы микросервисной архитектуры

• С 2018 года количество микросервисов в Авито увеличилось до 4000.

• Возникли проблемы с архитектурной слепотой и циклическими зависимостями.

• Синхронные запросы в цикле и длинные цепочки вызовов также создают задержки.

Определение критичности

• В Авито определили важные пользовательские сценарии и критичные сервисы.

• Возникла дилемма, как понять, какая часть функционала более приоритетна.

Сбор и анализ тресов

• Игорь рассказал о подходе к трейсингу в условиях тысяч сервисов и миллионов спаа в секунду.

• Создан сервис Архрейтер для сбора и анализа тресов.

• Использована графовая база данных Neo4j для хранения данных.

Структура базы данных

• В базе данных Neo4j хранятся методы и связи между ними.

• Это позволяет анализировать связи между методами, а не только между сервисами.

Прототип фронтенда

• Первый прототип фронтенда позволил увидеть взаимосвязи между сервисами.

• Однако, он имел проблемы с производительностью и визуалом.

Оптимизация запросов

• Из-за большого количества связей в графе, запросы были медленными.

• Использована библиотека APOC для оптимизации запросов.

• Переработан фронт для улучшения визуализации и фильтрации.

Решение проблемы с архитектурной слепотой

• Обнаружены циклические зависимости с помощью запроса в сайфер.

• Команды исправили архитектуру для устранения циклов.

 Обнаружение синхронных запросов

• Использовали алгоритм для поиска синхронных запросов.

• Обнаружено 5132 таких запроса, не все из которых требовали исправлений.

• Команды устранили синхронные запросы.

Поиск длинных цепочек

• Обнаружена максимальная глубина вложенности запросов 51.

• Команды переработали архитектуру для устранения длинных цепочек.

Грейсфл деградейшн

• Определено наличие грейсфл деградейшн между сервисами.

• Разработана методика для расчета наличия грейсфл деградейшн.

• Методика помогает определить критичность методов и сервисов.

Уровни критичности сценариев и сервисов

• Выделены уровни критичности сценариев: критичные, медиум и низкие.

• Разметка сценариев и сервисов для правильной простановки уровней критичности.

• Алгоритм для определения критичности методов и сервисов.

Выводы и дальнейшие шаги

• В больших компаниях сложно поддерживать правильную архитектуру.

• Архитектурные антипатерны — зло, за архитектурой нужно следить.

• В разработке доменная модель, автоматический поиск руткоус и автоматический поиск проблем в архитектуре.

• Внедрение автоматического выставления оценки архитектуре сервиса.