Post #887

Удивительно, но я никогда не видел хороших чеклистов для микросервисов, особенно для проверки — правильно ли они выделены, всё ли продумано. Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два. Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить? Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики. Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите: 1. Идентичность и ответственность 1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс». 1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.). 1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис 2. Границы и связи с другими сервисами 2.1. Для сервиса понятен список use-case’ов, в которых он: — ведущий (владеет бизнес-логикой), — участник (вызывается другим сервисом, реагирует на событие). 2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события. 2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми". 2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех. 3. Данные и инварианты 3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук). 3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться" 3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия) 3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных) 3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие). 3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории 3.7. Приняты решения по модели чтения (CQRS, Event Sourcing) 4. Контракты, схемы и API 4.1. Составлен список внешних операций: — команды (изменяют состояние), — запросы (чтение), — доменные события (что сервис публикует). 4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API. 4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки: — ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency), — какие — технические, — как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку). 4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем 4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка 4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности 5. Надёжность, производительность, наблюдаемость 5.1. Для ключевых операций определены SLO: — латентность — доступность — процент ошибок 5.2. Поведение при отказах: понятно, что делает сервис: — при падении зависимого сервиса, — при перегрузке (ограничение, деградация, очереди), — есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок 5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам 5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке 5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования