如何通過Zipkin或SKYwalking實現鏈路追蹤

前言

微服務架構將原先業務鏈條中的各個環節（節點或過程），如用戶、產品、訂單、支付拆分實現成獨立的服務運行，一定程度上提高了系統的容錯能力，例如支付服務失敗時，用戶依然可以通過產品及訂單服務，達到查看訂單和瀏覽產品的目的。隨著微服務應用開發框架（如springboot）和容器技術（如K8）越來越成熟，微服務的開發和運維趨于標準化。這些都是微服務的愈發流行的原因。同時，隨著業務復雜度的提高，越來越多的微服務被開發和集成進來，服務管理的重要性不言而喻。本文以服務調用的鏈路管理為題，淺談微服務治理中鏈路管理的主流技術如何實踐。

鏈路管理，主要指記錄服務的調用鏈路，通常用來定位不合理的服務設計，如鏈路過長帶來的服務耗時問題、鏈路過長帶來的服務穩定性風險、循環依賴等。鏈路管理，需要考慮哪些方面的問題，如何實現？

1. 首先，需要知道有哪些服務以及他們的服務狀態（服務注冊和發現機制），這個目前可以直接通過spring cloud的Eureka實現，當然也可以通過dubbo+zookeeper實現；
2. 有了服務清單之后，我們需要在每個服務調用的地方攔截并記錄，記錄調用堆棧，從發起服務到鏈尾。這一步自己實現起來有較多的工作，譬如統一服務調用規則、AOP攔截、調用鏈數據結構定義、調用信息采集發送及存儲等。
3. 最后，是鏈路數據的采集、存儲、發送以及最終的圖形化展示。

有了這個思路之后，我們再來看目前主流的鏈路解決方案，Twitter的Zipkin，以及Apache的在孵化項目SKYwalking。當然還有些比較熱的方案，如韓國的開源項目Pinpoint和美團的CAT。這些方案從實現技術上大致可分為兩個派系，攔截派，字節碼增強派。攔截派做法通過代理類攔截請求，將鏈路信息發送給服務器，Zipkin和CAT都屬于這種類型，不過CAT需要代碼侵入，即代碼中增加埋點，而Zipkin直接通過SpringCloud的Sleuth無縫對接SpringBoot的微服務。字節碼增強技術，通過JVMTI接口提供的javaagent（區別于JDK動態代理和CGLIB代理），利用字節碼操作技術（ASM），在類加載并實例化之前對class進行轉換，之后運行中將信息采集并發送給代理服務器(探針)，如sk*walking的Agent服務。關于兩種方式的比較，小結如下：

Zipkin實踐

Zipkin 分為兩端，Zipkin 服務端和Zipkin 客戶端，客戶端也就是微服務的應用。客戶端配置服務端的 URL 地址，一旦發生服務間的調用的時候，會被配置在微服務里面的 Sleuth 的監聽器監聽，并生成相應的 Trace 和 Span 信息發送給服務端。發送的方式主要有兩種，一種是 HTTP 報文的方式，另一種是消息總線的方式如 RabbitMQ。

不論哪種方式，我們都需要：一個 Eureka 服務注冊中心，先看下Zipkin運行架構：

左側應用服務，同時也是Zipkin-clinet，Eureka-client， 中間是依賴，包括Zipkin-server和Eureka-server，最右側是WebUI展示及開發接口。

Zipkin 的服務端，在使用 Spring Boot 2.x 版本后，官方就不推薦自行定制編譯了，反而是直接提供了編譯好的 jar 包來給我們使用。
所以官方提供了一鍵腳本

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

如果用 Docker 的話，直接
docker run -d -p 9411:9411 openzipkin/zipkin

這里使用docker環境測試，數據存儲選擇默認的內存方式。啟動zipkinserver后，直接訪問9411，看到管理頁面：

zipkinserver啟動后，啟動EurekaServer，先本地啟動一個，端口暫定為7777.

好了，現在依賴服務有了，接下來改造兩個現有的微服務(為至少兩個有調用關系的服務配置)，作為zkclient。要做的事情很簡單，下面幾步：

1. 配置EurekaClient

1）微服務增加zipkin依賴

compile "org.springframework.cloud:spring-cloud-starter-sleuth"
compile "org.springframework.cloud:spring-cloud-starter-zipkin"

2) 啟動類增加EurekaClient注解
@EnableDiscoveryClient

3）application配置文件增加Eureka配置

eureka.instance.hostname=localhost
eureka.client.serviceUrl.defaultZone = http://${eureka.instance.hostname}:7777/eureka/
eureka.instance.preferIpAddress= true

