一、概述
本文闡述微服務架構演進的過程。
二、單體應用
英文稱之爲Monolithic Application，此時應用是單進程的，由該進程起EndPoint（即監聽端口）對外提供服務。
優點：
- 代碼調試簡單
- 服務之間調用是簡單的方法調用，出錯概率低，錯誤處理簡單
- 日誌聚合，方便排查問題。
缺點：
- 隨着應用規模增長，無法支撐高併發量
- 任意模塊代碼修改都要重新發布整個應用
- 開發團隊規模大，難以管理
傳統解決方案：
- 使用nginx等反向代理設備進行負載均衡，通過集羣的方式提供服務，解決併發訪問的問題
- 後端數據庫服務，通過主從複製，分庫分表，或者通過數據庫中間件mycat等解決數據庫訪問壓力
…
三、微服務架構誕生
爲了解決單體架構存在的問題，微服務架構（micro service）誕生了。最初是Martin Fowler第一次系統性的闡述了這一架構：https://www.martinfowler.com/articles/microservices.html
簡單來說，微服務架構將單體應用，根據業務拆分爲多個獨立的微服務。微服務直接通過網絡通信的方式，相互調用，組成整個應用程序。
優點：
- 微服務可橫向擴展，訪問量大的微服務實例多，訪問量少的可相對少
- 一個微服務可以由一個小團隊管理
- 微服務之間可以使用不同的技術棧，如java, nodejs等
缺點：
- 引入了服務註冊發現，負載均衡、服務熔斷、服務治理等新的難題
- 增加了業務代碼編寫的難度，現在要處理服務調用相關的問題
- 排查問題困難，日誌分散
- 根據技術棧的不同，微服務之間可能有很強的依賴性，如dubbo框架
在微服務架構剛開始流行的時候，大家主要通過SpringCloud、Dubbo等微服務框架實現微服務，難度較大，上手難度高。
四、容器化
隨着docker技術的流行，應用容器化成爲主流。
容器化解決的是應用部署的難題：通過把所有的環境打包到鏡像，只要當前環境部署了docker，應用就能隨時部署擴容。
並且，容器之間相互隔離，互不影響。
五、Kubernetes
Kubernetes是Docker的分佈式解決方案，是一個分佈式的容器編排平臺。
docker雖然簡化了應用部署的難題，但是在服務治理方面的能力較弱，並且不是分佈式的解決方案。
通過Kubernetes，可以很容易實現應用的擴容縮容，應用監控、應用升級、服務註冊發現等功能。
其實在k8s的層面，已經實現了服務發現，負載均衡等功能了；可以發現SpringCloud、Dubbo等框架和k8s平臺存在功能重複的問題。
六、istio服務網格
Service Mesh是近兩年提出的概念，意爲微服務之間相互調用的網絡。
k8s雖然解決了服務自動擴容縮容等問題，但無法控制服務之間的網絡調用。
於是istio等服務網格平臺，通過sidecar模式，實現了在應用無感知的情況下，對服務之間網絡調用的控制。
原理如下：
在k8s的pod中，除了service的container之外，會注入istio的sidecar container，這個sidecar會攔截所有進入pod的網絡流量（通過改寫iptable規則實現），也會攔截所有從pod發出去的流量。由於所有的網絡流量都經過sidecar，通過配置相關的規則，istio可以實現對網絡流量的控制、加密、觀測等功能。
最重要的是，這一些都是應用無感知的，也就是說，應用幾乎無需做任何改造，只需要提供相應的配置給到istio，就可以享受這些功能。
感覺上，有了istio，傳統微服務框架中，服務註冊發現、服務熔斷、限流、負載均衡等功能都沒有必要存在了。你需要做的只是簡單的發起一個http服務調用（或者是grpc等），其他的一切留給istio處理。
但目前服務網格還沒有大規模應用，並且由於引入sidecar等間接層，對服務性能也有一定的影響，服務網格的未來還不可知。
七、總結
單體架構轉化爲微服務架構，微服務架構是主流。
docker、k8s解決的是應用部署、應用狀態監控，應用擴容縮容等服務治理的問題。這些工具的出現，使得擁抱微服務架構的難度大大降低了。
istio的出現，進一步解決了微服務網格之間，網絡流量的控制、加密、觀測等問題。