Сервисная сетка (Service mesh) представляет собой новый класс менеджера сервисов для распределенных вычислений, который может работать рука об руку с оркестраторами типа Kubernetes, пишет портал ZDNet. Ее можно мыслить как сетевой оверлей уровня 7, предназначенный исключительно для приложений. Не исключено, что появление сервисных сеток может привести к новому витку дебатов о сетевой архитектуре.

Сервисная сетка — это новая архитектура для динамического связывания между собой различных кусков серверных приложений (в особенности микросервисов), из которых коллективно формируется одно приложение. Это могут быть и компоненты, изначально мыслившиеся частями одного приложения, и компоненты от разных источников, задействованные для одновременных операций с общей рабочей нагрузкой.

Сервисные сетки уже доступны для использования

Возможно, самым старым примером инициативы, в которой выявилась принципиальная необходимость в сервисной сетке, стал Open Source-проект Linkerd (произносится «линкер-ди»), который ныне поддерживает организация Cloud-Native Computing Foundation. Зародившийся как ответвление от проекта Twitter, Linkerd популяризовал идею прокси, создаваемых для каждого сервиса и способных взаимодействовать друг с другом через специально выстроенную сеть. Коммерческий куратор Linkerd компания Buoyant недавно присовокупила к исходному проекту родственную инициативу под названием Conduit, в результате чего появился проект Linkerd 2.0.

Тем временем инженер Мэтт Клайн, работающий в компании Lyft (сервис для заказа поездок на попутных автомобилях), придумал метод построения сети, осуществляющей репрезентацию существующего кода (даже привязанного к унаследованному «монолиту») в форме микросервисов с API. Благодаря этому появился на свет прокси Envoy, ставший сегодня одним из компонентов проекта по созданию фреймворка под названием Istio. Следует отметить, что в разработке Istio участвуют IBM и Google.

Исторический прецедент

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

Ее аналогом в клиент-серверном мире и в мире веб-приложений является знакомая многим вещь, а именно middleware (промежуточное ПО). С начала нынешнего столетия компоненты веб-приложений обрабатываются асинхронно (не в такт друг с другом), и поэтому им часто требуется определенный метод коммуникации между процессами, хотя бы для их координации. Одним из типов middleware стала сервисная шина предприятия (ESB), позволяющая в теневом режиме осуществлять эти коммуникации, что впервые дало возможность взаимно интегрировать многие классы серверных приложений.

Микросервисное приложение структурно очень отличается от классической модели сервер-клиент. Хотя его компоненты в своих граничных точках используют API, одной из отличительных черт его поведения является способность сервисов при необходимости тиражировать себя в пределах системы, т. е. масштабироваться. Поскольку структура приложения при этом то и дело меняется, средствам оркестровки типа Kubernetes становится затруднительно определять местоположение каждого сервиса. Они могут оркестровать сложное контейнеризованное приложение, но при линейном росте масштаба объемы нагрузки на них растут экспоненциально.

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

Непонятное становится жизненно необходимым

Большинство современных приложений, и исключений тому становится все меньше, функционируют в дата-центре или на облачной платформе и общаются с администраторами и пользователями через Интернет. Не одно десятилетие определенная часть серверной логики (часто в немалых объемах) обслуживается повторно используемым кодом через компоненты, которые называются библиотеками. Пионерскую роль в практике прилинковки общих библиотек сыграл язык программирования Си, а несколько позже в ОС, например, в Windows, появились динамически подключаемые библиотеки (DLL), подсоединяемые к приложениям во время их выполнения.

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

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

SDN для самого верхнего уровня

Сервисную сетку можно мыслить как программно-определяемую сеть (SDN) на уровне исполняемого кода. В среде, где все микросервисы адресуемы через сеть, сервисная сетка переопределяет правила сети. Она устанавливает контроль над уровнем управления приложения — его сетью точек контакта или, образно говоря, его мозговым центром — и перемаршрутизирует его подключения через своеобразный комплекс динамического управления трафиком. Этот хаб состоит из нескольких компонентов, которые отслеживают природу трафика в сети и оптимально подстраивают подключения.

SDN отделяет уровень управления от уровня передачи данных в сети, чтобы по мере необходимости иметь возможность в буквальном смысле перестраивать уровень управления. Это позволяет приближать друг к другу нуждающиеся в этом компоненты, не трогая уровень передачи данных, к которому привязана полезная нагрузка. В случае сетевых серверов, обращающихся друг к другу с использованием уровней 3 и 4 модели OSI, для повышения эффективности и уменьшения задержек SDN маршрутизирует пакеты по упрощенным путям.

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

Примером работы сервисной сетки является платформа Istio. По словам Бахубали Шетти, директора VMware по публичным облачным решениям, «одно из ее достоинств состоит в том, что Istio включает компоненты для мониторинга и ведения логов. Поэтому вам не нужно отдельно загружать Prometheus или Jaeger, они уже есть в пакете. Кроме них есть и пара других инструментов видимости. В целом же Istio является механизмом коммуникаций между сервисами. Вы можете иметь сервисы на базе GKE (Google Kubernetes Engine), PKS (Pivotal Kubernetes Service) или VKE (VMware Kubernetes Engine), и все это будет друг с другом связано и сможет нормально работать. Istio помогает всем этим управлять».

Дополняя, но не перекрываясь с Kubernetes

Возможно, у вас возникает вопрос: «Разве за управление сетью на уровне приложений не отвечает оркестратор типа Kubernetes?». Ответ состоит в следующем: платформа Kubernetes реально не управляет сетью. Она имеет очень простое и неконтролируемое представление о пространстве приложений как о множестве кластеров, состоящих из подов (один или несколько контейнеров на одном узле с общим IP-адресом), независимо от того, где развернута система — на местной площадке, в гибридном облаке или на нативно-облачной сервисной платформе типа Azure AKS или Pivotal PKS. Если же используется сервисная сетка, то она учитывает все сложности соединений в бэкэнде и позволяет оркестратору сосредоточиться на приложении, а не на инфраструктуре.

Ключевые преимущества

Неожиданный взлет концепции сервисных сеток и особенно фреймворка Istio имеет большое практическое значение.

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

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

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