Почему сервисная сетка является улучшением по сравнению с более ранними сетевыми топологиями

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

Реагирует в режиме реального времени

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

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

Оторванный от реальности

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

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

Беспрепятственная наблюдаемость

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

Видимость часто имеет свою цену, и чаще всего этой ценой является производительность. Однако это не относится к технологии Service Mesh, поскольку прокси-серверы Sidecar созданы легкими и быстрыми. Вот почему, в отличие от традиционных сетей, они предоставляют разработчикам необходимый уровень видимости без ущерба для производительности. Технология Service Mesh также обеспечивает видимость среды выполнения и контроль над ней. Кроме того, он идеально подходит для мониторинга и регулирования всего входящего и исходящего трафика. Istio, популярный инструмент Service Mesh, имеет настраиваемые информационные панели, которые обеспечивают наглядность не только производительности всех ваших сервисов, но и дают дополнительную информацию о том, как они влияют на другие ваши процессы. Эти дополнительные расчеты и выводы, которые предоставляют вам инструменты Service Mesh, важны для понимания того, как небольшие изменения в производительности могут иметь большое влияние на пользователей.

«Родная» сеть микросервисов

Чтобы быть конкурентоспособными, современные приложения должны быть все время «на ходу», а это означает, что они должны реагировать в режиме реального времени, не зависеть от инфраструктуры и реализаций и быть кристально чистыми. Хотя более ранние сетевые топологии прекрасно работают для монолитов и даже для веб-приложений, управляемых API, они просто не могут справиться с непредсказуемостью и огромными цифрами, которые выбрасывают микросервисы. Технология Service Mesh, с другой стороны, обладает уникальной особенностью, поскольку она создана для взаимодействия между службами в первую очередь в архитектуре микросервисов. При этом многие утверждают, что Kubernetes в конечном итоге позаботится об этом за вас, и хотя в какой-то степени это правда, на данный момент Kubernetes предлагает только очень простую сервисную сетку, и вам нужны Istio, Envoy, Conduit или Linkerd2 для многофункциональный опыт.