4596. На диаграмме развертывания, как изображается отношение "развертывания", когда артефакт (например, .war файл) размещается на узле (сервере)?
Anonymous Quiz
8%
Линией ассоциации
39%
Стереотипом «deploy» на зависимости
25%
Иконкой артефакта внутри узла
28%
Все перечисленные варианты возможны
👩🏫Объяснение:
Отношение развертывания (manifestation) в UML 2 может быть показано несколькими способами: 1) Поместить иконку артефакта внутрь иконки узла — наиболее наглядный способ. 2) Нарисовать линию зависимости (пунктирная стрелка) от узла к артефакту со стереотипом «deploy». 3) Связать артефакт с узлом через ассоциацию. Выбор зависит от сложности диаграммы и предпочтений проектировщика.
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).