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

Автор оригинала: Tobias Kunze
  • Перевод
Доброе утро всем!

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



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

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

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

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


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

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




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

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

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

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




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



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



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



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

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


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

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

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

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


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

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

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

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

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

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


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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Актуальность follow-up

Издательский дом «Питер»
279,78
Компания
Поделиться публикацией

Похожие публикации

Комментарии 12

    +4

    Перевод ни к черту. Устоявшейся терминологии нет.
    Сервисная сеть? Мне кажется, что в оригинале service mesh имеет более широкое значение, чем просто "сервисная сеть".


    шлюзы доставки приложений

    WAT???


    плоскость управления
    компаньоны

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

      0

      Главная проблема микросервисов, вне зависимости от используемой технологии, это ненадёжность сети. При том, что tcp нам обещает гарантированную доставку, оно выполняет это обещание только в одном случае — когда мы получили подтверждение отправки. Если подтверждения не было, может быть что угодно — таймауты, полуотправленное сообщение, отправленное сообщение о котором мы не получили подтверждения и т.д.


      Это означает, что вместо someclass.do_it(args), который вызывается и выполняется один раз, мы должны изобретать целый идемпотентный протокол, который надо полировать внутри API и внутри клиента. Это очень, очень усложняет процесс.


      И никакие прокси-сервера не помогут с решением проблемы того, что внутренние вызовы в приложении — надёжно, а сетевые — нет.

        0
        Мне кажется, что это чрезмерное упрощение.
        В «жёсткой» модели обработки ошибок — ошибка «RPC» это просто ещё один тип ошибки, который подлежит классификации и обработке. То что внутри процесса таких ошибок не бывает, не отменяет необходимости классифицировать и обрабатывать другие ошибки на границах слоёв, включая те же самые механизмы классификации типа вызова (мутирующий или нет, идемпотентный или нет, кэшируемый или нет, и т.д.).
        Напомню что почти под чем угодно, для чего применяются микросервисы, где-то лежит внешнее хранилище данных, а значит что в общем-то, проблемы с сетью рано или поздно превратятся в некий CommunicationException, причём неизвестно где проще его «качественно» обработать — прямо по месту вызова в некоем Repository или в координационном слое, который обладает знанием о том, какую высокоуровневую операцию пытались совершить.
        Так что хоть монолит, хоть микросервисы — в распределённых системах наличие ошибок и постоянное состояние отказа части системы это норма (простите за капитанство), и утверждение «сеть ненадёжная» это просто констатация данности, а не аргумент за или против той или иной топологии одного из компонентов приложения.

        Мои стандартные рекомендации: dataintensive.net, book.mixu.net/distsys, www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf
          0

          Вы не поняли с чем я сравниваю. Я сравниваю сетевое взаимодействие с вызовом функции в программе. Для такой функции есть восхитительные свойства:
          а) Функция вызывается ровно столько раз, сколько была вызвана
          б) Функция вызывается, если она была вызвана.
          в) Функция вызывается тогда, когда была вызвана.


          Появление сети превращает "вызов функции" в церемонию, в которой все ритуалы важны. И поддержка at least once (вместо exactly once), и таймауты, и решение проблемы распухания очереди и т.д.


          Т.е. чем больше сетевых сервисов в приложении (и я отметаю слово "микро" как buzzword), тем больше мест для таких ритуалов. Обязательных, нарушение которых чревато рантайм-адом.


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

            0
            С последним утверждением согласен =)
          0
          При этом я не считаю что микросервисы это решение всех проблем. Сначала это создание кучи других проблем, из-за того что «клей» для них пока недостаточно коммодитизирован.
          Фактически, оправдание для использования микросервисов одно — масштабирование команды разработки темпами, которые превышают допустимые для монолита (грубо говоря «ну и что что-то нас тут всё на рельсах, возьмём вон тех троих и они нам биллинг на .NET Core налабают, а ещё есть на примете отличная команда пайтонистов, которые мастера в аналитике для нашей области»). Иначе микросервисы это слишком дорогой способ самодисциплины для поддержания качества кода, у которого (способа) есть лучшие альтернативы :)
            0

            Именно! Все плюсы микросервисной архитектуры — это управление (командой разработчиков) и возможность снизить порог вхождения для джуниоров.


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

              0

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

                0

                Я бы сказал, что сложность приложения возрастает. Мало того, что оригинальная сложность перераспределяется, так ещё и дополнительный слой сложности добавляется.


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

                  0

                  Я категорически против это называть микросервисами…
                  А причины могут многие — некоторые вещи реально на кубернетесе делать проще.

            0
            что внутренние вызовы в приложении — надёжно

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

              0

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

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое