4597. Какой ключевой признак отличает синхронную интеграцию от асинхронной?
Anonymous Quiz
6%
Использование разных транспортных протоколов (HTTP vs TCP)
86%
Необходимость немедленного ответа от системы-получателя для продолжения работы системы-отправителя
6%
Наличие гарантии доставки сообщения
2%
Направление потока данных (от системы A к системе B или наоборот)
👩🏫Объяснение:
Это фундаментальное различие.
* Синхронная интеграция (например, вызов REST API): Система-отправитель инициирует запрос и блокирует свое выполнение, ожидая немедленного ответа. Работа продолжится только после получения (или таймаута) этого ответа.
* Асинхронная интеграция (например, через очередь сообщений): Система-отправитель отправляет сообщение и не ждет немедленного ответа. Она продолжает свою работу. Система-получатель обработает сообщение, когда сможет, и может отправить ответ отдельным сообщением.
Остальные признаки (протоколы, гарантии доставки, направление) не являются определяющими для этого различия.
* Синхронная интеграция (например, вызов REST API): Система-отправитель инициирует запрос и блокирует свое выполнение, ожидая немедленного ответа. Работа продолжится только после получения (или таймаута) этого ответа.
* Асинхронная интеграция (например, через очередь сообщений): Система-отправитель отправляет сообщение и не ждет немедленного ответа. Она продолжает свою работу. Система-получатель обработает сообщение, когда сможет, и может отправить ответ отдельным сообщением.
Остальные признаки (протоколы, гарантии доставки, направление) не являются определяющими для этого различия.
4598. Какая основная архитектурная роль отводится Enterprise Service Bus (ESB)?
Anonymous Quiz
7%
Выполнять роль единой точки отказа для всех интеграций
2%
Полностью заменять собой базы данных в распределенных системах
9%
Обеспечивать только синхронное взаимодействие по принципу «запрос-ответ»
82%
Быть централизованным «посредником», который трансформирует и маршрутизирует сообщения
👩🏫Объяснение:
Быть централизованным «посредником», который трансформирует и маршрутизирует сообщения между разнородными системами.
📚 Объяснение: ESB — это архитектурный паттерн, представляющий собой центральный коммуникационный узел. Его ключевые функции:
* Маршрутизация: Определение, куда направить сообщение на основе его содержимого или правил.
* Трансформация: Преобразование формата данных (например, из XML в JSON) или протокола (из JMS в SOAP) для обеспечения совместимости систем.
* Оркестрация: Управление последовательностью вызовов сервисов для выполнения бизнес-процесса.
📚 Объяснение: ESB — это архитектурный паттерн, представляющий собой центральный коммуникационный узел. Его ключевые функции:
* Маршрутизация: Определение, куда направить сообщение на основе его содержимого или правил.
* Трансформация: Преобразование формата данных (например, из XML в JSON) или протокола (из JMS в SOAP) для обеспечения совместимости систем.
* Оркестрация: Управление последовательностью вызовов сервисов для выполнения бизнес-процесса.
4599. Чем протокол gRPC принципиально отличается от классического REST API при проектировании интеграции?
Anonymous Quiz
92%
gRPC использует бинарный формат Protocol Buffers и HTTP/2, а не текстовый JSON/XML поверх HTTP/1.1
2%
gRPC не поддерживает аутентификацию, в отличие от REST.
4%
gRPC может работать только в рамках синхронного взаимодействия.
1%
gRPC не поддерживает потоковую передачу данных.
👩🏫Объяснение:
gRPC использует бинарный формат Protocol Buffers (protobuf) и HTTP/2, а не текстовый JSON/XML поверх HTTP/1.1
📚 Объяснение: Это основное технологическое отличие, определяющее выбор протокола.
* REST (Representational State Transfer): Чаще использует текстовые форматы (JSON/XML) и стандарт HTTP/1.1, что человекочитаемо, но может быть менее эффективно по размеру и скорости.
* gRPC (Google Remote Procedure Call): Использует бинарный формат protobuf, который компактнее и быстрее сериализуется/десериализуется, а также транспортный протокол HTTP/2, поддерживающий мультиплексирование запросов и уменьшающий задержки.
gRPC отлично поддерживает аутентификацию, оба типа взаимодействия (синхронное и асинхронное) и, что важно, потоковую передачу данных.
📚 Объяснение: Это основное технологическое отличие, определяющее выбор протокола.
* REST (Representational State Transfer): Чаще использует текстовые форматы (JSON/XML) и стандарт HTTP/1.1, что человекочитаемо, но может быть менее эффективно по размеру и скорости.
* gRPC (Google Remote Procedure Call): Использует бинарный формат protobuf, который компактнее и быстрее сериализуется/десериализуется, а также транспортный протокол HTTP/2, поддерживающий мультиплексирование запросов и уменьшающий задержки.
gRPC отлично поддерживает аутентификацию, оба типа взаимодействия (синхронное и асинхронное) и, что важно, потоковую передачу данных.
4600. Каков основной недостаток использования паттерна интеграции «Общая база данных» (Shared Database), когда несколько систем читают и пишут в одну БД?
Anonymous Quiz
4%
Высокая производительность операций чтения.
94%
Нарушение инкапсуляции и сильная связанность систем, усложняет их независимое изменение и эволюцию.
1%
Отсутствие необходимости в создании отдельного интеграционного слоя.
0%
Упрощение процедур резервного копирования данных.
👩🏫Объяснение:
Хотя Shared Database кажется простым решением (вариант C верен как факт, но это преимущество, а не недостаток), он приводит к серьезным архитектурным проблемам:
* Связанность (Coupling): Все системы жестко зависят от одной схемы данных. Изменение таблицы или колонки может сломать несколько систем одновременно.
* Нарушение инкапсуляции: Каждая система имеет прямой доступ к внутренним данным других, что противоречит принципам модульного дизайна.
* Сложность поддержки: Трудно определить, какая система и когда изменила данные, что приводит к сложностям в отладке и обеспечении целостности.
Поэтому данный паттерн считается антипаттерном для интеграции сервисов в современных распределенных системах.
* Связанность (Coupling): Все системы жестко зависят от одной схемы данных. Изменение таблицы или колонки может сломать несколько систем одновременно.
* Нарушение инкапсуляции: Каждая система имеет прямой доступ к внутренним данным других, что противоречит принципам модульного дизайна.
* Сложность поддержки: Трудно определить, какая система и когда изменила данные, что приводит к сложностям в отладке и обеспечении целостности.
Поэтому данный паттерн считается антипаттерном для интеграции сервисов в современных распределенных системах.
4601. Для чего в первую очередь применяется паттерн «Адаптер» при реализации интеграционного решения?
Anonymous Quiz
17%
Для увеличения пропускной способности канала связи между системами.
6%
Для шифрования всех передаваемых данных между системами.
2%
Для автоматического создания документации по API.
75%
Для преобразования интерфейса одной системы в интерфейс, ожидаемый другой системой.
👩🏫Объяснение:
Паттерн Адаптер (Adapter) является одним из ключевых интеграционных паттернов. Он действует как «переходник» или «прослойка» между двумя системами, которые несовместимы на уровне своих API, форматов данных или протоколов.
* Пример: Старая система отправляет данные в фиксированном текстовом формате по FTP, а новая система ожидает JSON через REST API. Адаптер будет слушать FTP, парсить текстовый формат, преобразовывать его в JSON и вызывать REST-эндпоинт новой системы.
Его задача — обеспечить совместимость без изменения кода самих интегрируемых систем. Остальные варианты — задачи других инструментов или паттернов.
* Пример: Старая система отправляет данные в фиксированном текстовом формате по FTP, а новая система ожидает JSON через REST API. Адаптер будет слушать FTP, парсить текстовый формат, преобразовывать его в JSON и вызывать REST-эндпоинт новой системы.
Его задача — обеспечить совместимость без изменения кода самих интегрируемых систем. Остальные варианты — задачи других инструментов или паттернов.
4602. Как практики CI/CD (Continuous Integration / Continuous Delivery) в методологии DevOps помогают управлять интеграциями между сервисами?
Anonymous Quiz
5%
Обеспечивают ручное, но контролируемое развертывание изменений в продакшн.
2%
Позволяют полностью отказаться от написания интеграционных тестов.
80%
Автоматизируют сборку, тестирование и развертывание, позволяя быстро и безопасно вносить изменения.
12%
Концентрируются исключительно на автоматизации процессов разработки, не касаясь этапа тестирования.
👩🏫Объяснение:
В контексте интеграции множество сервисов должны работать вместе. Практики CI/CD критически важны для:
* Continuous Integration: Автоматическая сборка и прогон интеграционных тестов при каждом изменении кода. Это быстро выявляет поломки взаимодействия между сервисами.
* Continuous Delivery/Deployment: Автоматическое и предсказуемое развертывание протестированных изменений в различные среды (тестовые, продуктивные). Это минимизирует риски при обновлении отдельных компонентов сложной интегрированной системы.
Таким образом, CI/CD создает безопасный «конвейер» для эволюции интеграций, а не заменяет необходимость тестирования (варианты A и D неверны) и уходит от чисто ручных процессов (вариант B).
* Continuous Integration: Автоматическая сборка и прогон интеграционных тестов при каждом изменении кода. Это быстро выявляет поломки взаимодействия между сервисами.
* Continuous Delivery/Deployment: Автоматическое и предсказуемое развертывание протестированных изменений в различные среды (тестовые, продуктивные). Это минимизирует риски при обновлении отдельных компонентов сложной интегрированной системы.
Таким образом, CI/CD создает безопасный «конвейер» для эволюции интеграций, а не заменяет необходимость тестирования (варианты A и D неверны) и уходит от чисто ручных процессов (вариант B).
4603. В каком сценарии выбор SOAP для интеграции может быть более оправданным, чем REST?
Anonymous Quiz
6%
При необходимости максимальной простоты, скорости разработки и легковесного взаимодействия.
86%
При работе в экосистеме, где строго формализованные контракты, встроенные стандарты безопасности.
3%
При интеграции с современными сервисами, предоставляющими только JSON API.
5%
Когда важна возможность кэширования ответов на стороне клиента.
👩🏫Объяснение:
SOAP — это протокол с жесткой спецификацией, что в некоторых корпоративных и финансовых контекстах является преимуществом, а не недостатком.
* WSDL — машинно-читаемый контракт, по которому можно автоматически генерировать клиентский код.
* *WS-* стандарты* предоставляют готовые, стандартизированные решения для сложных требований безопасности, транзакций, надежной доставки.
REST (как архитектурный стиль) более гибкий и легковесный, лучше подходит для публичных API и веб-сервисов (вариант A). Кэширование (вариант D) — это сильная сторона REST. Вариант C описывает типичный сценарий для REST.
* WSDL — машинно-читаемый контракт, по которому можно автоматически генерировать клиентский код.
* *WS-* стандарты* предоставляют готовые, стандартизированные решения для сложных требований безопасности, транзакций, надежной доставки.
REST (как архитектурный стиль) более гибкий и легковесный, лучше подходит для публичных API и веб-сервисов (вариант A). Кэширование (вариант D) — это сильная сторона REST. Вариант C описывает типичный сценарий для REST.