ServiceMesh的理念從根本上將分佈式框架中的服務註冊/發現，服務治理，管理等內容從應用中分離出來，由SideCar來提供分佈式框架中數據面的功能，讓應用只關注其業務本身，簡化了應用開發，其思想類似於SDN，我認爲是未來分佈式框架演進的方向。本文記錄了筆者學習Istio官網文檔中Example的過程，有誤的地方請指出,本文中的istio環境是基於k8s搭建的，具體如何在k8s集羣中搭建istio,請參考官方文檔。
首先給出Bookinfo Application的應用架構圖，如圖所示，用戶請求到product page後，product page會去請求Details應用以及Reviews，Reviews應用還會去請求Ratings，其中Reviews分爲三個版本，product page會輪詢選擇一個版本進行訪問。
接下來我們對Bookinfo Application進行部署 ,這裏我們選擇手工注入sideCar的方式來部署:
第一步:部署應用
**istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml | kubectl apply -f -**
注入成功後，會在k8s的default namespace下生成相應的pod和service，如上面程序調用示意圖所示，productpage,ratings,reviews這三個服務之間的調用都是通過service的域名來完成的.
第二步:將productpage通過node port方式映射
首先生成一個bookinfo應用的網關，通過這個網關，集羣外部就能訪問這個應用的productpage頁面了，網關的實現是istio的gateway,其概念類似於k8s中的ingress。生成命令如下：
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
接下來按照官網的步驟找到網關的地址和端口，就可以訪問應用的頁面了，測試結果如下面三幅圖所示，因Reviews初始的時候會有三個版本，所以每次訪問productpage的時候，都會訪問到Reviews三個版本中的其中一個版本，他們分別是黑色星星，沒有星星和紅色的星星。
接下來就可以按照istio官網給的文檔來驗證它的功能了:
1.Configuring Request Routing（配置請求路由），個人理解這個功能點是控制服務之間的路由，例如我們能夠將請求reviews服務的流量都路由到v1版本。
**kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml**
配置文件如下:
[root@master istio-1.0.2]# cat samples/bookinfo/networking/virtual-service-all-v1.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
spec:
hosts:
- productpage
http:
- route:
- destination:
host: productpage
subset: v1
—
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
—
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
—
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: details
spec:
hosts:
- details
http:
- route:
- destination:
host: details
subset: v1
—
可以看到，我們通過定義了4個virtualService,分別將訪問productpage,ratings,reviews,details服務的流量路由到v1版本，通過訪問productpage的頁面可以看出，無論我們怎麼刷新，Reviews部分都沒有星星顯示出來，因爲我們定義了規則，將流量至訪問Reviews-v1的版本。
這裏我們簡單解釋下virtualService,virtualService主要用於定義訪問某服務請求的路由。
2.Route based on user identity(基於用戶身份的路由)
顧名思義，istio提供根據用戶的身份將流量路由到指定的版本，當然這裏要求應用支持，例如在本例中，productpage服務請求reviews服務的header中就攜帶了用戶身份的信息。我們通過kubectl提交如下yaml文件，可以看到我們定義了一個virtualService,告訴istio,將header中end-user爲jason的流量路由到reviews的v2版本。
kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
[root@master istio-1.0.2]# cat samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
我們登陸到productpage界面，通過jason的賬號登陸後，無論如何刷新，我們到看到reviews爲黑色的星星.
完成了上述的實驗，接下來我們進行下一個任務Fault Injection
3.Fault Injection(錯誤注入)
Istio之所以提供這個功能，是爲了讓我們能夠測試應用服務的彈性和可靠性，通過Istio，我們能夠模擬服務之間調用的延時和錯誤率，首先我們執行如下命令,我們在yaml文件中創建了一個virtualService,告訴istio,將用戶爲jason的請求路由到reviews的v1版本，並在請求之間加入7秒的延時。
kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml
[root@master istio-1.0.2]# cat samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- match:
- headers:
end-user:
exact: jason
fault:
delay:
percent: 100
fixedDelay: 7s
route:
- destination:
host: ratings
subset: v1
- route:
- destination:
host: ratings
subset: v1
可以看到，通過jason登陸後，頁面在6秒後響應，證明上述規則生效。當然細心的讀者可能返現，爲什麼reviews部分我們得到了錯誤的信息，那是因爲Istio提供的這個案例中，productpage請求reviews服務的時候，在應用內部設置了一個6秒的超時時間，超過6秒後，直接在reviews部分返回錯誤，當然爲了得到正確的結果，我們可以將固定延時時間調到6秒以內，這裏我們改成2.8秒。
4.Traffic Shifting(流量轉移)
這裏istio同樣提供了流量轉移的方法，例如某個服務有多個版本，我們能夠通過 istio將流量按照一定比例叢v1版本遷移到v2版本，甚至到最後將流量完全遷移到v2上面，這樣能夠幫助我們將流量從舊版本遷移到新的版本上面來。這裏我們定義了virtualService，讓50%的流量路由到reviews的v1版本，另外50%的流量路由到reviews的v2版本。
kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml
[root@master istio-1.0.2]# cat samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 50
- destination:
host: reviews
subset: v3
weight: 50
這裏就不截圖了，通過不斷刷新productpage頁面，並記錄我們訪問到v1和v3版本的次數，我們可以大致看到頁面的訪問量趨於1:1。
5.Setting Request Timeouts（設置服務超時時間）
Istio也爲我們提供了服務調用之間的超時時間，默認爲15秒，這裏我們將調用reviews-v2版本的超時時間設置成0.5秒，同時將reviews調用ratings的延遲設置爲2秒，這樣能夠保證productpage在調用reviews服務的時候，不能夠在0.5秒以內返回，從而達到超時時間的設置要求，設置如下圖所示:
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v2
EOF
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- fault:
delay:
percent: 100
fixedDelay: 2s
route:
- destination:
host: ratings
subset: v1
EOF
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v2
timeout: 0.5s
EOF
如上圖所示，在請求productpage後，reviews部分返回了錯誤，並且可以觀察到響應時間在1秒左右。
以上是本次實驗的內容，後續其它的實驗請繼續關注筆者後續的分享。