git地址
https://github.com/a18792721831/studySpringCloud.git

1. 理論

1.1 sleuth是什麼

sleuth是spring cloud的一個組件，主要的功能是在分佈式系統中提供服務鏈路追蹤的解決方案。
簡單來講，就是，展示微服務調用過程。

1.2 sleuth有哪些

常見的鏈路追蹤組件有Google的Dapper，Twitter的Zipkin，以及阿里的Eagleeye

1.3 鏈路追蹤的一些基本概念

1. Span 基本工作單元，每次一個遠程調度任務就會產生一個Span，Span是用一個64位ID唯一標識的。Span包含了摘要、時間戳標記、Span的ID以及進程ID.
1. Trace: 有一系列的Span組成，呈現樹狀結構。在一個微服務請求中，每次一個新的調用都會產生一個Span，這些所有的Span組成了Trace.
1. Annotation:用於記錄一個事件，一些核心的註解用於定義一個請求的開始和結束：
- cs-Client Sent:客戶端發送一個請求，這個註解描述了Span的開始。
- sr-Server Received:服務端獲得請求並準備開始處理。sr-cs的時間差就是網絡請求的時間。
- ss-Server Sent:服務端發送響應，該註解表明請求處理的完成(請求的結果開始返回客戶端)ss-sr的時間差就是服務器處理請求的真正時間
- cr-Client Received:客戶端接收響應，此時整個Span結束，cr-cs的時間差就是整個請求的時間。

1.4 zipkin的組成

zipkin由4部分組成：

Collector：收集器組件，它主要用於處理從外部系統發送過來的跟蹤信息，將這些信息轉換爲 Zipkin 內部處理的 Span 格式，以支持後續的存儲、分析、展示等功能。
Storage：存儲組件，它主要對處理收集器接收到的跟蹤信息，默認會將這些信息存儲在內存中，我們也可以修改此存儲策略，通過使用其他存儲組件將跟蹤信息存儲到數據庫中。
RESTful API：API 組件，它主要用來提供外部訪問接口。比如給客戶端展示跟蹤信息，或是外接系統訪問以實現監控等。
Web UI：UI 組件，基於 API 組件實現的上層應用。通過 UI 組件用戶可以方便而有直觀地查詢和分析跟蹤信息。

2. zipkin 實例

2.1 zipkin server

這裏有一個坑，現在好多書上或者資料上說怎麼怎麼搭建zipkin server工程。
但是你根據數據或者網上的步驟一步一步的完成，但是會出現各種各樣的問題。
這是因爲從19年左右開始，zipkin server已經被集成到jar包裏面了，不需要再搭建了，只需要java -jar啓動就可以了。
首先，zipkin server在搭建的時候都需要依賴zipkin-ui的，也就是說，我們搭建zipkin server只是爲了展示數據。
那麼，數據的展示是穩定的，不需要頻繁的更改，所以zipkin就將zipkin server（依賴的了ui）打成jar包，下載後啓動即可使用。
注意，jar包有jdk版本依賴。

latest傳送門

下載完成後啓動，會出現如下界面

訪問9411端口，可以進入zipkin的界面

這個界面一般不會修改的，所以爲了方便起見，將zipkin在服務器的docker上啓動。

訪問

2.2 zipkin client

zipkin server是負責將數據展示出去，而zipkin client則是收集數據，並將收集到的數據傳給zipkin server，然後完成數據的收集與展示。

2.2.1 創建

2.2.2 配置

最上面配置eureka server的地址
中間是日誌級別
然後指定服務名是zipkin-client-user-service
然後指定zipkin server的地址
最後的spring.sleuth.sampler.percentage是上傳到zipkin server的信息的百分比
1.0 表示將所有的鏈路信息全部上傳。

2.2.3 註解

2.2.4 對外接口 controller

2.2.5 啓動

首先啓動eureka server，然後啓動zipkin client.

然後嘗試請求zipkin client對外開放的接口

然後刷新zipkin server

我有一次地址寫錯了，所以這裏是兩條記錄。
點擊其中一個還可以進去

