Архитектура: про что мы забываем?
Дмитрий Масленников
Руководитель центра надежности ИС Т-Банк
Архитектура — совокупность важнейших решений об организации программной системы
Архитектура должна быть понятной
Архитектуре придется обучать
Логи
Логи используются:
- в триггерах алертов
- для ML
- в аналитике
Логи следует не только структурировать, но относится к ним, как к API
- обратная совместимость
- версионирование
- документирование
- тестирование
При тестировании логов:
- тестируем логгирование во время сбоев
- тестируем объемы порождаемых логов
Семплировать лучше совместно логи одного запроса
Метрики
RED: входящие и исходящие
USE — для всего, что может заканчиваться
- очереди
- воркеры
- подключения
Статус приложения:
- состояние выключателей
- режим работы
- статус зависимостей
Очереди
Поведение переполнения очереди надо знать и проектировать
Очереди имеют свойство накапливаться при сбоях
Необходимо:
- Ограничить размер
- Уметь сбрасывать
- Ограничивать время жизни
Очереди часто не нужны
Иногда очередь можно заменить на стек
Редко исползуемый функционал
Скорее всего он уже сломан!
- Встраиваем в работу
- Непрерывно тестируем в приложении
Сообщения об ошибках
Часто вообще не об ошибках!
Различаем:
- некорректные запросы
- получение ошибок от другого сервиса
- ожидаемые некорректное состояние сервиса
- неожиданное состояние сервиса
Фронтенд
(это не UI, а торчащий наружу бекенд)Фронтенд может:
- помогать собирать пострадавших от сбоев пользователей
- задавть глобальный таймаут
- управлять глобальным семплированием логов
Микросервисы
Минусы
- Дольше обрабатывается запрос
- Сетевой вызов ненадежен
- Надо реализовывать логику повторов
- Нужна идемпотентность
- Тратится много ресурсов на сериализацию/десериализацию
- Надо заботиться над версионированием и совместимостью версий
- Дополнительное логгирование
- Дополнительные метрики
- Нет удобных инструментов рефакторинга, как для локальных вызовов
- Сложнее отладка
- Сложнее эксплуатация (особенно устранение сбоев)
- Сложнее задокументировать и рассказать архитектуру
Плюсы
- Можно задействовать больше ресурсов на один вызов
- Позволяет сделать разное время жизни для разного функционала (неодновременные релизы)
- Изоляция критических ошибок
- Изоляция ресурсов
Плюсы должны перевешивать минусы
Репиты
Не забыть:
- Настроить таймауты
- Рандомизированый сдвиг
- Экспоненциальное затухание
- Выключатели
- Мониторинг
- Не повторять то, что уже затаймаутилось
Время запуска
Время запуска — важный параметр!
- Тестируем время запуска
- Откатываем релиз, если время запуска сильно увеличилось
Приложение должно быть способно стартовать без зависимостей!
Откат на предыдущую версию
Должен быть возможна всегда!
Миграцию данных можно сделать в приложении
Время, за которое возможен откат версии, нужно контролировать
Если нарушается — достаточная проблема, чтобы не релизиться
Модификаторы запроса
- Идентификатор запроса
- Идентификатор вызывающей системы
- Желаемый уровень логгирования для данного запроса
- Таймаут для данного запроса
Работа под нагрузкой
QPS лимит
Что будет происходить при привышении?
Тестирование работы под нагрузкой
- Тестируем под нагрузкой многократно превышающей расчетную
- Тестируем восстановление под рассчетной нагрузкой
CAP/PACELC
Для ускорения работы используйте по максимому отказ от консистентности
Клиент — часть распределенной системы