2014年，Martin Fowler撰寫的《Microservices》使得許多國內的先行者接觸到微服務這個概念並將其引入國內，2015年越來越多的人透過各種渠道瞭解到微服務的概念並有人開始在生產環境中落地，2016-2017年，微服務的概念被越來越多的人認可，帶動了一大批公司以微服務和容器為核心開始技術架構的全面革新。
至今微服務已經歷了兩代發展，第一代以Spring Cloud為代表的微服務開發框架，該框架在微服務發展的前幾年一度獨領風騷，甚至在部分人群中成為微服務的代名詞，但事實上該微服務框架並不是唯一實現微服務的方式；第二代微服務技術為服務網格（Service Mesh），它的出現解決了大部分開發人員在使用Spring Cloud中遇到的不足和痛點。
Service Mesh是如何解決這些問題的，又是何以贏得眾多開發者的支援呢？筆者就這些問題給大家分享一篇以Istio為代表的第二代微服務實踐。
此篇文章分為兩個部分，第一部分為微服務相關概念介紹，第二部分為Istio具體實踐。
服務網格是一個基礎設施層，主要用於處理服務間的通訊。雲原生應用有著複雜的服務拓撲，服務網格負責在這些拓撲中實現請求的可靠傳遞。在實踐中，服務網格通常實現為一組輕量級網路代理，它們與應用程式部署在一起，而對應用程式透明。
圖1展示了服務網格的拓撲，當微服務數量增多達到幾十上百時，服務網格就會呈現服務網格狀，其中綠色為微服務，藍色為服務網格，服務網格以典型的sidecar方式部署在微服務旁。
sidecar：一種單節點、多容器的應用設計形式。sidecar主張以額外的容器來擴充套件或增強主容器，而這個額外的容器被稱為sidecar容器。
Istio是由Google、IBM、Lyft聯合開發的開源專案，2017年5月釋出第一個release 0.1.0， 它是一個完全開源的服務網格，可以透明的分層到現有的分散式應用中，它也是一個平臺，包括允許它整合到任何日誌記錄平臺，遙測或策略系統的API。Istio 多樣化功能集能夠高效的執行在分散式微服務架構中，並同時提供保護、連線和監控微服務等方法。
由圖2可知，Istio架構在網格邏輯上主要分為控制平面（Control Plane API）和資料平面（Data Plane）。
控制平面：負責管理和配置代理來路由流量。主要分為三個元件Pilot、Mixer、Citadel，由於篇幅有限，此處對概念進行簡單介紹：
-
Pilot：為Envoy sidecar提供服務發現功能，為智慧路由和彈性提供管理功能，它將控制流量行為的高階路由轉化為特定於Envoy的配置，併在執行時將它們傳播到sidecar。
-
Mixer：獨立於平臺，負責在Service Mesh上執行訪問控制和使用策略，並從Envoy代理和其它服務中收集遙測資料。
-
Citadel：透過內建身份和憑證管理以提供服務與服務間的身份驗證並且可以升級Service Mesh中未加密的流量。
資料平面：由一組以sidecar方式部署的智慧代理組成，這些代理可以調節和控制微服務及Mixer之間所有的網路通訊。Istio預設使用Envoy做智慧代理，當然也支援其它代理，例如Linkerd、Nginmesh等。
隨著微服務規模的增長，其複雜性也越來越高，其中面臨許多需求，例如服務發現、故障恢復、監控、負載均衡、限流、訪問控制等，Istio提供了一體化的方案，透過為整個Service Mesh提供管理來滿足微服務應用中複雜變換的需求，其中提供了許多非常關鍵的需求：
-
流量管理：控制服務之間流量和API呼叫，使得呼叫更可靠。
-
可觀察性：瞭解服務之間依賴關係，以及它們之間流量的本質和流向。
-
策略執行：策略應用於微服務之間互動，確保訪問策略得以執行（執行是透過配置網格而不是修改程式程式碼）。
-
服務身份安全：為網格中的服務提供可靠身份驗證，並提供保護流量的能力。
Istio實踐主要分為三步，第一步下載並部署Istio；第二步部署Bookinfo微服務；第三步透過指定yaml檔案測試Istio的功能特性。
curl -L https://git.io/getLatestIstio | sh -
進入安裝包目錄後進入install/kubernetes/目錄安裝Kubernetes所需yaml檔案，如圖5所示：
使用kubectl執行istio-demo.yaml檔案（有四種方式安裝，對應有不同的yaml檔案，此處選擇預設不啟用TLS身份驗證的安裝方式，啟用TLS安裝方式的yaml檔案為istio-demo-auth.yaml），安裝過程如圖6所示：
kubectl create –f istio-demo.yaml
顯示已安裝成功（由於安裝內容較多，只截圖了其中一部分），之後檢視已部署的Istio Pod執行狀況：
kubectl get po -o wide --all-namespaces
由圖7可以看出Kubernetes中名稱空間為istio-system的Pod，其中包含許多元件，如用於監控的Grafana、Prometheus，用於服務檢視的ServiceGraph，以及Istio元件citadel、mixer、pilot等。
可以再檢視Istio安裝包中安裝的service，其中PORTS欄可以檢視服務對外暴露的埠號，以便在外部訪問，如圖8所示：
kubectl get svc -n istio-system
為了使用Istio的命令列工具istioctl，需要指定環境變數以便後期使用：
export PATH=/home/xxxx/istio-1.0.0/bin:$PATH
下麵可以簡單看看istioctl的命令使用，如圖9所示：
Bookinfo是Istio提供的一個樣例應用，它由四個單獨的微服務構成，用來演示多種 Istio 特性：
其中所有的微服務都和Envoy sidecar整合在一起，所有服務的出入流量都被Envoy劫持，這樣Istio的控制平面就可以為應用提供服務路由、遙測資料收集以及策略實施等內容。
由於之前已經下載了bookinfo相關yaml檔案，所以直接執行就好了，如圖11、12所示：
kubectl create –f bookinfo.yaml
kubectl create –f bookinfo-gateway.yaml
檢視Kubernetes中Bookinfo應用執行狀況，如圖13所示：
kubectl get po
檢視Bookinfo中service部署情況，如圖14所示：
kubectl get svc
至此Bookinfo應用已部署完畢，那麼如何訪問Bookinfo中的微服務呢？透過前面所講可知Bookinfo有對應的Web微服務productpage，可以透過以下方式訪問：
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istio-system -o 'jsonpath={.items[0].status.hostIP}')
export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
具體操作如圖15所示，可知閘道器入口為20.0.0.13:31380。
測試Bookinfo應用的執行情況，傳回200為正常，如圖16所示：
curl -o /dev/null -s -w "%{http_code}\n" http://${GATEWAY_URL}/productpage
在Chrome瀏覽器中輸入，如圖17所示：http://192.168.19.13:31380/productpage。
上圖可以看出Bookinfo應用由4個微服務組成，即web微服務頁面productpage、頁面左邊部分為Book Details服務，右邊部分為Book Reviews服務， reviews服務目前為v1狀態即無星級評分。由於未設定請求路由，多掃清頁面幾次，請求路由流量會隨機的在reviews服務v1、v2、v3中切換。
此樣例會把Bookinfo應用的進入流量導向reviews服務的v1版本，配置yaml檔案如圖18所示：
圖18 route-rule-all-v1.yaml檔案部分內容
kubectl apply -f route-rule-all-v1.yaml
圖19 route-rule-all-v1.yaml檔案執行過程
此時多次掃清頁面就會發現每次掃清reviews服務始終為v1版本。
如果想看具體的virtualservices和destinationrules可以透過命令檢視：
kubectl get virtualservices -o yaml
kubectl get destinationrules -o yaml
請求也可以基於使用者身份去路由，比如“xx”登入就是reviews服務的v1版本，其它使用者登入則為v2版本。
此樣例會使用Istio測試Bookinfo應用的彈性，具體方式為當使用者jason登入時在reviews:v2和ratings之間進行延遲註入。此樣例對應yaml檔案如圖20所示：
圖20 route-rule-ratings-test-delay.yaml檔案內容
kubectl replace -f route-rule-ratings-test-delay.yaml
圖21 route-rule-ratings-test-delay.yaml檔案執行過程
此時用jason賬號登入就會發現每次請求路由到reviews微服務都要6秒左右，可以開啟chrome瀏覽器開發者工具檢視，並且reviews部分顯示錯誤訊息，如圖22所示：
此樣例會使用Istio將所有使用者的流量按照權重進行轉移，此樣例對應的yaml檔案如圖23所示：
圖23 route-rule-reviews-50-v3.yaml檔案內容
由上圖可知當有流量進入時，百分之五十流量遷移到reviews v1，另外百分之五十流量遷移到reviews v3，終端執行以下命令，如圖21所示：
kubectl replace -f route-rule-reviews-50-v3.yaml
此時掃清頁面就會看到有一半的機率是reviews v3（紅色星），一半機率是reviews v1（無評星）。
此樣例首先將流量全部匯入reviews v2服務，再給ratings服務增加2秒延遲，最後為reviews服務呼叫新增0.5秒請求超時，順序如圖24-29所示：
圖25 productpage頁面顯示reviews v2
最終掃清頁面由圖29顯示，看到傳回時間為1秒左右並且評論不可用，這是為什麼呢?答案是productpage服務有硬編碼重試，因此在頁面掃清時，請求傳回之前需要呼叫超時reviews服務兩次，每次為0.5秒左右，兩次就為1秒左右了。
大家想象下，當微服務的數量增多時，運維人員根據需求需要對部分微服務進行A/B測試，金絲雀釋出或是限流、流量分片等操作，這無疑增加了運維人員的管理複雜度，Istio考慮的非常周全，在安裝包中附加了監控、跟蹤等元件，以下分別展示：
Istio還有許多功能特性例如熔斷機制，控制Ingress流量等，在此由於篇幅限制不多做描述，大家感興趣的話可以去官網檢視https://istio.io/docs/tasks/。
透過以上對Istio的實踐大家不難看出Istio相比於Spring Cloud的幾個優點。首先相比於Spring Cloud學習元件內容多，門檻高的痛點，Istio是非常容易上手的，只需在Kubernetes平臺上跑一個yaml檔案即可完成部署；再者相比於Spring Cloud需要把認證授權、分散式追蹤、監控等這些高階功能加入到應用程式內部導致了應用本身複雜度的痛點，反觀Istio是很輕量級的，它將以上那些高階功能作為元件內建在Istio中，從而達到了對應用程式的無侵入性，只需要配置相應的yaml檔案並下發至Istio控制平面執行後續的操作即可，操作過程使用者是無感知的；最後相比於Spring Cloud對Java環境的過度依賴以及跨語言痛點，Istio也完美的解決了，其支援多種語言，包括新興程式語言Golang、Rust、Node.js、R語言等。
雖然目前Istio在社群有眾多的支持者，但從第一個版本到現在只有不到 一年半的時間，目前Istio國內生產落地的公司還相對較少，華為的CES Mesher、新浪微博的Motan、唯品會的OSP等都已經在使用，阿裡雲和騰訊雲的持續跟進相信也不遠了， Istio的未來一片光明，讓我們共同期待。
基於Kubernetes的DevOps實踐培訓將於2018年8月24日在北京開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：容器特性、映象、網路；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設則；Kubernetes的資料庫、執行時、網路、外掛已經落地經驗；微服務架構、元件、監控方案等，點選下方圖片檢視詳情。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
