使用 Istio治理微服務入門

04-09

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

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

微服務的「痛點」

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

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

服務註冊與發現
身份驗證與授權
服務的伸縮控制
反向代理與負載均衡
路由控制
流量切換
日誌管理
性能度量、監控與調優
分散式跟蹤
過載保護
服務降級
服務部署與版本升級策略支持
錯誤處理

… …

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

Service Mesh橫空出世，Istio帶來「福音」

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

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

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

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

「Service Mesh」概念還非常年輕，這個詞在國內被翻譯為「服務網格」或「服務嚙合層」，我們這裡就用Service Mesh這個英文詞。這裡摘錄一下 ServiceMesh 中文網社區上的一篇名為「年度盤點2017之Service Mesh：群雄逐鹿烽煙起」的文章中對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的部署形式提供。下面是官方的架構圖：

圖：Istio架構圖(來自官網)

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

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

Istio安裝

Istio目前支持最好的就是kubernetes了，因此我們的實驗環境就定在kubernetes上。至於版本，Istio當前最新版本為0.4.0，這個版本據說要K8S 1.7.4及以上版本用起來才不會發生小毛病:)。我的K8S集群是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 -Fbin/ 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.yamlnamespace "istio-system" createdclusterrole "istio-pilot-istio-system" createdclusterrole "istio-initializer-istio-system" createdclusterrole "istio-mixer-istio-system" createdclusterrole "istio-ca-istio-system" createdclusterrole "istio-sidecar-istio-system" createdclusterrolebinding "istio-pilot-admin-role-binding-istio-system" createdclusterrolebinding "istio-initializer-admin-role-binding-istio-system" createdclusterrolebinding "istio-ca-role-binding-istio-system" createdclusterrolebinding "istio-ingress-admin-role-binding-istio-system" createdclusterrolebinding "istio-sidecar-role-binding-istio-system" createdclusterrolebinding "istio-mixer-admin-role-binding-istio-system" createdconfigmap "istio-mixer" createdservice "istio-mixer" createdserviceaccount "istio-mixer-service-account" createddeployment "istio-mixer" createdcustomresourcedefinition "rules.config.istio.io" createdcustomresourcedefinition "attributemanifests.config.istio.io" created... ...customresourcedefinition "reportnothings.config.istio.io" createdattributemanifest "istioproxy" createdattributemanifest "kubernetes" createdstdio "handler" createdlogentry "accesslog" createdrule "stdio" createdmetric "requestcount" createdmetric "requestduration" createdmetric "requestsize" createdmetric "responsesize" createdmetric "tcpbytesent" createdmetric "tcpbytereceived" createdprometheus "handler" createdrule "promhttp" createdrule "promtcp" createdkubernetesenv "handler" createdrule "kubeattrgenrulerule" createdkubernetes "attributes" createdconfigmap "istio" createdcustomresourcedefinition "destinationpolicies.config.istio.io" createdcustomresourcedefinition "egressrules.config.istio.io" createdcustomresourcedefinition "routerules.config.istio.io" createdservice "istio-pilot" createdserviceaccount "istio-pilot-service-account" createddeployment "istio-pilot" createdservice "istio-ingress" createdserviceaccount "istio-ingress-service-account" createddeployment "istio-ingress" createdserviceaccount "istio-ca-service-account" createddeployment "istio-ca" created

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

unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metricunable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metricunable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metricunable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metricunable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metricunable 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-systemNAME READY STATUS RESTARTS AGEistio-ca-1363003450-jskp5 1/1 Running 0 3distio-ingress-1005666339-c7776 1/1 Running 4 3distio-mixer-465004155-twhxq 3/3 Running 24 3distio-pilot-1861292947-6v37w 2/2 Running 18 3d# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEistio-ingress 10.98.10.87 <pending> 80:31759/TCP,443:25804/TCP 4distio-mixer 10.109.244.155 <none> 9091/TCP,15004/TCP,9093/TCP,9094/TCP,9102/TCP,9125/UDP,42422/TCP 4distio-pilot 10.105.80.55 <none> 15003/TCP,443/TCP 4d

istio安裝成功！

服務治理策略驗證

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

1驗證環境和拓撲

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

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

service_a: 模擬pay服務，在收到client請求後，進行pay處理，並將處理結果通過service_b提供的msg notify服務下發給user。該服務的endpoint為/pay；
service_b: 模擬notify服務，在收到service_a請求後，將message轉發給external service，完成notify邏輯。該服務的endpoint為/notify；
external service: 位於service mesh之外。
client：我們使用curl模擬。

我們先來部署service_a和service_b的v0.1版本：

以service_a的部署為例, service_a的deployment文件如下：

//svca-v0.1.yamlapiVersion: extensions/v1beta1kind: Deploymentmetadata: name: svcaspec: 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: v1kind: Servicemetadata: name: svca labels: app: svcaspec: 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容器。當然也可以配置為自動為每個k8s啟動的pod注入sidecar，但我們這裡沒有使用自動注入。我們執行下面命令：

# kubectl apply -f <(istioctl kube-inject -f svca-v0.1.yaml)deployment "svca" createdservice "svca" created# kubectl get podsNAME READY STATUS RESTARTS AGEsvca-1997590752-tpwjf 2/2 Running 0 2m

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

