Шаблоны микросервисов с посредником-посредником, часть III: распределенная трассировка

Этот блог является частью серии статей, в которых подробно рассматриваются Envoy Proxy и Istio.io, а также рассказывается о том, как он обеспечивает более элегантный способ подключения и управления микросервисами. Следуйте за мной @christianposta, чтобы не отставать от этих выпусков поста в блоге.

• Что такое Envoy Proxy , как он работает?
• Как реализовать некоторые из базовых шаблонов с Envoy Proxy ?
• Как Istio Mesh вписывается в эту картину
• Как работает Istio Mesh и как он обеспечивает функциональность высшего порядка в кластерах с Envoy
• Как работает Istio Mesh auth

Вот идея для следующих нескольких частей (обновим ссылки по мере их публикации):

• Автоматические выключатели (часть I)
• Повторные попытки / Тайм-ауты (Часть II)
• Распределенная трассировка (часть III)
• Коллекция метрик с Прометеем (Часть IV)
• Обнаружение услуг (часть V)
• Следующие части будут касаться большей части функциональности на стороне клиента (Request Shadowing, TLS и т. Д.), Просто не уверен, какие части будут, какие еще ?

Часть III — Распределенная трассировка с доверенным лицом

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

Эта демонстрация состоит из клиента и сервиса. Клиент — это Java-приложение http, которое имитирует выполнение http-вызовов к «восходящему» сервису (обратите внимание, мы используем терминологию Envoys здесь и выполняем это репо ). Клиент упакован в образ Docker с именем docker.io/ceposta/http-envoy-client:latest . Наряду с http-клиентом Java-приложение является экземпляром Envoy Proxy . В этой модели развертывания Envoy разворачивается как сопутствующая служба вместе со службой (в данном случае клиентом http). Когда http-клиент совершает исходящие звонки (в «восходящий» сервис), все звонки проходят через коляску Envoy Proxy. Затем Envoy добавляет заголовки трассировки, которые отправляются вместе с сервисными вызовами и отправляются Zipkin (или вашему провайдеру трассировки … Envoy в настоящее время поддерживает Zipkin и Lightstep )

Сервис «upstream» для этих примеров — httpbin.org . httpbin.org позволяет нам легко моделировать поведение службы HTTP. Это круто, так что проверь, если ты не видел.

Демо-версия tracing имеет собственный envoy.json конфигурации envoy.json . Я определенно рекомендую взглянуть на справочную документацию для каждого раздела файла конфигурации, чтобы помочь понять полную конфигурацию. Хорошие люди из datawire.io также собрали хорошее введение в Envoy и его конфигурацию, которую вы также должны проверить.

Запуск демо трассировки

Для демонстрации трассировки мы будем настраивать нашего посланника со следующим существенным конфигом ( см. Полный конфиг для остальной части контекста :

Здесь мы настраиваем наш драйвер трассировки и кластер трассировки. В этом случае, чтобы запустить эту демонстрацию, нам нужно запустить сервер Zipkin:

Сначала остановите все существующие демонстрации:

Затем загрузите наш zipkin сервер:

Это выставит zipkin на порты 9411 . Если вы используете minikube или что-то подобное для запуска этих демонстраций, вы можете напрямую экспортировать порт minikube на ваш хост, например:

Проверьте эту команду, чтобы перенести ее на то, каким может быть ваш хост докера. После того, как Zipkin запущен и запущен, перейдите к службе (т. Е. На мини-кубе после переадресации порта это будет просто http: // localhost: 9411). Вы должны увидеть Zipkin:

Теперь, когда у нас есть наш zipkin-сервер, давайте запустим демо-версию tracing :

Давайте отправим трафик через нашего клиента:

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

Теперь, если мы пойдем на наш сервер Zipkin, мы должны увидеть один диапазон / трассу для этого вызова (обратите внимание, вам, возможно, придется настроить время запуска / остановки в фильтре zipkin:

Здесь мы имеем единственную трассировку с одним диапазоном (что мы и ожидаем, поскольку наш демонстрационный клиент, в котором есть Envoy, напрямую общается с внешним сервисом, у которого нет Envoy… если в восходящем сервисе также был Envoy с включенным zipkin, мы ‘ буду видеть полный набор промежутков между сервисами)

Если мы щелкнем в промежутке, чтобы увидеть больше деталей, мы увидим что-то вроде этого:

Запись

Обратите внимание, что каждый сервис в вашей сервисной архитектуре должен иметь развернутый Envoy и участвовать в распределенной трассировке. Прелесть этого подхода в том, что отслеживание происходит вне приложения. Тем не менее, для правильного распространения контекста, разработчик приложения несет ответственность за правильное распространение правильных заголовков для правильной корреляции различных диапазонов. Проверьте zipkin для более подробной информации, но как минимум вы хотите распространить эти заголовки (как видно из выше):

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• x-ot-span-context

Серии

Пожалуйста, следите за обновлениями ! Часть IV должна скоро приземлиться!