這個圖怎麼看？
1.系統的展示了微服務請求的時間以及微服務的深度和這次微服務調用的唯一標識traceID
2.表示這次微服務調用的入口以及請求方式restful
3.選擇的請求的span id以及這個span的父親。
4.這個事件
5.記錄了微服務請求的結果以及來源信息。

對於事件還可以展示更多信息，記得我們在理論裏面說事件有4個註解：cs、sr、ss、cr
上面只展示了sr、ss
我們再來看一個成功的

2.3 gateway service

上面我們看了1層深度的微服務的調用，我們之前瞭解過zuul，基於zuul實現微服務的轉發，進而實現多層微服務的調用。

2.3.1 創建

2.3.2 配置

指定端口、eureka server的地址，日誌級別，以及服務名稱zipkin server的地址，上報比例以及zuul轉發路由。

2.3.3 註解

2.3.4 啓動

此時訪問zipkin server

這個時候，搜索結果就有不一樣了
1.表示微服務調用入口微服務
2.表示那些微服務參與，其順序
點擊進去查看詳細信息

這是gateway-service的調用信息，可以看到這是調用入口微服務，因爲其span的父親是空的。

這是user-service的調用詳細信息，也是gateway的下一級調用的服務。因爲user-service的span的父親是gateway的span.
而且這個事件的節點信息就與我們理論中的所有都有了。
當然，下面遮住的是user-service的返回信息。
當然，這是微服務請求調用其他微服務比較少的時間，如果調用的微服務比較多的時候，查看起來就非常的不方便了。幸好，zipkin server還可以以更加簡單明瞭的方式查看微服務調用鏈路

而且這圖還可以動，連接線上的小圓點會指明調用的方向的。

2.4 自定義鏈路數據

在瞭解zuul的時候，我們知道了zuul有4種filter
我們在2.3種的gateway-service中實現post過濾器
在過濾器中我們加入請求者信息(打印一些信息)

注意導入的tracer包是zipkin的包裏的類。
我們通過之前看traceID和SpanID以及tag基本上就能知道其樹狀關係。
接下來重啓訪問

查看zipkin server

很奇怪，爲什麼沒有我們的tag，難道沒有走posty過濾器》？
我們在過濾器裏面打印控制檯輸出

然後重試
但是還是沒有打印我們想要的輸出

仔細查看，重新梳理，發現是因爲沒有將過濾器註冊到spring容器中

重試

打印了。
接下來看看zipkin server

與我們想象中的一樣，至於訪問不到主機名，然後異常的情況就不試了。

3. zipkin 集成 rabbitmq

在我們之前的實例中，zipkin client收集到信息是通過http將數據傳輸到zipkin server的，使用http請求傳輸數據比較性能差，所以zipkin 可以集成rabbitmq進行數據的傳輸。

3.1 rabbitmq的搭建

rabbitmq的搭建參考這裏：
https://blog.csdn.net/a18792721831/article/details/104737243

所以我們是有rabbitmq的

3.2 zipkin server rabbitmq

我們可以通過環境變量讓 Zipkin 從 RabbitMQ 中讀取信息，就像這樣：

RABBIT_ADDRESSES=localhost java -jar zipkin.jar

可配置的環境變量如下表所示：

屬性	環境變量	描述
zipkin.collector.rabbitmq.concurrency	RABBIT_CONCURRENCY	併發消費者數量，默認爲 1
zipkin.collector.rabbitmq.connection-timeout	RABBIT_CONNECTION_TIMEOUT	建立連接時的超時時間，默認爲 60000 毫秒，即 1 分鐘
zipkin.collector.rabbitmq.queue	RABBIT_QUEUE	從中獲取 span 信息的隊列，默認爲 zipkin
zipkin.collector.rabbitmq.uri	RABBIT_URI	符合 RabbitMQ URI 規範的 URI，例如 amqp://user:pass@host:10000/vhost

如果設置了 URI，則以下屬性將被忽略。

