使用Istio治理微服務入門

近兩年微服務架構流行，主流網際網路廠商內部都已經微服務化，初創企業雖然技術積澱不行，但也透過各種開源工具擁抱微服務。再加上容器技術賦能，Kubernetes又添了一把火，微服務架構已然成為當前軟體架構設計的首選。

但微服務化易弄，服務治理難搞！

一、微服務的“痛點”

微服務化沒有統一標準，多數是進行業務領域垂直切分，業務按一定的粒度劃分職責，並形成清晰、職責單一的服務介面，這樣每一塊規劃為一個微服務。微服務之間的通訊方案相對成熟，開源領域選擇較多的有RPC或RESTful API方案，比如：gRPC、Apache Thrift等。這些方案多偏重於資料如何打包、傳輸與解包，對服務治理的內容涉及甚少。

微服務治理是頭疼的事，也是微服務架構中的痛點。治理這個詞有多元含義，很難下達一個精確定義，這裡可以像小學二年級學生那樣列出治理的諸多近義詞：管理、控制、規則、掌控、監督、支配、規定、統治等。對於微服務而言，治理體現在以下諸多方面：

• 服務註冊與發現

• 身份驗證與授權

• 服務的伸縮控制

• 反向代理與負載均衡

• 路由控制

• 流量切換

• 日誌管理

• 效能度量、監控與調優

• 分散式跟蹤

• 過載保護

• 服務降級

• 服務部署與版本升級策略支援

• 錯誤處理

• ……

從微服務治理角度來說，微服務其實是一個“大系統”，要想將這個大系統全部落地，絕非易事，尤其是之前尚沒有一種特別優雅的技術方案。多數方案（比如：Dubbo、go-kit等）都或多或少地對應用邏輯有一定的侵入性，讓業務開發人員不能只focus到業務本身，還要關心那些“治理”邏輯。並且市面上內建了微服務治理邏輯的框架較少，且很多程式語言相關。這種情況下，大廠多選擇自研或基於某個框架改造，小廠一般只能“東拼西湊”一些“半成品”湊合著使用，就這樣微服務也走過了若干年。

二、Service Mesh橫空出世，Istio帶來“福音”

我不知道在沒有TCP/IP協議的年代，主機和主機之間的應用通訊時是否需要應用關心底層通訊協議實現邏輯。但是和TCP/IP誕生的思想類似，在微服務使用多年後，人們發現需要獨立地抽象出一層邏輯網路，專門用於“微服務通訊與治理策略的落地”，讓應用只關心業務，把服務治理的事情全部交由“這一層”去處理。

圖 1：傳統微服務之間的微服務治理邏輯的位置

圖 2：微服務治理邏輯被獨立出來之後的位置

由“Service Govern Logic”這一層組成的邏輯網路被定義為Service Mesh，每個微服務都包含一個service mesh的端點。

“Service Mesh”概念還非常年輕，這個詞在國內被翻譯為“服務網格”或“服務嚙合層”，我們這裡就用Service Mesh這個英文詞。這裡摘錄一下ServiceMesh中文社群上的一篇名為《年度盤點2017之Service Mesh：群雄逐鹿烽煙起[1]》的文章中對Service Mesh概念的回顧：

在 2016 年年初，“Service Mesh”還只是 Buoyant 公司的內部詞彙，而之後，它開始逐步走向社群：

2016 年 9 月 29 日在 SF Microservices 上，“Service Mesh”這個詞彙第一次在公開場合被使用。這標志著“Service Mesh”這個詞，從 Buoyant 公司走向社群。

2016 年 10 月，Alex Leong 開始在 Buoyant 公司的官方 Blog 中連載系列文章“A Service Mesh for Kubernetes”。隨著“The Services must Mesh”口號的喊出，Buoyant 和 Linkerd 開始 Service Mesh 概念的佈道。

2017 年 4 月 25 日，William Morgan 釋出博文“What’s a Service Mesh? And why do I need one?”。正式給 Service Mesh 做了一個權威定義。

