Service Mesh，這里以Istio（目前Service Mesh具體落地實(shí)現(xiàn)的一種，且呼聲最高）為例簡(jiǎn)要說(shuō)明其功能。 Istio 有助于降低這些部署的復(fù)雜性，并減輕開(kāi)發(fā)團(tuán)隊(duì)的壓力。它是一個(gè)完全開(kāi)源的服務(wù)網(wǎng)格，可以透明地分層到現(xiàn)有的分布式應(yīng)用程序上。它也是一個(gè)平臺(tái)，包括允許它集成到任何日志記錄平臺(tái)、遙測(cè)或策略系統(tǒng)的 API。Istio的多樣化功能集使你能夠成功高效地運(yùn)行分布式微服務(wù)架構(gòu)，并提供保護(hù)、連接和監(jiān)控微服務(wù)的統(tǒng)一方法。

從上面的簡(jiǎn)單介紹中，我們可以看出為什么會(huì)存在要把Spring Cloud體系的應(yīng)用遷移到Service Mesh這樣的需求，總結(jié)下來(lái)，有四方面的原因：

1. 功能重疊

來(lái)簡(jiǎn)單看一下他們的功能對(duì)比：

?

?

從上面表格中可以看到，如果從功能層面考慮，Spring Cloud與Service Mesh在服務(wù)治理場(chǎng)景下，有相當(dāng)大量的重疊功能，從這個(gè)層面而言，為Spring Cloud向Service Mesh遷移提供了一種潛在的可能性。

2. 服務(wù)容器化

在行業(yè)當(dāng)前環(huán)境下，還有一個(gè)趨勢(shì)，或者說(shuō)是現(xiàn)狀。越來(lái)越多的應(yīng)用走在了通往應(yīng)用容器化的道路上，或者在未來(lái)，容器化會(huì)成為應(yīng)用部署的標(biāo)準(zhǔn)形態(tài)。而且無(wú)論哪種容器化運(yùn)行環(huán)境，都天然支撐服務(wù)注冊(cè)發(fā)現(xiàn)這一基本要求，這就導(dǎo)致Spring Cloud體系應(yīng)用上容器的過(guò)程中，存在一定的功能重疊，有可能為后期的應(yīng)用運(yùn)維帶來(lái)一定的影響，而Service Mesh恰恰需要依賴容器運(yùn)行環(huán)境，同時(shí)彌補(bǔ)了容器環(huán)境所欠缺的內(nèi)容（后續(xù)會(huì)具體分析）。

3. 術(shù)業(yè)有專攻

從軟件設(shè)計(jì)角度出發(fā)，我們一直在追求松耦合的架構(gòu)，也希望做到領(lǐng)域?qū)９ァ＠鐦I(yè)務(wù)開(kāi)發(fā)人員希望我只要關(guān)心業(yè)務(wù)邏輯即可，不需要關(guān)心鏈路跟蹤，熔斷，服務(wù)注冊(cè)發(fā)現(xiàn)等支撐工具的服務(wù)；而平臺(tái)支撐開(kāi)發(fā)人員，則希望我的代碼中不要包含任何業(yè)務(wù)相關(guān)的內(nèi)容。而Service Mesh的出現(xiàn)，讓這種情況成為可能。

4. 語(yǔ)言壁壘

目前而言Spring Cloud雖然提供了對(duì)眾多協(xié)議的支持，但是受限于Java技術(shù)體系。這就要求應(yīng)用需要在同一種語(yǔ)言下進(jìn)行開(kāi)發(fā)（這不一定是壞事兒），在某種情況下，不一定適用于一些工作場(chǎng)景。而從微服務(wù)設(shè)計(jì)考慮，不應(yīng)該受限于某種語(yǔ)言，各個(gè)服務(wù)應(yīng)該能夠相互獨(dú)立，大家需要的是遵循通信規(guī)范即可。而Service Mesh恰好可以消除服務(wù)間的語(yǔ)言壁壘，同時(shí)實(shí)現(xiàn)服務(wù)治理的能力。

基于以上四點(diǎn)原因，當(dāng)下環(huán)境，除了部分大多已經(jīng)提前走在了Service Mesh實(shí)踐的道路上互聯(lián)網(wǎng)大廠以外（例如螞蟻金服的SOFASTACK），也有大部分企業(yè)已經(jīng)開(kāi)始接觸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)備。我們來(lái)看一個(gè)典型的Spring Cloud架構(gòu)體系，如圖所示：

?

?

從圖中我們可以簡(jiǎn)要的分析出，一個(gè)基于Spring Cloud的微服務(wù)架構(gòu)，主要包括四部分內(nèi)容：服務(wù)網(wǎng)關(guān)，應(yīng)用服務(wù)，外圍支撐組件，服務(wù)管理控制臺(tái)。

服務(wù)網(wǎng)關(guān)

服務(wù)網(wǎng)關(guān)涵蓋的功能包括路由，鑒權(quán)，限流，熔斷，降級(jí)等對(duì)入站請(qǐng)求的統(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ù)依賴的工具，包括注冊(cè)中心，配置中心，消息中心，安全中心，日志中心等。

服務(wù)管理控制臺(tái)
服務(wù)管理控制臺(tái)面向服務(wù)運(yùn)維或者運(yùn)營(yíng)人員，實(shí)現(xiàn)對(duì)應(yīng)用服務(wù)運(yùn)行狀態(tài)的實(shí)時(shí)監(jiān)控，以及根據(jù)情況需要能夠動(dòng)態(tài)玩成在線服務(wù)的管理和配置。

