Шаблон бокового компонента

Разверните компоненты приложения в процессе или контейнере, отдельно от основного приложения, чтобы обеспечить изоляцию и инкапсуляцию. Этот шаблон позволяет создавать приложения из различных компонентов и технологий.

Как и мотоциклетная коляска, эти компоненты присоединяются к родительскому приложению и разделяют его жизненный цикл, поэтому вы создаете и удаляете их вместе. Этот шаблон также называется шаблоном Sidekick и поддерживает декомпозицию приложения.

Контекст и проблема

Приложения и службы часто требуют связанных функций, таких как мониторинг, ведение журнала, конфигурация и сетевые службы. Эти периферийные задачи можно реализовать как отдельные компоненты или службы.

Тесно интегрированные компоненты выполняются в одном процессе и эффективно используют общие ресурсы, но они не имеют изоляции. Сбой в одном компоненте может повлиять на все приложение. Они также требуют реализации на языке родительского приложения, что создает взаимозависимость.

Если вы разложите приложение на службы, вы можете создать каждую службу с помощью разных языков и технологий. Такой подход обеспечивает большую гибкость. Но каждый компонент имеет собственные зависимости и требует, чтобы библиотеки, относящиеся к языку, должны получать доступ к платформе и общим ресурсам. При развертывании этих функций в качестве отдельных служб вы добавляете задержку. Код и зависимости, относящиеся к языку, также повышают сложность размещения и развертывания.

Решение

Разверните единый набор задач вместе с основным приложением в отдельном процессе или контейнере. Этот подход обеспечивает согласованный интерфейс для служб платформы на разных языках.

Схема, показывающая шаблон Sidecar.

Побочный сервис подключается к приложению, не будучи его частью, и разворачивается вместе с ним. Каждый экземпляр приложения получает собственный экземпляр сайдкара, который разделяет его жизненный цикл.

Шаблон Sidecar предоставляет следующие преимущества:

  • Независимость языка: Сайдкар работает независимо от среды выполнения основного приложения и выбранного языка программирования. Вы можете использовать одну реализацию сайдкар в разных приложениях, написанных на разных языках.

  • Доступ к общему ресурсу: Боковая машина может получить доступ к тем же ресурсам, что и основное приложение. Например, сайдкар может отслеживать системные ресурсы, которые используют оба компонента.

  • Низкая задержка: Близость бокового автомобиля к основному приложению сводит к минимуму задержку связи.

  • Расширенная расширяемость: Вы можете расширить приложения, которые не имеют собственных механизмов расширяемости, подключив сайдкар в качестве отдельного процесса на одном узле или в подконтейнере.

Наиболее распространенной реализацией этого шаблона является использование контейнеров, которые также называются sidecar контейнерами или sidekick контейнерами.

Проблемы и рекомендации

При реализации этого шаблона следует учитывать следующие моменты:

  • Рассмотрите формат развертывания и упаковки для развертывания служб, процессов или контейнеров. Контейнеры хорошо подходят для шаблона Sidecar.

  • При разработке сайдкар-сервиса тщательно выберите механизм межпроцессного взаимодействия. Используйте технологии, не зависящие от языка или платформы, если требования к производительности не делают этот подход нецелесообразным.

  • Прежде чем добавлять функционал в сайдкар, оцените, работает ли он лучше как отдельная служба или традиционный демон.

  • Рассмотрите возможность реализации функциональных возможностей в виде библиотеки или с помощью традиционного механизма расширения. Библиотеки, относящиеся к языку, обеспечивают более глубокую интеграцию и меньше сетевых затрат.

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

  • Основное приложение использует различные языки и платформы. Сайдкары предоставляют согласованный интерфейс, который различные приложения могут использовать независимо от языка или фреймворка.

  • Отдельная команда или внешний партнер владеет компонентом.

  • Необходимо развернуть компонент или функцию на том же узле, что и приложение.

  • Вам нужна служба, которая делится общим жизненным циклом основного приложения, но она может обновляться независимо.

  • Вам нужен подробный контроль над ограничениями ресурсов для определенного ресурса или компонента. Например, можно развернуть компонент как сайдкар, чтобы независимо от основного приложения ограничивать и управлять использованием его памяти.

