我對微服務、SpringCloud、k8s、Istio的一些雜想
一、微服務與SOA
“微服務”是一個名詞,沒有這個名詞之前也有“微服務”,一個朗朗上口的名詞能讓大家產生一個認知共識,這對推動一個事務的發展挺重要的,不然你叫微服務他叫小服務的大家很難集中到一個點上。
業界對微服務與SOA的區別爭論比較多大多都是在微觀上對比他們的區別什麼微服務粒度更細啊、微服務沒有ESB啊、微服務通訊相比SOA採用更輕量級的協議啊等等,但是從微觀談區別本身就有悖論,
這些區別只是微服務的一種”最佳實踐“而已。我個人理解微服務與SOA靈魂上的不同是
微服務是網際網路時代的產物而SOA是系統整合的產物,微服務是對系統的打散而SOA是對系統的整合。
二、 微服務與SpringCloud
因為SpringCloud的流行很多人就把SpringCloud等同於微服務,這也沒有錯共識的人多了就是對的。準確點說SpringCloud是適合實現微服務的一套基礎框架,SpringCloud有助於訊速的落地微服務架構。SpringCloud是以Java庫的形式工作所以它的工作層面是在應用層(研發層)。
SpringCloud通過提供一籃子解決方案來應對微服務中的各種需求和通點,通過Eureka提供服務註冊與發現,Ribbon實現客戶端的負載均衡,Feign牛逼的將REST變成強型別的介面呼叫,Config提供方便但不靈活的配置中心,Hystrix提供熔斷方案,Zuul提供閘道器方案等。
優點:
1、提供較全的微服務治理全套解決方案
2、對開發人員友好(對程式碼侵入強)
缺點:
1、只能java平臺技術棧使用,當然提供了SideCar用於整合異構技術但是限制比較大
2、對開發人員友好(對程式碼侵入強)
三、Kubernetes(k8s)
k8s並不是因為微服務而生而是因為docker而生只是天時地利人和正好趕上了微服務流行的時代,docker的特性正好特別適用於微服務,而k8s進一步對docker方便的編排。從基礎設施方向來講k8s可以比作是IDC機房和機房工作人員,對物理伺服器(docker)的存放與管理,上機架、裝系統、接網路等等。從微服務的角度來講,k8s通過基礎設施的方式通過邏輯抽象出service等概念提供了對微服務的另一種實現,就好比用N臺電腦聯網提供了FTP服務。
優點:
1、在基礎層提供了抽象,對程式碼無侵入
缺點:
1、對微服務治理比較弱,如熔斷限流等,當然這也不應該是k8s做的。
四、Istio
Istio的理論概念是Service Mesh(服務網路),我們不必糾結於概念實際也是微服務的一種落地形式有點類似上面的SideCar模式,它的主要思想是關注點分離,即不像SpringCloud一樣交給研發來做,也不整合到k8s中產生職責混亂,Istio是通過為服務配 Agent代理來提供服務發現、負截均衡、限流、鏈路跟蹤、鑑權等微服務治理手段。
Istio開始就是與k8s結合設計的,Istio結合k8s可以牛逼的落地微服務架構。
優點:
1、關注點分離,對程式碼無侵入
2、服務治理相關較全面
缺點:
1、老子學不動了
五、我理想中的微服務架構
&n