Spring Cloud基于Spring Boot開發(fā)卒茬，提供一套完整的微服務(wù)解決方案，具體包括服務(wù)注冊與發(fā)現(xiàn)咖熟，配置中心扬虚，全鏈路監(jiān)控，API網(wǎng)關(guān)球恤，熔斷器辜昵，遠(yuǎn)程調(diào)用框架，工具客戶端等選項(xiàng)中立的開源組件咽斧，并且可以根據(jù)需求對部分組件進(jìn)行擴(kuò)展和替換堪置。
Service Mesh，這里以Istio（目前Service Mesh具體落地實(shí)現(xiàn)的一種张惹，且呼聲最高）為例簡要說明其功能舀锨。 Istio 有助于降低這些部署的復(fù)雜性，并減輕開發(fā)團(tuán)隊(duì)的壓力宛逗。它是一個(gè)完全開源的服務(wù)網(wǎng)格坎匿，可以透明地分層到現(xiàn)有的分布式應(yīng)用程序上。它也是一個(gè)平臺雷激，包括允許它集成到任何日志記錄平臺替蔬、遙測或策略系統(tǒng)的 API。Istio的多樣化功能集使你能夠成功高效地運(yùn)行分布式微服務(wù)架構(gòu)屎暇，并提供保護(hù)承桥、連接和監(jiān)控微服務(wù)的統(tǒng)一方法。
從上面的簡單介紹中根悼，我們可以看出為什么會存在要把Spring Cloud體系的應(yīng)用遷移到Service Mesh這樣的需求凶异，總結(jié)下來蜀撑，有四方面的原因：
功能重疊
來簡單看一下他們的功能對比：
| 功能列表 | Spring Cloud | Istio |
|---|---|---|
| 服務(wù)注冊與發(fā)現(xiàn)支持 | 基于Eureka，consul等組件剩彬，提供server酷麦，和Client管理支持 | 基于XDS接口獲取服務(wù)信息，并依賴“虛擬服務(wù)路由表”實(shí)現(xiàn)服務(wù)發(fā)現(xiàn) |
| 鏈路監(jiān)控支持 | 基于Zikpin或者Pinpoint或者Skywalking實(shí)現(xiàn)支持 | 基于sideCar代理模型喉恋，記錄網(wǎng)絡(luò)請求信息實(shí)現(xiàn) |
| API網(wǎng)關(guān)支持 | 基于zuul或者spring-cloud-gateway實(shí)現(xiàn)支持 | 基于Ingress gateway以及egress實(shí)現(xiàn) |
| 熔斷器支持 | 基于Hystrix實(shí)現(xiàn)支持 | 基于聲明配置文件贴铜，最終轉(zhuǎn)化成路由規(guī)則實(shí)現(xiàn) |
| 服務(wù)路由支持 | 基于網(wǎng)關(guān)層實(shí)現(xiàn)路由轉(zhuǎn)發(fā)支持 | 基于iptables規(guī)則實(shí)現(xiàn) |
| 安全策略支持 | 基于spring-security組件實(shí)現(xiàn)，包括認(rèn)證瀑晒，鑒權(quán)等绍坝，支持通信加密支持 | 基于RBAC的權(quán)限模型，依賴Kubernetes實(shí)現(xiàn)苔悦，同時(shí)支持通信加密 |
| 配置中心支持 | springcloud-config組件實(shí)現(xiàn) | 不支持 |
| 性能監(jiān)控支持 | 基于Spring cloud提供的監(jiān)控組件收集數(shù)據(jù)轩褐，對接第三方的監(jiān)控?cái)?shù)據(jù)存儲支持 | 基于SideCar代理，記錄服務(wù)調(diào)用性能數(shù)據(jù)玖详，并通過metrics adapter把介，導(dǎo)入第三方數(shù)據(jù)監(jiān)控工具 |
| 日志收集支持 | 提供client，對接第三方日志系統(tǒng)蟋座，例如ELK支持 | 基于SideCar代理拗踢，記錄日志信息，并通過log adapter向臀，導(dǎo)入第三方日志系統(tǒng) |
| 工具客戶端集成支持 | 提供消息巢墅，總線，部署管道券膀，數(shù)據(jù)處理等多種工具客戶端SDK | 不支持 |
| 分布式事務(wù)支持 | 支持不同的分布式事務(wù)模式：JTA君纫，TCC，SAGA等芹彬，并且提供實(shí)現(xiàn)的SDK框架 | 不支持 |
其他…………
從上面表格中可以看到蓄髓，如果從功能層面考慮，Spring Cloud與Service Mesh在服務(wù)治理場景下舒帮，有相當(dāng)大量的重疊功能会喝，從這個(gè)層面而言，為Spring Cloud向Service Mesh遷移提供了一種潛在的可能性玩郊。
服務(wù)容器化
在行業(yè)當(dāng)前環(huán)境下肢执，還有一個(gè)趨勢，或者說是現(xiàn)狀瓦宜。越來越多的應(yīng)用走在了通往應(yīng)用容器化的道路上蔚万，或者在未來，容器化會成為應(yīng)用部署的標(biāo)準(zhǔn)形態(tài)临庇。而且無論哪種容器化運(yùn)行環(huán)境反璃，都天然支撐服務(wù)注冊發(fā)現(xiàn)這一基本要求，這就導(dǎo)致Spring Cloud體系應(yīng)用上容器的過程中假夺，存在一定的功能重疊淮蜈，有可能為后期的應(yīng)用運(yùn)維帶來一定的影響，而Service Mesh恰恰需要依賴容器運(yùn)行環(huán)境已卷，同時(shí)彌補(bǔ)了容器環(huán)境所欠缺的內(nèi)容（后續(xù)會具體分析）梧田。
術(shù)業(yè)有專攻
從軟件設(shè)計(jì)角度出發(fā)，我們一直在追求松耦合的架構(gòu)侧蘸，也希望做到領(lǐng)域?qū)９ゲ妹小＠鐦I(yè)務(wù)開發(fā)人員希望我只要關(guān)心業(yè)務(wù)邏輯即可，不需要關(guān)心鏈路跟蹤讳癌，熔斷穿稳，服務(wù)注冊發(fā)現(xiàn)等支撐工具的服務(wù)；而平臺支撐開發(fā)人員晌坤，則希望我的代碼中不要包含任何業(yè)務(wù)相關(guān)的內(nèi)容逢艘。而Service Mesh的出現(xiàn)，讓這種情況成為可能骤菠。
語言壁壘
目前而言Spring Cloud雖然提供了對眾多協(xié)議的支持它改，但是受限于Java技術(shù)體系。這就要求應(yīng)用需要在同一種語言下進(jìn)行開發(fā)（這不一定是壞事兒）商乎，在某種情況下央拖，不一定適用于一些工作場景。而從微服務(wù)設(shè)計(jì)考慮鹉戚，不應(yīng)該受限于某種語言爬泥，各個(gè)服務(wù)應(yīng)該能夠相互獨(dú)立，大家需要的是遵循通信規(guī)范即可崩瓤。而Service Mesh恰好可以消除服務(wù)間的語言壁壘袍啡，同時(shí)實(shí)現(xiàn)服務(wù)治理的能力。
基于以上四點(diǎn)原因却桶，當(dāng)下環(huán)境境输，除了部分大多已經(jīng)提前走在了Service Mesh實(shí)踐的道路上互聯(lián)網(wǎng)大廠以外（例如螞蟻金服的SOFASTACK），也有大部分企業(yè)已經(jīng)開始接觸Service Mesh颖系，并且嘗試把Spring Cloud構(gòu)建的應(yīng)用嗅剖，遷移到Service Mesh中。
Spring Cloud向Service Mesh的遷移方案
Spring Cloud向Service Mesh遷移嘁扼，從我們考慮而言大體分為七個(gè)步驟信粮，如圖所示：
Spring Cloud架構(gòu)解析
Spring Cloud架構(gòu)解析的目的在于確定需要從當(dāng)前的服務(wù)中去除與Service Mesh重疊的功能，為后續(xù)服務(wù)替換做準(zhǔn)備趁啸。我們來看一個(gè)典型的Spring Cloud架構(gòu)體系强缘，如圖所示：
從圖中我們可以簡要的分析出督惰，一個(gè)基于Spring Cloud的微服務(wù)架構(gòu)，主要包括四部分內(nèi)容：服務(wù)網(wǎng)關(guān)旅掂，應(yīng)用服務(wù)赏胚，外圍支撐組件，服務(wù)管理控制臺商虐。
服務(wù)網(wǎng)關(guān)
服務(wù)網(wǎng)關(guān)涵蓋的功能包括路由觉阅，鑒權(quán)，限流秘车，熔斷典勇，降級等對入站請求的統(tǒng)一攔截處理。具體可以進(jìn)一步劃分為外部網(wǎng)關(guān)（面向互聯(lián)網(wǎng)）和內(nèi)部網(wǎng)關(guān)（面向服務(wù)內(nèi)部管理）叮趴。
應(yīng)用服務(wù)
應(yīng)用服務(wù)是企業(yè)業(yè)務(wù)核心割笙。應(yīng)用服務(wù)內(nèi)部由三部分內(nèi)容構(gòu)成：業(yè)務(wù)邏輯實(shí)現(xiàn)，外部組件交互SDK集成疫向，服務(wù)內(nèi)部運(yùn)行監(jiān)控集成咳蔚。
外圍支撐組件
外圍支撐組件，涵蓋了應(yīng)用服務(wù)依賴的工具搔驼，包括注冊中心谈火，配置中心，消息中心舌涨，安全中心糯耍，日志中心等。
服務(wù)管理控制臺
服務(wù)管理控制臺面向服務(wù)運(yùn)維或者運(yùn)營人員囊嘉，實(shí)現(xiàn)對應(yīng)用服務(wù)運(yùn)行狀態(tài)的實(shí)時(shí)監(jiān)控温技，以及根據(jù)情況需要能夠動態(tài)玩成在線服務(wù)的管理和配置。
這里面哪些內(nèi)容是我們可以拿掉或者說基于Service Mesh（以Istio為例）能力去做的扭粱？分析下來舵鳞，可以替換的組件包括網(wǎng)關(guān)（gateway或者Zuul，由Ingress gateway或者egress替換）琢蛤，熔斷器（hystrix蜓堕，由SideCar替換），注冊中心（Eureka及Eureka client博其，由Polit套才，SideCar替換），負(fù)責(zé)均衡（Ribbon慕淡，由SideCar替換）背伴，鏈路跟蹤及其客戶端（Pinpoint及Pinpoint client，由SideCar及Mixer替換）。這是我們在Spring Cloud解析中需要完成的目標(biāo)：即確定需要?jiǎng)h除或者替換的支撐模塊傻寂。
服務(wù)改造
服務(wù)單元改造的目的在于基于第一步的解析結(jié)果息尺，完成依賴去除或者依賴替換。根據(jù)第一步的分析結(jié)果服務(wù)單元改造分為三步：
刪除組件崎逃，包括網(wǎng)關(guān)掷倔，熔斷器眉孩，注冊中心个绍，負(fù)載均衡，鏈路跟蹤組件浪汪，同時(shí)刪除對應(yīng)client的SDK巴柿；
替換組件，采用httpClient 的SDK支持http協(xié)議的遠(yuǎn)程調(diào)用（原來在Ribbon中）死遭，由原來基于注冊中心的調(diào)用广恢，轉(zhuǎn)變成http直接調(diào)用；
配置信息變更呀潭，修改與刪除組件管理的配置信息以及必要的組件交互代碼（根據(jù)實(shí)際應(yīng)用情況操作）钉迷；
當(dāng)然服務(wù)單元改造過程中，還會涉及到很多的細(xì)節(jié)問題钠署，都需要根據(jù)應(yīng)用特點(diǎn)進(jìn)行處理糠聪，這里不做深入分析。
服務(wù)容器化
服務(wù)容器化是目前應(yīng)用部署的趨勢所在谐鼎。服務(wù)容器化本身有很多不同的方式舰蟆，例如基于Jenkins的pipeline實(shí)現(xiàn)，基于docker-maven-plugin + dockerfile實(shí)現(xiàn)狸棍，當(dāng)然還有很多不同的方式身害。這里以Spring Cloud一個(gè)demo服務(wù)通過docker-maven-plugin+dockerfile實(shí)現(xiàn)說明為例：
簡易的一個(gè)服務(wù)的Dockerfile如下所示：
文件中定義了服務(wù)端口以及運(yùn)行命令。
Maven-docker-plugin的插件配置如下所示：
通過增加docker-maven-plugin草戈，在執(zhí)行mvn package的時(shí)候可以加載Dockerfile塌鸯，自動構(gòu)建服務(wù)的容器鏡像（需要說明的前提是本地安裝docker運(yùn)行環(huán)境，或者通過環(huán)境變量在開發(fā)工具中配置Docker的遠(yuǎn)程連接環(huán)境）唐片，從而完成服務(wù)容器化改造丙猬。
容器環(huán)境構(gòu)建
容器環(huán)境決定這Service Mesh的部署形態(tài)，這里不詳細(xì)描述容器環(huán)境的部署過程牵触。感興趣的朋友淮悼，可以參考https://github.com/easzlab/kubeasz 開源項(xiàng)目，提供了Kubernetes基于ansible的自動化部署腳本揽思。我們也建議選擇Kubernetes來構(gòu)建容器環(huán)境袜腥。這里說明容器環(huán)境構(gòu)建的考慮因素：
1. 集群部署方案
集群部署方案主要考慮多集群，跨數(shù)據(jù)中心，存儲選擇羹令，網(wǎng)絡(luò)方案鲤屡，集群內(nèi)部主機(jī)標(biāo)簽劃分，集群內(nèi)部網(wǎng)絡(luò)地址規(guī)劃等多方面因素福侈。
2. 集群規(guī)模
集群規(guī)模主要考慮etcd集群大小酒来，集群內(nèi)運(yùn)行實(shí)例規(guī)模（用來配置ip范圍段），集群高可用節(jié)點(diǎn)規(guī)模等因素肪凛。
基于以上兩點(diǎn)來考慮容器化環(huán)境的部署方案堰汉，關(guān)鍵是合理規(guī)劃，避免資源浪費(fèi)伟墙。
Service Mesh環(huán)境構(gòu)建
Service Mesh環(huán)境構(gòu)建依賴于容器環(huán)境構(gòu)建翘鸭，主要考慮兩個(gè)方面，以Isito為例：
1. 部署插件
Istio部署插件需要根據(jù)需要的場景戳葵，考慮采用的插件完整性就乓，例如prometheus，kiali拱烁，是否開啟TLS等生蚁，具體安裝選項(xiàng)可以參考https://preliminary.istio.io/zh/docs/reference/config/installation-options/。
2. 跨集群部署
依據(jù)容器環(huán)境考慮是否需要支持Isito的跨集群部署方案.
服務(wù)注入
服務(wù)注入用于將容器化的服務(wù)接入到Service Mesh的平臺中戏自，目前主要有兩種方式邦投。以Isito為例說明，主要包括自動注入和手動入住浦妄。選擇手動注入的目的在于可以根據(jù)企業(yè)內(nèi)部上線流程尼摹，對服務(wù)接入進(jìn)行人為控制。而自動注入則能夠更加快捷剂娄，方便蠢涝。到此實(shí)際上已經(jīng)完成服務(wù)遷移工作。
服務(wù)管理控制臺
由于Service Mesh目前而言阅懦，多是基于聲明式的配置文件和二，達(dá)到服務(wù)治理的效果，因此無法實(shí)時(shí)傳遞執(zhí)行結(jié)果耳胎」呗溃基于這種原因，需要一個(gè)獨(dú)立的Service Mesh的管理控制臺怕午，一方面能夠查看各個(gè)服務(wù)的運(yùn)行狀態(tài)以及策略執(zhí)行情況废登，另外一方面能夠支持服務(wù)運(yùn)行過程中策略的動態(tài)配置管理。目前而言郁惜，可以在Isito安裝過程中選擇kiali作為一個(gè)控制臺實(shí)現(xiàn)堡距，當(dāng)然未來也會有大量的企業(yè)提供專門的服務(wù)。
通過以上七個(gè)步驟，能夠在一定程度上幫助企業(yè)應(yīng)用羽戒，從Spring Cloud遷移到Service Mesh上缤沦，但遷移過程中必然存在不斷踩坑的過程，需要根據(jù)應(yīng)用特點(diǎn)易稠，事前做好評估規(guī)劃缸废。
遷移優(yōu)缺點(diǎn)分析
Spring Cloud遷移到Service Mesh是不是百利而無一害呢？
首先驶社，從容器化的環(huán)境出發(fā)企量，后續(xù)Knative，Kubernetes衬吆，Service Mesh必然會構(gòu)建出一套相對完整的容器化PaaS解決方案梁钾，從而完成容器化PaaS支撐平臺的構(gòu)建绳泉。Service Mesh將為容器運(yùn)行態(tài)提供保駕護(hù)航的作用逊抡。
其次，就目前Service Mesh的落地實(shí)現(xiàn)而言零酪，對于一些特定需求的監(jiān)測粒度有所欠缺冒嫡，例如調(diào)用線程棧的監(jiān)測（當(dāng)然，從網(wǎng)絡(luò)層考慮四苇，或者不在Service Mesh的考慮范圍之內(nèi)）孝凌，但是恰恰在很多服務(wù)治理場景的要求范圍之中。我們也需要針對這種情況月腋，考慮實(shí)現(xiàn)方案蟀架。
最后，大家一直詬病的性能和安全問題榆骚。目前已經(jīng)有所加強(qiáng)片拍，但是依然被吐槽。
整體而言妓肢，Spring Cloud是微服務(wù)實(shí)現(xiàn)服務(wù)治理平臺的現(xiàn)狀捌省，而Service Mesh卻是未來，當(dāng)然也不能完全取而代之碉钠，畢竟設(shè)計(jì)思路和側(cè)重點(diǎn)不同纲缓，是否遷移需要根據(jù)業(yè)務(wù)場景而定。
作者：博云BoCloud
鏈接：http://www.reibang.com/p/fe8f849634ca
來源：簡書
著作權(quán)歸作者所有喊废。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)祝高，非商業(yè)轉(zhuǎn)載請注明出處。
