эта статьяgithub/JavaMapОн был включен, есть карта расширенных технических знаний Java-программистов и моя серия статей, добро пожаловать в Star.
Зачем распределенным системам нужно отслеживание ссылок?
С быстрым расширением интернет-бизнеса архитектура программного обеспечения становится все более сложной.Чтобы адаптироваться к высоким одновременным запросам большого количества пользователей, все больше и больше компонентов в системе начали распределяться, такие как разделение единую архитектуру в микросервисы и изменение внутрисервисных кешей.Для распределенного кэширования обмен данными сервисных компонентов становится распределенными сообщениями, и эти компоненты вместе образуют сложную распределенную сеть.
Предположим, что сейчас в системе развернуты тысячи сервисов, и пользователь загружает и загружает одну коробку вина Moutai на основной интерфейс через браузер, в результате чего система сообщает пользователю: В системе внутренняя ошибка , и считается, что пользователь очень подавлен.
Оператор передает проблему разработчику, чтобы найти проблему.Разработчик знает только, что есть исключение, но какой микросервис вызвал исключение, нужно проверять сервис за сервисом.
Разработчикам крайне неэффективно проверять по одному по логам, есть ли решение получше?Ответ заключается в том, чтобы ввести систему отслеживания ссылок.
Что такое отслеживание ссылок?
Отслеживание распределенных ссылок предназначено для восстановления распределенного запроса на ссылку вызова и централизованного отображения ситуации вызова распределенного запроса, например, затрат времени на каждом сервисном узле, на какой машине достигает запрос, и информации о каждом сервисный узел статус запроса и т.д.
Основные функции отслеживания ссылок:
- Быстрое обнаружение неисправности: Вы можете быстро найти информацию об ошибках через цепочку вызовов в сочетании с бизнес-журналом.
- Визуализация производительности ссылок: Отнимающие много времени ссылки и сервисные зависимости каждого этапа могут отображаться через визуальный интерфейс.
- анализ ссылок: Путь поведения пользователя может быть получен путем анализа затрат времени на связь и зависимостей службы.Сводный анализ применяется во многих бизнес-сценариях.
Основы отслеживания ссылок
Система отслеживания ссылок (вероятно) была впервые опубликована компанией Goggle, статья «Dapper, крупномасштабная инфраструктура отслеживания распределенных систем» широко известна всем, поэтому, если у вас есть черное оружие, не прячьте его и опубликуйте.
В этой знаменитой статье в основном описаны основные принципы и ключевые технические моменты системы отслеживания ссылок Dapper. Затем выберите несколько ключевых технических моментов, чтобы представить их вам подробно.
Trace
Значение Trace относительно интуитивно понятно, то есть ссылка, которая относится к пути, по которому запрос проходит через все сервисы, что может быть представлено следующей древовидной графикой.
Полная ссылка на рисунке: chrome -> служба A -> служба B -> служба C -> служба D -> служба E -> служба C -> служба A -> chrome. Локальные ссылки между службами составляют полную ссылку, и каждая локальная ссылка идентифицируется уникальным в глобальном масштабе идентификатором трассировки.
Span
На приведенном выше рисунке видно, что запрос проходит через службу A, и служба A вызывает службу B и службу C одновременно, но какая служба B или служба C вызывается первой? По картинке сложно сказать, порядок известен только по исходному коду.
Чтобы выразить эти отношения родитель-потомок, вводится понятие Span.
На том же уровне родительский идентификатор тот же, но идентификатор интервала отличается. Идентификатор интервала указывает порядок запросов от малого к большому. Из рисунка ниже видно, что служба A сначала вызывает службу B, а затем вызывает C .
Верхний и нижний уровни представляют отношения вызова.Как показано на рисунке ниже, идентификатор диапазона службы C равен 2, а идентификатор родителя службы D равен 2, что означает, что служба C и служба D образуют связь родитель-потомок. Очевидно, сервис C вызывает сервис D.
Сводка. Заранее скрывая точки в журнале, находя журналы с одинаковым идентификатором трассировки и добавляя родительский идентификатор и идентификатор диапазона, можно последовательно соединить полную цепочку вызовов запросов.
Annotations
Dapper также определяет концепцию аннотации, которая используется для определяемых пользователем событий, чтобы помочь в обнаружении проблем.
Проходятдовольно частоСодержит четыре аннотации: cs: Client Start, указывающий, что клиент инициирует запрос; sr: ServerReceived, указывающий, что сервер получил запрос; ss: отправка сервера, указывающая, что сервер завершает обработку и отправляет результат клиенту; cr: ClientReceived, указывающий, что клиент получает информацию, возвращенную сервером;
На приведенном выше рисунке показан процесс запроса и ответа, а четыре точки соответствуют четырем событиям Annotation.
На следующем рисунке показан полный процесс вызова сервера из клиента. Если вы хотите рассчитать время, затрачиваемое на вызов, вам нужно всего лишь вычесть момент времени, полученный клиентом, из момента времени, когда клиент запустился, что соответствует T4-T1 на временной шкале на рисунке. Если вы хотите рассчитать время, необходимое клиенту для отправки в сеть, то есть T2 - T1 на временной шкале на рисунке, и другие можно рассчитать аналогично.
Внутриполосные и внеполосные данные
Восстановление информации о ссылке зависит отвнутриполосныйа такжеиз группыдва вида данных.
Внеполосные данные — это события, генерируемые каждым узлом, такие как cs и ss.Эти данные могут генерироваться узлами независимо, и о них необходимо централизованно сообщать на сторону хранилища. При использовании внеполосных данных на стороне хранилища можно проанализировать дополнительные сведения о каналах.
Внутриполосные данные, такие как traceid, spanid и parentid, используются для идентификации трассы, промежутка и положения промежутка в трассе.Эти данные необходимо передавать от начальной точки ссылки к конечной точке. Благодаря внутриполосной передаче данных все процессы канала могут быть объединены в цепочку.
выборка
Поскольку каждый запрос генерирует ссылку, чтобы снизить потребление производительности и не тратить ресурсы хранилища, dapper не сообщает все данные диапазона, а использует выборку. Например, на доступ к системе поступает 1000 запросов в секунду, если частота дискретизации установлена на 1/1000, на сторону хранилища будет отправлен только один запрос.
Адаптивно регулируя частоту дискретизации в конце сбора данных и контролируя количество отображаемых диапазонов, можно найти узкие места в производительности и эффективно снизить потери производительности.
место хранения
После того, как данные диапазона в ссылке будут собраны и переданы в отчет, они будут храниться в одном месте.Dapper использует хранилище данных BigTable, а обычно используемое хранилище — ElasticSearch, HBase, In-memory DB и т. д.
Система отслеживания ссылок, широко используемая в отрасли
После того, как документ Google Dapper был опубликован, многие компании представили свои собственные решения, основанные на основных принципах отслеживания ссылок, такие как Zipkin в Twitter, Jaeger в Uber, pinpoint, прыжки по небу с открытым исходным кодом в Apache, а также отечественные продукты, такие как Ali's Eagle Eye, Mtrace от United States Group, Didi Trace, Sina Watchman, Jingdong's Hydra, но они в основном не имеют открытого исходного кода в Китае.
Чтобы облегчить совместимость и взаимодействие различных систем, организация OpenTracing разработала ряд стандартов, направленных на обеспечение унифицированного интерфейса для каждой системы.
Давайте сравним несколько компонентов с открытым исходным кодом, чтобы облегчить будущий технический выбор.
Прикрепите адреса основных компонентов с открытым исходным кодом:
- молния:zipkin.io/
- Джагер:www.jaegertracing.io/
- Точный:GitHub.com/pinpoint-AP…
- SkyWalking:skywalking.apache.org/
Далее мы представим базовую реализацию Zipkin.
Реализация Zipkin системы отслеживания распределенных ссылок
Zipkin — проект Twitter с открытым исходным кодом, реализованный на базе Google Dapper и посвященный сбору временных данных сервисов для решения проблемы задержки в микросервисной архитектуре, включая сбор, хранение, поиск и представление данных.
Базовая архитектура Зипкина
Во время работы службы будет сгенерировано много информации о ссылках, и место, где генерируются данные, можно назвать Reporter. Информация о ссылке отправляется сборщику Zipkin с помощью различных методов передачи, таких как HTTP, RPC, очередь сообщений kafka и т. д., и информация о ссылке окончательно сохраняется в памяти после обработки Zipkin. Эксплуатационный и обслуживающий персонал может запрашивать информацию о цепочке вызовов, вызывая интерфейс через интерфейс пользовательского интерфейса.
Основные компоненты Zipkin
Zipkin состоит из четырех основных компонентов.
(1) коллектор
Как только поток коллекции Collector получит данные отслеживания ссылок, Zipkin проверит, сохранит и проиндексирует их, а также вызовет интерфейс хранилища, чтобы сохранить данные для поиска.
(2) Хранение
Zipkin Storage изначально создавался для хранения данных в Cassandra, потому что Cassandra масштабируема, имеет гибкие схемы и активно используется в Twitter. В дополнение к Cassandra также поддерживаются хранилища ElasticSearch и MySQL, а в будущем могут быть предоставлены сторонние расширения.
(3) Служба запросов
После того, как данные отслеживания ссылок сохранены и проиндексированы, webui может вызвать службу запросов, чтобы запросить любые данные, чтобы помочь оперативному и обслуживающему персоналу быстро найти онлайн-проблемы. Служба запросов предоставляет простой json API для поиска и извлечения данных.
(4) Веб-интерфейс
Zipkin предоставляет веб-интерфейс для основных запросов и поиска, а персонал по эксплуатации и техническому обслуживанию может быстро выявлять онлайн-проблемы на основе конкретной информации о цепочке вызовов.
Суммировать
- Отслеживание распределенных ссылок заключается в восстановлении каждого распределенного запроса в ссылку вызова.
- Основные понятия трассировки ссылок: трассировка, интервал, аннотация, внутриполосные и внеполосные данные, выборка, хранение.
- Компоненты с открытым исходным кодом, обычно используемые в отрасли, разработаны на основе документа Google Dapper;
- Основные компоненты Zipkin: сборщик, хранилище, служба запросов, веб-интерфейс.
-- END --
Ежедневные лайки: Здравствуйте, техники, сначала ставьте лайки, а потом смотрите, чтобы выработать привычку. Ваши лайки - движущая сила для меня на пути вперед, а следующий выпуск будет более захватывающим.
Введение: Блогер окончил Хуачжунский университет науки и технологий со степенью магистра, он программист со страстью к технологиям и страстью к жизни. В последние несколько лет он бродил по Huawei, NetEase и Baidu и имеет многолетний опыт разработки.
Публичный номер поиска в Wechat [Архитектор, который любит смеяться], у меня есть технологии и истории, которые ждут вас.
Статья постоянно обновляется вgithub/JavaMapВы можете увидеть мою заархивированную серию статей в , с опытом интервью и техническими галантерейными товарами, добро пожаловать в Star.