👩🏫Объяснение:
Идемпотентность — критически важное свойство для надежных интеграций, особенно в распределенных системах, где возможны повторные отправки запросов из-за сетевых сбоев или таймаутов.
* Пример: Операция PUT /orders/{id}/status с телом {"status": "CANCELLED"} должна быть идемпотентной. Сколько бы раз клиент ни отправил этот запрос (с одним и тем же id и телом), заказ должен оказаться в состоянии CANCELLED, а не переходить в какое-либо другое состояние или вызывать ошибку после первого применения.
Это позволяет безопасно повторять запросы, не опасаясь побочных эффектов (например, списания денег дважды). HTTP-методы GET, PUT, DELETE по спецификации должны быть идемпотентными, в отличие от POST.
* Пример: Операция PUT /orders/{id}/status с телом {"status": "CANCELLED"} должна быть идемпотентной. Сколько бы раз клиент ни отправил этот запрос (с одним и тем же id и телом), заказ должен оказаться в состоянии CANCELLED, а не переходить в какое-либо другое состояние или вызывать ошибку после первого применения.
Это позволяет безопасно повторять запросы, не опасаясь побочных эффектов (например, списания денег дважды). HTTP-методы GET, PUT, DELETE по спецификации должны быть идемпотентными, в отличие от POST.
4605. Какой из перечисленных подходов НАИЛУЧШЕ описывает практику «Плавной деградации» (Graceful Degradation) в контексте интеграции с внешними сервисами?
Anonymous Quiz
69%
Продолжение работы с ограниченной функциональностью или с использованием закешированных данных
8%
Немедленная попытка непрерывного перезапуска упавшего внешнего сервиса.
10%
Полное отключение функционала системы при недоступности любого из внешних сервисов.
13%
Перенаправление всех запросов пользователей на резервный центр обработки данных.
👩🏫Объяснение:
Graceful Degradation — это дизайн-принцип, направленный на обеспечение отказоустойчивости. Система спроектирована так, чтобы при сбое одной из её зависимостей (например, внешнего API прогноза погоды или рекомендательного сервиса) основные функции (например, оформление заказа в интернет-магазине) продолжали работать, а дополнительный функционал (показать прогноз погоды для доставки) временно отключался или показывался в упрощенном виде (например, из старого кэша).
Это противоположность подходу «единая точка отказа», когда крах одной зависимости обрушивает всю систему (вариант A). Варианты C и D описывают другие аспекты отказоустойчивости и DR (Disaster Recovery).
Это противоположность подходу «единая точка отказа», когда крах одной зависимости обрушивает всю систему (вариант A). Варианты C и D описывают другие аспекты отказоустойчивости и DR (Disaster Recovery).
🤔1
4606. К какому основному недостатку приводит широкое использование прямых точечных интеграций (Point-to-Point) между множеством систем в организации?
Anonymous Quiz
1%
Высокая скорость передачи данных между каждой парой систем.
1%
Упрощение процесса документирования взаимодействий.
96%
оздание «спагетти-архитектуры», где сложность управления, тестирования и модификации связей растет.
2%
Увеличение безопасности за счет уменьшения количества промежуточных узлов.
👩🏫Объяснение:
При Point-to-Point подходе каждая система взаимодействует с другими напрямую, по своим уникальным протоколам и форматам. Для N систем потенциальное количество связей приближается к N*(N-1). Это приводит к:
* Неподдерживаемости: Изменение одной системы может потребовать изменений во многих других.
* Сложности отслеживания: Крайне трудно понять, как данные передаются по цепочке и какие системы зависят от каких.
* Отсутствию контроля: Нет единой точки для применения политик безопасности, логирования, мониторинга.
Это классическая проблема, для решения которой и были предложены паттерны вроде Интеграционной шины (ESB) или Шины событий (Event Bus).
* Неподдерживаемости: Изменение одной системы может потребовать изменений во многих других.
* Сложности отслеживания: Крайне трудно понять, как данные передаются по цепочке и какие системы зависят от каких.
* Отсутствию контроля: Нет единой точки для применения политик безопасности, логирования, мониторинга.
Это классическая проблема, для решения которой и были предложены паттерны вроде Интеграционной шины (ESB) или Шины событий (Event Bus).
4607. В чем ключевое различие в основном назначении API Gateway и Message Broker (Брокера сообщений)?
Anonymous Quiz
20%
API Gateway работает только с синхронными запросами, а Message Broker — только с асинхронными.
7%
Message Broker имеет встроенную функциональность аутентификации пользователей, а Gateway — нет.
9%
API Gateway используется исключительно для преобразования форматов данных.
65%
API Gateway предназначен для управления, маршрутизации и агрегации ,а Message Broker — для обмена.
👩🏫Объяснение:
Это различие в направлении и паттерне взаимодействия.
* API Gateway: Это «фасад» для клиентов (мобильное приложение, веб-браузер). Он принимает синхронные HTTP-запросы, занимается аутентификацией, ограничением скорости (rate limiting), кэшированием, и может агрегировать данные из нескольких внутренних сервисов в один ответ для клиента (трафик «север-юг»).
* Message Broker: Это инфраструктурный компонент для внутренней коммуникации сервисов. Сервисы публикуют и подписываются на события/сообщения асинхронно. Брокер гарантирует доставку, поддерживает очереди и обеспечивает слабую связанность (трафик «восток-запад»).
Оба инструмента могут использоваться вместе в одной архитектуре.
* API Gateway: Это «фасад» для клиентов (мобильное приложение, веб-браузер). Он принимает синхронные HTTP-запросы, занимается аутентификацией, ограничением скорости (rate limiting), кэшированием, и может агрегировать данные из нескольких внутренних сервисов в один ответ для клиента (трафик «север-юг»).
* Message Broker: Это инфраструктурный компонент для внутренней коммуникации сервисов. Сервисы публикуют и подписываются на события/сообщения асинхронно. Брокер гарантирует доставку, поддерживает очереди и обеспечивает слабую связанность (трафик «восток-запад»).
Оба инструмента могут использоваться вместе в одной архитектуре.
4608. Для чего в асинхронной интеграции через очереди сообщений используется специальная очередь «мертвых писем» (Dead Letter Queue, DLQ)?
Anonymous Quiz
1%
Для хранения самых важных, высокоприоритетных сообщений.
8%
Для временного хранения сообщений перед их отправкой основным получателям.
86%
Для приема и изоляции сообщений, они не могут быть обработаны корректно после многократных попыток.
5%
Для дублирования всех сообщений из основной очереди в целях резервного копирования.
👩🏫Объяснение:
Dead Letter Queue (DLQ) — это механизм повышения надежности. Если система-получатель не может обработать сообщение (например, из-за ошибки в данных, недоступности зависимостей, бага в коде), оно возвращается в очередь. После нескольких неудачных попыток обработки (retries) брокер сообщений автоматически перемещает такое «отравленное» сообщение в DLQ.
Цели DLQ:
1. Изоляция проблемных сообщений, чтобы они не блокировали обработку других сообщений в основной очереди.
2. Анализ причин сбоев инженерами вручную.
3. Возможность восстановления: после исправления ошибки сообщения из DLQ можно вернуть в основную очередь для повторной обработки.
Цели DLQ:
1. Изоляция проблемных сообщений, чтобы они не блокировали обработку других сообщений в основной очереди.
2. Анализ причин сбоев инженерами вручную.
3. Возможность восстановления: после исправления ошибки сообщения из DLQ можно вернуть в основную очередь для повторной обработки.
4609. Какой подход к интеграции описывает паттерн Change Data Capture (CDC)?
Anonymous Quiz
13%
Регулярный опрос базы данных на предмет изменений с помощью SQL-запросов.
6%
Прямой доступ к таблицам базы данных другой системы для чтения и записи.
78%
Определение,отслеживание и распространение изменений данных на уровне журнала транзакций базы данных
3%
Ручной экспорт данных в файл и последующая загрузка его в целевую систему по расписанию.
👩🏫Объяснение:
CDC — это мощный паттерн интеграции, позволяющий реагировать на изменения данных почти в реальном времени с минимальной нагрузкой на источник.
* Как работает: Специальный агент (например, Debezium) читает журнал транзакций БД (например, binlog в MySQL, WAL в PostgreSQL), в который СУБД записывает все изменения. Агент преобразует эти низкоуровневые изменения в события (например, «в таблице Orders добавлена запись с id=123») и публикует их в брокер сообщений (Kafka).
* Преимущества перед опросом (polling, вариант A): Нет нагрузки лишними запросами, задержка минимальна,捕获 все изменения без пропусков.
Это основа для построения event-driven архитектур и актуальных зеркал данных.
* Как работает: Специальный агент (например, Debezium) читает журнал транзакций БД (например, binlog в MySQL, WAL в PostgreSQL), в который СУБД записывает все изменения. Агент преобразует эти низкоуровневые изменения в события (например, «в таблице Orders добавлена запись с id=123») и публикует их в брокер сообщений (Kafka).
* Преимущества перед опросом (polling, вариант A): Нет нагрузки лишними запросами, задержка минимальна,捕获 все изменения без пропусков.
Это основа для построения event-driven архитектур и актуальных зеркал данных.
4610. Паттерн «Сага» (Saga) в распределенных системах используется для решения проблемы...
Anonymous Quiz
5%
... кэширования результатов запросов к нескольким сервисам.
74%
... обеспечения согласованности данных при выполнении бизнес-транзакции.
7%
... шифрования сообщений при передаче между сервисами.
15%
... балансировки нагрузки на один сервис с помощью нескольких его экземпляров.
👩🏫Объяснение:
В монолитной системе с одной БД согласованность обеспечивается ACID-транзакциями. В микросервисной архитектуре, где каждый сервис управляет своей собственной базой данных, классические распределенные транзакции (2PC) непрактичны. Паттерн «Сага» решает эту проблему, разбивая единую транзакцию на последовательность локальных транзакций в каждом сервисе.
* Как работает: Каждая локальная транзакция публикует событие, которое запускает следующую локальную транзакцию в другом сервисе. Если на каком-то шаге происходит ошибка, Сага запускает серию компенсирующих транзакций (compensating transactions) для отката изменений, сделанных на предыдущих шагах (например, не «отменить платеж», а «запустить процесс возврата средств»).
Это паттерн event-driven оркестрации или хореографии для поддержания eventual consistency в распределенных бизнес-процессах (например, «Оформление заказа» с участием сервисов Заказов, Платежей и Склада).
* Как работает: Каждая локальная транзакция публикует событие, которое запускает следующую локальную транзакцию в другом сервисе. Если на каком-то шаге происходит ошибка, Сага запускает серию компенсирующих транзакций (compensating transactions) для отката изменений, сделанных на предыдущих шагах (например, не «отменить платеж», а «запустить процесс возврата средств»).
Это паттерн event-driven оркестрации или хореографии для поддержания eventual consistency в распределенных бизнес-процессах (например, «Оформление заказа» с участием сервисов Заказов, Платежей и Склада).
4611. Что означает принцип идемпотентности при проектировании интеграционных API?
Anonymous Quiz
5%
Операцию можно выполнить только один раз за определенный период времени.
91%
Многократное выполнение операции (с одинаковыми параметрами) приводит к тому же результату.
3%
Обязательное использование уникального идентификатора для каждого запроса.
1%
Требование к немедленному ответу на каждый входящий запрос.