Отслеживание ссылок сервиса Sleuth+Zipkin на сервис Sleuth+Zipkin весной 25 ТЦ Cloud of Guli

зачем использовать

Распределенная система огромна и сложна, содержит множество сервисов, а сеть связи вызовов также очень сложна.

1. Если какие-либо ошибки возникают после запуска службы, будет сложно найти исключение ошибки.
2. Запрос может вызывать много ссылок, и нам нужно знать, какая из них неверна.

В конце концов, мы надеемся получить систему отслеживания ссылок, от каждого запроса до его конечного завершения, сколько среди них вызывается микросервисов, в том числе сколько времени занимает каждый вызов сервиса.

Только когда система отслеживания ссылок будет окончательно объединена, можно будет понизить предохранитель.Благодаря системе отслеживания ссылок обнаружено, что определенный сервис работает особенно медленно, но все еще работает нормально, поэтому мы напрямую понизим его, чтобы предотвратить лавину. всей нашей системы вопрос.

Микросервисная архитектура — это распределенная архитектура, которая разделяет сервисные единицы по бизнесу, а распределенная система часто имеет много сервисных единиц. Из-за большого количества сервисных единиц и сложности бизнеса трудно локализовать ошибки и исключения, если они происходят.
В основном это выражается в том, что для запроса может потребоваться вызов многих служб, а сложность вызова внутренних служб затрудняет поиск проблемы.
Поэтому в микросервисной архитектуре должно быть реализовано распределенное отслеживание ссылок, чтобы отслеживать, какие сервисы участвуют в запросе и каков порядок участия, чтобы шаги каждого запроса были четко видны, и в случае возникновения проблемы он мог быть быстро обнаруженным.

Поэтому очень важно построить систему отслеживания служебных ссылок в распределенной системе.

Компоненты отслеживания ссылок включают Dapper от Google, Zipkin от Twitter и Eagleeye от Ali (Eagle Eye) и т. д., которые являются отличными компонентами с открытым исходным кодом для отслеживания ссылок.

Основная терминология и процесс

• Span (промежуток): базовая единица работы. Отправка задачи удаленного планирования генерирует Span. Span однозначно идентифицируется 64-битным идентификатором. Трассировка однозначно идентифицируется другим 64-битным идентификатором. как сводка, событие с отметкой времени, идентификатор диапазона и идентификатор выполнения.

• Трассировка (отслеживание): древовидная структура, состоящая из серии Span. Запрос API-интерфейса микросервисной системы. Этот API-интерфейс должен вызывать несколько микросервисов. При вызове каждого микросервиса будет создан новый Span. Все Span, сгенерированные этим запросом, образуют эту трассировку.

• Аннотация: используется для записи события во времени, некоторые основные аннотации используются для определения начала и конца запроса. Эти аннотации включают следующее:

  • cs — Client Sent — клиент отправляет запрос, эта аннотация описывает начало Span
  • sr - Server Received - Сервер получил запрос и готов начать его обработку.Если из его sr вычесть временную метку cs, можно получить время передачи по сети.
  • ss — Server Sent (сервер отправляет ответ) — эта аннотация указывает на завершение обработки запроса (когда запрос возвращается к клиенту), если отметка времени ss минус отметка времени sr, то время запроса сервера может быть полученный.
  • cr — Client Received (клиент получает ответ) — конец Span в это время, если отметка времени cr минус отметка времени cs, можно получить время, затраченное на весь запрос.

1. Браузер отправляет запрос в службу1, генерирует диапазон A, записывает идентификатор трассировки, идентификатор диапазона и идентифицирует полученный сервер (представляющий, когда запрос был получен), а служба1 обрабатывает его.
   Поскольку запрос отправляется браузером, Client Sent не будет записан.

2. Затем удаленно вызовите service2, чтобы отправить запрос, и будет сгенерирован spanB для записи отправленного клиента (время отправки запроса) и полученного сервером.Вычитание двух — это время передачи, которое мы можем.

3. После завершения обработки service2 одновременно генерируется и отправляется spanC (который представляет следующий запрос), а также два разных span, SpanD и spanF, которые записывают отправленный клиент соответственно.

4. service3 получает запись запроса Server Received и генерирует spanE после завершения обработки, но мы больше не вызываем удаленный метод, и spanE можно отбросить.
   После того, как служба service3 завершит обработку spanD, запишите serverSent, а вычитание serverSent и serverRecived — это время, в течение которого служба 3 должна обработать запрос.

