Паттерн Sidecar: расширение микросервисов без изменения кода

Ожидается, что в современных облачных системах микросервисы будут делать гораздо больше, чем просто выполнять бизнес-логику. Они должны вести журналирование, управлять сертификатами SSL/TLS, собирать метрики, реализовывать механизмы повторных попыток и координировать безопасную связь с другими службами.

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

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

Реальная аналогия: мотоцикл с коляской

Самый простой способ понять эту закономерность — представить себе мотоцикл с коляской.

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

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

Вместо этого вы прикрепляете коляску.

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

В архитектуре программного обеспечения:

• Мотоцикл — это ваш основной контейнер приложения (выполняющий вашу основную бизнес-логику, например оформление заказа или аутентификацию пользователя).
• ** Sidecar** — это отдельный вспомогательный контейнер (выполняющий служебные задачи, такие как завершение SSL, мониторинг или доставка журналов).
• Путешествие — это жизненный цикл развертывания (например, модуля Kubernetes).

Проблема: сквозные проблемы и раздувание кода

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

Этот библиотечный подход создал несколько серьезных проблем:

• Привязка к языку: если библиотека мониторинга написана только на Go, вы не сможете легко использовать ее в микросервисе Python или Java. Вам нужно найти или создать библиотеку для каждого языка в вашем стеке.
• Загрязнение кода. Бизнес-логика загромождается специфичным для инфраструктуры кодом для повторных попыток, обнаружения служб, шифрования и ведения журналов.
• Сложные обновления. Если в коммуникационной библиотеке обнаруживается уязвимость безопасности, каждый микросервис должен обновить свою зависимость, перекомпилировать и повторно развернуть.
• Конфликт за ресурсы. Вспомогательный код выполняется в том же процессе выполнения, что и основное приложение. Это означает, что утечка памяти в средстве регистрации может привести к сбою всего основного приложения.

Решение: шаблон коляски

Шаблон Sidecar решает эти проблемы, перемещая вспомогательные задачи из основного процесса приложения и помещая их в отдельный, независимый процесс, выполняемый непосредственно рядом с приложением.

В контейнерных средах, таких как Kubernetes, контейнер приложения и дополнительный контейнер выполняются внутри одного Pod. Потому что они используют один и тот же Pod:

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

Ключевые случаи использования шаблона Sidecar

Коляски невероятно универсальны. Некоторые из наиболее распространенных приложений включают в себя:

1. Проксирование Service Mesh (например, Envoy, Linkerd)

Вместо того, чтобы ваше приложение выполняло прямые HTTP-вызовы к другим службам, оно отправляет запросы к своему локальному дополнительному прокси-серверу. Дополнительный прокси-сервер обрабатывает маршрутизацию, повторные попытки, балансировку нагрузки, разрыв цепи и взаимное шифрование TLS (mTLS), а затем пересылает запрос. Приложение совершенно не осведомлено об этих сетевых сложностях.

2. Сбор и пересылка журналов (например, Fluent Bit)

Ваше приложение просто записывает свои операторы журнала в стандартный вывод или в локальный файл журнала. Дополнительный контейнер отслеживает этот файл, анализирует журналы и пересылает их в центральную аналитическую систему, такую ​​​​как Elasticsearch или Datadog.

3. Конфигурация и перезагрузка секрета

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

Пример реализации Kubernetes

Настроить коляску в Kubernetes очень просто. Вот простая конфигурация YAML, показывающая, как контейнер приложения записывает журналы в общий том, а дополнительный контейнер Fluent Bit читает и отправляет эти журналы:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-logging-sidecar
  labels:
    app: billing-service
spec:
  containers:
    # 1. Primary Application Container
    - name: web-app
      image: node:18-alpine
      command: ["/bin/sh", "-c"]
      args:
        - >
          while true; do
            echo "$(date) [INFO] Transaction processed successfully" >> /var/log/app/output.log;
            sleep 5;
          done
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app

    # 2. Sidecar Container (Log Shipper)
    - name: log-shipper
      image: fluent/fluent-bit:latest
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app
      # In a real setup, Fluent Bit config would read /var/log/app/output.log
      # and forward it to an external logging system.

  # Shared disk storage accessible by both containers
  volumes:
    - name: shared-logs
      emptyDir: {}

Плюсы и минусы шаблона с коляской

Как и любой шаблон проектирования, коляски имеют свои недостатки:

Заключение

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

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

Узнайте больше о разработке программного обеспечения и серверной части в блоге Ghaznix →