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

by moiseevrus

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

Каждая часть приложения, называемая «службой», опирается на другие службы, чтобы предоставить пользователям то, что они хотят. Если пользователь онлайн-приложения для розничной торговли хочет что-то купить, ему нужно знать, есть ли этот товар в наличии. Таким образом, служба, которая взаимодействует с базой данных инвентаря компании, должна взаимодействовать с веб-страницей продукта, которая сама должна взаимодействовать с онлайн-корзиной пользователя. Чтобы повысить ценность бизнеса, этот ритейлер может в конечном итоге создать сервис, который дает пользователям рекомендации по продуктам в приложении. Этот новый сервис будет взаимодействовать с базой данных тегов продуктов, чтобы давать рекомендации, но он также должен взаимодействовать с той же базой данных инвентаризации, которая нужна странице продукта — это много повторно используемых, движущихся частей.

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

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

 

Архитектура микросервисов

 

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

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

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

  1. Поскольку ваш запрос на эту страницу был отправлен, он был сначала получен веб-прокси вашей компании…
  2. После прохождения мер безопасности прокси, он был отправлен на сервер, на котором размещена эта страница…
  3. Далее эта страница была возвращена на прокси и снова проверена на его меры безопасности…
  4. И вот наконец он был отправлен вам с прокси.

 

 

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

 

 

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

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

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

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

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

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

С сервисной сеткой:

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

Начните планировать будущее — поэкспериментируйте с сервисной сеткой в ​​Red Hat® OpenShift® Service Mesh. Воспользуйтесь единым способом подключения, управления и наблюдения за приложениями на основе микросервисов с поведенческим анализом и контролем сетевых микросервисов в вашей сервисной сетке. Сервисная сетка OpenShift доступна (бесплатно) для Red Hat OpenShift.

Компонент сетки автоматизации Red Hat Ansible Automation Platform предоставляет простую и надежную структуру сервисной сетки для масштабируемой автоматизации. Благодаря гибкому многонаправленному коммуникационному уровню сетка автоматизации повышает способность организации работать в глобальном масштабе. Обладая меньшей чувствительностью к задержкам и разрывам соединения, а также собственными возможностями пиринга, вы можете добиться большего благодаря повышенной надежности по сравнению с любой другой платформой автоматизации, представленной сегодня на рынке. Благодаря таким функциям безопасности, как аутентификация и шифрование TLS, а также дополнительным элементам управления доступом, вы можете положиться на Red Hat Ansible Automation Platform , чтобы расширить границы возможного для всей ИТ-инфраструктуры вашего предприятия.

Статья является переводом redhat.com

You may also like

Leave a Comment