Рынок сервисных сеток Kubernetes намного больше, чем Istio
Традиционная монолитная архитектура приложений устарела благодаря развитию микросервисов. Архитектура микросервисов изменила способ создания и доставки приложений. Разбиение одного приложения на несколько независимых контейнерных служб упрощает разработку приложений. Разработчики могут проектировать изолированные компоненты, которые можно интегрировать в полнофункциональное приложение, и эти компоненты также можно повторно использовать в будущих приложениях.
Рождение сервисной сетки
В приложениях на основе микрослужб разработчики должны были добавлять логику маршрутизации для межпроцессного взаимодействия внутри каждой службы. Это работало нормально, но сложные приложения, особенно облачные, нуждаются в чем-то лучше. Войдите в сервисную сетку. Сервисная сетка — это выделенный уровень инфраструктуры, встроенный непосредственно в приложение, который упрощает взаимодействие между сервисами. Сервисная сетка управляет логикой, управляющей перемещением запросов между различными сервисами. Как это делается, так это то, что он добавляет уровень абстракции, который отделяет сами запросы от их исходных или целевых служб. Сервисная сетка использует прокси-серверы, чтобы помочь запросам пройти через последовательность сервисов, чтобы беспрепятственно обеспечить желаемую функциональность. Envoy, разработанный Lyft, является одним из самых популярных прокси-сервисов с открытым исходным кодом в экосистеме Kubernetes, который используется различными сервисными сетками.
С помощью сервисной сетки разработчики могут просто работать над своими приложениями, не заботясь о написании отдельного кода прямо в сервисах, которые они создают. Это помогает им сосредоточиться на своих бизнес-целях, а не на лежащей в их основе сантехнике. Сервисная сетка также помогает в мониторинге приложений. Сервисная сетка может помочь отслеживать производительность приложений, а разработчики могут использовать эту информацию для оптимизации приложений, избегая простоев.
Рынок сервисных сеток: какие у вас есть варианты?
Istio, возможно, является одной из самых популярных сервисных сетей на данный момент. Istio — это решение с открытым исходным кодом, основанное на Envoy Proxy и являющееся результатом сотрудничества Google, IBM и Lyft. Большинство поставщиков в экосистеме Kubernetes работают над разработкой решений на базе Istio. Но есть несколько других решений Service Mesh, которые могут принять разработчики, желающие поэкспериментировать с микросервисами. Вот некоторые из вариантов, которые стоит рассмотреть.
1. Linkerd от Buoyant
Linkerd (произносится Linker-dee) был первой сервисной сеткой, разработанной еще в 2016 году. Linkerd снискал большую известность. Инженеры инфраструктуры Twitter Уильям Морган и Оливер Гулд являются соучредителями Buoyant. Они разработали Linker на основе библиотек Twitter Finagle, чтобы помочь решить проблемы, с которыми сталкиваются большие производственные системы. Написанный на Scala, Linkerd прост в установке и предоставляет разработчикам более прозрачное представление о взаимодействии между службами за счет отделения логики связи от служб. Пользователи могут отслеживать поток запросов в своих приложениях и легко устранять проблемы.
Linkerd не зависит от языка, что означает, что он позволяет пользователям выбирать язык, на котором они хотят разрабатывать свои приложения. Пользователи могут легко масштабировать свои приложения для обработки большого количества запросов. Многие компании, включая Karma, Paypal и Ticketmaster, используют Linkerd для производства. Linkerd обеспечивает поддержку различных контейнерных платформ, таких как Docker, DC/OS, Amazon ECS и Kubernetes. Linkerd также обеспечивает поддержку автономных приложений.
Conduit — еще один продукт, разработанный Buoyant как облегченная альтернатива Linkerd. Conduit использует вспомогательный прокси-сервер с низким уровнем ресурсов с кластерами Kubernetes, чтобы упростить развертывание и повысить производительность приложений. Conduit помогает разработчикам, сокращая количество конфигураций и ресурсов. Но после семи месяцев работы в качестве отдельного проекта Buoyant объединил Conduit с Linkerd 2.0.
Linkerd стал свидетелем полной перестройки своей новой версии 2.0, которая была запущена в 2018 году. Самая большая новость о версии 2.0 заключается в том, что Linkerd был принят CNCF, официально включив его в стабильную версию Kubernetes, которой он по праву принадлежит. Linkerd 2.0 компактнее и намного быстрее своего предшественника. Благодаря новому дизайну сопутствующей службы владельцы платформ могут создавать приложения поэтапно и развертывать функциональные возможности сетки служб для каждой службы отдельно. Это приводит к более безопасной и менее сложной инфраструктуре.
Linkerd отлично подходит для выявления точного местоположения сбоев, чтобы разработчики могли мгновенно устранять проблемы. В новой версии разработчики получают представление о запросах в режиме реального времени, что может помочь выявить сбои. Linkerd показывает графики зависимостей и различные визуализации, отображающие показатели успешности, задержки и другие показатели на мгновенных информационных панелях Grafana. Linkerd — самая достойная альтернатива Istio, и последние обновления показывают, что у него впереди многообещающее будущее.
2. SuperGloo от Solo.io
Solo предлагает продукты с открытым исходным кодом, такие как функциональный шлюз Gloo, сервер Sqoop GrapQl и SuperGloo, которые помогают предприятиям с легкостью разрабатывать собственные облачные приложения. Платформа для оркестровки сервисных сеток Solo.io, SuperGloo, стала очень популярной за последние несколько месяцев, и это правильно. SuperGloo предлагает гораздо более автоматизированную и простую функциональность сервисной сетки, чем его аналоги. Пользователям, которые не хотят переходить на подход Service Mesh, не составит труда использовать SuperGloo, поскольку он автоматизирует установку и избавляет разработчиков от обременительной задачи по написанию сложных файлов YAML. Разработчики могут использовать все функции сервисной сетки через интерактивный пользовательский интерфейс без необходимости их ручной настройки.
SuperGloo заботится как о входящем трафике (север-юг), так и о сетевом трафике (восток-запад) и предоставляет пользователям унифицированный опыт управления. Пользователи могут выбрать сопряжение любой сервисной сетки и любого входа по своему вкусу и получить беспрепятственный опыт, поскольку SuperGloo позаботится обо всех установках и конфигурациях, необходимых для работы любой пары вход-меш. Пользователи могут свободно переходить на различные сетки с помощью унифицированного интерфейса SuperGloo. SuperGloo позволяет разработчикам использовать один продукт в любой сервисной сетке без внесения каких-либо изменений.
Solo планирует превратить SuperGloo в мультисервисную ячеистую инфраструктуру. По словам Соло, будущее за мультисетью, что означает, что пользователи могут использовать различные сервисные сетки в зависимости от потребностей своих приложений. Для предприятий, использующих различные сервисные сетки, SuperGloo может помочь «склеить» их вместе без стресса, связанного со сложной настройкой. В многооблачном мире такой подход, не зависящий от поставщика, обязательно привлечет внимание.
3. Консул от HashiCorp
Самое впечатляющее в HashiCorp то, что она создала комплексный набор продуктов, которые глубоко интегрированы друг с другом и решают широкий спектр задач по всему спектру облачных технологий. В то время как Terraform — самый популярный продукт HashiCorp, Consul — еще один многообещающий продукт из конюшни HashiCorp. Это инструмент с открытым исходным кодом, который помогает разработчикам решать проблемы с облачной инфраструктурой.
Консул основан на агентах или клиентах для управления связью между службами. На всех узлах кластера работает клиент Consul, управляющий локальным кешем. Этот кеш регулярно обновляется с серверов. Поскольку никакой внешней связи не происходит, API каждого сервиса отвечает быстрее, что обеспечивает гораздо более быстрое взаимодействие с пользователем. Консул написан на Go и в первую очередь представляет собой сервисный реестр, обеспечивающий обнаружение.
Consul построен на предположении, что балансировщики нагрузки неэффективны в настройке микросервисов. Согласно HashiCorp, балансировщики нагрузки увеличивают стоимость, приводят к задержке и обеспечивают единую точку отказа. Решением этой проблемы является использование реестра, который содержит информацию обо всех узлах и службах в конкретном кластере. Службы запрашивают этот реестр для прямого подключения к другим службам, используя динамически обновляемый DNS вместо использования балансировщиков нагрузки. Эта функция известна как сервисное обнаружение и является основой любого предложения сервисной сетки, доступного сегодня.
Consul отдает приоритет аутентификации соединений между различными сервисами, а не шифрованию. Он предоставляет только услуги уровня управления. Тем не менее, он поддерживает Envoy для решений плоскости данных и сопутствующих решений. Он также ориентирован только на сетчатый трафик. Несколько поставщиков входящего трафика предлагают интеграцию с Consul. На данный момент Consul Connect ограничен поддержкой уровня 4, но поддержка уровня 7 находится в стадии разработки. Consul полагается на Envoy для функций наблюдения, поскольку сам Consul не имеет многих из этих функций. Клиенты Consul могут выполнять проверку работоспособности сервисов и локальных узлов. Обнаружение служб использует эти проверки работоспособности для направления трафика от неработоспособных служб или узлов. Consul также поддерживает несколько центров обработки данных. Это помогает пользователям переходить в новые регионы, не беспокоясь о создании дополнительных уровней абстракции.
Рынок сервисных сеток: что впереди?
На рынке есть множество других поставщиков, предлагающих сервисную сетку. Сервисная сетка Envoy — еще один вариант. Популярный поставщик дополнительных прокси-серверов использовал свою концепцию прокси-серверов, которую он разделяет с различными поставщиками, для разработки собственного предложения сервисной сетки, которое кажется весьма многообещающим. NGINX использует Istio для разработки собственного продукта сервисной сетки. Все эти альтернативы предлагают функции, которые отличают их друг от друга. В конечном итоге выбор поставщика сервисной сетки сводится к требованиям предприятия. Однако это новая парадигма, и разработчики, переходящие на сервисную сетку, должны быть готовы поэкспериментировать с этими вариантами, чтобы найти то, что им подходит. Разработчики также должны стараться принимать активное участие в сообществах с открытым исходным кодом, чтобы улучшить реализацию сервисной сетки. Но, тем не менее, это будущее. Можно с уверенностью сказать, что легкомысленное отношение к сервисной сетке не сулит ничего хорошего предприятиям в будущем. С нынешними темпами инноваций традиционная монолитная инфраструктура приложений наверняка скоро устареет. Внедрение сервисной сетки больше не является тенденцией, это необходимость. Здоровым признаком этого является то, что Istio — не единственный вариант — сегодня существует надежная экосистема инструментов Service Mesh, которые могут удовлетворить различные потребности.