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

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

Что такое сервисная сетка?

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

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

Мы можем приравнять сервисную сетку к уровню 7 сетевой модели OSI для программно-определяемой сети (SDN). Точно так же, как SDN создает уровень абстракции, где сетевым администраторам не приходится иметь дело с физическими сетевыми подключениями, сервисная сетка отделяет базовую инфраструктуру приложений, с которыми вы взаимодействуете в абстракции.

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

Балансировка нагрузки сервисной сетки

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

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

Service mesh vs Kubernetes

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

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

Сервисная сетка против API-шлюза

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

С другой стороны, сервисная сетка используется для оптимизации трафика восток-запад (трафик сервер-сервер) внутри кластера, а шлюз API используется для трафика север-юг (трафик сервер-клиент) в кластер и из него. Но сервисная сетка все еще находится на ранних стадиях и все еще развивается. Многие сервисные сетки, в том числе Linkerd и Istio, теперь доступны для функций север-юг.

Сетчатая архитектура сервисов

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

Библиотека, импортируемая каждым микросервисом
Агент узла, предоставляющий услуги всем контейнерам на определенном узле.
sidecar-контейнер, работающий с контейнером приложения

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

Sidecar

Что означает запуск sidecar-контейнера вместе с контейнером вашего приложения? В этом типе сервисной сетки каждому контейнеру микросервиса соответствует другой прокси-контейнер. Все потребности в межсервисном взаимодействии абстрагируются от микросервисов и размещаются в дополнительных компонентах.

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

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

Звездные проекты Service Mesh: Linkerd, Envio, Istio, Consul

Итак, после всего сказанного, что такое сервисная сетка? В настоящее время в этой области нет полностью готовых коммерческих продуктов. Большинство сервисных сеток - это только проекты с открытым исходным кодом, которые необходимо реализовать с помощью определенных этапов работы.Сейчас хорошо известны проекты:

Linkerd: выпущен в 2016 году, самый старый из этих проектов. Linkerd был разветвлен из библиотеки, разработанной Twitter. Другой тяжеловес в этой области, Conduit, присоединился к проекту Linkerd и лег в основу Linkerd 2.0.

Envoy: Созданный Lyft для обеспечения полной функциональности сервисной сетки, Envoy занимает часть «плоскости данных» и сопоставляет ее.

Istio: Совместно разработанный Lyft, IBM и Google, Istio может легко добавлять в него такие функции, как балансировка нагрузки и аутентификация, не изменяя исходный код микросервиса.Он может контролировать все прокси-сервисы, контролируя Envoy и другие прокси-сервисы. Кроме того, Istio обеспечивает отказоустойчивость, канареечное развертывание, A/B-тестирование, мониторинг и многое другое, а также поддерживает пользовательские компоненты и интеграции. Istio поддерживается в Rancher 2.3 Preview 2. Пользователи могут запускать Istio непосредственно в пользовательском интерфейсе и добавлять автоматические дополнения для каждого пространства имен. Rancher имеет встроенную панель инструментов с поддержкой Kiali, которая упрощает установку и настройку Istio. Все это делает развертывание и управление Istio простым и быстрым.

HashiCorp Consul: Представленная в Consul 1.2 функция Connect добавляет шифрование службы и авторизацию на основе идентификации в распределенную систему HashiCorp, которую можно использовать для обнаружения и настройки службы.

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