屬性	環境變量	描述
zipkin.collector.rabbitmq.addresses	RABBIT_ADDRESSES	用逗號分隔的 RabbitMQ 地址列表，例如 localhost:5672,localhost:5673
zipkin.collector.rabbitmq.password	RABBIT_PASSWORD	連接到 RabbitMQ 時使用的密碼，默認爲 guest
zipkin.collector.rabbitmq.username	RABBIT_USER	連接到 RabbitMQ 時使用的用戶名，默認爲 guest
zipkin.collector.rabbitmq.virtual-host	RABBIT_VIRTUAL_HOST	使用的 RabbitMQ virtual host，默認爲 /
zipkin.collector.rabbitmq.use-ssl	RABBIT_USE_SSL	設置爲 true 則用 SSL 的方式與 RabbitMQ 建立鏈接

但是我們是使用docker啓動的，所以需要使用-e實現指定環境變量
我們重新啓動zipkinserver
我們之前啓動的是簡化版的，只能用於內存和elasticsearch存儲。
如果要使用kafka或者rabbitmq,則需要啓動完整版的。

docker run -d -p 9411:9411 -e "RABBIT_ADDRESSES=10.0.228.93:30672"  --name=zipkin-server openzipkin/zipkin

3.3 zipkin client rabbitmq

3.3.1 創建

3.3.2 配置

我們註釋掉了zipkin的base-url的配置

3.3.3 註解

3.3.4 啓動

首先啓動eureka server,然後啓動zipkin-rabbitmq

4. zipkin 集成oracle

目前zipkin官方沒有實現oracle的集成，只支持mysql，由於我本機沒有安裝mysql，所以這部分不做深入。
詳細介紹見 https://github.com/openzipkin/brave/tree/master/instrumentation
不過，基於zipkin的實現原理，可以用其他方式實現對普遍數據庫的支持，需要自己實現數據的存儲於插入到span中。
詳細實現見 Zipkin原理學習–日誌追蹤 MySQL 執行語句

5. zipkin集成 elasticsearch

5.1 安裝 elasticsearch

我們需要在服務器上的docker環境下安裝elasticsearch。

我們根據docker hub 上給出的教程，安裝elasticsearch

使用的鏡像如下：

訪問驗證

這裏借用一張圖片

很明白。
我們安裝的是單機版，如果需要集羣安裝，參考這裏
https://www.elastic.co/guide/en/elasticsearch/reference/7.5/docker.html

5.2 安裝 kibana

elasticsearch只是存儲了數據，那麼數據的展示是通過kibana展示的。
我們在docker hub上搜索elasticsearch時，kibana會一起展示，這兩個基本上都是一塊使用的。

安裝過程也是一樣的

訪問驗證

kibana啓動比較慢
要做好多的操作才能成功啓動

5.3 zipkin 使用 elasticsearch

基於此，我們需要重新創建一個docker 容器，之前創建的容器是基於rabbitmq的，現在重新創建一個基於elasticsearch的容器

docker run -d -p 9412:9411 -e "STORAGE_TYPE=elasticsearch" -e "ES_HOSTS=10.0.251.180:9200"  --name=zipkin-elsearch openzipkin/zipkin

訪問驗證

5.5 zipkin client 使用 elasticsearch

5.5.1 創建

和普通的一樣，直接創建。
我是這樣理解，也不知道是否正確，大家當做參考就行。

zipkin server集成了elasticsearch,當zipkin client 通過http或者mq將鏈路信息上傳至zipkin server後，zipkin server會將信息存儲到elasticsearch而不是內存中，此時，elasticsearch就擁有了zipkin client的鏈路信息。
zipkin client通過http或者mq將鏈路信息上傳到zipkin server.
elasticsearch接收到zipkin server的信息後，存儲到elasticsearch然後提供給其他組件進行使用
kibana連接elasticsearch，並且根據定義的查詢進行信息的展示。
這裏有一個誤區：
網上或者書上的許多資料，都是基於本地的zipkin server進行集成elasticsearch的。很容易給人一種錯覺：zipkin client直接將鏈路信息上傳給elasticsearch的。實際上，zipkin client也可以直接將鏈路信息上傳給elasticsearch，只不過需要進行手動的上傳。
而將信息上傳給zipkin server，且指定zipkin server的存儲方式後，這些就都不需要了，zipkin server會將這些都處理完成的。
(這一塊花費了我大概4小時才意識到這個思想誤區)