使用 Istio治理微服務入門

近兩年微服務架構流行，主流網際網路廠商內部都已經微服務化，初創企業雖然技術積澱不行，但也透過各種開源工具擁抱微服務。再加上

容器技術

賦能，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 -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

注：我還曾在K8S v1。7。3上安裝過istio 0。3。0版本，但在建立元件時會報下面錯誤（這個錯誤可能會導致後續addon安裝後工作不正常）：

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 9091/TCP，15004/TCP，9093/TCP，9094/TCP，9102/TCP，9125/UDP，42422/TCP 4d

istio-pilot 10。105。80。55 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。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容器。當然也可以配置為自動為每個k8s啟動的pod注入sidecar，但我們這裡沒有使用自動注入。我們執行下面命令：

# kubectl apply -f <（istioctl kube-inject -f svca-v0。1。yaml）

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 <（istioctl kube-inject -f svcb-v0。1。yaml）

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了。下面我們來驗證一下業務是否是通的。

2egress rule

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

# kubectl get svc

NAME CLUSTER-IP EXTERNAL-IP PORT（S）

svca 10。105。38。238 80/TCP 9h

svcb 10。105。119。194 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

我們看到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。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 <（istioctl kube-inject -f svcb-v0。2。yaml）

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

。。。。。。

此時，如果按照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。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上不再有流量，這個切換是成功的。

在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。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 3000/TCP 16m

prometheus 10。103。160。37 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。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 8088/TCP 52s

。。。。。。

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

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

3zipkin

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 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/exp

eriments/tree/master/istio-demo

可以下載到，demo service的映象可以在我的docker hub：

https：//

hub。docker。com/u/bigwhi

上pull。

ServiceMesh中文社群：

ServiceMesh中文社群（

http://servicemesh.cn

）已上線，Istio、Conduit官方文件翻譯版已在社群釋出，歡迎大家登入瀏覽。

ServiceMesh微信交流群：

新增微信

xiaoshu062

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

http：//

weixin。qq。com/r/QSiYgM7

E0JOvrYrj931T

（二維碼自動識別）

小蜜蜂問答

小蜜蜂問答

使用 Istio治理微服務入門

推薦文章

小蜜蜂問答

小蜜蜂問答

使用 Istio治理微服務入門

相關文章

火影忍者手遊現在3000金幣，一直在攢，V0，一片虎皮都沒有，能出嗎？

網路連線的時候出現錯誤程式碼503是什麼意思？

有了雲計算之後，為什麼還會出現大資料？

怎麼檢視已刪除記錄的qq空間訪客

推薦文章