Sidecar паттерн

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

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

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

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

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

Решение

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

Sidecar сервис необязательно входит в приложение, хотя и подключен к нему. Он всегда работает с родительским приложением. Sidecar'ы поддерживают процессы или службы, развернутые с помощью основного приложения. Если говорить про аналогию, возьмем пример с мотоциклом, к мотоциклу можно присоединить лишь одну коляску, и у каждого мотоцикла отдельная коляска. Таким же образом sidecar работает с родительским приложением, как коляска к мотоциклу. Для каждого экземпляра приложения размещен и развернут каждый экземпляр sidecar'a.

Преимущества использования sidecar:

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

Паттерн Sidecar часто используется с контейнерами и называется "sidecar container" или "sidekick container".

Проблемы и вопросы при реализации

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

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

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

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

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

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

Источник: https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar