ServiceMesh-Istio：1. 認識ServiceMesh
初識
前幾年微服務概念火了🚀，微服務火了之後，ServiceMesh隨之崛起。2018年是ServiceMesh評估乃至炒作的一年。雖然ServiceMesh作爲一種新型的技術引發人們廣泛的關注。但是對其重視程度主要停留在評估階段。尚未真正觸及，廣泛採用。但是具備實際功能的ServiceMesh在普及之後，將有望幫助運維人員更輕鬆的管理基於的微服務程序架構。ServiceMesh將有望在不久的將來從炒作階段，過渡至真正的應用層面。在這個階段來臨之前先發制人，系統瞭解一下它。
什麼是ServiceMesh
什麼是ServiceMesh———服務網格，聽起來比較高大上，但是它不是一個具體的東西具體的產品。而且一個概念，理論層面的東西。
這個概念是隨着微服務而來，前幾年微服務火了同時也帶來很多新問題。像服務發現、負載均衡、路由、流量控制、服務間通信的可靠性、監控等等需要解決的問題，然後出現了API網關（API Gateway）可以把服務集中管理起來，解決上述的問題，但是它有一個單點的問題：容易成爲系統的瓶頸，並且實踐起來越來越臃腫，不容易維護。然後一點點出現了ServiceMesh的概念。
上面說的問題都是一個問題：網絡問題。所有能不能把網絡從功能代碼裏面單獨抽離出來，讓他自己實現：服務發現、負載均衡、流量控制去實現熔斷，確保通信的安全。讓應用開發者不在關注這些底層與應用無關東西，甚至完全感知不到這一層的存在，我們就把這個東西叫做ServiceMesh。然而他只是空中樓閣，需要有人去實現它。目前有兩個非常知名的ServiceMesh實現：Linkerd、Istio。
Linkerd
始於2016年的CNCF的官方項目，最初使用Scala語言編寫，1.x的版本的時候是基於物理機、虛擬機的部署，由於最初版本的內存佔用問題，廣受詬病，導致了Conduit項目的開發，Conduit是一個輕量級的服務網格，爲Kubernetes定製，用Rust和Go語言編寫。Conduit項目目前已經合併到Linkerd項目，並在2018年7月發佈爲Linkerd 2．0 版本。鑑於Linkerd 2．x 基於Kubernetes，而Linkerd 1．x 可以基於節點的模式部署，當面臨複雜環境的場景時，人們可以有更靈活的選擇。
Istio
Istio是由三大巨頭Google、IBM和Lyft發起的開源的服務網格項目。該項目在2017年推出，並在2018年7月發佈了1．0版本。可以說Istio是如今最炙手可熱的服務網格，同時他還支持多種平臺的部署，目前支持在kuernetes上部署的服務，使用Cousul註冊的服務，也支持在虛擬機上部署的服務。
Linkerd&&Istio 對比
都是基於sidecar(邊車)模式，在這種模式下每個服務都會分配一個單獨的代理(使用Envoy)，服務之間的通信是通過自身的代理進行轉發，代理會將請求的數據路由到目標服務的代理，改代理再將請求目標的微服務。所有這些代理構成的數據層，有了數據層就需要一個管理它的那就是控制層。控制層需要單位部署。
Linkerd&&Istio 網上對比，總體來說不管是穩定性，功能豐富程度，還是社區知識都是Istio更勝一籌。
gitHub https://github.com/istio/istio 的Star已經達到21.6K，非常火，所有我們選擇Istio來使用。