5. В возвращаемом ответе запишите Client Received, то есть время ответа, полученное клиентом и service2.

6. Ссылку в это время можно проследить, spanA — spanB — spanD (spanC не считается, это просто span, сгенерированный бизнес-обработкой), а затем spanD возвращает ответ.

7. Ссылка службы4 такая же, как и у службы3.

Чтобы определить, является ли это сбоем сети или сбоем службы, возьмем в качестве примера spanF.

• serverSent минус serverRecived Если время слишком большое, то проблема с сервисом
• Если serverRecived минус clientSent занимает слишком много времени, то есть проблема с сетью

Время передачи в середине ссылки и время обработки каждой службы помечаются тегами, поэтому мы все можем получить эти данные.

Теги имеют отношение родитель-потомок, и родительский тег каждого тега более низкого уровня является тегом более высокого уровня.
После установления родительско-дочерних отношений можно нарисовать древовидную структуру всей цепочки вызовов, включая ее структуру ссылок.

springboot объединяет Sleuth и zipkin

# 服务提供者与消费者导入依赖
# 所以我们直接把依赖导入到common模块中
<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>

Благодаря информации мониторинга цепочки вызовов, сгенерированной Sleuth, вы можете узнать связи вызовов между микросервисами, но информация мониторинга выводится только
на консоль и неудобна для просмотра. Нам понадобится графический инструмент — zipkin. Zipkin — это распределенная система отслеживания Twitter с открытым исходным кодом
, которая в основном используется для сбора данных временных рядов системы, чтобы отслеживать проблемы с вызовами в системе.

Zipkin имеет интерфейс пользовательского интерфейса и связанные с ним операции API, а также может хранить данные в одном месте и одновременно собирать данные.

Zipkin может собирать данные нашего сервиса, и клиент нашего сервиса будет сообщать ему данные, поэтому нам нужно импортировать зависимость zipkin, и наш клиент может сообщать данные, и сообщаемые данные будут собираться в zipkin сервер для визуализации.

По умолчанию Zipkin хранит данные мониторинга в памяти, если Zipkin зависнет или перезапустится, данные мониторинга будут потеряны. Поэтому, если вы хотите создать Zipkin, доступный для производства, вам необходимо реализовать постоянство данных мониторинга.
Для обеспечения постоянства данных естественно хранить данные в базе данных. zipkin поддерживает хранение данных в

• память (по умолчанию)
• MySQL
• Elasticsearch (мы используем это)
• Кассандра

 docker run -d -p 9411:9411 openzipkin/zipkin

# 启动zipkin，将数据保存至es中
docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200
openzipkin/zipkin-dependencies

# 也是导入到common中 
# zipkin中已经导入了sleuth，所以之前的sleuth依赖可以去掉
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

приложение.свойства

spring.cache.type=redis
spring.cache.redis.time-to-live=3600000
spring.cache.redis.use-key-prefix=true
spring.cache.redis.cache-null-values=true


gulimall.thread.core-size=20
gulimall.thread.keep-alive-time=10
gulimall.thread.max-size=200

spring.session.store-type=redis


# actuator 暴露所有资源
management.endpoints.web.exposure.include=*
# sentinel dashboard 地址
spring.cloud.sentinel.transport.dashboard=localhost:8333
# 限流成功指定返回的内容类型
spring.cloud.sentinel.scg.fallback.content-type=application/json
spring.cloud.sentinel.scg.fallback.response-status=400

# 开启feign的sentinel远程保护
feign.sentinel.enabled=true

# 开启debug日志
logging.level.org.springframework.cloud.openfeign=debug
logging.level.org.springframework.cloud.sleuth=debug

# zipkin服务器地址
spring.zipkin.base-url=http://192.168.56.10:9411/
# 关闭服务发现，否则spring cloud会把zipkin的url当作服务名称
spring.zipkin.discovery-client-enabled=false
# zipkin以web http的方式发送数据
spring.zipkin.sender.type=web
# 采样器，默认为0.1，即百分之十，只采样百分之十的请求数据
spring.sleuth.sampler.probability=1

Потребности предприятий реалистичны, потому что мы должны решать реальные проблемы, но образование не должно ориентироваться на реальные потребности, а должно быть ориентировано на будущее.

https://baijiahao.baidu.com/s?id=1760664270073856317&wfr=spider&for=pc
Зажигайте фейерверки и вместе творите будущее — выступление Жэнь Чжэнфэя на симпозиуме по присуждению награды «Фейерверки» «Раскрытие проблем»
Рен Чжэнфэй