Интерпретация архитектуры Service Mesh на уровне предприятия — разделение Service Mesh на сеансовом уровне

Прослеживая источник, Service Mesh на самом деле является своего рода SDN, который эквивалентен сеансовому уровню в модели OSI. Каждое технологическое изменение неизбежно ведет к изменениям в производительности и производственных отношениях, и мы видим, что эта тенденция ускоряется. Эта книга описывает путь Service Mesh на предприятии, который может быть использован в качестве справочника для большинства технического и управленческого персонала.

Это книга по сервисной сетке от O'Reilly, спонсируемая Nginx, под названием

Об авторе

Автором этой книги являетсяLee Calcote, работал в Cisco, Seagate, Solarwind, последовательно отвечая за принятие технических стратегических решений, участвовал в DMTF (Distributed Management Task Foundation), CIS (Center for Internet Security), амбассадор CNCF, капитан Docker.

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

содержание

Глава 1. Основы Service Mesh

• Управление несколькими услугами
• Что такое сервисная сетка
• Зачем вам нужна сервисная сетка
• в заключении

Глава 2 Сравнение технологий

• Различные сервисные сетки (и шлюз)
• Оркестрация контейнеров
• API Gateway
• клиентская библиотека
• Суммировать

Глава 3 Принятие и развитие

• Постепенно принять
• принимать меры
• Модернизация развертывания
• Эволюция архитектуры
• Суммировать

Глава 4 Настройка и интеграция

• Настраиваемая коляска
• Расширяемый адаптер
• Суммировать

Глава 5. Резюме

• Использовать или не использовать?

Каждая глава будет объяснена ниже.

Глава 1. Основы Service Mesh

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

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

Service Mesh построен на физическом или виртуальном сетевом уровне, а управление потоком микросервисов на основе политик отличается от общих сетевых протоколов тем, что имеет следующие характеристики:

• движимый разработчиком
• Настраиваемые политики
• Служба предпочитает сетевую конфигурацию протоколу

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

Разница между Service Mesh и традиционной сетью заключается в том, чтоаппаратная или виртуальная сетьиПрограммно определяемая сеть (SDN)Разница, которую мы можем видеть на рисунке выше, заключается в том, что физических и виртуальных сетей больше, чем SDN.плоскость управления.

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

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

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

Сетчатая архитектура сервисов

На картинке нижеConduitСхема архитектуры Service Mesh (теперь объединенной в Linkerd2), которая представляет собой типичную архитектуру Service Mesh.

Service Mesh делится наплоскость управленияиплоскость данных, два популярных в настоящее время Service Mesh с открытым исходным кодом, Istio и Linkerd, на самом деле являются такой структурой, но Istio более четко разделен, и развертывание более фрагментировано, многие компоненты разделены, а плоскость управления включает Mixer, Pilot, Citadel, плоскость данных по умолчанию использует Envoy; в Linkerd в качестве плоскости данных используется только linkerd, а в качестве плоскости управления используется namerd.

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

Особенности плоскости управления:

• Не анализировать пакеты напрямую
• Общайтесь с агентами в плоскости управления для выдачи политик и конфигураций
• Отвечает за визуализацию поведения сети
• Обычно предоставляет инструменты API или командной строки для управления версиями конфигурации для непрерывной интеграции и развертывания.

плоскость данных

Особенности плоскости данных:

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

Значение сервисной сетки

Сервисы в Service Mesh являются первоклассными гражданами, которые обеспечивают управление сетевым трафиком L5 и предоставляют следующие функции:

наблюдаемость

Взяв Istio в качестве примера, Mixer отправляет данные телеметрии приложения в серверные системы мониторинга, ведения журнала, аутентификации и управления общим доступом через адаптеры.

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

управление потоком

Примерами, приведенными в тексте, являются тайм-ауты, повторные попытки, крайние сроки и ограничение скорости.

безопасность

На следующем рисунке схематично показан защищенный канал связи в Istio.

Общая безопасность достигается с помощью сертификатов. Дополнительный прокси-сервер отвечает за управление жизненным циклом сертификата, включая создание, распространение, обновление и отзыв сертификата. Также из рисунка видно, что между sidecar и контейнером приложения внутри Pod устанавливается локальное TCP-соединение, которое использует mTLS (двунаправленное шифрование транспортного уровня). Это очень важно, потому что узел или даже Pod не обязательно запускает контейнер, и контейнер может быть открыт для внешнего доступа, обеспечивая двустороннее шифрование транспортного уровня, что может обеспечить безопасность передачи трафика.

Задержка и внесение ошибок

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

Развязка на L5

Это самый важный пункт книги, настолько важный, что его следует поместить в подзаголовок.Любой, кто знаком с моделью OSI, знает, что такое L5.

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

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

Такое разделение обязанностей значительно увеличивает скорость итерации программного обеспечения.Короче говоря, вы можете использовать Service Mesh в качестве сеансового уровня в модели OSI.

Глава 2 Сравнение технологий

В этой главе в основном объясняются различия между технологиями Service Mesh и различиями между Service Mesh и другими связанными технологиями Читатели могут напрямую просмотреть этот веб-сайт, чтобы просмотреть сравнение:layer5.IO/service - в чем дело...

