Введение
В эпоху микросервисов сервисно-ориентированное мышление постепенно становится основным способом мышления программистов, однако, поскольку большинство проектов просто слепо наращивают сервисы и не управляют ими должным образом, когда возникает проблема с интерфейсом, ее трудно решить сложные проблемы.Основная причина проблемы была найдена в сети сервисных обращений, таким образом упущена прекрасная возможность остановить убыток.
Появление отслеживания ссылок призвано решить эту проблему: оно может обнаруживать проблемы в сложных вызовах службы, а после того, как новички присоединяются к фоновой команде, они могут четко знать, за какое звено службы они отвечают.
Кроме того, если потребление времени интерфейса внезапно увеличивается, то больше не нужно запрашивать время потребления каждого сервиса, мы можем интуитивно проанализировать узкое место в производительности сервиса, что удобно для точного и разумного расширения в случае всплеск трафика.
отслеживание ссылок
Термин «отслеживание ссылок» был придуман в 2010 году, когда Google выпустил документ Dapper, в котором был представлен принцип реализации собственной разработки Google для отслеживания распределенных ссылок и то, как они добились прозрачности для приложений при низких затратах.
По сути, Dapper вначале была просто независимой системой отслеживания звонков, а затем постепенно превратилась в платформу мониторинга.На основе платформы мониторинга было разработано множество инструментов, таких как предупреждение в реальном времени, защита от перегрузки и индексирование данных. запрос.
Помимо dapper от Google, есть и другие известные продукты, такие как Eagle Eye от Ali, CAT от Dianping, Zipkin от Twitter, pinpoint от Naver (материнская компания известного социального программного обеспечения LINE) и отечественный open source skywalking.
Основной принцип реализации
Если вы хотите знать, какое звено интерфейса имеет проблему, вы должны знать, какие службы вызываются интерфейсом и порядком вызовов.Если эти службы соединены вместе, это выглядит как цепочка, и мы называем это вызовом. цепь.
Если вы хотите реализовать цепочку вызовов, вам необходимо сделать метку для каждого звонка, а затем расположить услуги по размеру метки, чтобы последовательность звонков была видна более четко. в настоящее время.
В реальном сценарии нам нужно знать ситуацию вызова запроса, поэтому одного спанида недостаточно, мы должны сделать уникальный идентификатор для каждого запроса, чтобы мы могли узнать все сервисы, вызываемые этим запросом в соответствии с идентификатор, и этот идентификатор называется traceid.
Теперь, согласно spanid, вы можете легко узнать порядок вызываемых услуг, но он не может отражать иерархическую взаимосвязь вызовов.Как показано на рисунке ниже, несколько сервисов могут представлять собой цепочку вызовов шаг за шагом, или они могут вызываться одной и той же службой в одно и то же время.
Так что это должно быть записано каждый раз, когда кто звонил, мы используем parentid в качестве имени этой идентификации.
До сих пор я уже знаю последовательность вызовов и иерархические отношения, но после того, как интерфейс имеет проблемы, я все еще не могу найти проблемную ссылку.Если есть проблема со службой, служба, вызываемая и выполняемая, должна занимать много времени. , Если вы хотите рассчитать стоимость Когда вышеперечисленных трех идентификаторов недостаточно, необходимо добавить временную метку.Временная метка может быть более точной и с точностью до микросекунд.
Запись временной метки только при инициации вызова не занимает много времени. Необходимо записать временную метку, когда услуга возвращается. Разницу во времени можно рассчитать, только если есть начало и конец. также запоминается один, запишите все три вышеуказанных идентификатора, иначе не могу сказать, чья это временная метка.
Хотя общее время от вызова службы до возврата службы можно рассчитать, это время включает время выполнения службы и задержку в сети.Иногда нам необходимо различать эти два типа времени, чтобы упростить целевую оптимизацию. Так как же рассчитать сетевую задержку? Мы можем разделить процесс звонка и возврата на следующие четыре события.
-
Client Sent упоминается как cs, и клиент инициирует запрос вызова на сервер.
-
Server Received сокращенно обозначается как sr, что означает, что сервер получает запрос на вызов от клиента.
-
Server Sent обозначается аббревиатурой ss, что означает, что сервер завершил обработку и готов вернуть информацию клиенту.
-
Сообщение Client Received обозначается как cr, что означает, что клиент получает возвращаемую информацию с сервера.
Если временные метки записываются при возникновении этих четырех событий, можно легко рассчитать затраты времени, например, sr минус cs — задержка в сети во время вызова, ss минус sr — время выполнения услуги, а cr минус ss. — ответ службы.Задержка, cr минус cs, — это время выполнения всего вызова службы.
На самом деле, помимо записи этих параметров, блок span также может записывать некоторую другую информацию, такую как имя вызывающей службы, имя вызываемой службы, возвращаемый результат, IP, имя вызывающей службы и т. д. Наконец , ставим тот же спанид. Информация синтезируется в большой блок спана, и завершается полная цепочка вызовов. Заинтересованные студенты могут узнать больше об отслеживании ссылок, надеюсь, эта статья будет вам полезна.