Хабрахабр

[Перевод] Что такое сервисная сеть

Доброе утро всем!

Наиболее интересным решением в этой сфере (на наш взгляд) является Istio, но предлагаемая статья интересна, в первую очередь, экспресс-сравнением имеющихся технологий такого рода и high-level обзором всей парадигмы. Сегодня мы рады предложить вам перевод статьи, кратко рассказывающей о новом технологическом веянии под названием «Service mesh» (сервисная сеть). Автор Тобиас Кунце также написал вторую, более практически-ориентированную статью о service mesh — просьба высказаться, стоит ли опубликовать и ее перевод

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

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

А вот что наблюдается недавно: бурное распространение контейнеров и сопутствующий ему взрывной рост сервисных вызовов, степень горизонтального масштабирования и связанная с ней недолговременность существования сервисных терминалов. Разумеется, большинство из этих проблем – не новы, и уже давно в нашем распоряжении есть технологии, помогающие организовать механизмы обмена сообщениями, например, SOAP, Apache Thrift и gRPC. Наиболее популярный подход к предоставлению такого уровня, применяемый сегодня, называется «сервисная сеть». Когда сложность и зыбкость выходят на новый уровень, возникает желание инкапсулировать сетевую коммуникацию и вынести ее на новый инфраструктурный уровень.

Что же такое “сервисная сеть” на самом деле?

Сервисная сеть – это не «сетка из сервисов». Эта сеть API-посредников (прокси), к которым могут подключаться (микро)сервисы для полного абстрагирования сети. Как выразился Уильям Морган, это «выделенный инфраструктурный уровень, обеспечивающий безопасную, быструю и надежную коммуникацию между сервисами». Сервисные сети помогают справляться со множеством вызовов, которые встают перед разработчиками, когда приходится обмениваться информацией с удаленными терминалами. Однако, следует отметить, что крупные эксплуатационные проблемы при помощи сервисных сетей не решаются.

Как работают сервисные сети?

Прокси в плоскости данных развернуты как компаньоны (sidecar), а плоскость управления располагается отдельно. Типичная архитектура сервисной сети.

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

Именно в плоскости управления пользователи задают политики и конфигурируют плоскость данных в целом.
Для реализации сервисной сети нужны как плоскость данных, так и плоскость управления. Напротив, набор API и инструментов, используемых для управления поведением прокси в пределах всей сервисной сети называется ее «плоскостью управления».

Основные игроки: Envoy, Linkerd, Istio и Consul

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

Исходно он был написан на Scala, как и Finagle, от Twitter, от которого он произошел, а затем слился с легковесным проектом Conduit и был перезапущен как Linkerd 2. Linkerd – опенсорсный проект, поддерживаемый Buoyant и, в то же время, самая первая сервисная сеть. 0.

Ее совместно запустили Google, IBM и Lyft; ожидается, что в конечном итоге она войдет в проект Cloud-Native Computing Foundation (CNCF). Istio – пожалуй, наиболее популярная сервисная сеть нашего времени. Как правило, Istio используется вместе с Envoy и лучше всего работает на Kubernetes. Строго говоря, Istio – это плоскость управления и, чтобы образовать сервисную сеть, она должна сочетаться с плоскостью данных.

Он лучше всего работает с топологиями, охватывающими множество датацентров, и специализируется на обнаружении сервисов. Consul – сравнительно новое явление в экосистеме плоскостей управления. Его поддержкой занимается HashiCorp. Consul работает со множеством плоскостей данных, и может использоваться без привлечения других плоскостей управления, например, без Istio.

Основные достоинства и расхождения в приоритетах

Хотя, пространство сервисных сетей продолжает развиваться, большинство проектов, по-видимому, уже пришли к представлению об основном наборе фич, которые должны в такой сети поддерживаться:

  • Обнаружение сервисов: обнаружение сервисов и ведение их реестра
  • Маршрутизация: умная балансировка нагрузки и сетевая маршрутизация, более качественная проверка работоспособности, паттерны автоматического развертывания, например, сине-зеленые и канареечные конфигурации
  • Устойчивость: повторные попытки, таймауты и автоматические выключатели
  • Безопасность: Шифрование на основе TLS, в том числе, управление ключами
  • Телеметрия: сбор метрик и отслеживание идентификаторов

Кроме этих возможностей (а иногда и на их основе) существует и более богатый уровень функций, на котором между разными сервисными сетями начинаются серьезные расхождения по поводу того, что может быть ценно для архитекторов, разработчиков и администраторов микросервисных систем. Например, Envoy поддерживает WebSockets, а Linkerd 2.0 (пока) нет. В то время, как и Istio, и Consul поддерживают разные плоскости данных, Linkerd работает только со своей собственной. У Consul есть собственная встроенная плоскость данных, которую можно заменить на более мощную, когда вопрос производительности становится приоритетным. Istio разработана как отдельная централизованная плоскость управления, а Consul и Linkerd являются полностью распределенными. Наконец, из всех рассмотренных выше сервисных сетей лишь Istio поддерживает внесение неисправностей (fault injection). Это лишь некоторые из ключевых различий, которые нужно учитывать, если вы подумываете о внедрении такой сети.

Критика сервисных сетей

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

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

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

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

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

Связанные технологии

Сервисные сети пересекаются и с другими архитектурными компонентами, но, конечно, несводимы к ним. Среди таких элементов – API, шлюзы приложений, балансировщики нагрузки, контроллеры входящего и исходящего трафика (ingress и egress) или шлюзы доставки приложений. Основное назначение шлюза API – предоставлять сервисам выход во внешний мир, действуя при этом как единый API для обеспечения балансировки нагрузки, безопасности и базовых функций управления. Контроллеры входящего и исходящего трафика транслируют информацию между немаршрутизируемыми адресами в оркестровщике контейнеров и маршрутизируемыми адресами вне его. Наконец, контроллеры доставки приложений подобны шлюзам API, но их специализация – в ускорении доставки веб-приложений, а не только API.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть