使用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：群雄逐鹿烽煙起[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的部署形式提供。下面是官方的架構圖：
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