Sidecar pattern (Шаблон расширения)

Azure

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

Он называется расширением, так как напоминает коляску, присоединенную к мотоциклу. В шаблоне расширение присоединяется к родительскому приложению и предоставляет для него вспомогательные функции. Жизненный цикл расширения и родительского приложения один и тот же, так как расширение создается и удаляется вместе с родительским приложением. Иногда шаблон расширения называют шаблоном-компаньоном, который является шаблоном декомпозиции.

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

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

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

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

Решение

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

Шаблон расширения

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

Преимущества шаблона расширения:

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

  • Расширение может получить доступ к тем же ресурсам, что и основное приложение. Например, оно может наблюдать за системными ресурсами, используемыми основным приложением и им самим.

  • Из-за его близости к основному приложению при взаимодействии между ними нет значительной задержки.

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

Шаблон расширения часто используется с контейнерами и называется контейнером-расширением или контейнером-компаньоном.

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

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

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

Используйте этот шаблон в следующих случаях:

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

Эту схему не стоит применять в следующих случаях:

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

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

Архитектор должен оценить, как шаблон Сайдкара можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

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

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

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

- Pe:07 Code и инфраструктура

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

Пример

Шаблон расширения применяется во многих сценариях. Несколько распространенных примеров:

  • API инфраструктуры. Команда разработчиков инфраструктуры создает службу, развертываемую вместе с каждым приложением, а не языковую клиентскую библиотеку для доступа к инфраструктуре. Служба загружается как расширение и предоставляет общий уровень для служб инфраструктуры, включая ведение журнала, данные среды, хранилище конфигураций, обнаружение, проверку работоспособности и контрольные службы. Расширение также отслеживает среду размещения и процесс родительского приложения (или контейнера) и записывает сведения в централизованную службу.
  • Управление NGINX и HAProxy. Разверните NGINX с помощью службы-расширения, которая отслеживает состояние среды, а затем обновляет файл конфигурации NGINX и перезапускает процесс, если требуются изменения в состоянии.
  • Расширение-посредник. Разверните службу-посредник в качестве расширения. Приложение вызывает посредник, который обрабатывает журнал запросов, маршрутизацию, автоматическое выключение и другие функции, связанные с подключением.
  • Разгрузка прокси-сервера. Разместите прокси-сервер NGINX перед экземпляром службы node.js для обработки содержимого статических файлов для службы.