Spring Cloud 還沒學(xué)明白，Istio 又是什么鬼？？

推薦閱讀：Spring Cloud Alibaba 終于一統(tǒng)江湖！

背景

過去，我們運(yùn)維著“能做一切”的大型單體應(yīng)用程序。這是一種將產(chǎn)品推向市場(chǎng)的很好的方式，因?yàn)閯傞_始我們也只需要讓我們的第一個(gè)應(yīng)用上線。

而且我們總是可以回頭再來(lái)改進(jìn)它的。部署一個(gè)大應(yīng)用總是比構(gòu)建和部署多個(gè)小塊要容易。

集中式：

集群：

分布式：

分布式和集中式會(huì)配合使用。

我們?cè)诖罱ňW(wǎng)站的時(shí)候，為了及時(shí)響應(yīng)用戶的請(qǐng)求，尤其是高并發(fā)請(qǐng)求的時(shí)候，我們需要搭建分布式集群來(lái)處理請(qǐng)求。

我們一個(gè)服務(wù)器的處理能力是有限的。如果用我們一臺(tái)設(shè)備當(dāng)作服務(wù)器，那么當(dāng)并發(fā)量比較大的時(shí)候，同一時(shí)間達(dá)到上百的訪問量。那服務(wù)器就宕機(jī)了。然后只能重啟服務(wù)器，當(dāng)出現(xiàn)高并發(fā)訪問的時(shí)候，就又會(huì)宕機(jī)。

所以我們需要更多的服務(wù)器來(lái)并行工作，處理用戶的請(qǐng)求。那么問題來(lái)了，我們服務(wù)器運(yùn)行的時(shí)候，怎么分發(fā)大量的請(qǐng)求給不同的服務(wù)器呢？

一般會(huì)采用(1apache+nTomcat)或者服務(wù)器模式來(lái)分發(fā)并處理請(qǐng)求?；蛘卟捎胣ginx分發(fā)請(qǐng)求。

微服務(wù)是運(yùn)行在自己的進(jìn)程中的可獨(dú)立部署的服務(wù)套件。他們通常使用 HTTP 資源進(jìn)行通信，每個(gè)服務(wù)通常負(fù)責(zé)整個(gè)應(yīng)用中的某一個(gè)單一的領(lǐng)域。

在流行的電子商務(wù)目錄例子中，你可以有一個(gè)商品條目服務(wù)，一個(gè)審核服務(wù)和一個(gè)評(píng)價(jià)服務(wù)，每個(gè)都只專注一個(gè)領(lǐng)域。

用這種方法讓多語(yǔ)言服務(wù)（使用不同語(yǔ)言編寫的服務(wù)）也成為可能，這樣我們就可以讓 Java/C++ 服務(wù)執(zhí)行更多的計(jì)算密集型工作，讓 Rails / Node.js 服務(wù)更多來(lái)支持前端應(yīng)用等等。

微服務(wù)會(huì)成為大規(guī)模分布式應(yīng)用的主流架構(gòu)。任何復(fù)雜的工程問題都會(huì)歸結(jié)為devide and conquer（分而治之），意思就是就是把一個(gè)復(fù)雜的問題分成兩個(gè)或更多的相同或相似的子問題，再把子問題分成更小的子問題……

直到最后子問題可以簡(jiǎn)單的直接求解，原問題的解即子問題的解的合并。微服務(wù)本質(zhì)是對(duì)服務(wù)的拆分，與工程領(lǐng)域慣用的“分而治之”的思路是一致的。

Spring Cloud 與 K8S 對(duì)比

兩個(gè)平臺(tái) Spring Cloud 和 Kubernetes 非常不同并且它們之間沒有直接的相同特征。

兩種架構(gòu)處理了不同范圍的MSA障礙，并且它們從根本上用了不同的方法。Spring Cloud方法是試圖解決在JVM中每個(gè)MSA挑戰(zhàn)，然而Kubernetes方法是試圖讓問題消失，為開發(fā)者在平臺(tái)層解決。

