Выделение сервиса¶

Требования применяются к поэтапному переносу прикладной ответственности из существующего компонента в независимо развёртываемый сервис. Они регулируют владение, маршрутизацию и данные во время перехода, но не предписывают конкретный транспорт или deployment-механизм. Уровни обязательности определены в корневом README.md.

В этом документе:

исходный компонент — компонент, владеющий переносимой ответственностью до начала выделения;
целевой сервис — независимо развёртываемый сервис, выбранный владельцем ответственности после завершения;
этап выделения — ограниченный период с одним объявленным распределением владельцев, маршрутов и источников истины.

ARC-SVC-011. Решение о выделении сервиса¶

Уровень: MUST

Применяется к: началу выделения ответственности в отдельный сервис

Проект должен иметь принятый ADR, который определяет исходную и целевую границы, потребителей и независимо изменяемое свойство по ARC-SVC-001. Сравнение должно включать сохранение ответственности модулем общей release-границы и стоимость дополнительного сетевого и операционного отказа.

ADR должен задавать измеримые критерии успеха выделения, условие остановки, условие возврата к исходному маршруту и состояние, при котором перенос считается завершённым.

Обоснование¶

Поэтапный перенос без проверяемой цели может оставить постоянную двойную реализацию и увеличить связанность вместо создания независимой границы.

Проверка¶

review ADR по DEV-ADR-004–DEV-ADR-006;
сопоставление причины с независимо изменяемым свойством;
проверка численных или однозначных критериев успеха, остановки и завершения.

Исключения¶

Граница, обязательная для внешней платформы, MAY не иметь модульной альтернативы, но ADR должен определить источник ограничения и остальные перечисленные критерии.

ARC-SVC-012. Владение на каждом этапе выделения¶

Уровень: MUST

Применяется к: каждому этапу выделения сервиса

Для каждого поддерживаемого command, query, источника данных и исходящего события проект должен определить единственного действующего владельца, источник истины, правило маршрутизации и поддерживаемые версии контрактов. Эта запись должна храниться в Git и изменяться вместе с переходом на следующий этап.

Один command, query, источник данных или тип события не должен иметь неразличимых равноправных владельцев. Временный получатель копии должен быть явно обозначен как replica, shadow либо migration target и не должен публиковаться как дополнительный источник истины.

Обоснование¶

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

Проверка¶

сопоставление записи этапа с route, credentials, schemas и runtime topology;
проверка единственного владельца каждого command, query, источника и события;
тест маршрутизации каждой поддерживаемой версии контракта.

Исключения¶

Не допускаются для отсутствующего владельца или источника истины.

ARC-SVC-013. Единственный путь прикладной записи¶

Уровень: MUST

Применяется к: изменяющей операции во время выделения сервиса

Каждый логический запрос на изменение должен направляться одному действующему владельцу. Caller не должен выполнять независимые записи одного результата в исходный компонент и целевой сервис.

Если перенос требует распространить подтверждённое изменение второму участнику, механизм должен иметь стабильную идентичность операции, идемпотентное применение, сохраняемое состояние доставки и восстановление после частичного либо неопределённого результата. Переключение владельца записи должно быть версионируемым, ограниченным по времени и исключать конкурирующую запись через старый маршрут.

Обоснование¶

Неатомарная двойная запись caller создаёт расхождение, для которого ни один участник не имеет полного состояния восстановления.

Проверка¶

fault-injection между записью владельца и распространением изменения;
конкурентный тест старого и нового маршрутов во время переключения;
тест дубликата и неопределённого результата с одной идентичностью операции;
проверка отсутствия write credentials после отключения старого маршрута.

Исключения¶

Одна общая транзакция MAY атомарно изменять оба представления до фактического разделения хранилищ, если это ограничение и порядок его удаления определены в ADR.

ARC-SVC-014. Перенос и сверка данных¶

Уровень: MUST

Применяется к: копированию существующих данных в целевой сервис

Backfill должен быть идемпотентным и иметь сохраняемые checkpoint либо watermark, однозначный диапазон входных данных и определённое поведение для изменений, происходящих конкурентно с копированием. До переключения чтения или записи проект должен сверить полноту, ключи и влияющие на прикладной результат значения по заранее заданным критериям.

Shadow-чтение MAY сравнивать старый и новый путь, но не должно изменять состояние, выполнять внешний эффект или определять ответ пользователю. Различие результатов должно классифицироваться и сохраняться; допустимый порог, минимальный объём и окно сравнения должны быть определены до запуска.

Обоснование¶

Копирование без checkpoint и сверки пропускает конкурентные изменения, а shadow-путь с эффектами превращается в скрытого второго владельца.

Проверка¶

прерывание и повтор backfill с того же checkpoint;
конкурентное изменение уже обработанного и ещё не обработанного ключа;
reconciliation количества, ключей и значимых значений;
тест отсутствия записи и внешнего эффекта shadow-пути;
контролируемое превышение порога расхождений.

Исключения¶

Данные MAY не переноситься, если целевой сервис начинает с пустого состояния и контракт явно запрещает использование исторических данных; это решение должно быть зафиксировано в ADR.

ARC-SVC-015. Переключение и удаление прежнего пути¶

Уровень: MUST

Применяется к: переключению потребителей на целевой сервис и завершению выделения

План должен определять совместимые версии контрактов, порядок переключения, критерии продвижения, rollback или roll-forward для каждого этапа и минимальное окно наблюдения после последнего переключения. Удаление прежнего пути допускается только после подтверждённого отсутствия трафика, фоновой работы и поддерживаемых потребителей в течение заданного окна.

После выполнения критерия проект должен удалить прежние routes, subscriptions, write credentials и реализацию перенесённой ответственности либо оформить оставшуюся ответственность как отдельную действующую границу. Обязательные данные и audit evidence должны сохраняться по своим retention-контрактам.

Обоснование¶

Неудалённый прежний путь сохраняет скрытую возможность записи и не позволяет считать новую границу независимой.

Проверка¶

rehearsal переключения и возврата на каждом этапе;
проверка telemetry по версиям контрактов, routes и consumers;
поиск прежних credentials, subscriptions и достижимого write path после завершения;
сверка сохранённых данных и audit evidence с retention-контрактами.

Исключения¶

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