Что такое Service Mesh?

И снова здравствуйте!.. В преддверии старта курса «Архитектор ПО» мы подготовили еще один полезный перевод.

Service Mesh – это конфигурируемый инфраструктурный уровень с низкой задержкой, который нужен для обработки большого объема сетевых межпроцессных коммуникаций между программными интерфейсами приложения (API). Service Mesh обеспечивает быструю, надёжную и безопасную коммуникацию между контейнеризированными и часто эфемерными сервисами инфраструктуры приложений. Service Mesh предоставляет такие возможности, как обнаружение сервисов, балансировку нагрузки, шифрование, прозрачность, трассируемость, аутентификацию и авторизацию, а также поддержку шаблона автоматического выключения (circuit breaker).
Service Mesh обычно реализуется путем предоставления каждому экземпляру сервиса экземпляра прокси, который называется Sidecar. Sidecar обрабатывают коммуникации между сервисами, производят мониторинг и устраняют проблемы безопасности, то есть все, что может быть абстрагировано от отдельных сервисов. Таким образом, разработчики могут писать, поддерживать и обслуживать код приложения в сервисах, а системные администраторы могут работать с Service Mesh и запускать приложение.

Istio от Google, IBM и Lyft, на данный момент является самый известной Service Mesh-архитектурой. А Kubernetes, который изначально разрабатывался в Google, сейчас является единственным фреймворком для оркестрации контейнеров, который поддерживается Istio. Вендоры пытаются создать коммерческие поддерживаемые версии Istio. Интересно, что нового они смогут привнести в проект с открытым исходным кодом.

Однако Istio – это не единственный вариант, поскольку разрабатываются и другие реализации Service Mesh. Паттерн sidecar proxy является наиболее популярной реализацией, как можно судить по проектам Buoyant, HashiCorp, Solo.io и другим. Существуют и альтернативные архитектуры: технологический инструментарий Netflix – это один из подходов, где функционал Service Mesh реализуется за счет библиотек Ribbon, Hysterix, Eureka, Archaius, а также таких платформ, как Azure Service Fabric.

Service Mesh также имеет свою собственную терминологию для компонентов-сервисов и функций:

• Фреймворк оркестрации контейнеров. По мере того, как все больше и больше контейнеров добавляется в инфраструктуру приложения, появляется необходимость в отдельном инструменте для мониторинга и управления контейнерами – фреймворке оркестрации контейнеров. Kubernetes плотно занял эту нишу, причем настолько, что даже его основные конкуренты Docker Swarm и Mesosphere DC/OS предлагают в качестве альтернативы интеграцию с Kubernetes.
• Сервисы и экземпляры (поды Kubernetes). Экземпляр – это единственная запущенная копия микросервиса. Иногда один экземпляр – это один контейнер. В Kubernetes экземпляр состоит из небольшой группы независимых контейнеров, который называется подом. Клиенты редко обращаются напрямую к экземпляру или поду, чаще они обращаются к сервису, который представляет из себя набор идентичных масштабируемых и отказоустойчивых экземпляров или подов (реплик).
• Sidecar Proxy. Sidecar Proxy работает с одним экземпляром или подом. Смысл Sidecar Proxy в том, чтобы направлять или проксировать трафик, приходящий от контейнера, с которым он работает, и обратный трафик. Sidecar взаимодействует с другими Sidecar Proxy и управляется фреймворком оркестрации. Многие реализации Service Mesh используют Sidecar Proxy для перехвата и управления всем входящим и исходящим трафиком экземпляра или пода.
• Обнаружение сервисов. Когда экземпляру нужно взаимодействовать с другим сервисом, ему нужно найти (обнаружить) исправный и доступный экземпляр другого сервиса. Как правило экземпляр выполняет поиск по DNS. Фреймворк оркестрации контейнеров хранит список экземпляров, которые готовы к получению запросов, и предоставляет интерфейс для DNS-запросов.
• Балансировка нагрузки. Большинство фреймворков оркестрации контейнеров обеспечивают балансировку нагрузки на 4 уровне (транспортном). Service Mesh реализует более сложную балансировку нагрузки на 7 уровне (прикладном), богатую алгоритмами и более эффективную в вопросе управления трафиком. Параметры балансировки нагрузки могут быть изменены с помощью API, что позволяет оркестрировать сине-зеленое или канареечное развертывание.
• Шифрование. Service Mesh может зашифровывать и расшифровывать запросы и ответы, снимая это бремя с сервисов. Service Mesh также может повысить производительность за счет приоритезации или переиспользования существующих постоянных соединений, что снижает необходимость в дорогих вычислениях для создания новых соединений. Наиболее распространенной реализацией шифрования трафика является mutual TLS (mTLS), где инфраструктура открытых ключей (PKI) генерирует и распространяет сертификаты и ключи для использования их в Sidecar Proxy.
• Аутентификация и авторизация. Service Mesh может авторизовывать и аутентифицировать запросы сделанные снаружи или изнутри приложения, отправляя экземплярам только валидированные запросы.
• Поддержка шаблона автоматического выключения. Service Mesh поддерживает шаблон автоматического выключения, который изолирует нездоровые экземпляры, а затем постепенно возвращает их в пул здоровых экземпляров при необходимости.

Та часть приложения Service Mesh, которая управляет сетевым трафиком между экземплярами называется Data Plane. Создание и развертывание конфигурации, которая управляет поведением Data Plane, выполняется с помощью отдельной Control Plane. Control Plane обычно включает в себя или спроектирована таким образом, чтобы подключаться к API, CLI или GUI для управления приложением.

Control Plane в Service Mesh распределяет конфигурацию между Sidecar Proxy и Data Plane.

Часто архитектура Service Mesh применяется для решения сложных операционных задач с использованием контейнеров и микросервисов. Пионерами в области микросервисов являются такие компании как Lyft, Netflix и Twitter, которые предоставляют стабильно работающие сервисы миллионам пользователей по всему миру. (Здесь вы можете познакомиться с подробным описанием некоторых архитектурных задач, с которыми столкнулся Netflix). Для менее требовательных прикладных задач скорее всего будет достаточно более простых архитектур.

Архитектура Service Mesh вряд ли когда-нибудь станет ответом на все вопросы, связанные с работой приложений и их доставкой. Архитекторы и разработчики обладают огромным арсеналом инструментов, и только один из них — молоток, который среди множества задач должен решать лишь одну – забивать гвозди. Microservices Reference Architecture от NGINX, например, включает в себя несколько различных моделей, которые дают непрерывный спектр подходов к решению задач с помощью микросервисов.

Элементы, которые объединяются в архитектуре Service Mesh, такие как NGINX, контейнеры, Kubernetes и микросервисы в качестве архитектурного подхода, могут быть не менее продуктивно использованы и в реализациях без Service Mesh. Например, Istio был разработан как полноценная архитектура Service Mesh, но модульность говорит о том, что разработчики могут выбирать и применять только необходимые им компоненты технологий. Помня об этом, необходимо сформировать четкое понимание концепции Service Mesh, даже если вы не уверены в том, что сможете когда-нибудь полноценно ее реализовать в приложении.

Модульные монолиты и DDD

Источник: habr.com