Spring Cloud在JVM中非常強(qiáng)大，Kubernetes管理那些JVM很強(qiáng)大。同樣的，它就像一個(gè)自然發(fā)展，結(jié)合兩種工具并且從兩個(gè)項(xiàng)目中最好的部分受益。

可以看到，里面差不多一半關(guān)注點(diǎn)是和運(yùn)維相關(guān)的。這么看來(lái)，似乎拿spring cloud和kubernetes比較有點(diǎn)不公平，spring cloud只是一個(gè)開發(fā)框架，對(duì)于應(yīng)用如何部署和調(diào)度是無(wú)能為力的，而kubernetes是一個(gè)運(yùn)維平臺(tái)。

也許用spring cloud+cloud foundry去和kubernetes比較才更加合理，但需要注意的是，即使加入了cloud foundry的paas能力，spring cloud仍然是“侵入式”的且語(yǔ)言相關(guān)，而kubernetes是“非侵入式”的且語(yǔ)言無(wú)關(guān)。

推薦閱讀：Spring Cloud Alibaba 終于一統(tǒng)江湖！

Spring Cloud vs Istio

這里面哪些內(nèi)容是我們可以拿掉或者說基于 Service Mesh（以 Istio 為例）能力去做的？最新 Spring Cloud 面試題整理好了，大家可以在Java面試庫(kù)小程序在線刷題。

分析下來(lái)，可以替換的組件包括網(wǎng)關(guān)（gateway 或者 Zuul，由Ingress gateway 或者 egress 替換），熔斷器（hystrix，由SideCar替換），注冊(cè)中心（Eureka及Eureka client，由Polit，SideCar 替換），負(fù)責(zé)均衡（Ribbon，由SideCar 替換），鏈路跟蹤及其客戶端（Pinpoint 及 Pinpoint client，由 SideCar 及Mixer替換）。

這是我們?cè)?Spring Cloud 解析中需要完成的目標(biāo)：即確定需要?jiǎng)h除或者替換的支撐模塊。

可以說，springcloud關(guān)注的功能是kubernetes的一個(gè)子集。

可以看出，兩邊的解決方案都是比較完整的。kubernetes這邊，在Istio還沒出來(lái)以前，其實(shí)只能提供最基礎(chǔ)的服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)能力（service只是一個(gè)4層的轉(zhuǎn)發(fā)代理），istio出來(lái)以后，具有了相對(duì)完整的微服務(wù)能力。

而spring cloud這邊，除了發(fā)布、調(diào)度、自愈這些運(yùn)維平臺(tái)的功能，其他的功能也支持的比較全面。相對(duì)而言，云廠商會(huì)更喜歡kubernetes的方案，原因就是三個(gè)字：非侵入。

平臺(tái)能力與應(yīng)用層的解耦，使得云廠商可以非常方便的升級(jí)、維護(hù)基礎(chǔ)設(shè)施而不需要去關(guān)心應(yīng)用的情況，這也是我比較看好service mesh這類技術(shù)前景的原因。

點(diǎn)擊關(guān)注公眾號(hào)，Java干貨及時(shí)送達(dá)

Spring Boot + K8S

如果不用 Spring Cloud，那就是使用 Spring Boot + K8S。Spring Boot 基礎(chǔ)就不介紹了，推薦下這個(gè)實(shí)戰(zhàn)教程：

https://github.com/javastacks/spring-boot-best-practice

這里就需要介紹一個(gè)項(xiàng)目，Spring Cloud Kubernetes，作用是把kubernetes中的服務(wù)模型映射到Spring Cloud的服務(wù)模型中，以使用Spring Cloud的那些原生sdk在kubernetes中實(shí)現(xiàn)服務(wù)治理。

具體來(lái)說，就是把k8s中的services對(duì)應(yīng)到Spring Cloud中的services，k8s中的endpoints對(duì)應(yīng)到Spring Cloud的instances。這樣通過標(biāo)準(zhǔn)的Spring Cloud api就可以對(duì)接k8的服務(wù)治理體系。

