Границы независимо развёртываемых сервисов¶
Требования применяются к компонентам, которые проект создаёт и поставляет как
независимо развёртываемые сервисы. Они не требуют микросервисной архитектуры и
не предписывают способ внутренней организации сервиса. Уровни обязательности
определены в корневом README.md.
В этом документе независимо развёртываемый сервис — запускаемый компонент с собственными release-артефактом, версией и deployment lifecycle, который может поставляться отдельно от других компонентов проекта.
ARC-SVC-001. Обоснованная граница сервиса¶
Уровень: MUST
Применяется к: созданию или сохранению независимо развёртываемого сервиса
Проект должен определить назначение сервиса, предоставляемый наблюдаемый результат, потребителей и причину отдельной release-границы. Причина должна называть хотя бы одно независимо изменяемое свойство: контракт, владельца, данные, масштабирование, доступ, отказ или lifecycle.
Если ни одно из этих свойств нельзя независимо определить и проверить, компонент должен оставаться модулем общей release-границы, а не отдельным сервисом.
Обоснование¶
Отдельный deployment без независимого результата увеличивает сетевое взаимодействие и операционную стоимость, не создавая управляемой границы.
Проверка¶
- сопоставление сервиса с результатом, потребителями и release-артефактом;
- проверка независимо изменяемого свойства и способа его контроля;
- review возможности реализовать ту же границу модулем общего компонента.
Исключения¶
Граница, навязанная внешней платформой или приобретаемым компонентом, MAY не иметь внутренней альтернативы, но её источник, контракт и владелец интеграции должны быть определены.
ARC-SVC-002. Владение поведением и контрактами¶
Уровень: MUST
Применяется к: каждому независимо развёртываемому сервису
Проект должен определить одну ответственную роль за поведение сервиса, публичные контракты и принятие несовместимого изменения. Репозиторий, CODEOWNERS или эквивалентное проверяемое правило должны связывать эту роль с изменениями реализации и контрактов.
Отсутствие конкретного сотрудника не должно блокировать изменение: владельцем должна быть поддерживаемая роль или команда с маршрутом замещения.
Обоснование¶
Контракт без владельца меняется независимо от последствий для потребителей и не имеет ответственного за миграцию или восстановление.
Проверка¶
- проверка owner metadata и маршрута замещения;
- контролируемое изменение контракта с проверкой требуемого approval;
- сопоставление владельца реализации и публичного контракта.
Исключения¶
Не допускаются для production-сервиса.
ARC-SVC-003. Закрытая поверхность взаимодействия¶
Уровень: MUST
Применяется к: входящему или исходящему межсервисному взаимодействию
Сервис должен иметь закрытый перечень поддерживаемых входов, выходов и зависимостей. Для каждого элемента должны быть определены владелец контракта, протокол или формат, версия либо правило совместимости и участвующие потребители.
Вызов, событие, совместно читаемое представление или фоновый вход вне этого перечня не должен использоваться как поддерживаемая интеграция.
Обоснование¶
Неучтённое взаимодействие создаёт скрытую связанность и не попадает в проверку совместимости или план миграции.
Проверка¶
- сопоставление inventory с API schemas, event schemas и runtime topology;
- поиск сетевых вызовов и credentials вне объявленного перечня;
- contract-тест каждого поддерживаемого входа и выхода.
Исключения¶
Временное диагностическое взаимодействие MAY не становиться публичным контрактом, если оно ограничено отдельными полномочиями, не изменяет бизнес-состояние и имеет срок удаления.
ARC-SVC-004. Граница изменения данных¶
Уровень: MUST
Применяется к: устойчивым данным, изменяемым независимо развёртываемым сервисом
Для каждого источника истины должен быть определён один сервис-владелец и поддерживаемый путь изменения. Другой сервис не должен изменять эти данные прямым доступом к таблице, файлу, bucket, cache keyspace или внутреннему storage API владельца.
Совместное физическое хранилище MAY использоваться, если write credentials и права разделены по владельцам, а межсервисное изменение проходит через версионируемый контракт владельца. Производное read-only представление должно иметь владельца, freshness contract и способ полного пересоздания.
Обоснование¶
Несколько независимых writers обходят инварианты владельца и связывают развёртывание сервисов внутренней схемой хранения.
Проверка¶
- сопоставление источников истины, владельцев и write paths;
- проверка storage permissions отдельными identities;
- негативный integration-тест прямой записи другого сервиса;
- тест пересоздания производного представления.
Исключения¶
Временная миграционная запись требует принятого ADR с порядком переключения, совместимостью версий, rollback или roll-forward и сроком удаления доступа.
ARC-SVC-005. Независимая поставка¶
Уровень: MUST
Применяется к: изменению независимо развёртываемого сервиса
Изменение не должно требовать одновременного deployment другого сервиса. Опубликованные API, события и форматы совместно используемых read-only представлений должны поддерживать период сосуществования версий и проверяемый порядок миграции потребителей.
Временная координация поставок должна быть определена принятым ADR с версиями участников, порядком действий, критерием завершения, восстановлением после каждого шага и сроком удаления временной связанности.
Обоснование¶
Обязательный синхронный release превращает заявленные сервисы в одну скрытую release-границу и увеличивает область отказа.
Проверка¶
- contract-тест старого и нового сочетания producer и consumer;
- deployment-тест несовпадающих версий;
- проверка ADR и удаления временной совместимости после миграции.
Исключения¶
Не допускаются без ограниченного миграционного ADR, указанного выше.
ARC-SVC-006. Контракт отказа зависимости¶
Уровень: MUST
Применяется к: каждой обязательной или необязательной межсервисной зависимости
Контракт зависимости должен классифицировать взаимодействие как синхронное или асинхронное, определить его обязательность для результата и поведение при timeout, недоступности, дубликате и неопределённом результате, когда они применимы. Должны быть определены восстановление после возобновления зависимости и наблюдаемый результат вызывающей операции.
Необязательная зависимость не должна становиться обязательной из-за неограниченного ожидания, retry или отсутствующего fallback contract.
Обоснование¶
Неявная зависимость распространяет отказ и позволяет разным точкам вызова сообщать несовместимые результаты одной операции.
Проверка¶
- fault-injection каждого применимого класса отказа;
- сверка timeout и retry с общим deadline;
- тест восстановления и обработки отложенного или повторного результата.
Исключения¶
Локальный вызов внутри общей process- и release-границы находится вне области требования.