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%
Требование к немедленному ответу на каждый входящий запрос.
👩🏫Объяснение:
Идемпотентность — это не просто техническое требование, а ключевой принцип проектирования надежных интеграций в распределенных системах, где сетевые сбои, таймауты и повторные отправки запросов — это норма.
Почему это так важно?
Представьте, что клиентское приложение отправляет запрос на списание денег, но не получает ответ из-за обрыва сети. Что делает разумный клиент? Он отправляет запрос повторно. Без идемпотентности это привело бы к двойному списанию — катастрофическая ошибка.
С идемпотентностью:
* Сколько бы раз ни пришел идентичный запрос (с одним и тем же payment_id и суммой), сервис платежей обработает его так, будто это первый раз, и вернет тот же результат. Деньги спишутся один раз.
Как это достигается на практике?
1. Использование уникальных ключей: Сервис сохраняет ID обработанного запроса и проверяет, не обрабатывался ли он уже.
2. Семантика HTTP-методов: Методы GET, PUT, DELETE по спецификации должны быть идемпотентными. POST — не идемпотентен (каждый вызов создает новый ресурс), поэтому для него нужно предусматривать механизмы идемпотентности отдельно.
3. Пример из жизни: Нажатие кнопки «Отправить» в лифте. Сколько бы вы ни нажимали на кнопку этажа, лифт поедет только один раз на нужный этаж.
Роль системного аналитика: При описании интеграционных API вы должны явно указывать, какие операции должны быть идемпотентными (особенно изменяющие состояние: обновление статуса, списания, отмены), и обеспечивать это требование в контракте.
Почему это так важно?
Представьте, что клиентское приложение отправляет запрос на списание денег, но не получает ответ из-за обрыва сети. Что делает разумный клиент? Он отправляет запрос повторно. Без идемпотентности это привело бы к двойному списанию — катастрофическая ошибка.
С идемпотентностью:
* Сколько бы раз ни пришел идентичный запрос (с одним и тем же payment_id и суммой), сервис платежей обработает его так, будто это первый раз, и вернет тот же результат. Деньги спишутся один раз.
Как это достигается на практике?
1. Использование уникальных ключей: Сервис сохраняет ID обработанного запроса и проверяет, не обрабатывался ли он уже.
2. Семантика HTTP-методов: Методы GET, PUT, DELETE по спецификации должны быть идемпотентными. POST — не идемпотентен (каждый вызов создает новый ресурс), поэтому для него нужно предусматривать механизмы идемпотентности отдельно.
3. Пример из жизни: Нажатие кнопки «Отправить» в лифте. Сколько бы вы ни нажимали на кнопку этажа, лифт поедет только один раз на нужный этаж.
Роль системного аналитика: При описании интеграционных API вы должны явно указывать, какие операции должны быть идемпотентными (особенно изменяющие состояние: обновление статуса, списания, отмены), и обеспечивать это требование в контракте.