Устойчивые связи

  • Статья

Совет

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

Скачать в формате PDF

Cloud Native .NET apps for Azure eBook cover thumbnail.

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

  • Внепроцессное сетевое взаимодействие. Каждая микрослужба взаимодействует по сетевому протоколу, который представляет перегрузку сети, задержку и временные ошибки.

  • Обнаружение служб. Как микрослужбы обнаруживают и взаимодействуют друг с другом при работе на кластере компьютеров с собственными IP-адресами и портами?

  • Устойчивость. Как управлять короткими сбоями и поддерживать стабильность системы?

  • Балансировка нагрузки. Как входящий трафик распределяется по нескольким экземплярам микрослужбы?

  • Безопасность. Как применяются такие проблемы безопасности, как шифрование на уровне транспорта и управление сертификатами?

  • Распределенный мониторинг. — Как сопоставлять и отслеживать трассировку и мониторинг для одного запроса в нескольких микрослужбах?

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

Сетка служб

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

Service mesh with a side car

Рис. 6-7. Сетка обслуживания с боковой машиной

На предыдущем рисунке обратите внимание, как прокси-сервер перехватывает и управляет обменом данными между микрослужбами и кластером.

Сетка службы логически разделена на два разных компонента: плоскость данных и плоскость управления. На рисунке 6–8 показаны эти компоненты и их обязанности.

Service mesh control and data plane

Рис. 6-8. Управление сеткой службы и плоскость данных

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

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

Istio и Envoy

Хотя в настоящее время существуют несколько вариантов сетки служб, Istio является наиболее популярным во время написания этой статьи. Istio — это совместное предприятие ibm, Google и Lyft. Это предложение с открытым кодом, которое можно интегрировать в новое или существующее распределенное приложение. Технология обеспечивает согласованное и полное решение для защиты, подключения и мониторинга микрослужб. Она обладает следующими возможностями:

  • Безопасное взаимодействие между службами в кластере с надежной проверкой подлинности и авторизацией на основе удостоверений.
  • Автоматическая балансировка нагрузки для HTTP, gRPC, WebSocket и TCP-трафика.
  • Точное управление поведением трафика с расширенными правилами маршрутизации, повторными попытками, отработкой отказа и внедрением ошибок.
  • Подключаемый уровень политики и API конфигурации, поддерживающий элементы управления доступом, ограничения скорости и квоты.
  • Автоматические метрики, журналы и трассировки для всего трафика в кластере, включая входящий трафик кластера и исходящий трафик.

Ключевым компонентом реализации Istio является прокси-служба с именем прокси-сервера Envoy. Он работает вместе с каждой службой и предоставляет платформу, не зависящая от платформы, для следующих функций:

  • Динамическое обнаружение служб.
  • Балансировка нагрузки.
  • Завершение TLS.
  • Прокси-серверы HTTP и gRPC.
  • Устойчивость средства разбиения цепи.
  • Работоспособности проверка.
  • Последовательное обновление с помощью канареарных развертываний.

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

Интеграция с Служба Azure Kubernetes

Облако Azure принимает Istio и обеспечивает прямую поддержку в Служба Azure Kubernetes. Следующие ссылки помогут вам приступить к работе:

Ссылки

НазадДалее