Зачем нам по-прежнему нужна Service Mesh с оркестровкой контейнеров, такой как Kubernetes?В следующей таблице сравниваются основные функции планировщика оркестрации контейнеров и отсутствие возможностей на уровне обслуживания.

Выше перечислены возможности уровня службы, которых не хватает в оркестровке контейнеров.Когда система оркестровки контейнеров, такая как Kubernetes, также имеет возможности управления службами, такие как Ingress Controller, она отвечает только за обратный прокси-сервер, предоставляемый службами в кластере. Ingress Возможности контроллера ограничены моделью программирования Kubernetes. Управление службами также может осуществляться с помощью, например, Kong, облачных балансировщиков нагрузки, шлюза API и управления API.Finagle,Hystrix,RibbonПоддержка клиентской библиотеки.

На рисунке ниже показано использованиеклиентская библиотекаСхема тесно связанного управления приложениями и службами.

Как видно из диаграммы, код приложения тесно связан с клиентской библиотекой, и разные сервисные команды должны работать вместе, чтобы согласовывать тайм-ауты, механизмы повторных попыток и т. д. Оркестрация контейнеров больше подходит для распределенных приложений. Шлюз API обычно необходимо развертывать только на границе системы и не нужно развертывать в каждом приложении, в то время как Service Mesh необходимо развертывать в каждой службе или узле.

Глава 3 Принятие и развитие

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

• Полное внедрение: обычно это делается для новых приложений, также известных как проект Greenfiled.
• Постепенное внедрение: модернизация устаревшей системы, также известная как проект Brownfiled.

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

Эволюция архитектуры

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

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

Входящий или пограничный прокси

Если вы используете Kubernetes для оркестровки и планирования контейнеров, прежде чем перейти к архитектуре Service Mesh, вы обычно используете Ingress Controller в качестве обратного прокси-сервера для трафика внутри и вне кластера, например Traefik или Nginx Ingress Controller.

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

сетка маршрутизатора

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

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

Proxy per Node

Эта архитектура развертывает агент на каждом узле или при использовании Kubernetes для развертыванияDaemonSetObjects, первое поколение Linkerd развертывается таким образом, первое поколение Linkerd разрабатывается с использованием Scala, который потребляет больше ресурсов на основе JVM, а второе поколение Linkerd разрабатывается с использованием Go.

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

Прокси коляски/модель ткани

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

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

Sidecar proxy/плоскость управления

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

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

Многокластерное развертывание и масштабирование

Выше приведена архитектура одного кластера сервисной сетки. Все сервисы расположены в одном кластере. Сервисная сетка управляет входящим и исходящим трафиком кластера и внутри кластера. Когда нам нужно управлять несколькими кластерами или внедрять внешние сервисы, нам надорасширение сетииМультикластерная конфигурация.

Глава 4 Настройка и интеграция

Например, в Service Mesh есть много мест, таких как Istio, которые можно настроить под себя, например, sidecar в качестве плоскости данных.Хотя Envoy используется по умолчанию, вы можете разработать свой собственный sidecar-прокси, а также различные адаптеры в Mixer, вы также можете разработать собственный адаптер для расширения возможностей телеметрии и аутентификации,Consul ConnectПросто пример.

Доступные в настоящее время прокси с открытым исходным кодом можно найти по адресуlandscapeможно найти, например, при использовании nginMesh вместо Envoy в качестве плоскости данных. На следующем рисунке показана архитектурная схема использования nginx в качестве дополнения.

nginMesh

Подключайтесь к различным серверам мониторинга, расширяя адаптер Istio Mixer.

SOFAMosn

Существует также версия платформы данных Ant Financial с открытым исходным кодом на языке Go.SOFAMosn, который является частью SOFAMesh, который также совместим с Istio и может использоваться только в качестве прокси-сервера, см.:SOFAMesh и SOFA MOSN — решение Service Mesh на основе Istio для крупномасштабного трафика.

SOFAMosnСхема архитектуры модуля.

В будущем мы увидим больше пользовательских плоскостей данных и адаптеров Mixer.

Суммировать

Последняя глава представляет собой краткое изложение книги, 2018 год должен быть сервисной сеткой или прокси-войной.

использовать или нет

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

Технологии всегда движутся вперед.После появления контейнеров проблемы с программной средой и распространением были решены, но как управлять распределенными приложениями, снова появилось программное обеспечение для оркестровки контейнеров, развертывание микросервисов решалось программным обеспечением для оркестрации контейнеров, но управление микросервисы слишком слабы, поэтому появляется Service Mesh.Конечно, Service Mesh не всемогущ.Куда он пойдет дальше? Будет ли это бессерверным? Подождем - увидим.

Service Mesh все еще имеет некоторые нерешенные проблемы или относительно слабые функции:

• Для отладки распределенных приложений см.squash
• Топологию службы и диаграмму состояний вы можете найти вkialiиvistio
• Поддержка нескольких арендаторов и мультикластеров
• Мониторинг белого ящика, поддержка APM
• Улучшить инструменты нагрузочного тестирования slow_cooker, fortio, lago и т. д.
• Более продвинутая поддержка резервного пути
• Подключаемые компоненты центра сертификации, поддерживающие внешние центры сертификации

Вот факторы, которые следует учитывать перед внедрением Service Mesh.

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

Эта статья воспроизведена из:Джимми отправляет .IO/posts/он и-о…