# kubectl apply -f <(istioctl kube-inject -f svcb-v0.1.yaml)deployment "svcb" createdservice "svcb" created

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

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

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

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

2egress rule

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

# kubectl get svcNAME CLUSTER-IP EXTERNAL-IP PORT(S)svca 10.105.38.238 <none> 80/TCP 9hsvcb 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 <nil>}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]] {} <nil> 0 [] false svcb map[] map[] <nil> map[] 127.0.0.1:58778 /notify?msg=service_a:v0.1-pays-ok <nil> <nil> <nil> 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

我們看到service_a和service_b都返回了錯誤日誌（注意：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.yamlapiVersion: config.istio.io/v1alpha2kind: EgressRulemetadata: name: enable-svcb-engress-rulespec: 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]] {} <nil> 0 [] false 10.100.35.27:9997 map[] map[] <nil> map[] 10.100.35.28:38188 /send?msg=service_a:v0.1-pays-ok <nil> <nil> <nil> 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.yamlapiVersion: extensions/v1beta1kind: Deploymentmetadata: name: svcb-v0.2spec: 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 <(istioctl kube-inject -f svcb-v0.2.yaml)deployment "svcb-v0.2" created# kubectl get podsNAME READY STATUS RESTARTS AGEsvca-1997590752-pq9zg 2/2 Running 0 9hsvcb-2008973769-gq0lh 2/2 Running 0 9hsvcb-v0.2-3233505404-0g55w 2/2 Running 0 1m

svcb服務下又增加了一個endpoint:

# kubectl describe svc/svcb.... ...Selector: app=svcbType: ClusterIPIP: 10.105.119.194Port: <unset> 80/TCPEndpoints: 10.40.0.28:8080,10.46.0.12:8080... ...

此時，如果按照K8S的調度方式，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.yamlapiVersion: config.istio.io/v1alpha2kind: RouteRulemetadata: name: route-rules-svcbspec: 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.yamlCreated 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.yamlapiVersion: config.istio.io/v1alpha2kind: RouteRulemetadata: name: route-rules-svcbspec: destination: name: svcb precedence: 1 route: - labels: version: v0.2 weight: 100# istioctl replace -f route-rules-svcb-v0.2-100.yamlUpdated 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上不再有流量，這個切換是成功的。

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

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

插件安裝

Istio的強大微服務治理能力還體現在其集成了grafana、prometheus、servicegraph、zipkin等addons，應用程序無需做任何改動，就可以具有數據收集、度量與可視化的監控能力、服務的分散式跟蹤能力等。我們可以在Istio的安裝包中找到這些addons的安裝文件，我們來逐一試試。

prometheus&grafana

我們先來安裝一下prometheus 和 grafana插件(位於istio-0.4.0/install/kubernetes/addon下面)：

# kubectl apply -f prometheus.yamlconfigmap "prometheus" createdservice "prometheus" createddeployment "prometheus" created# kubectl apply -f grafana.yamlservice "grafana" createddeployment "grafana" created# kubectl get pods -n istio-systemNAME READY STATUS RESTARTS AGEgrafana-3617079618-zpglx 1/1 Running 0 5mprometheus-168775884-ppfxr 1/1 Running 0 5m... ...# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEgrafana 10.105.21.25 <none> 3000/TCP 16mprometheus 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注入流量，我們會看到儀錶盤變化如下：

2servicegraph

servicegraph插件是用來查看服務調用關係的，我們來創建一下該組件：

# kubectl apply -f servicegraph.yamldeployment "servicegraph" createdservice "servicegraph" created# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEservicegraph 10.108.245.21 <none> 8088/TCP 52s... ...

創建成功後，向service mesh網路注入流量，然後訪問servicegraph：http://{servicegraph_ip}:8088/dotviz，在我的環境里，我看到的圖示如下：

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

3zipkin

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

我們安裝一下zipkin addon:

# kubectl apply -f zipkin.yamldeployment "zipkin" createdservice "zipkin" created# kubectl get svc -n istio-systemNAME CLUSTER-IP EXTERNAL-IP PORT(S) AGEzipkin 10.105.7.219 <none> 9411/TCP 1h

我們訪問以下zikpin的UI，通過瀏覽器打開http://{zipkin_service_ip}:9411。

接下來，我們向service mesh注入一些流量，然後再zipkin首頁的「服務名」下拉框中選擇」svcb」，查找跟蹤情況：

我們看到：在沒有對svca, svcb做任何修改的情況下，我們依然可以在zipkin中找到svcb相關的調用。點擊其中一個trace，可以查看細節：

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

小結

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

本文涉及到的源碼在這裡 https://github.com/bigwhite/experiments/tree/master/istio-demo 可以下載到，demo service的鏡像可以在我的docker hub: https://hub.docker.com/u/bigwhite 上pull。

ServiceMesh中文社區：

ServiceMesh中文社區（http://servicemesh.cn）已上線，Istio、Conduit官方文檔翻譯版已在社區發布，歡迎大家登錄瀏覽。

ServiceMesh微信交流群：

添加微信xiaoshu062，備註：服務網格，即可加入Service Mesh微信交流群。

http://weixin.qq.com/r/QSiYgM7E0JOvrYrj931T (二維碼自動識別)