Предыстория введение
В эпоху микросервисов сервис-ориентированное мышление постепенно стало основным способом мышления программистов. Однако, поскольку большинство проектов добавляют службы только вслепую и не управляют ими должным образом, при возникновении проблем с интерфейсом трудно найти первопричину проблемы в сложной сети вызова служб, что приводит к сбою. Прекрасная возможность проиграть.
Появление отслеживания ссылок призвано решить эту проблему. Он может обнаружить проблему в вызове сложной службы и четко сообщить новичкам, за какую часть службы они отвечают, когда присоединяются к фоновой команде.
Кроме того, если время, затрачиваемое на интерфейс, внезапно увеличивается, мы можем интуитивно проанализировать узкое место в производительности сервиса, чтобы мы могли точно и разумно расширить пропускную способность в случае увеличения трафика.
Отслеживание ссылок
Термин “отслеживание ссылок” был предложен в 2010 году, когда Google опубликовал статью Dapper, в которой был представлен принцип самостоятельно разработанного Google распределенного отслеживания ссылок и то, как они реализовали прозрачность приложений при низких затратах.
Фактически, Dapper начинался как независимая система отслеживания вызовов и постепенно превратился в платформу мониторинга. На основе платформы мониторинга было разработано множество инструментов, таких как раннее предупреждение в режиме реального времени, защита от перегрузки, запрос индексных данных и так далее.
В дополнение к dapper от Google, существуют и другие известные продукты, такие как Eagle Eye от Али, CAT для общественного обсуждения, Zipkin от Twitter, pinpoint от Naver (материнская компания известной линейки социального программного обеспечения) и skywalking с открытым исходным кодом.
Основной Принцип Реализации
Если вы хотите знать, по какой ссылке интерфейс имеет проблему, вы должны знать, какие службы вызывает интерфейс и порядок вызова. Если вы свяжете эти службы вместе, это будет выглядеть как цепочка. Мы называем их цепочками вызовов.
Чтобы реализовать цепочку вызовов, нам нужно выполнить идентификацию для каждого вызова, а затем упорядочить услуги в соответствии с размером идентификации, чтобы мы могли более четко видеть порядок вызовов. Давайте назовем идентификатор идентификационного диапазона на данный момент.
В реальном сценарии нам нужно знать ситуацию вызова запроса, поэтому одного испанского недостаточно. Мы должны сделать уникальную идентификацию для каждого запроса, чтобы мы могли идентифицировать все службы, вызываемые этим запросом, в соответствии с идентификацией, которую мы называем traceid.
Теперь, согласно испанскому языку, легко узнать порядок вызываемых служб, но он не может отражать иерархические отношения вызова. Как показано на рисунке ниже, несколько служб могут быть вызваны шаг за шагом или они могут быть вызваны одновременно одной и той же службой.
Поэтому мы должны каждый раз записывать, кто звонил. Мы используем parentid в качестве названия логотипа.
До сих пор мы знали порядок вызова и иерархическую взаимосвязь, но после проблем с интерфейсом мы все еще не можем найти связь проблемы. Если у службы возникает проблема, то вызываемая и выполняемая служба должна занимать много времени. Для того, чтобы рассчитать трудоемкость, вышеперечисленных трех идентификаций недостаточно, но также необходимо добавить временную метку, отнимающую много времени. Штамп может быть более усовершенствован до микросекундного уровня.
Запись только метки времени при инициировании вызова не отнимает много времени. Чтобы записать метку времени, когда служба вернется, разница во времени может быть рассчитана только от начала до конца. Теперь, когда возврат также записан, запишите все вышеперечисленные три удостоверения, иначе вы не сможете отличить, чья метка времени.
Хотя общее время, затраченное от вызова службы до возврата службы, можно рассчитать, это время включает время выполнения службы и сетевую задержку. Иногда нам нужно различать эти два вида времени, чтобы облегчить целенаправленную оптимизацию. Итак, как рассчитать задержку в сети? Мы можем разделить процесс вызова и возврата на следующие четыре события.
- Отправленный клиент сокращенно обозначается как cs. Клиент инициирует запрос вызова на сервер.
- Полученный сервер является сокращением от sr, что означает, что сервер получает запрос на вызов от клиента.
- Отправленный сервер является сокращением от ss, что означает, что сервер завершил обработку и готов вернуть информацию клиенту.
- Полученный клиент сокращенно обозначается как cr, что означает, что клиент получает информацию о возврате с сервера.
Если временные метки записаны, когда происходят эти четыре события, легко рассчитать затраты времени. Например, SR минус CS-это сетевая задержка во время вызова, SS минус SR-время выполнения службы, CR минус SS-задержка ответа службы, а Cr минус CS-время выполнения всего вызова службы.
Фактически, в блоке span, помимо записи этих параметров, мы также можем записать некоторую другую информацию, такую как имя вызывающей службы, имя вызываемой службы, возвращаемый результат, IP-адрес, имя вызывающей службы и т.д. Наконец, мы синтезируем одну и ту же информацию идентификатора диапазона в большой блок диапазона и завершаем полную цепочку вызовов. Заинтересованные студенты могут углубиться в отслеживание ссылок, я надеюсь, что эта статья будет вам полезна.