在軟件行業(yè)，微服務(wù)架構(gòu)是一種重要的發(fā)展趨勢(shì)。這一趨勢(shì)，不僅僅是對(duì)企業(yè)內(nèi)的IT信息系統(tǒng)建設(shè)，甚至在企業(yè)向數(shù)字化轉(zhuǎn)型方面，都有著深遠(yuǎn)的影響。
什么是微服務(wù)架構(gòu)？
微服務(wù)架構(gòu)（也可簡(jiǎn)稱為微服務(wù)）是一種依賴于一系列可獨(dú)立部署服務(wù)的架構(gòu)方法。這些服務(wù)有自己的業(yè)務(wù)邏輯和數(shù)據(jù)庫(kù)，并負(fù)責(zé)實(shí)現(xiàn)特定的目標(biāo)。更新、測(cè)試、部署和擴(kuò)展都在每一項(xiàng)服務(wù)中進(jìn)行。微服務(wù)可將特定于領(lǐng)域的主要業(yè)務(wù)問(wèn)題分解為單獨(dú)的獨(dú)立代碼庫(kù)。微服務(wù)不會(huì)降低復(fù)雜性，但它們可將任務(wù)劃分成彼此獨(dú)立運(yùn)行且對(duì)整體有益的較小流程，從而使任何復(fù)雜情況都變得一目了然且更易管理。微服務(wù)通常與 DevOps 并駕齊驅(qū)，因?yàn)樗鼈兪浅掷m(xù)交付實(shí)踐的基礎(chǔ)，可讓團(tuán)隊(duì)快速適應(yīng)用戶需求。
SpringCloud 和 K8s 對(duì)比
兩種架構(gòu)處理了不同范圍的MSA障礙，并且它們從根本上用了不同的方法。Spring Cloud方法是試圖解決在JVM中每個(gè)MSA挑戰(zhàn)，然而Kubernetes方法是試圖讓問(wèn)題消失，為開發(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)。
SpringCloud 和 istio 對(duì)比
這里面哪些內(nèi)容是我們可以拿掉或者說(shuō)基于 Service Mesh（以 Istio 為例）能力去做的？
分析下來(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除或者替換的支撐模塊。
可以說(shuō)，springcloud關(guān)注的功能是kubernetes的一個(gè)子集。
可以看出，兩邊的解決方案都是比較完整的。kubernetes這邊，在Istio還沒(méi)出來(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ù)前景的原因。
也許用spring cloud+cloud foundry去和kubernetes比較才更加合理，但需要注意的是，即使加入了cloud foundry的paas能力，spring cloud仍然是“侵入式”的且語(yǔ)言相關(guān)，而kubernetes是“非侵入式”的且語(yǔ)言無(wú)關(guān)。
ServiceMesh的價(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是通過(guò)為服務(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ǔ)備。
Istio探索和實(shí)踐——SolarMesh
SolarMesh 是基于 Istio 及容器技術(shù)，提供流量監(jiān)控和管理，提供完善的非侵入式服務(wù)治理解決方案。
SolarMesh 功能：
-
· 幫助企業(yè)在紛繁復(fù)雜的微服務(wù)調(diào)度中快速定位問(wèn)題，增強(qiáng)研發(fā)效率。
-
· 通過(guò)流量灰度讓版本更新更加平滑，降低版本升級(jí)風(fēng)險(xiǎn)。
-
· 支持實(shí)時(shí)反映真實(shí)集群狀態(tài)，以流量的角度凸顯業(yè)務(wù)問(wèn)題，增強(qiáng)運(yùn)維能力。
-
· 支持多集群管理，可對(duì)接任意數(shù)量的標(biāo)準(zhǔn)k8s集群，接入成本極低。
SolarMesh架構(gòu)圖
Istio 與 SolarMesh 對(duì)比
體驗(yàn)SolarMesh，從這里開始！
原文部分素材來(lái)源：https://mp.weixin.qq.com/s/Qd6ZWYvQ2VIIy1jM2y3L1Q
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數(shù)字化創(chuàng)新平臺(tái)CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務(wù)Methodot