而Service Mesh真正引起大家關註要源於Istio專案的開源釋出。為什麼呢？個人覺得還是因為“爹好”！Istio專案由Google、IBM共同合作建立，Lyft公司貢獻了Envoy專案將作為Istio Service Mesh的data panel。Google、IBM的影響力讓Service Mesh概念迅速傳播，同時也讓大家認識到了Istio專案在Service Mesh領域的重要性，於是紛紛選擇積極支援並將自己的產品或專案與Istio專案整合。

Istio專案是Service Mesh概念的最新實現，旨在所有主流叢集管理平臺上提供Service Mesh層，初期以實現Kubernetes上的服務治理層為標的。它由控制平面和資料平面組成（是不是感覺和SDN的設計理念相似啊）。控制平面由Go語言實現，包括Pilot、Mixer、Auth三個元件；資料平面功能暫由Envoy在Pod中以Sidecar的部署形式提供。下麵是官方的架構圖：

圖 3：Istio架構圖（來自官網）

Sidecar中Envoy代理了Pod中真正業務Container的所有進出流量，並對這些流量按照控制平面設定的“治理邏輯”進行處理。而這一切對Pod中的業務應用是透明的，開發人員可以專心於業務邏輯，而無需再關心微服務治理的邏輯。Istio代表的Service Mesh的設計理念被認為是下一代“微服務統一框架”，甚至有人認為是微服務框架演化的終點。

Istio於2017年5月24日釋出了0.1 release版本，截至目前為止Istio的版本更新到v 0.4.0，演進速度相當快，不過目前依然不要用於生產環境，至少要等到1.0版本釋出吧。但對於Istio的早期接納者而言，現在正是深入研究Istio的好時機。在本篇的接下來內容中，我們將帶領大家感性的認識一下Istio，入個門兒。

三、Istio安裝

Istio目前支援最好的就是Kubernetes了，因此我們的實驗環境就定在Kubernetes上。至於版本，Istio當前最新版本為0.4.0，這個版本據說要Kubernetes 1.7.4及以上版本用起來才不會發生小毛病:)。我的Kubernetes叢集是v1.7.6版本的，恰好滿足條件。下麵是安裝過程：（Node上的OS是Ubuntu 16.04）

# wget -c https://github.com/istio/istio/releases/download/0.4.0/istio-0.4.0-linux.tar.gz
解壓後，進入istio-0.4.0目錄，
# ls -F
bin/  install/  istio.VERSION  LICENSE  README.md  samples/
# cat istio.VERSION
# DO NOT EDIT THIS FILE MANUALLY instead use
# install/updateVersion.sh (see install/README.md)
export CA_HUB="docker.io/istio"
export CA_TAG="0.4.0"
export MIXER_HUB="docker.io/istio"
export MIXER_TAG="0.4.0"
export PILOT_HUB="docker.io/istio"
export PILOT_TAG="0.4.0"
export ISTIOCTL_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/istioctl"
export PROXY_TAG="0.4.0"
export ISTIO_NAMESPACE="istio-system"
export AUTH_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PILOT_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PROXY_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export FORTIO_HUB="docker.io/istio"
export FORTIO_TAG="0.4.2"
# cd install/kubernetes
我們先不用auth功能，因此使用istio.yaml這個檔案進行Istio元件安裝：
# kubectl apply -f istio.yaml
namespace "istio-system" created
clusterrole "istio-pilot-istio-system" created
clusterrole "istio-initializer-istio-system" created
clusterrole "istio-mixer-istio-system" created
clusterrole "istio-ca-istio-system" created
clusterrole "istio-sidecar-istio-system" created
clusterrolebinding "istio-pilot-admin-role-binding-istio-system" created
clusterrolebinding "istio-initializer-admin-role-binding-istio-system" created
clusterrolebinding "istio-ca-role-binding-istio-system" created
clusterrolebinding "istio-ingress-admin-role-binding-istio-system" created
clusterrolebinding "istio-sidecar-role-binding-istio-system" created
clusterrolebinding "istio-mixer-admin-role-binding-istio-system" created
configmap "istio-mixer" created
service "istio-mixer" created
serviceaccount "istio-mixer-service-account" created
deployment "istio-mixer" created
customresourcedefinition "rules.config.istio.io" created
customresourcedefinition "attributemanifests.config.istio.io" created
... ...
customresourcedefinition "reportnothings.config.istio.io" created
attributemanifest "istioproxy" created
attributemanifest "kubernetes" created
stdio "handler" created
logentry "accesslog" created
rule "stdio" created
metric "requestcount" created
metric "requestduration" created
metric "requestsize" created
metric "responsesize" created
metric "tcpbytesent" created
metric "tcpbytereceived" created
prometheus "handler" created
rule "promhttp" created
rule "promtcp" created
kubernetesenv "handler" created
rule "kubeattrgenrulerule" created
kubernetes "attributes" created
configmap "istio" created
customresourcedefinition "destinationpolicies.config.istio.io" created
customresourcedefinition "egressrules.config.istio.io" created
customresourcedefinition "routerules.config.istio.io" created
service "istio-pilot" created
serviceaccount "istio-pilot-service-account" created
deployment "istio-pilot" created
service "istio-ingress" created
serviceaccount "istio-ingress-service-account" created
deployment "istio-ingress" created
serviceaccount "istio-ca-service-account" created
deployment "istio-ca" created 

