我對微服務、SpringCloud、k8s、Istio的一些雜想

1、微服務與SOA

       「微服務」是一個名詞，沒有這個名詞以前也有「微服務」，一個朗朗上口的名詞能讓你們產生一個認知共識，這對推進一個事務的發展挺重要的，否則你叫微服務他叫小服務的你們很難集中到一個點上。

業界對微服務與SOA的區別爭論比較多大多都是在微觀上對比他們的區別什麼微服務粒度更細啊、微服務沒有ESB啊、微服務通信相比SOA採用更輕量級的協議啊等等，可是從微觀談區別自己就有悖論，

這些區別只是微服務的一種」最佳實踐「而已。我我的理解微服務與SOA靈魂上的不一樣是

微服務是互聯網時代的產物而SOA是系統集成的產物，微服務是對系統的打散而SOA是對系統的整合。

 

2、 微服務與SpringCloud

        由於SpringCloud的流行不少人就把SpringCloud等同於微服務，這也沒有錯共識的人多了就是對的。準確點說SpringCloud是適合實現微服務的一套基礎框架，SpringCloud有助於訊速的落地微服務架構。SpringCloud是以Java庫的形式工做因此它的工做層面是在應用層（研發層）。

SpringCloud經過提供一籃子解決方案來應對微服務中的各類需求和通點，經過Eureka提供服務註冊與發現，Ribbon實現客戶端的負載均衡，Feign牛逼的將REST變成強類型的接口調用，Config提供方便但不靈活的配置中心，Hystrix提供熔斷方案，Zuul提供網關方案等。

優勢：

一、提供較全的微服務治理全套解決方案

二、對開發人員友好（對代碼侵入強）

缺點：

一、只能java平臺技術棧使用，固然提供了SideCar用於集成異構技術可是限制比較大

二、對開發人員友好（對代碼侵入強）

 

3、Kubernetes(k8s)

        k8s並非由於微服務而生而是由於docker而生只是天時地利人和正好遇上了微服務流行的時代，docker的特性正好特別適用於微服務，而k8s進一步對docker方便的編排。從基礎設施方向來說k8s能夠比做是IDC機房和機房工做人員，對物理服務器（docker）的存放與管理，上機架、裝系統、接網絡等等。從微服務的角度來說，k8s經過基礎設施的方式經過邏輯抽象出service等概念提供了對微服務的另外一種實現，就比如用N臺電腦聯網提供了FTP服務。

優勢：

一、在基礎層提供了抽象，對代碼無侵入

缺點：

一、對微服務治理比較弱，如熔斷限流等，固然這也不該該是k8s作的。

 

4、Istio

       Istio的理論概念是Service Mesh（服務網絡），咱們沒必要糾結於概念實際也是微服務的一種落地形式有點相似上面的SideCar模式，它的主要思想是關注點分離，即不像SpringCloud同樣交給研發來作，也不集成到k8s中產生職責混亂，Istio是經過爲服務配 Agent代理來提供服務發現、負截均衡、限流、鏈路跟蹤、鑑權等微服務治理手段。

Istio開始就是與k8s結合設計的，Istio結合k8s能夠牛逼的落地微服務架構。

優勢：

一、關注點分離，對代碼無侵入

二、服務治理相關較全面

缺點：

一、老子學不動了

 

5、我理想中的微服務架構