Service Mesh объяснен: как open-source mesh упрощают коммуникацию микросервисов

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

Один из способов управления и мониторинга коммуникации между сервисами — использование service mesh.

Что такое Service Mesh?

Service mesh — это выделенный инфраструктурный слой, добавляемый к микросервисной архитектуре. Его главная роль — обеспечить быструю и безопасную сервис-то-сервис коммуникацию. Этот low-latency инструмент управляет и мониторит межсервисную коммуникацию и обмен данными.

Он состоит из control plane, из которого разработчики реализуют специфические правила и политики к сетевому слою. Control plane работает напрямую с data plane — коллекцией sidecar прокси, запускаемых рядом с сервисами. Эти прокси отвечают за всю коммуникацию между сервисами. Дополнительно они мониторят и предоставляют ценный инсайт в общую производительность приложения и помогают находить потенциальные проблемы и избегать простоя.

Прокси предоставляют ценные возможности, включая:

• Динамическое обнаружение сервисов
• Балансировку нагрузки
• Проверки здоровья
• Шифрование
• Наблюдаемость
• Circuit breakers
• Поэтапные развертывания с процентным разделением трафика
• Аутентификацию
• Богатые метрики
• Авторизацию

Подъем Service Mesh архитектуры

Чтобы полностью понять, как работает service mesh, нужно посмотреть на то, почему был разработан такой инструмент. Подъем service mesh архитектуры возник как решение ряда проблем, связанных с микросервисами.

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

Сложность с разработкой такого приложения — настройка лучшего способа для этих сервисов общаться друг с другом. Производительность приложения зависит от сервисов, работающих вместе и делящихся данными для обеспечения лучшего пользовательского опыта. Например, веб-магазин может состоять из login service, общающегося с buy service, требующим информации от inventory database и так далее.

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

До mesh сервисной архитектуры эту задачу обрабатывали load balancers. Однако это не было практичным решением, особенно в большом масштабе, из-за проблем с развертыванием и стоимостью. Service mesh был разработан как окончательное решение для всех вышеупомянутых проблем. Он представил сетевой слой с централизованным реестром (control plane), управляющим всеми сервисами через свои sidecar прокси. Они намного легче настраивать и масштабировать по сравнению с load balancers. Разработчики могут масштабировать прокси вверх и вниз по необходимости и менять правила маршрутизации без модификации сервисов.

Преимущества Service Mesh

Наиболее значительные преимущества service mesh:

• Улучшенная безопасность — внедрение service mesh в микросервисную архитектуру улучшает общую безопасность. Этот сетевой слой вводит автоматическую авторизацию, аутентификацию, шифрование и принуждение политик. Он использует mutual Transport Layer Security (mTLS) для обеспечения безопасности всей сервис-то-сервис коммуникации. Сервисы идентифицируют себя своими TLS сертификатами для установления соединения. После валидации идентичности они устанавливают зашифрованный канал для обмена данными.
• Контроль трафика и видимость — одна из первичных функций service mesh — предоставление контроля трафика. Он управляет восток-запад трафиком, а также трафиком между сервисами. Вся коммуникация идет через sidecar прокси, администрируемые control plane. Трафик прозрачно маршрутизируется, давая разработчикам лучшую видимость всего обмена данными. С более четким инсайтом в производительность приложения, легче заметить потенциальные проблемы внутри системы.
• Наблюдаемость — поскольку платформа управляет всем трафиком, она собирает ценный инсайт в поведении трафика и взаимодействии пользователей. С такими большими объемами данных бизнес-аналитики могут планировать стратегию для улучшения приложения.
• Разработчики фокусируются на разработке приложений вместо нетворкинга — вместо того чтобы команда разработки настраивала и управляла всем сетевым слоем, они могут внедрить service mesh в архитектуру. Пока платформа требует первоначальной конфигурации, она автоматизирует трудоемкие задачи, связанные с управлением сетью. Это позволяет разработчикам фокусироваться на микросервисах. Оставляя service mesh управлять сервис-то-сервис взаимодействиями, экономится время и деньги, а также улучшается продуктивность.
• Устойчивость — service mesh предоставляет функции, помогающие создавать устойчивые микросервисные приложения. Одна такая функция — паттерн circuit breaker, помогающий обнаруживать сбои и скачки задержки. Дополнительно service mesh использует балансировку нагрузки для обнаружения сервисов и маршрутизации трафика через микросервисную сеть. Другие функции, добавляющие к устойчивости, включают retries, timeouts и deadlines.
• Более быстрые циклы тестирования и развертывания — использование sidecar прокси для pod-to-pod коммуникации намного проще и быстрее для настройки. Вместо кодирования избыточных функций в каждый сервис, они развертывают прокси и соединяют их с сервисом. Это ускоряет общий цикл разработки и тестирования.

