設想這麼一種情況，如果你的微服務數量逐漸增大，服務間的依賴關系越來越複雜，怎麼分析它們之間的調用關系及互相的影響？
一個由微服務構成的應用系統通過服務來劃分問題域，通過rest請求服務api來連接配接服務來完成完整業務。對于入口的一個調用可能需要有多個背景服務協同完成，鍊路上任何一個調用逾時或出錯都可能造成前端請求的失敗。服務的調用鍊也會越來越長，并形成一個樹形的調用鍊。
随着服務的增多，對調用鍊的分析也會越來越負責。設想你在負責下面這個系統，其中每個小點都是一個微服務，他們之間的調用關系形成了複雜的網絡。
有密集恐懼症的同學就忽略吧。
在這個示例中，我們準備開發兩個基于spring cloud的應用，利用spring cloud sleuth來和zipkin進行內建。spring cloud sleuth是對zipkin的一個封裝，對于span、trace等資訊的生成、接入http request，以及向zipkin server發送采集資訊等全部自動完成。
這是spring cloud sleuth的概念圖。
本次示範的服務有兩個：tracedemo做為前端服務接收使用者的請求，tracebackend為後端服務，tracedemo通過http協定調用後端服務。
tracedemo應用通過resttemplate調用後端tracedemo服務，注意，url中指明tracedemo的位址為<code>backend</code>。
後端服務響應http請求，輸出一行日志後傳回經典的“hello world”。
可以看到，這是典型的兩個spring應用通過resttemplate進行通路的方式，哪在http請求中注入追蹤資訊并把相關資訊發送到zipkin server呢？答案在兩個應用所加載的jar包裡。
本示例采用gradle來建構應用，在build.gradle中加載了sleuth和zipkin相關的jar包：
spring應用在監測到java依賴包中有sleuth和zipkin後，會自動在resttemplate的調用過程中向http請求注入追蹤資訊，并向zipkin server發送這些資訊。
哪麼zipkin server的位址又是在哪裡指定的呢？答案是在application.properties中：
注意zipkin server的位址為<code>zipkin-server</code>。
為這兩個服務建立相同的dockerfile，用于生成docker鏡像：
建構容器鏡像的步驟如下：
建構鏡像完成後用<code>docker push</code>指令上傳到你的鏡像倉庫。
在build.gradle中引入zipkin依賴包。
在主程式class增加一個注解<code>@enablezipkinserver</code>
在<code>application.properties</code>将端口指定為9411。
dockerfile和前面的兩個服務一樣，這裡就不重複了。
建立docker-compose.yml檔案，内容如下：
在阿裡雲容器服務上<code>使用編排模版建立</code>應用，通路zipkin端點，可以看到服務分析的效果。
通路前端應用3次，頁面顯示3次服務調用。
點選其中任意一個trace，可以看到請求鍊路上不同span所花費的時間。
進入dependencies頁面，還可以看到服務之間的依賴關系。
從這個過程可以看出，zipkin和spring cloud的內建做得很好。而且對服務追蹤分析的可視化也很直覺。
注意的是，在生産環境中還需要為zipkin配置資料庫，這裡就不詳細介紹了。
本文簡單介紹了如何利用zipkin對springcloud應用進行服務分析。在實際的應用場景中，zipkin可以結合壓力測試工具一起使用，分析系統在大壓力下的可用性和性能。這部分内容未來會在devops系列中繼續介紹。