Интеграционная архитектура
Все объяснения, задачи и лабораторная в одном месте.
Можно сохранить страницу в PDF через печать браузера. Для печати разборы ответов раскрываются автоматически.
1. System boundaries и canonical models
Объяснение
Граница системы определяет её модель и ответственность. Canonical model уменьшает число преобразований, но чрезмерно общая схема становится связующим монолитом. Контракт должен иметь владельца.
Задача для самостоятельного решения
Нужно ли всем системам одинаковое поле status?
Показать разбор ответа
Только при одинаковом смысле. Иначе нужны явные mapping и состояния, не скрывающие различия процессов.
2. Synchronous API и asynchronous events
Объяснение
Синхронный API связывает доступность сторон во времени. Событие сообщает о факте и позволяет отложенную обработку. Команда просит действие и отличается от уже произошедшего события.
Задача для самостоятельного решения
Чем OrderCreated отличается от CreateOrder?
Показать разбор ответа
Первое утверждает факт, второе может быть отклонено. Потребитель события не должен повторно решать, был ли заказ создан.
3. Queues, streams и delivery semantics
Объяснение
Queue распределяет задачи, stream хранит последовательность для повторного чтения по правилам платформы. ACK и commit offset влияют на повторы. Ordering часто гарантируется только внутри partition.
Задача для самостоятельного решения
Что случится при сбое до commit offset?
Показать разбор ответа
Сообщение может быть прочитано повторно. Обработчик должен дедуплицировать бизнес-эффект или быть идемпотентным.
4. Schema evolution и contract testing
Объяснение
Schema evolution определяет совместимость старых и новых участников. Добавление optional поля обычно проще удаления обязательного. Contract test проверяет реальные ожидания потребителя.
Задача для самостоятельного решения
Почему переименование поля может сломать незнакомый сервис?
Показать разбор ответа
Он зависит от опубликованного контракта. Нужны версия, переходный период и учёт потребителей.
5. Idempotency, retries и reconciliation
Объяснение
Retry требует backoff, ограничения попыток и классификации ошибки. Идемпотентность предотвращает дублирование. Reconciliation сравнивает системы и исправляет потерянные или расходящиеся состояния.
Задача для самостоятельного решения
Нужно ли бесконечно повторять запрос с неверной схемой?
Показать разбор ответа
Нет: это постоянная ошибка до исправления данных. Отправьте в обработку отказов с диагностикой; повторы только расходуют ресурсы.
6. Observability, governance и lifecycle
Объяснение
Correlation id связывает события одного процесса. Governance управляет владельцами, схемами и сроком поддержки. Replay полезен для восстановления, но может повторить внешние эффекты.
Задача для самостоятельного решения
Как безопасно повторно обработать старые события?
Показать разбор ответа
Разделить пересчёт состояния и внешние действия, сохранить дедупликацию и проверить версию обработчика на ограниченном наборе.
Лабораторная работа
Подготовка
Python 3, модель потребителя с дедупликацией.
Учебный пример
processed=set()
state={}
def consume(event):
if event['id'] in processed: return
state[event['order']]=event['status']
processed.add(event['id'])
event={'id':'e1','order':'o1','status':'paid'}
consume(event); consume(event)
print(state,len(processed))Как работает пример и что ожидать
Вывод показывает один заказ paid и один обработанный id. В памяти нет долговременной атомарности: production требует транзакции между изменением и записью processed. Порядок событий тоже важен — более старый статус не должен молча затереть новый.
Итоговая работа
Реализуйте outbox/inbox на учебной БД, schema version, retry и dead-letter обработку. Проверьте crash между этапами, повтор и reorder. Добавьте reconciliation, находящий расхождения после восстановления.
Проверка результата
1. Опишите исходные данные и условия запуска, чтобы другой человек мог повторить работу.
2. Приложите результат обычного сценария и сравните его с ожидаемым.
3. Проверьте неверный вход, граничный случай и отказ зависимости, если она есть.
4. Объясните выбранное решение и известное ограничение.
5. Сохраните исправления после самопроверки вместе с примером, который раньше не работал.
Как оценить работу
По каждому пункту поставьте 0 (не выполнено), 1 (выполнено с пробелами) или 2 (результат воспроизводим и объяснён). Если обязательный сценарий не работает, вернитесь к нему независимо от общей суммы. Это рубрика самопроверки: сайт не исполняет присланный код и не выдаёт автоматическую оценку проекта.