Список Open Source Service Meshes

Существует ряд open source service meshes. Istio, Linkerd и Consul — наиболее широко используемые.

Ниже вы найдете больше деталей о каждой платформе.

Istio

Istio — open source инфраструктура, спроектированная Google, IBM и Lyft. Это одна из самых ранних service mesh платформ. Она использует Istiod, control plane, состоящий из множественных компонентов (Pilot, Citadel и Mixer) для операций и конфигурации service mesh. Data plane состоит из Envoy прокси, разработанных на C++. HTTP/TCP соединения управляются Gateway, балансировщиком нагрузки Istio. VirtualService и DestinationRules определяют правила маршрутизации и политики.

Linkerd

Linkerd — легковесный open source service mesh, разработанный проектом Cloud Native Computing Foundation (CNCF). Он прост в установке в Kubernetes кластере поверх любой платформы, без дополнительной конфигурации. Отсутствие конфигурации полезно при работе с меньшими кластерами. Однако крупномасштабные проекты требуют возможности конфигурации для успешного управления всеми сервисами в кластере.

Его sidecar прокси написаны на Rust. Linkerd использует Controller для control plane и Web Deployment для дашборда. Дополнительно использует Prometheus для исследования и хранения метрик и Grafana для рендеринга и отображения дашбордов.

Consul Connect

Consul был сначала спроектирован как инструмент service discovery и позже эволюционировал в service mesh. В отличие от Linkerd, Consul Connect включает много конфигурации, давая больше контроля над сетевой средой. Соответственно, он сложнее в использовании, чем Linkerd. Этот open source service mesh платформ-агностик, означает, что не требует Kubernetes или Nomad. Тем не менее, Nomad упрощает процесс управления микросервисной коммуникацией через Consul.

Microsoft's Open Service Mesh

Open Service Mesh (OSM) — CNCF Envoy проект, реализующий service mesh интерфейс для управления и защиты динамических микросервисных приложений. Использует Envoy xDS как sidecar контейнеры. Главные функции включают traffic shifting, управление сертификатами, включение mTLS, автоматическую инъекцию sidecar и политики контроля доступа.

Kuma

Kuma — open source control plane для Kubernetes и VMs, запускаемых внутри service mesh. Имеет L4+L7 policy архитектуру, реализующую функции: service discovery, routing, zero-trust безопасность и наблюдаемость. Платформа высокомасштабируема и легка в настройке.

OpenShift Service Mesh Red Hat

Red Hat разработал свой OpenShift Service Mesh для управления микросервисными приложениями. Обеспечивает множественные интерфейсы для нетворкинга и повышенную безопасность с Security Context Constraint. Измеряет производительность с Jaeger и наблюдает взаимодействия между сервисами с Kiali. Дополнительно OpenShift включает Red Hat 3scale Istio Mixer Adapter для лучшей API безопасности.

AWS App Mesh

Amazon разработал App Mesh, бесплатный service mesh софт, управляющий всеми вашими сервисами внутри микросервисной архитектуры. Обеспечивает high-availability и end-to-end видимость для вашего микросервисного приложения. AWS App Mesh интегрируется с AWS Fargate, Amazon ECS, Amazon EC2, Amazon EKS, Kubernetes и AWS Outposts. С его инструментами мониторинга автоматически экспортирует мониторинговые данные.

Network Service Mesh

Network Service Mesh — open source CNCF Sandbox проект. Это hybrid/multi-cloud IP service mesh, использующий простой набор API для облегчения коннективности. Устанавливает соединение между сервисами, запущенными внутри контейнеров, и с внешними эндпоинтами. Когда реализован, требует минимальных изменений к Kubernetes.

Заключение

Service mesh упрощает управление и поддержку приложения, разработанного с использованием микросервисной архитектуры. Он улучшает общую безопасность внутри микросервисной архитектуры и обеспечивает видимость и наблюдаемость потока трафика. В целом, функции service mesh улучшают производительность и ускоряют цикл разработки. С широким разнообразием open source решений, найдите тот, который лучше всего подходит потребностям ваших приложений.