Что мы знаем о микросервисах

Intro

Авито: много сервисов и очень много связей между ними.

Вот основные проблемы от количества:

Проблемы с инфраструктурой: слишком много элементов:

Слои: service mesh, k8s, bare metal. Отдельно мониторинг и PaaS. Доклад будет как раз про него.

В платформе есть три основных части:

Стандартный конвейер разработки микросервиса

CLI-push

Создаём сервис из шаблона. Вместо первого git push.

Долго учили разработчиков правильно начинать работу, но это всё равно становится узким местом при внедрении микросервисов. Поэтому сделали утилиту в помощь разработчикам. Утилита делает вот что:

  1. Создаёт сервис из шаблона.
  2. Разворачивает инфраструктуру для локальной разработки
  3. Подключает БД одной командой без конфигов.

Раньше деплой сервиса был сложный и составной. Сделали проще: один файл app.toml.

Базовая валидация:

Документация

Входит:

Подготовка пайплайна

Дальше

Go + k8s + GOMAXPROCS — придётся оптимизировать производительность. Поможет библиотека automaxprocs.

Проверка

Вот что проверяем:

Тесты

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

Canary tests

Начинаем с очень малого процента — меньше 0,1%.

Держим от 5 минут до 2 часов.

Смотрим:

Squeeze testing

Тестирование через выдавливание. Нагружаем реальными пользователями один инстанс, пока он не нагрузится на 100%, «в полку». Потом добавляем +1, снова смотрим полку, вычисляем дельту. Сравниваем эти данные с данными от искусственной нагрузки.

Прод

Мониторим на продакшене.

Смотреть только на CPU — неэффективно, потому что соседи фонят. Поэтому смотрим на специфические для приложения метрики. Результаты — в Атлас.

Итого:

Что ещё

Дашборд

Смотрим на всё сверху в агрегированном виде и делаем выводы.