Предыстория введение
В эпоху микросервисов сервис-ориентированное мышление постепенно стало основным способом мышления программистов. Однако, поскольку большинство проектов только добавляют услуги вслепую и не управляют ими должным образом, когда возникает проблема в интерфейсе, трудно найти первопричину проблемы в сети вызовов сложных служб, тем самым упуская золотую возможность стоп-лосса.
Появление отслеживания ссылок как раз и призвано решить эту проблему. Он может обнаружить проблему в вызове комплексной службы и четко сообщить новым сотрудникам, за какое звено они отвечают, после того как присоединятся к основной команде.
Кроме того, если интерфейс внезапно займет больше времени, нам не нужно запрашивать одну за другой ситуацию, требующую много времени. Мы можем интуитивно проанализировать узкое место в производительности сервиса, чтобы точно и разумно расширить пропускную способность в случае резкого увеличения трафика.
Отслеживание ссылок
Термин “отслеживание ссылок” был выдвинут в 2010 году, когда Google опубликовал статью dapper, в которой был представлен принцип реализации распределенного отслеживания ссылок, разработанный самой Google, а также рассказывалось о том, как они реализовали прозрачность приложений при низких затратах.
Фактически, dapper вначале была всего лишь независимой системой отслеживания ссылок на звонки, а затем постепенно превратилась в платформу мониторинга, и на основе платформы мониторинга было выведено множество инструментов, таких как раннее предупреждение в реальном времени, защита от перегрузки, запрос индексных данных и т.д.
В дополнение к dapper от Google, есть некоторые другие известные продукты, такие как eagle eye от Alibaba, кошка популярного комментария, Zipkin от Twitter, pinpoint от naver и отечественный скайуокинг с открытым исходным кодом.
Основной принцип реализации
Если вы хотите знать, какая ссылка интерфейса имеет проблемы, вы должны знать, какие службы вызывает интерфейс и порядок вызовов. Если вы свяжете эти службы, это будет выглядеть как цепочка, которую мы называем цепочкой вызовов.
Чтобы реализовать цепочку вызовов, нам нужно создать идентификатор для каждого вызова, а затем упорядочить услуги в соответствии с размером идентификатора, чтобы мы могли более четко видеть порядок вызовов. Давайте пока назовем идентификатор диапазона идентификации.
В реальном сценарии нам нужно знать ситуацию с запросом вызова, поэтому одного испанского недостаточно. Нам нужно сделать уникальную идентификацию для каждого запроса, чтобы мы могли узнать все службы, вызываемые этим запросом, в соответствии с идентификацией, которую мы называем traceid.
Теперь вы можете легко узнать последовательность вызываемых служб в соответствии с испанским языком, но это не может отражать иерархическую взаимосвязь вызовов. Как показано на рисунке ниже, несколько служб могут представлять собой цепочку вызовов уровня за уровнем, или они могут быть вызваны одной и той же службой одновременно.
Поэтому мы должны каждый раз записывать, кто звонил. Мы используем parentid в качестве имени этого идентификатора.
До сих пор мы знали последовательность вызовов и иерархическую взаимосвязь, но после того, как в интерфейсе возникли проблемы, мы все еще не можем найти проблемную ссылку. Если у службы возникают проблемы, выполнение вызываемой службы должно занять много времени. Чтобы рассчитать время, вышеперечисленных трех идентификаций недостаточно, и необходимо добавить метки времени. Отметки времени могут быть более точными до микросекундного уровня.
Это не отнимает много времени, чтобы записать только отметку времени, когда вызов инициирован. Чтобы записать метку времени, когда служба вернется, разницу во времени можно рассчитать от начала до конца. Поскольку возвращенный также записан, пожалуйста, запишите все три вышеуказанных идентификатора, иначе невозможно определить, чья это временная метка.
Хотя мы можем рассчитать общее время от вызова службы до возврата службы, это время включает время выполнения и сетевую задержку службы. Иногда нам нужно различать эти два типа времени, чтобы облегчить целевую оптимизацию. Как рассчитать сетевую задержку? Мы можем разделить процедуры вызова и возврата на следующие четыре события.
- Отправленный клиент для краткости называется CS. Клиент отправляет запрос на вызов серверу.
- Полученный сервер, или сокращенно Sr, означает, что сервер получает запрос на вызов от клиента.
- Отправленный сервер для краткости называется SS, что означает, что сервер завершил обработку и готов вернуть информацию клиенту.
- Полученный клиент называется Cr, что означает, что клиент получает информацию о возврате с сервера.
Если временные метки записаны, когда происходят эти четыре события, можно легко рассчитать затраты времени. Например, Sr минус CS-это сетевая задержка при вызове, SS минус SR-время выполнения службы, Cr минус SS-задержка ответа службы, а Cr минус CS-все время выполнения вызова службы.
Фактически, в блоке span в дополнение к этим параметрам может быть записана некоторая другая информация, такая как имя вызывающей службы, имя вызываемой службы, возвращаемый результат, IP, имя вызывающей службы и т. Д. Наконец, мы объединяем информацию одного и того же идентификатора диапазона в большой блок диапазона, чтобы завершить полную цепочку вызовов. Заинтересованные студенты могут перейти к более глубокому пониманию отслеживания ссылок, я надеюсь, что эта статья поможет вам.