摘要:服務(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ù)核心。到此實際上已經(jīng)完成服務(wù)遷移工作。
導(dǎo)讀
Spring Cloud基于Spring Boot開發(fā),提供一套完整的微服務(wù)解決方案,具體包括服務(wù)注冊與發(fā)現(xiàn),配置中心,全鏈路監(jiān)控,API網(wǎng)關(guān),熔斷器,遠(yuǎn)程調(diào)用框架,工具客戶端等選項中立的開源組件,并且可以根據(jù)需求對部分組件進(jìn)行擴(kuò)展和替換。
Service Mesh,這里以Istio(目前Service Mesh具體落地實現(xiàn)的一種,且呼聲最高)為例簡要說明其功能。 Istio 有助于降低這些部署的復(fù)雜性,并減輕開發(fā)團(tuán)隊的壓力。它是一個完全開源的服務(wù)網(wǎng)格,可以透明地分層到現(xiàn)有的分布式應(yīng)用程序上。它也是一個平臺,包括允許它集成到任何日志記錄平臺、遙測或策略系統(tǒng)的 API。Istio的多樣化功能集使你能夠成功高效地運行分布式微服務(wù)架構(gòu),并提供保護(hù)、連接和監(jiān)控微服務(wù)的統(tǒng)一方法。
從上面的簡單介紹中,我們可以看出為什么會存在要把Spring Cloud體系的應(yīng)用遷移到Service Mesh這樣的需求,總結(jié)下來,有四方面的原因:
1. 功能重疊
來簡單看一下他們的功能對比:
?
功能列表 | Spring Cloud | Isito |
---|---|---|
服務(wù)注冊與發(fā)現(xiàn) |
支持,基于Eureka,consul等組件,提供server,和Client管理 |
支持,基于XDS接口獲取服務(wù)信息,并依賴“虛擬服務(wù)路由表”實現(xiàn)服務(wù)發(fā)現(xiàn) |
鏈路監(jiān)控 |
支持,基于Zikpin或者Pinpoint或者Skywalking實現(xiàn) |
支持,基于sideCar代理模型,記錄網(wǎng)絡(luò)請求信息實現(xiàn) |
API網(wǎng)關(guān) |
支持,基于zuul或者spring-cloud-gateway實現(xiàn) |
支持,基于Ingress gateway以及egress實現(xiàn) |
熔斷器 |
支持,基于Hystrix實現(xiàn) |
支持,基于聲明配置文件,最終轉(zhuǎn)化成路由規(guī)則實現(xiàn) |
服務(wù)路由 |
支持,基于網(wǎng)關(guān)層實現(xiàn)路由轉(zhuǎn)發(fā) |
支持,基于iptables規(guī)則實現(xiàn) |
安全策略 |
支持,基于spring-security組件實現(xiàn),包括認(rèn)證,鑒權(quán)等,支持通信加密 |
支持,基于RBAC的權(quán)限模型,依賴Kubernetes實現(xiàn),同時支持通信加密 |
配置中心 |
支持,springcloud-config組件實現(xiàn) |
不支持 |
性能監(jiān)控 |
支持,基于Spring cloud提供的監(jiān)控組件收集數(shù)據(jù),對接第三方的監(jiān)控數(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等,并且提供實現(xiàn)的SDK框架 |
不支持 |
其他 |
…… |
…… |
?
從上面表格中可以看到,如果從功能層面考慮,Spring Cloud與Service Mesh在服務(wù)治理場景下,有相當(dāng)大量的重疊功能,從這個層面而言,為Spring Cloud向Service Mesh遷移提供了一種潛在的可能性。
2. 服務(wù)容器化
在行業(yè)當(dāng)前環(huán)境下,還有一個趨勢,或者說是現(xiàn)狀。越來越多的應(yīng)用走在了通往應(yīng)用容器化的道路上,或者在未來,容器化會成為應(yīng)用部署的標(biāo)準(zhǔn)形態(tài)。而且無論哪種容器化運行環(huán)境,都天然支撐服務(wù)注冊發(fā)現(xiàn)這一基本要求,這就導(dǎo)致Spring Cloud體系應(yīng)用上容器的過程中,存在一定的功能重疊,有可能為后期的應(yīng)用運維帶來一定的影響,而Service Mesh恰恰需要依賴容器運行環(huán)境,同時彌補(bǔ)了容器環(huán)境所欠缺的內(nèi)容(后續(xù)會具體分析)。
3. 術(shù)業(yè)有專攻
從軟件設(shè)計角度出發(fā),我們一直在追求松耦合的架構(gòu),也希望做到領(lǐng)域?qū)9ァ@鐦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),讓這種情況成為可能。
4. 語言壁壘
目前而言Spring Cloud雖然提供了對眾多協(xié)議的支持,但是受限于Java技術(shù)體系。這就要求應(yīng)用需要在同一種語言下進(jìn)行開發(fā)(這不一定是壞事兒),在某種情況下,不一定適用于一些工作場景。而從微服務(wù)設(shè)計考慮,不應(yīng)該受限于某種語言,各個服務(wù)應(yīng)該能夠相互獨立,大家需要的是遵循通信規(guī)范即可。而Service Mesh恰好可以消除服務(wù)間的語言壁壘,同時實現(xiàn)服務(wù)治理的能力。
基于以上四點原因,當(dāng)下環(huán)境,除了部分大多已經(jīng)提前走在了Service Mesh實踐的道路上互聯(lián)網(wǎng)大廠以外(例如螞蟻金服的SOFASTACK),也有大部分企業(yè)已經(jīng)開始接觸Service Mesh,并且嘗試把Spring Cloud構(gòu)建的應(yīng)用,遷移到Service Mesh中。
?
Spring Cloud向Service Mesh的遷移方案
?
?
1. Spring Cloud架構(gòu)解析
Spring Cloud架構(gòu)解析的目的在于確定需要從當(dāng)前的服務(wù)中去除與Service Mesh重疊的功能,為后續(xù)服務(wù)替換做準(zhǔn)備。我們來看一個典型的Spring Cloud架構(gòu)體系,如圖所示:
?
?
從圖中我們可以簡要的分析出,一個基于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ù)邏輯實現(xiàn),外部組件交互SDK集成,服務(wù)內(nèi)部運行監(jiān)控集成。
外圍支撐組件
外圍支撐組件,涵蓋了應(yīng)用服務(wù)依賴的工具,包括注冊中心,配置中心,消息中心,安全中心,日志中心等。
服務(wù)管理控制臺
服務(wù)管理控制臺面向服務(wù)運維或者運營人員,實現(xiàn)對應(yīng)用服務(wù)運行狀態(tài)的實時監(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):即確定需要刪除或者替換的支撐模塊。
?
2. 服務(wù)改造
服務(wù)單元改造的目的在于基于第一步的解析結(jié)果,完成依賴去除或者依賴替換。根據(jù)第一步的分析結(jié)果服務(wù)單元改造分為三步:
刪除組件,包括網(wǎng)關(guān),熔斷器,注冊中心,負(fù)載均衡,鏈路跟蹤組件,同時刪除對應(yīng)client的SDK;
替換組件,采用httpClient 的SDK支持http協(xié)議的遠(yuǎn)程調(diào)用(原來在Ribbon中),由原來基于注冊中心的調(diào)用,轉(zhuǎn)變成http直接調(diào)用;
配置信息變更,修改與刪除組件管理的配置信息以及必要的組件交互代碼(根據(jù)實際應(yīng)用情況操作);
?
當(dāng)然服務(wù)單元改造過程中,還會涉及到很多的細(xì)節(jié)問題,都需要根據(jù)應(yīng)用特點進(jìn)行處理,這里不做深入分析。
?
3. 服務(wù)容器化
服務(wù)容器化是目前應(yīng)用部署的趨勢所在。服務(wù)容器化本身有很多不同的方式,例如基于Jenkins的pipeline實現(xiàn),基于docker-maven-plugin + dockerfile實現(xiàn),當(dāng)然還有很多不同的方式。這里以Spring Cloud一個demo服務(wù)通過docker-maven-plugin+dockerfile實現(xiàn)說明為例:
簡易的一個服務(wù)的Dockerfile如下所示:
ROM openjdk:8-jre-alpine
ENV TZ=Asia/Shanghai
SPRING_OUTPUT_ANSI_ENABLED=ALWAYS
JAVA_OPTS=""
JHIPSTER_SLEEP=0
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
CMD echo "The application will start in ${JHIPSTER_SLEEP}s..." &&
sleep ${JHIPSTER_SLEEP} &&
java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar /app.jar
# java ${JAVA_OPTS} -Djava.security.egd=environment:/dev/./urandom -jar /app.@project.packaging@
EXPOSE 8080
ADD microservice-demo.jar /app.jar
?
文件中定義了服務(wù)端口以及運行命令。
Maven-docker-plugin的插件配置如下所示:
microservice-demo
......
com.spotify
docker-maven-plugin
1.2.0
build-image
package
build
tag-image
package
tag
${project.build.finalName}:${project.version}
${docker.registry.name}/${project.build.finalName}:${project.version}
${project.basedir}/src/main/docker
${project.build.finalName}:${project.version}
/
${project.build.directory}
${project.build.finalName}.${project.packaging}
通過增加docker-maven-plugin,在執(zhí)行mvn package的時候可以加載Dockerfile,自動構(gòu)建服務(wù)的容器鏡像(需要說明的前提是本地安裝docker運行環(huán)境,或者通過環(huán)境變量在開發(fā)工具中配置Docker的遠(yuǎn)程連接環(huán)境),從而完成服務(wù)容器化改造。
?
4. 容器環(huán)境構(gòu)建
容器環(huán)境決定這Service Mesh的部署形態(tài),這里不詳細(xì)描述容器環(huán)境的部署過程。感興趣的朋友,可以參考https://github.com/easzlab/kubeasz 開源項目,提供了Kubernetes基于ansible的自動化部署腳本。我們也建議選擇Kubernetes來構(gòu)建容器環(huán)境。這里說明容器環(huán)境構(gòu)建的考慮因素:
?
集群部署方案 集群部署方案主要考慮多集群,跨數(shù)據(jù)中心,存儲選擇,網(wǎng)絡(luò)方案,集群內(nèi)部主機(jī)標(biāo)簽劃分,集群內(nèi)部網(wǎng)絡(luò)地址規(guī)劃等多方面因素。?
?
集群規(guī)模 集群規(guī)模主要考慮etcd集群大小,集群內(nèi)運行實例規(guī)模(用來配置ip范圍段),集群高可用節(jié)點規(guī)模等因素。?
基于以上兩點來考慮容器化環(huán)境的部署方案,關(guān)鍵是合理規(guī)劃,避免資源浪費。
?
5. Service Mesh環(huán)境構(gòu)建
Service Mesh環(huán)境構(gòu)建依賴于容器環(huán)境構(gòu)建,主要考慮兩個方面,以Isito為例:
?
部署插件 Istio部署插件需要根據(jù)需要的場景,考慮采用的插件完整性,例如prometheus,kiali,是否開啟TLS等,具體安裝選項可以參考https://preliminary.istio.io/zh/docs/reference/config/installation-options/。?
?
跨集群部署 依據(jù)容器環(huán)境考慮是否需要支持Isito的跨集群部署方案.?
?
6. 服務(wù)注入
服務(wù)注入用于將容器化的服務(wù)接入到Service Mesh的平臺中,目前主要有兩種方式。以Isito為例說明,主要包括自動注入和手動入住。選擇手動注入的目的在于可以根據(jù)企業(yè)內(nèi)部上線流程,對服務(wù)接入進(jìn)行人為控制。而自動注入則能夠更加快捷,方便。到此實際上已經(jīng)完成服務(wù)遷移工作。
?
7. 服務(wù)管理控制臺
由于Service Mesh目前而言,多是基于聲明式的配置文件,達(dá)到服務(wù)治理的效果,因此無法實時傳遞執(zhí)行結(jié)果。基于這種原因,需要一個獨立的Service Mesh的管理控制臺,一方面能夠查看各個服務(wù)的運行狀態(tài)以及策略執(zhí)行情況,另外一方面能夠支持服務(wù)運行過程中策略的動態(tài)配置管理。目前而言,可以在Isito安裝過程中選擇kiali作為一個控制臺實現(xiàn),當(dāng)然未來也會有大量的企業(yè)提供專門的服務(wù)。
通過以上七個步驟,能夠在一定程度上幫助企業(yè)應(yīng)用,從Spring Cloud遷移到Service Mesh上,但遷移過程中必然存在不斷踩坑的過程,需要根據(jù)應(yīng)用特點,事前做好評估規(guī)劃。
?
遷移優(yōu)缺點分析
首先,從容器化的環(huán)境出發(fā),后續(xù)Knative,Kubernetes,Service Mesh必然會構(gòu)建出一套相對完整的容器化PaaS解決方案,從而完成容器化PaaS支撐平臺的構(gòu)建。Service Mesh將為容器運行態(tài)提供保駕護(hù)航的作用。
其次,就目前Service Mesh的落地實現(xiàn)而言,對于一些特定需求的監(jiān)測粒度有所欠缺,例如調(diào)用線程棧的監(jiān)測(當(dāng)然,從網(wǎng)絡(luò)層考慮,或者不在Service Mesh的考慮范圍之內(nèi)),但是恰恰在很多服務(wù)治理場景的要求范圍之中。我們也需要針對這種情況,考慮實現(xiàn)方案。
最后,大家一直詬病的性能和安全問題。目前已經(jīng)有所加強(qiáng),但是依然被吐槽。
整體而言,Spring Cloud是微服務(wù)實現(xiàn)服務(wù)治理平臺的現(xiàn)狀,而Service Mesh卻是未來,當(dāng)然也不能完全取而代之,畢竟設(shè)計思路和側(cè)重點不同,是否遷移需要根據(jù)業(yè)務(wù)場景而定。
?
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/6635.html
摘要:微軟已經(jīng)很久沒有支持開源社區(qū)了,這也是很多公司不采用的原因之一。當(dāng)然微軟總是致力于提供無的工具簡單的語法和良好的教程,他們最近也意識到,開源可以為提供更多的創(chuàng)新和業(yè)務(wù)。 得益于CTO、CEO和CDO們積極的推動,IT基礎(chǔ)設(shè)施正在向云環(huán)境遷移,底層架構(gòu)師則在熱烈討論圍繞著云原生應(yīng)用的SaaS、PaaS和微服務(wù)架構(gòu),而開發(fā)者們正在大顯身手,努力探索云計算的魔盒,找出什么是對業(yè)務(wù)有價值的,什...
摘要:并不會在微服務(wù)框架中有其它的注冊機(jī)制。微服務(wù)框架本身不會維護(hù)服務(wù)組件的啟動順序,這一問題可以由來解決。啟動先后邏輯為被依賴的服務(wù)先啟動,只有當(dāng)前服務(wù)所依賴的服務(wù)全部正常啟動后,才會開始啟動流程。 概述 這篇文檔,著重解決一個問題:Spring Cloud 融合于 Rainbond 原生 Service Mesh 的正確姿勢是什么樣子的。 Rainbond 原生支持 Service Me...
摘要:原文鏈接時代,架構(gòu)該怎么跟進(jìn),來自于微信公眾號次靈均閣作為核心開發(fā)者,請先簡單介紹下自己答大家好,我是小馬哥,一名學(xué)習(xí)當(dāng)爸爸的父親,勸退師,項目架構(gòu)師,編程思想的作者。因此,需求的來源不再已阿里為絕對主導(dǎo),社區(qū)共建和共制的發(fā)展模式已成事實。 原文鏈接:Service Mesh 時代,Dubbo 架構(gòu)該怎么跟進(jìn)?,來自于微信公眾號:次靈均閣 作為 Duboo 核心開發(fā)者,請先簡單介紹下...
摘要:原文鏈接時代,架構(gòu)該怎么跟進(jìn),來自于微信公眾號次靈均閣作為核心開發(fā)者,請先簡單介紹下自己答大家好,我是小馬哥,一名學(xué)習(xí)當(dāng)爸爸的父親,勸退師,項目架構(gòu)師,編程思想的作者。因此,需求的來源不再已阿里為絕對主導(dǎo),社區(qū)共建和共制的發(fā)展模式已成事實。 原文鏈接:Service Mesh 時代,Dubbo 架構(gòu)該怎么跟進(jìn)?,來自于微信公眾號:次靈均閣 作為 Duboo 核心開發(fā)者,請先簡單介紹下...
摘要:目前,網(wǎng)易云輕舟微服務(wù)平臺已經(jīng)應(yīng)用于銀行證券視頻監(jiān)控物流工業(yè)等行業(yè)不少中大型企業(yè),幫助其實施微服務(wù)化改造,建設(shè)符合行業(yè)特點的業(yè)務(wù)中臺,支撐企業(yè)數(shù)字化戰(zhàn)略的落地。 微服務(wù)技術(shù)由于天生支持快速迭代、彈性擴(kuò)展的特點,使企業(yè)能夠在不確定性下提升發(fā)展速度及抗風(fēng)險能力,受到了越來越多的關(guān)注。當(dāng)前,云服務(wù)商紛紛試水微服務(wù)產(chǎn)品,最為典型的,當(dāng)屬推出輕舟微服務(wù)平臺、劍指整個微服務(wù)應(yīng)用生命周期的網(wǎng)易云。 ...
閱讀 3649·2021-09-22 15:15
閱讀 3555·2021-08-12 13:24
閱讀 1309·2019-08-30 15:53
閱讀 1815·2019-08-30 15:43
閱讀 1178·2019-08-29 17:04
閱讀 2792·2019-08-29 15:08
閱讀 1573·2019-08-29 13:13
閱讀 3084·2019-08-29 11:06