註：我還曾在Kubernetes v1.7.3上安裝過Istio 0.3.0版本，但在建立元件時會報下麵錯誤（這個錯誤可能會導致後續addon安裝後工作不正常）：

unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric

安裝後，我們在istio-system這個namespace下會看到如下Pod和Service在執行（由於Istio的各個元件的image size都不小，因此Pod狀態變為Running需要一丟丟時間，耐心等待）：

# kubectl get pods -n istio-system
NAME                             READY     STATUS    RESTARTS   AGE
istio-ca-1363003450-jskp5        1/1       Running   0          3d
istio-ingress-1005666339-c7776   1/1       Running   4          3d
istio-mixer-465004155-twhxq      3/3       Running   24         3d
istio-pilot-1861292947-6v37w     2/2       Running   18         3d
# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                   AGE
istio-ingress   10.98.10.87           80:31759/TCP,443:25804/TCP                         4d
istio-mixer     10.109.244.155   <none>        9091/TCP,15004/TCP,9093/TCP,9094/TCP,9102/TCP,9125/UDP,42422/TCP   4d
istio-pilot     10.105.80.55     <none>        15003/TCP,443/TCP                                              4d

Istio安裝成功！

四、服務治理策略驗證

接下來我們來用幾個例子驗證一下Istio在服務治理方面的能力！（Istio自帶一些完整的例子，比如bookinfo，用於驗證服務治理的能力，但這裡先不打算用這些例子）

1、驗證環境和拓撲

我們先來看一下驗證環境的示意圖：

我們看到在Service Mesh中部署了兩個service: servera和serviceb，前者呼叫後者完成某項業務，後者則呼叫外部服務完成業務邏輯。

• servicea：模擬pay服務，在收到client請求後，進行pay處理，並將處理結果透過serviceb提供的msg notify服務下發給user。該服務的endpoint為/pay；

• serviceb：模擬notify服務，在收到servicea請求後，將message轉發給external service，完成notify邏輯。該服務的endpoint為/notify；

• external service：位於Service Mesh之外；

• client：我們使用curl模擬。

我們先來部署servicea和serviceb的v0.1版本：

以servicea的部署為例，servicea的deployment檔案如下：

//svca-v0.1.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: svca
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: svca
        version: v0.1
    spec:
      containers:
      - name: svca
        image: docker.io/bigwhite/istio-demo-svca:v0.1
        imagePullPolicy: Always
 ---
apiVersion: v1
kind: Service
metadata:
  name: svca
  labels:
    app: svca
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: svca

註意，我們部署service_a時不能直接使用kubectl apply -f svca-v0.1.yaml，而是要apply經過istioctl（需將Istio安裝目錄下的bin放入PATH）處理過的yaml，以註入sidecar容器。當然也可以配置為自動為每個Kubernetes啟動的Pod註入sidecar，但我們這裡沒有使用自動註入。我們執行下麵命令：

# kubectl apply -f 
deployment "svca" created
service "svca" created
# kubectl get pods
NAME                               READY     STATUS    RESTARTS   AGE
svca-1997590752-tpwjf              2/2       Running   0          2m

同樣的方法，我們來建立svcb:v0.1：

# kubectl apply -f 
deployment "svcb" created
service "svcb" created

我們看到Istio向每個Pod中插入一個sidecar container，這個就是前面說的envoy，只不過container名字為istio-proxy。

