?大家好，我是不才陳某~

過去，我們運維著“能做一切”的大型單體應用程序。這是一種將產品推向市場的很好的方式，因為剛開始我們也只需要讓我們的第一個應用上線。

而且我們總是可以回頭再來改進它的。部署一個大應用總是比構建和部署多個小塊要容易。

集中式：

集群：

分布式：

分布式和集中式會配合使用。

我們在搭建網站的時候，為了及時響應用戶的請求，尤其是高并發請求的時候，我們需要搭建分布式集群來處理請求。

我們一個服務器的處理能力是有限的。如果用我們一臺設備當作服務器，那么當并發量比較大的時候，同一時間達到上百的訪問量。那服務器就宕機了。然后只能重啟服務器，當出現高并發訪問的時候，就又會宕機。

所以我們需要更多的服務器來并行工作，處理用戶的請求。那么問題來了，我們服務器運行的時候，怎么分發大量的請求給不同的服務器呢？

一般會采用(1apache+nTomcat)或者服務器模式來分發并處理請求。或者采用nginx分發請求。

微服務是運行在自己的進程中的可獨立部署的服務套件。他們通常使用 HTTP 資源進行通信，每個服務通常負責整個應用中的某一個單一的領域。

在流行的電子商務目錄例子中，你可以有一個商品條目服務，一個審核服務和一個評價服務，每個都只專注一個領域。

用這種方法讓多語言服務（使用不同語言編寫的服務）也成為可能，這樣我們就可以讓 Java/C++ 服務執行更多的計算密集型工作，讓 Rails / Node.js 服務更多來支持前端應用等等。推薦公號：碼猿技術專欄，回復關鍵詞：1111 獲取阿里內部java調優手冊

微服務會成為大規模分布式應用的主流架構。任何復雜的工程問題都會歸結為devide and conquer（分而治之），意思就是就是把一個復雜的問題分成兩個或更多的相同或相似的子問題，再把子問題分成更小的子問題……

直到最后子問題可以簡單的直接求解，原問題的解即子問題的解的合并。微服務本質是對服務的拆分，與工程領域慣用的“分而治之”的思路是一致的。

Spring Cloud 與 K8S 對比

兩個平臺 Spring Cloud 和 Kubernetes 非常不同并且它們之間沒有直接的相同特征。

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

Spring Cloud在JVM中非常強大，Kubernetes管理那些JVM很強大。同樣的，它就像一個自然發展，結合兩種工具并且從兩個項目中最好的部分受益。

可以看到，里面差不多一半關注點是和運維相關的。這么看來，似乎拿spring cloud和kubernetes比較有點不公平，spring cloud只是一個開發框架，對于應用如何部署和調度是無能為力的，而kubernetes是一個運維平臺。

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

Spring Cloud vs Istio

這里面哪些內容是我們可以拿掉或者說基于 Service Mesh（以 Istio 為例）能力去做的？

分析下來，可以替換的組件包括網關（gateway 或者 Zuul，由Ingress gateway 或者 egress 替換），熔斷器（hystrix，由SideCar替換），注冊中心（Eureka及Eureka client，由Polit，SideCar 替換），負責均衡（Ribbon，由SideCar 替換），鏈路跟蹤及其客戶端（Pinpoint 及 Pinpoint client，由 SideCar 及Mixer替換）。推薦公號：碼猿技術專欄，回復關鍵詞：1111 獲取阿里內部java調優手冊

這是我們在 Spring Cloud 解析中需要完成的目標：即確定需要刪除或者替換的支撐模塊。

可以說，springcloud關注的功能是kubernetes的一個子集。

可以看出，兩邊的解決方案都是比較完整的。kubernetes這邊，在Istio還沒出來以前，其實只能提供最基礎的服務注冊、服務發現能力（service只是一個4層的轉發代理），istio出來以后，具有了相對完整的微服務能力。

而spring cloud這邊，除了發布、調度、自愈這些運維平臺的功能，其他的功能也支持的比較全面。相對而言，云廠商會更喜歡kubernetes的方案，原因就是三個字：非侵入。

平臺能力與應用層的解耦，使得云廠商可以非常方便的升級、維護基礎設施而不需要去關心應用的情況，這也是我比較看好service mesh這類技術前景的原因。

Spring Boot + K8S

如果不用 Spring Cloud，那就是使用 Spring Boot + K8S。

這里就需要介紹一個項目，Spring Cloud Kubernetes，作用是把kubernetes中的服務模型映射到Spring Cloud的服務模型中，以使用Spring Cloud的那些原生sdk在kubernetes中實現服務治理。

具體來說，就是把k8s中的services對應到Spring Cloud中的services，k8s中的endpoints對應到Spring Cloud的instances。這樣通過標準的Spring Cloud api就可以對接k8的服務治理體系。

老實說，個人認為這個項目的意義并不是很大，畢竟都上k8了，k8本身已經有了比較完善的微服務能力（有注冊中心、配置中心、負載均衡能力），應用之間直接可以互相調用，應用完全無感知，你再通過sdk去調用，有點多此一舉的感覺。

而且現在強調的是語言非侵入，Spring Cloud一個很大的限制是只支持java語言（甚至比較老的j2ee應用都不支持，只支持Spring Boot應用）。所以我個人感覺，這個項目，在具體業務服務層面，使用的范圍非常有限。

借助于Spring Cloud Kubernetes項目，zuul可以以一種無侵入的方式提供api網關的能力，應用完全不需要做任何改造，并且網關是可插拔的，將來可以用其他網關產品靈活替換，整體耦合程度非常低。

得益于k8的service能力，zuul甚至支持異構應用的接入，這是Spring Cloud體系所不具備的。

而本身基于java開發，使得java程序員可以方便的基于zuul開發各種功能復雜的filter，而不需要去學習go或者openresty這樣不太熟悉的語言。

Service Mesh的價值

無論是單體應用，還是分布式應用，都可以建立在Service Mesh上，mesh上的sidecar支撐了所有的上層應用，業務開發者無須關心底層構成，可以用Java，也可以用Go等語言完成自己的業務開發。

當微服務架構體系越來越復雜的時候，需要將“業務服務”和“基礎設施”解耦，將一個微服務進程一分為二：

為什么代理會叫sidecar proxy？

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

未來，sidecar和proxy就指微服務進程解耦成兩個進程之后，提供基礎能力的那個代理進程。

Istio的理論概念是Service Mesh（服務網絡），我們不必糾結于概念實際也是微服務的一種落地形式有點類似上面的SideCar模式。

它的主要思想是關注點分離，即不像SpringCloud一樣交給研發來做，也不集成到k8s中產生職責混亂，Istio是通過為服務配 Agent代理來提供服務發現、負截均衡、限流、鏈路跟蹤、鑒權等微服務治理手段。

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

istio 超越 spring cloud和dubbo 等傳統開發框架之處, 就在于不僅僅帶來了遠超這些框架所能提供的功能, 而且也不需要應用程序為此做大量的改動，開發人員也不必為上面的功能實現進行大量的知識儲備。

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