Этот шаблон может быть не подходит, если:

  • Необходимо оптимизировать взаимодействие между процессами. Сайдкары добавляют нагрузку, особенно задержки в связи, что делает их неэффективными для приложений с частым обменом данными между компонентами.

  • Ваше приложение небольшое. Затраты на ресурсы при развертывании бокового автомобиля для каждого экземпляра могут перевесить преимущества изоляции.

  • Необходимо иметь возможность независимо масштабировать компонент. Если необходимо масштабировать компонент по-разному от основного приложения, разверните его как отдельную службу.

  • Платформа предоставляет эквивалентные функциональные возможности. Если платформа приложений уже предоставляет необходимые возможности встроенным образом, сайдкары добавляют излишнюю сложность.

Проектирование рабочей нагрузки

Узнайте, как использовать шаблон sidecar в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Azure Well-Architected Framework. В следующей таблице приведены рекомендации по использованию этого шаблона для целей каждого компонента.

Столп Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки. Когда вы инкапсулируете эти задачи и развертываете их в отдельных процессах, вы сокращаете область атаки только на необходимый код. Вы также можете использовать сайдкары для добавления сквозных механизмов управления безопасностью в компоненты приложений, которые не поддерживают эти функции.

- SE:04 Сегментация
- Шифрование SE:07
Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды. Этот шаблон позволяет гибко интегрировать средства наблюдения без добавления зависимостей в код приложения. Вы можете обновлять и поддерживать сателлитное приложение независимо от основного приложения.

- Инструменты и процессы OE:04
- Система мониторинга OE:07
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода. Этот шаблон позволяет централизованно выполнять сквозные задачи на сайдкарах, масштабируемых на несколько экземпляров приложений. Вам не нужно развертывать повторяющиеся функции для каждого экземпляра приложения.

- PE:07 Код и инфраструктура

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Пример

Можно применять шаблон внешнего контурирования Sidecar во многих сценариях. Рассмотрим следующие примеры:

  • Абстракция зависимостей: Разверните пользовательскую службу вместе с каждым приложением, чтобы предоставить доступ к общим возможностям зависимостей через согласованный API. Этот подход заменяет клиентские библиотеки, специфические для языка, на сайдкар, который обрабатывает такие задачи, как логирование, конфигурация, обнаружение сервисов, управление состоянием и проверки здоровья.

    Примером этого варианта использования является сайдкар Distributed Application Runtime (Dapr).

  • Плоскость данных mesh-службы: Разверните боковой прокси-сервер вместе с каждым экземпляром службы, чтобы обрабатывать перекрестные сетевые проблемы, такие как маршрутизация трафика, повторные попытки, взаимная защита TLS, применение политик и телеметрия.

    Сетевые службы, такие как Istio, используют сайдкар-прокси для реализации этих возможностей без необходимости изменений в коде приложения.

  • Боковая машина посла: Разверните службу послов в качестве бокового автомобиля. Приложение направляет вызов через посредника, который обрабатывает журналирование запросов, маршрутизацию, предотвращение перегрузок и другие функции подключения.

  • Адаптеры протокола: Разверните побочный контейнер для перевода между несовместимыми протоколами или форматами данных или для соединения систем обмена сообщениями. Такой подход позволяет приложению использовать более простые или устаревшие интерфейсы.

  • Обогащение телеметрии: Разверните сайдкар для предварительной обработки или обогащения данных телеметрии, таких как метрики, журналы и трассировки, перед тем как передавать данные во внешние системы мониторинга. Такие компоненты, как сборщик OpenTelemetry могут выполняться в качестве сайдкаров для нормализации, обогащения или маршрутизации телеметрии отдельно от приложения.

Дальнейшие шаги

  • Last updated on