接下來，我們把那個external service啟動起來：

# nohup ./msgd > 1.log & 2>&1
[1] 9423

實驗環境OK了。下麵我們來驗證一下業務是否是通的。

2、Egress Rules

按照之前我們的設定，我們使用curl去訪問service_a服務的/pay端點，我們檢視一下svca服務的IP和埠：

# kubectl get svc
NAME               CLUSTER-IP       EXTERNAL-IP   PORT(S)
svca               10.105.38.238    <none>        80/TCP                                         9h
svcb               10.105.119.194   <none>        80/TCP                                         9h

我們訪問一下svca服務，svca的服務地址可以透過kubectl get svc查到：

# curl {svca_ip}/pay

檢視svca和svcb的日誌：

//service_a的日誌：
service_a:v0.1 is serving the request...
service_a:v0.1 pays ok
&{500 Internal Server Error 500 HTTP/1.1 1 1 map[X-Content-Type-Options:[nosniff] Date:[Tue, 02 Jan 2018 15:41:50 GMT] Content-Length:[66] Content-Type:[text/plain; charset=utf-8]] 0xc420058d40 66 [] false false map[] 0xc4200eaf00 }
service_a:v0.1 notify customer ok
// service_b的日誌：
&{GET /notify?msg=service_a:v0.1-pays-ok HTTP/1.1 1 1 map[User-Agent:[Go-http-client/1.1] Accept-Encoding:[gzip]] {}  0 [] false svcb map[] map[]  map[] 127.0.0.1:58778 /notify?msg=service_a:v0.1-pays-ok    0xc4200fa3c0}
service_b:v0.1 is serving the request...
service_b:v0.1 send msg error: Get http://10.100.35.27:9997/send?msg=service_a:v0.1-pays-ok: EOF

我們看到servicea和serviceb都傳回了錯誤日誌（註意：go http get方法對於non-2xx response不會傳回錯誤，我們只是看到了response中的500狀態碼才意識到錯誤的存在）。其中源頭在service_b，原因是其連不上那個external service！那麼為什麼連不上external service呢？這是由於預設情況下，啟用了Istio的服務是無法訪問外部URL的，這是因為Pod中的iptables把所有外發傳輸都轉向到了Sidecar代理，而這一代理只處理叢集內的訪問標的。因此位於Service Mesh內的服務svcb無法訪問外部的服務（msgd），我們需要顯式的新增egressrule規則：

我們建立一個允許svcb訪問外部特定服務的EgressRule：

//rules/enable-svcb-engress-rule.yaml
apiVersion: config.istio.io/v1alpha2
kind: EgressRule
metadata:
  name: enable-svcb-engress-rule
spec:
  destination:
    service: 10.100.35.27
  ports:
    - port: 9997
      protocol: http

使規則生效：

# istioctl create -f enable-svcb-engress-rule.yaml
Created config egress-rule/default/enable-svcb-engress-rule at revision 30031258

這時你再嘗試curl svca，我們可以看到msgd的日誌中出現了下麵的內容：

2018/01/02 23:58:16 &{GET /send?msg=service_a:v0.1-pays-ok HTTP/1.1 1 1 map[X-Ot-Span-Context:[2157e7ffb8105330;2157e7ffb8105330;0000000000000000] Content-Length:[0] User-Agent:[Go-http-client/1.1] X-Forwarded-Proto:[http] X-Request-Id:[13c3af6e-2f52-993d-905f-aa6aa4b57e2d] X-Envoy-Decorator-Operation:[default-route] X-B3-Spanid:[2157e7ffb8105330] X-B3-Sampled:[1] Accept-Encoding:[gzip] X-B3-Traceid:[2157e7ffb8105330] X-Istio-Attributes:[Ch8KCXNvdXJjZS5pcBISMhAAAAAAAAAAAAAA//8KLgAMCjoKCnNvdXJjZS51aWQSLBIqa3ViZXJuZXRlczovL3N2Y2ItMjAwODk3Mzc2OS1ncTBsaC5kZWZhdWx0]] {}  0 [] false 10.100.35.27:9997 map[] map[]  map[] 10.100.35.28:38188 /send?msg=service_a:v0.1-pays-ok    0xc4200584c0}
2018/01/02 23:58:16 Msgd is serving the request...
2018/01/02 23:58:16 Msgd recv msg ok, msg= service_a:v0.1-pays-ok

說明Svcb到外部服務的通訊被打通了！

3、遷移流量到新版本svcb:v0.2

我們經常有這樣的需求，當svcb執行一段時間後，svcb添加了新feature，版本要升級到v0.2了，這時我們會部署svcb:v0.2，並將流量逐步切到v0.2上。

我們先來部署一下svcb:v0.2：

// svcb-v0.2.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: svcb-v0.2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: svcb
        version: v0.2
    spec:
      containers:
      - name: svcb
        image: docker.io/bigwhite/istio-demo-svcb:v0.2
        imagePullPolicy: Always

我們可以看到，服務名不變，但版本的label變成了v0.2，我們來執行這次部署：

# kubectl apply -f 
deployment "svcb-v0.2" created
# kubectl get pods
NAME                               READY     STATUS    RESTARTS   AGE
svca-1997590752-pq9zg              2/2       Running   0          9h
svcb-2008973769-gq0lh              2/2       Running   0          9h
svcb-v0.2-3233505404-0g55w         2/2       Running   0          1m
svcb服務下又增加了一個endpoint:
# kubectl describe svc/svcb
.... ...
Selector:        app=svcb
Type:            ClusterIP
IP:            10.105.119.194
Port:                80/TCP
Endpoints:        10.40.0.28:8080,10.46.0.12:8080
... ...

此時，如果按照Kubernetes的排程方式，v0.1和v0.2版本的兩個svcb pod應該1:1均衡地承載流量。為了方便檢視流量分佈，我們將每個版本的svcb的pod副本數量都擴充套件為2個（replicas: 2），這樣Service Mesh中一共會有4個 svcb endpoints。

透過curl訪問svca註入流量後，我們發現流量都集中在一個svcb:v0.2的pod上，並且長時間沒有變化。我們透過下麵的route rule規則來嘗試將流量在svcb:v0.1和svcb:v0.2之間1:1均衡：

// route-rules-svcb-v0.2-50.yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: route-rules-svcb
spec:
  destination:
    name: svcb
  precedence: 1
  route:
  - labels:
      version: v0.1
    weight: 50
  - labels:
      version: v0.2
    weight: 50
# istioctl create -f route-rules-svcb-v0.2-50.yaml
Created config route-rule/default/route-rules-svcb at revision 30080638

按照Istio檔案中的說法，這個規則的生效需要一些時間。之後我們註入流量，發現流量切換到svcb:v0.1的一個Pod上去了，並且很長一段時間不曾變化，未均衡到svcb:v0.2上去。

我們更新一下route rule，將流量全部切到svcb:v0.2上去：

//route-rules-svcb-v0.2-100.yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: route-rules-svcb
spec:
  destination:
    name: svcb
  precedence: 1
  route:
  - labels:
      version: v0.2
    weight: 100
# istioctl replace -f route-rules-svcb-v0.2-100.yaml
Updated config route-rule/default/route-rules-svcb to revision 30082944

我們用Istio的replace命令更新了規則：route-rules-svcb。更新後，再次註入流量，這迴流量重新集中在svcb:v0.2的一個Pod上了，再過一段時間另外一個svcb:v0.2的pod上才有了一些流量。但svcb:v0.1上不再有流量，這個切換是成功的。

在Kubernetes的Service的負載均衡中，Kubernetes就利用了iptables的機率轉發（random –probability 0.5），因此這種流量均衡並非是精確的，只有在長時間大量流量經過後，才能看到流量的分佈與設定的權重是相似的，可能Istio也是如此，這裡僅是入門，就不深入挖掘了。

當然Istio在路由規則設施方面的“能耐”遠不止上面例子中所展示的那樣，如果要悉數列出，那本文的長度可是要爆掉了。有興趣的朋友可以去翻看官方檔案。

五、外掛安裝

Istio的強大微服務治理能力還體現在其集成了Grafana、Prometheus、ServiceGraph、Zipkin等Addons，應用程式無需做任何改動，就可以具有資料收集、度量與視覺化的監控能力、服務的分散式跟蹤能力等。我們可以在Istio的安裝包中找到這些Addons的安裝檔案，我們來逐一試試。

1、Prometheus & Grafana

我們先來安裝一下Prometheus和Grafana外掛（位於istio-0.4.0/install/kubernetes/addon下麵）：

# kubectl apply -f prometheus.yaml
configmap "prometheus" created
service "prometheus" created
deployment "prometheus" created
# kubectl apply -f grafana.yaml
service "grafana" created
deployment "grafana" created
# kubectl get pods -n istio-system
NAME                             READY     STATUS    RESTARTS   AGE
grafana-3617079618-zpglx         1/1       Running   0          5m
prometheus-168775884-ppfxr       1/1       Running   0          5m
... ...
# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)            AGE
grafana         10.105.21.25     <none>        3000/TCP                     16m
prometheus      10.103.160.37    <none>        9090/TCP                16m
... ...

瀏覽器中輸入Prometheus的服務地址http://10.103.160.37:9090，訪問Prometheus：

點選選單項：status -> targets，檢視各個target的狀態是否正常：

如果像上圖所示那樣，各個target都是up狀態，那就說明Istio執行時OK的。否則請參考istio troubleshooting中的內容對Istio逐一進行排查，尤其是istio-mesh這個Target在istio-0.3.0+kubernetes 1.7.3的環境中就是Down的狀態。

瀏覽器輸入grafana的服務地址：http://10.105.21.25:3000/，開啟grafana面板：

切換到Istio Dashboard，並向Istio Service Mesh註入流量，我們會看到儀錶盤變化如下：

2、ServiceGraph

ServiceGraph外掛是用來檢視服務呼叫關係的，我們來建立一下該元件：

# kubectl apply -f servicegraph.yaml
deployment "servicegraph" created
service "servicegraph" created
# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)                 AGE
servicegraph    10.108.245.21    <none>        8088/TCP                     52s
... ...

建立成功後，向Service Mesh網路註入流量，然後訪問ServiceGraph：http://{servicegraph_ip}:8088/dotviz，在我的環境裡，我看到的圖示如下：

呼叫關係似乎有些亂，難道是我在程式使用的呼叫方法不夠標準？:(

3、Zipkin

Istio集成了Zipkin，利用Zipkin我們可以做分散式服務呼叫的追蹤。之前自己曾經搭建過基於Jaeger和OpenTracing的分散式呼叫服務，十分繁瑣。並且要想使用tracing，對應用程式碼的侵入必不可少。

我們安裝一下Zipkin Addon：

# kubectl apply -f zipkin.yaml
deployment "zipkin" created
service "zipkin" created
# kubectl get svc -n istio-system
NAME            CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
zipkin          10.105.7.219     <none>        9411/TCP                             1h

我們訪問以下Zikpin的UI，透過瀏覽器開啟http://{zipkinserviceip}:9411。

接下來，我們向Service Mesh註入一些流量，然後在Zipkin首頁的“服務名”下拉框中選擇”svcb”，查詢跟蹤情況：

我們看到：在沒有對svca，svcb做任何修改的情況下，我們依然可以在Zipkin中找到svcb相關的呼叫。點選其中一個trace，可以檢視細節：

當然如果你想做內容更為豐富的、更為強大的跟蹤，可能需要在應用程式碼中做些配合，具體可以參見：Istio的分散式跟蹤[2]。

六、小結

Istio專案誕生不到一年，目前離成熟還遠。快速積極開發可能會導致Istio的介面和實現機制都會發生很大的變化，因此本文不能保證內容將適用於後續所有Istio的釋出版本。

本文涉及到的原始碼在這裡[3]可以下載到，demo service的映象可以在[我的Docker Hub[4]上pull。

相關連結：

1. http://www.servicemesh.cn/?/article/27

2. https://istio.io/docs/tasks/telemetry/distributed-tracing.html

3. https://github.com/bigwhite/experiments/tree/master/istio-demo

4. https://hub.docker.com/u/bigwhite/

本文轉載自公眾號：TongBai，ID：iamtonybai，點選檢視原文。

基於Kubernetes的容器雲平臺實踐培訓

本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；Docker的企業級應用與運維等，點選識別下方二維碼加微信好友瞭解具體培訓內容。

點選閱讀原文連結即可報名。