2. 配置Zipkin

1）開啟sleuth client

spring.sleuth.web.client.enabled=true
spring.sleuth.sampler.percentage=1.0 

sampler.percentage是采樣率，1代表選取全部樣本，因為是測試，所以直接設置成1，實際情況可能是個小數，0.3或者0.5，根據需求自行決定。

2）配置zipkinserver地址
spring.zipkin.base-url=http://192.168.72.101:9411/

3. 調用服務查看結果

1) Eureka服務清單

2) Zipkin服務鏈路

需要注意的是，由于Sleuth trace filter僅針對Spring內置的Rest調用做攔截，跨服務的調用需要使用Spring官宣方式，如RestTemplate，直接使用apache的httpclient工具包調用，是無法追蹤到完整鏈路。

下面從實現層面了解，Zipkin的工作機制。引入sleuth和zipkin依賴包之后，系統自動掃描所有包中的@configuration，TraceAutoConfiguration是sleuth包的配置入口，看看它的定義，spring.sleuth.enabled開啟的時候注解有效。

@Configuration
@ConditionalOnProperty(
    value = {"spring.sleuth.enabled"},
    matchIfMissing = true
)
@EnableConfigurationProperties({TraceKeys.class, SleuthProperties.class})
public class TraceAutoConfiguration {
...

同理，Zipkin的配置如下：

@Configuration
@EnableConfigurationProperties({ZipkinProperties.class, SamplerProperties.class})
@ConditionalOnProperty(value = "spring.zipkin.enabled", matchIfMissing = true)
@AutoConfigureBefore(TraceAutoConfiguration.class)
public class ZipkinAutoConfiguration {
...

TraceFilter作為整個追蹤的切入口，針對所有的request進行過濾標記，并通過AsyncReporter進行異步發送報文。下圖框起來的部分，分別是接口地址和編碼協議（Thrift）

SKYwalking實踐

Zipkin使用起來很簡單，但是因為是接口級的跟蹤，能看到的信息比較有限，另外頁面的展示形式也相對簡單，缺少多角度或者多樣性，所以，我們再試試SKYWalking。
skywalking的工作機制，需要三塊協同，一塊是skywalking server，負責接收、存儲并展示，所以server模塊包含一個展示web子模塊；第二塊是agent，負責代理微服務并收集需要的信息，轉發給server；第三塊便是微服務本身，需要在啟動時指定agent，以便生成代理類。工作原理圖大致如下:

先看下效果圖，再記錄配置過程。

選中其中一個服務，可以查看調用關系及服務基礎狀態。

拓撲圖還有個扁平展示效果（很適合ppt介紹有沒有）

儀表盤看服務狀態：

追蹤欄看調用明細：

失敗調用還有錯誤日志：

告警欄速覽全局風險：

吹完療效，看下怎么配置，先看server。

下載最新的skywalking，選了6.4，一開選的6.1有bug，拓撲圖經常出不來。server的運行可以運行在容器內，也可以運行虛擬服務器譬如ECS上。server的配置主要是存儲相關，mysql和es任選一個，看數據量和操作便捷性，數據量可控的情況下，簡單起見，直接用mysql，換掉innodb引擎即可。

1. 配置文件applicaiton.yml中打開datasource選項。
   
2. datasource-setting.properties中指向自建的數據庫。（只需要建庫和訪問賬號，表在啟動時會自動初始化，表很多。。。）

server的訪問端口分別是：11800和12800，分別是gRPC和rest端口，如果改了，需要通過修改后面config的訪問端口。這里提示開防火墻端口。

Agent的同樣有兩種方式，一種是將agent打在鏡像中，微服務的鏡像基于這個鏡像；另一種是直接copy到一個共享目錄，每個微服務啟動參數增加指向。第二種方式在測試環境比較實用，生產環境基本上用鏡像更合適，因為微服務運行在容器中，訪問共享目錄不現實。
不管選擇哪種方式，config的配置是關鍵。

agentName需要和微服務參數指定的一致。后臺服務地址指向oapserver。

最后一步，微服務啟動參數增加agent指向：
-Dskywalking.agent.application_code=agent-test
這個agent-test就是agentname，需要和agent配置的name一致！

非容器方式的配置主要就這三步，完事就可以看到效果了。當然，服務之前的調用，需要用spring提供的restTemplate，不要直接用apache的httpclient工具包，否則不會被采集。關于容器環境的部署，后面抽空再補記錄。