這里面哪些內(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è)赟pring Cloud解析中需要完成的目標(biāo)：即確定需要?jiǎng)h除或者替換的支撐模塊。

?

2. 服務(wù)改造

服務(wù)單元改造的目的在于基于第一步的解析結(jié)果，完成依賴去除或者依賴替換。根據(jù)第一步的分析結(jié)果服務(wù)單元改造分為三步：

刪除組件，包括網(wǎng)關(guān)，熔斷器，注冊(cè)中心，負(fù)載均衡，鏈路跟蹤組件，同時(shí)刪除對(duì)應(yīng)client的SDK；

替換組件，采用httpClient 的SDK支持http協(xié)議的遠(yuǎn)程調(diào)用（原來(lái)在Ribbon中），由原來(lái)基于注冊(cè)中心的調(diào)用，轉(zhuǎn)變成http直接調(diào)用；

配置信息變更，修改與刪除組件管理的配置信息以及必要的組件交互代碼（根據(jù)實(shí)際應(yīng)用情況操作）；
?

當(dāng)然服務(wù)單元改造過(guò)程中，還會(huì)涉及到很多的細(xì)節(jié)問(wèn)題，都需要根據(jù)應(yīng)用特點(diǎn)進(jìn)行處理，這里不做深入分析。

?

3. 服務(wù)容器化

服務(wù)容器化是目前應(yīng)用部署的趨勢(shì)所在。服務(wù)容器化本身有很多不同的方式，例如基于Jenkins的pipeline實(shí)現(xiàn)，基于docker-maven-plugin + dockerfile實(shí)現(xiàn)，當(dāng)然還有很多不同的方式。這里以Spring Cloud一個(gè)demo服務(wù)通過(guò)docker-maven-plugin+dockerfile實(shí)現(xiàn)說(shuō)明為例：

簡(jiǎn)易的一個(gè)服務(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 /[email protected]@

EXPOSE 8080
ADD microservice-demo.jar /app.jar

?

文件中定義了服務(wù)端口以及運(yùn)行命令。

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}
                    
                
            
        
    

通過(guò)增加docker-maven-plugin，在執(zhí)行mvn package的時(shí)候可以加載Dockerfile，自動(dòng)構(gòu)建服務(wù)的容器鏡像（需要說(shuō)明的前提是本地安裝docker運(yùn)行環(huán)境，或者通過(guò)環(huán)境變量在開(kāi)發(fā)工具中配置Docker的遠(yuǎn)程連接環(huán)境），從而完成服務(wù)容器化改造。

?

4. 容器環(huán)境構(gòu)建

容器環(huán)境決定這Service Mesh的部署形態(tài)，這里不詳細(xì)描述容器環(huán)境的部署過(guò)程。感興趣的朋友，可以參考https://github.com/easzlab/kubeasz 開(kāi)源項(xiàng)目，提供了Kubernetes基于ansible的自動(dòng)化部署腳本。我們也建議選擇Kubernetes來(lái)構(gòu)建容器環(huán)境。這里說(shuō)明容器環(huán)境構(gòu)建的考慮因素：

?

?

?

?

基于以上兩點(diǎn)來(lái)考慮容器化環(huán)境的部署方案，關(guān)鍵是合理規(guī)劃，避免資源浪費(fèi)。

?

5. Service Mesh環(huán)境構(gòu)建

由于Service Mesh目前而言，多是基于聲明式的配置文件，達(dá)到服務(wù)治理的效果，因此無(wú)法實(shí)時(shí)傳遞執(zhí)行結(jié)果。基于這種原因，需要一個(gè)獨(dú)立的Service Mesh的管理控制臺(tái)，一方面能夠查看各個(gè)服務(wù)的運(yùn)行狀態(tài)以及策略執(zhí)行情況，另外一方面能夠支持服務(wù)運(yùn)行過(guò)程中策略的動(dòng)態(tài)配置管理。目前而言，可以在Isito安裝過(guò)程中選擇kiali作為一個(gè)控制臺(tái)實(shí)現(xiàn)，當(dāng)然未來(lái)也會(huì)有大量的企業(yè)提供專門的服務(wù)。

通過(guò)以上七個(gè)步驟，能夠在一定程度上幫助企業(yè)應(yīng)用，從Spring Cloud遷移到Service Mesh上，但遷移過(guò)程中必然存在不斷踩坑的過(guò)程，需要根據(jù)應(yīng)用特點(diǎn)，事前做好評(píng)估規(guī)劃。

?

其次，就目前Service Mesh的落地實(shí)現(xiàn)而言，對(duì)于一些特定需求的監(jiān)測(cè)粒度有所欠缺，例如調(diào)用線程棧的監(jiān)測(cè)（當(dāng)然，從網(wǎng)絡(luò)層考慮，或者不在Service Mesh的考慮范圍之內(nèi)），但是恰恰在很多服務(wù)治理場(chǎng)景的要求范圍之中。我們也需要針對(duì)這種情況，考慮實(shí)現(xiàn)方案。

最后，大家一直詬病的性能和安全問(wèn)題。目前已經(jīng)有所加強(qiáng)，但是依然被吐槽。

整體而言，Spring Cloud是微服務(wù)實(shí)現(xiàn)服務(wù)治理平臺(tái)的現(xiàn)狀，而Service Mesh卻是未來(lái)，當(dāng)然也不能完全取而代之，畢竟設(shè)計(jì)思路和側(cè)重點(diǎn)不同，是否遷移需要根據(jù)業(yè)務(wù)場(chǎng)景而定。

?