老實(shí)說，個(gè)人認(rèn)為這個(gè)項(xiàng)目的意義并不是很大，畢竟都上k8了，k8本身已經(jīng)有了比較完善的微服務(wù)能力（有注冊(cè)中心、配置中心、負(fù)載均衡能力），應(yīng)用之間直接可以互相調(diào)用，應(yīng)用完全無(wú)感知，你再通過sdk去調(diào)用，有點(diǎn)多此一舉的感覺。

而且現(xiàn)在強(qiáng)調(diào)的是語(yǔ)言非侵入，Spring Cloud一個(gè)很大的限制是只支持java語(yǔ)言（甚至比較老的j2ee應(yīng)用都不支持，只支持Spring Boot應(yīng)用）。所以我個(gè)人感覺，這個(gè)項(xiàng)目，在具體業(yè)務(wù)服務(wù)層面，使用的范圍非常有限。

借助于Spring Cloud Kubernetes項(xiàng)目，zuul可以以一種無(wú)侵入的方式提供api網(wǎng)關(guān)的能力，應(yīng)用完全不需要做任何改造，并且網(wǎng)關(guān)是可插拔的，將來(lái)可以用其他網(wǎng)關(guān)產(chǎn)品靈活替換，整體耦合程度非常低。

得益于k8的service能力，zuul甚至支持異構(gòu)應(yīng)用的接入，這是Spring Cloud體系所不具備的。

而本身基于java開發(fā)，使得java程序員可以方便的基于zuul開發(fā)各種功能復(fù)雜的filter，而不需要去學(xué)習(xí)go或者openresty這樣不太熟悉的語(yǔ)言。Spring Boot 學(xué)習(xí)筆記，這個(gè)分享給你看下。

Service Mesh的價(jià)值

無(wú)論是單體應(yīng)用，還是分布式應(yīng)用，都可以建立在Service Mesh上，mesh上的sidecar支撐了所有的上層應(yīng)用，業(yè)務(wù)開發(fā)者無(wú)須關(guān)心底層構(gòu)成，可以用Java，也可以用Go等語(yǔ)言完成自己的業(yè)務(wù)開發(fā)。

當(dāng)微服務(wù)架構(gòu)體系越來(lái)越復(fù)雜的時(shí)候，需要將“業(yè)務(wù)服務(wù)”和“基礎(chǔ)設(shè)施”解耦，將一個(gè)微服務(wù)進(jìn)程一分為二：

為什么代理會(huì)叫sidecar proxy？

看了上圖就容易懂了，biz和proxy相生相伴，就像摩托車(motor)與旁邊的車廂(sidecar)。

未來(lái)，sidecar和proxy就指微服務(wù)進(jìn)程解耦成兩個(gè)進(jìn)程之后，提供基礎(chǔ)能力的那個(gè)代理進(jìn)程。

Istio的理論概念是Service Mesh（服務(wù)網(wǎng)絡(luò)），我們不必糾結(jié)于概念實(shí)際也是微服務(wù)的一種落地形式有點(diǎn)類似上面的SideCar模式。

它的主要思想是關(guān)注點(diǎn)分離，即不像SpringCloud一樣交給研發(fā)來(lái)做，也不集成到k8s中產(chǎn)生職責(zé)混亂，Istio是通過為服務(wù)配 Agent代理來(lái)提供服務(wù)發(fā)現(xiàn)、負(fù)截均衡、限流、鏈路跟蹤、鑒權(quán)等微服務(wù)治理手段。

Istio開始就是與k8s結(jié)合設(shè)計(jì)的，Istio結(jié)合k8s可以牛逼的落地微服務(wù)架構(gòu)。

istio 超越 spring cloud和dubbo 等傳統(tǒng)開發(fā)框架之處, 就在于不僅僅帶來(lái)了遠(yuǎn)超這些框架所能提供的功能, 而且也不需要應(yīng)用程序?yàn)榇俗龃罅康母膭?dòng)，開發(fā)人員也不必為上面的功能實(shí)現(xiàn)進(jìn)行大量的知識(shí)儲(chǔ)備。

但結(jié)論是不是 spring cloud 能做到的，k8s + istio 也能做到？甚至更好？

原文鏈接：https://blog.csdn.net/zhangxin09/article/details/105342762

版權(quán)聲明：本文為CSDN博主「sp42a」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。