一、現有微服務架構
微服務本質上是分佈式架構、分佈式應用、分佈式計算。
分佈式計算可以帶來的好處有：性能、可靠性、彈性、可擴展性、可用性、穩健性。
而從應用開發者角度看，使用微服務架構必須考慮：斷路、服務發現、
客戶端負載平衡等組件。也就是說，開發人員需要在應用邏輯中考慮太多的PaaS基礎設計相關的內容，所以他們很煩。。。：
現有主流的微服務架構是這樣的：
也就是說，通過各種組件拼湊而成，當然，通過現有的模式，搭建實驗環境，做Demo展示是完全沒問題的，例如此前我做的實驗，通過Spring Cloud搭建一個電商：
但老實說，代碼比較複雜：
而且這還只是一個實驗，如果真的大規模上生產，我相信現有Spring Cloud的複雜度還是非常高的。所以有的客戶，只使用了Spring Cloud的某幾個組件，而非整套上，這其實是比較明智的。
而架構複雜的原因是：現有微服務模式，需要應用開發人員過多地考慮PaaS基礎架構！
二、新一代微服務架構
Istio是新一代微服務架構，這個觀點我在去年的文章中已經介紹過了。今天我們看一下這種架構的優勢。這個架構的核心觀點，就是提供一種：儘量減少開發人員處理其應用程序分佈式特性的要求的微服務架構。
如果說目前的微服務架構，只針整個PaaS的第七層，因此開發人員非常累，需要考慮的點很多。而Istio，面向的是PaaS的4-6層。這樣，開發人員只需要關注大麥本身即可。
Istio的架構圖如下：
Istio分為數據平面和控制平面。
Istio的管理平面有三個核心組件：
Pilot：負責流量管理髮現
Mixer負責：訪問控制、策略管理、信息收集
Auth:負責認證
Istio的數據平面創建了一個跨平臺的服務網格來解決常見的微服務架構問題，如其中包括很多：通信，負載平衡，流量路由，指標，配額，身份驗證，速率限制，斷路器，超時，自動重試，等等。Istio的數據平面採取sidecars的方式，也就是在一個pod的主容器旁邊，增加一個istio的proxy。
我看看一下，在istio模式下，容器的通訊方式。例如Service和ServiceB。ServiceA和ServiceB分別屬於兩個pod。
我們再看得細一些：
我們查看一個調用istio的應用：
這個pod有兩個容器，一個是主應用bookinfo-productpage,一個是istio/proxy。
我們看一下我們如何可以利用Pilot規則控制應用，策略一共有三個：
DestinationPolicy:
●Client-side load-balancing, circuit-breaking
這個策略主要負責應用之間的負載均衡、熔斷。
我們看一個設置策略的例子：裡面設置了http最大請求連接數等。超出閾值，會觸發熔斷。
EgressRule
●Enable whitelist access to external (HTTP/S) services
●External access is off by default in Istio
這個策略控制應用訪問外部網絡，設置白名單的策略。默認是不能訪問外部網絡的。
RouteRule
●Timeouts, retries, fault injection, http rewriting and redirection
這策略主要設置應用之間通信的路由策略，屬於Ingress策略。
我們看一個使用例子，在應用的yaml文件中定義Ingress resource策略：
三、實驗驗證Istio
使用OCP3.7的環境。先創建項目：
oc new-project istio-system
增加SA權限：
oc adm policy add-scc-to-user anyuid -z istio-ingress-service-account -n istio-system oc adm policy add-scc-to-user anyuid -z istio-grafana-service-account -n istio-system oc adm policy add-scc-to-user anyuid -z istio-prometheus-service-account -n istio-system
oc adm policy add-scc-to-user privileged -z default -n bookinfo
下載istio的包：
curl -L https://git.io/getLatestIstio | sh -
cd istio-0.5.0
export PATH=$PWD/bin:$PATH
安裝istio：
kubectl apply -f install/kubernetes/istio.yaml
查看部署的相關istio組件：
截至到目前，istio相關的內容就配好了：
接下來，部署一個應用調用istio，應用的名稱叫bookinfo，就是定票信息網站。
這個應用也是一套微服務，有產品描述、評論、評級、詳細信息。
不是應用使用一個yaml：samples/bookinfo/kube/bookinfo.yaml，我們看一下這個yaml的主要內容：
我們看一下文件中對詳細信息服務的定義：
查看評級服務的定義：
評論服務：
查看產品定義：
yaml文件的最後部分，是調用istio ingress策略的描述：
所以，在istio模式下，對於開發人員而言，不用再過多考慮PaaS基礎架構層面的東西。
通過yaml文件部署微服務：
oc adm policy add-scc-to-user privileged -z default -n bookinfo
配置route：
oc expose svcproductpage --name=productpage --path=/productpage--hostname=productpage-bookinfo.example.com
oc expose svc productpage --name=productpage-login --path=/login--hostname=productpage-bookinfo.example.com
接下來，設置ingress路徑：
oc get routes productpage -o jsonpath='{.spec.host}'
把Gateway的URL設置成productpage-istio-system.apps.example.com
通過瀏覽器訪問應用：
訪問normal user，可以看到用戶是json，顯示的信息是莎士比亞的作品“錯誤喜劇”的票據信息，包括預定信息、話劇評論等。
接下來，我們展示如何在線更換路由策略。我們更換的路由策略，實際上就是微服務之間相互調用的策略。
在這個實驗中，有多個routes相關的yaml文件。
在沒有路由的情況下，頁面展示如下（將已有路由刪除），裡面沒有評論相關內容，因為微服務之前的路由被刪除了：
創建並使用V1版本的路由：
瀏覽器訪問頁面如下（已經出現了評論，但沒有出現rating）：
創建V3版本的路由：然後將路由在線替換到V3：
重新訪問頁面（已經可以看到rating的信息）：
同樣，我們可以設置在多個版本路由之間的訪問比率：
然後我們訪問頁面，在線點擊頁面刷新：
刷新一次：
再刷新一次（頁面回來了）：
也就是說，我們可以通過簡單的替換路由的方式，改變微服務之間的調用關係。
在Istio中，我們可以部署prometheus、Metrics、Tracing，這些都是istio的addson：
oc apply -f prometheus.yaml
oc expose svc prometheus
oc apply -n istio-system -fhttps://raw.githubusercontent.com/jaegertracing/jaeger-kubernetes/master/all-in-one/jaeger-all-in-one-template.yml
oc expose -nistio-system deployment jaeger-deployment --name=jaeger --port=16686
oc expose svc jaeger
查看產品定義：
yaml文件的最後部分，是調用istio ingress策略的描述：
所以，在istio模式下，對於開發人員而言，不用再過多考慮PaaS基礎架構層面的東西。
通過yaml文件部署微服務：
oc adm policy add-scc-to-user privileged -z default -n bookinfo
配置route：
oc expose svcproductpage --name=productpage --path=/productpage--hostname=productpage-bookinfo.example.com
oc expose svc productpage --name=productpage-login --path=/login--hostname=productpage-bookinfo.example.com
接下來，設置ingress路徑：
oc get routes productpage -o jsonpath='{.spec.host}'
把Gateway的URL設置成productpage-istio-system.apps.example.com
通過瀏覽器訪問應用：
訪問normal user，可以看到用戶是json，顯示的信息是莎士比亞的作品“錯誤喜劇”的票據信息，包括預定信息、話劇評論等。
接下來，我們展示如何在線更換路由策略。我們更換的路由策略，實際上就是微服務之間相互調用的策略。
在這個實驗中，有多個routes相關的yaml文件。
在沒有路由的情況下，頁面展示如下（將已有路由刪除），裡面沒有評論相關內容，因為微服務之前的路由被刪除了：
創建並使用V1版本的路由：
瀏覽器訪問頁面如下（已經出現了評論，但沒有出現rating）：
創建V3版本的路由：然後將路由在線替換到V3：
重新訪問頁面（已經可以看到rating的信息）：
同樣，我們可以設置在多個版本路由之間的訪問比率：
然後我們訪問頁面，在線點擊頁面刷新：
刷新一次：
再刷新一次（頁面回來了）：
也就是說，我們可以通過簡單的替換路由的方式，改變微服務之間的調用關係。
在Istio中，我們可以部署prometheus、Metrics、Tracing，這些都是istio的addson：
oc apply -f prometheus.yaml
oc expose svc prometheus
oc apply -n istio-system -fhttps://raw.githubusercontent.com/jaegertracing/jaeger-kubernetes/master/all-in-one/jaeger-all-in-one-template.yml
oc expose -nistio-system deployment jaeger-deployment --name=jaeger --port=16686
oc expose svc jaeger
然後可以看到豐富的頁面：
