javascript
服务迁移之路 | Spring Cloud向Service Mesh转变 | 技术干货
戳藍字“CSDN云計算”關注我們哦！
技術頭條：干貨、簡潔、多維全面。更多云計算精華知識盡在眼前，get要點、solve難題，統統不在話下！
作者：?李寧
轉自：博云技術社區
Spring Cloud基于Spring Boot開發，提供一套完整的微服務解決方案，具體包括服務注冊與發現，配置中心，全鏈路監控，API網關，熔斷器，遠程調用框架，工具客戶端等選項中立的開源組件，并且可以根據需求對部分組件進行擴展和替換。
Service Mesh，這里以Istio（目前Service Mesh具體落地實現的一種，且呼聲最高）為例簡要說明其功能。 Istio 有助于降低這些部署的復雜性，并減輕開發團隊的壓力。它是一個完全開源的服務網格，可以透明地分層到現有的分布式應用程序上。它也是一個平臺，包括允許它集成到任何日志記錄平臺、遙測或策略系統的 API。Istio的多樣化功能集使你能夠成功高效地運行分布式微服務架構，并提供保護、連接和監控微服務的統一方法。
從上面的簡單介紹中，我們可以看出為什么會存在要把Spring Cloud體系的應用遷移到Service Mesh這樣的需求，總結下來，有四方面的原因：
功能重疊
來簡單看一下他們的功能對比：
服務注冊與發現 | 支持，基于Eureka，consul等組件，提供server，和Client管理 | 支持，基于XDS接口獲取服務信息，并依賴“虛擬服務路由表”實現服務發現 |
鏈路監控 | 支持，基于Zikpin或者Pinpoint或者Skywalking實現 | 支持，基于sideCar代理模型，記錄網絡請求信息實現 |
API網關 | 支持，基于zuul或者spring-cloud-gateway實現 | 支持，基于Ingress gateway以及egress實現 |
熔斷器 | 支持，基于Hystrix實現 | 支持，基于聲明配置文件，最終轉化成路由規則實現 |
服務路由 | 支持，基于網關層實現路由轉發 | 支持，基于iptables規則實現 |
安全策略 | 支持，基于spring-security組件實現，包括認證，鑒權等，支持通信加密 | 支持，基于RBAC的權限模型，依賴Kubernetes實現，同時支持通信加密 |
配置中心 | 支持，springcloud-config組件實現 | 不支持 |
性能監控 | 支持，基于Spring cloud提供的監控組件收集數據，對接第三方的監控數據存儲 | 支持，基于SideCar代理，記錄服務調用性能數據，并通過metrics adapter，導入第三方數據監控工具 |
日志收集 | 支持，提供client，對接第三方日志系統，例如ELK | 支持，基于SideCar代理，記錄日志信息，并通過log adapter，導入第三方日志系統 |
工具客戶端集成 | 支持，提供消息，總線，部署管道，數據處理等多種工具客戶端SDK | 不支持 |
分布式事務 | 支持，支持不同的分布式事務模式：JTA，TCC，SAGA等，并且提供實現的SDK框架 | 不支持 |
其他 | …… | …… |
從上面表格中可以看到，如果從功能層面考慮，Spring Cloud與Service Mesh在服務治理場景下，有相當大量的重疊功能，從這個層面而言，為Spring Cloud向Service Mesh遷移提供了一種潛在的可能性。
服務容器化
在行業當前環境下，還有一個趨勢，或者說是現狀。越來越多的應用走在了通往應用容器化的道路上，或者在未來，容器化會成為應用部署的標準形態。而且無論哪種容器化運行環境，都天然支撐服務注冊發現這一基本要求，這就導致Spring Cloud體系應用上容器的過程中，存在一定的功能重疊，有可能為后期的應用運維帶來一定的影響，而Service Mesh恰恰需要依賴容器運行環境，同時彌補了容器環境所欠缺的內容（后續會具體分析）。
術業有專攻
從軟件設計角度出發，我們一直在追求松耦合的架構，也希望做到領域專攻。例如業務開發人員希望我只要關心業務邏輯即可，不需要關心鏈路跟蹤，熔斷，服務注冊發現等支撐工具的服務；而平臺支撐開發人員，則希望我的代碼中不要包含任何業務相關的內容。而Service Mesh的出現，讓這種情況成為可能。
語言壁壘
目前而言Spring Cloud雖然提供了對眾多協議的支持，但是受限于Java技術體系。這就要求應用需要在同一種語言下進行開發（這不一定是壞事兒），在某種情況下，不一定適用于一些工作場景。而從微服務設計考慮，不應該受限于某種語言，各個服務應該能夠相互獨立，大家需要的是遵循通信規范即可。而Service Mesh恰好可以消除服務間的語言壁壘，同時實現服務治理的能力。
基于以上四點原因，當下環境，除了部分大多已經提前走在了Service Mesh實踐的道路上互聯網大廠以外（例如螞蟻金服的SOFASTACK），也有大部分企業已經開始接觸Service Mesh，并且嘗試把Spring Cloud構建的應用，遷移到Service Mesh中。
Spring Cloud向Service Mesh的遷移方案
Spring Cloud向Service Mesh遷移，從我們考慮而言大體分為七個步驟，如圖所示：
Spring Cloud架構解析
Spring Cloud架構解析的目的在于確定需要從當前的服務中去除與Service Mesh重疊的功能，為后續服務替換做準備。我們來看一個典型的Spring Cloud架構體系，如圖所示：
從圖中我們可以簡要的分析出，一個基于Spring Cloud的微服務架構，主要包括四部分內容：服務網關，應用服務，外圍支撐組件，服務管理控制臺。
服務網關
服務網關涵蓋的功能包括路由，鑒權，限流，熔斷，降級等對入站請求的統一攔截處理。具體可以進一步劃分為外部網關（面向互聯網）和內部網關（面向服務內部管理）。
應用服務
應用服務是企業業務核心。應用服務內部由三部分內容構成：業務邏輯實現，外部組件交互SDK集成，服務內部運行監控集成。
外圍支撐組件
外圍支撐組件，涵蓋了應用服務依賴的工具，包括注冊中心，配置中心，消息中心，安全中心，日志中心等。服務管理控制臺
服務管理控制臺面向服務運維或者運營人員，實現對應用服務運行狀態的實時監控，以及根據情況需要能夠動態玩成在線服務的管理和配置。
這里面哪些內容是我們可以拿掉或者說基于Service Mesh（以Istio為例）能力去做的？分析下來，可以替換的組件包括網關（gateway或者Zuul，由Ingress gateway或者egress替換），熔斷器（hystrix，由SideCar替換），注冊中心（Eureka及Eureka client，由Polit，SideCar替換），負責均衡（Ribbon，由SideCar替換），鏈路跟蹤及其客戶端（Pinpoint及Pinpoint client，由SideCar及Mixer替換）。這是我們在Spring Cloud解析中需要完成的目標：即確定需要刪除或者替換的支撐模塊。
服務改造
服務單元改造的目的在于基于第一步的解析結果，完成依賴去除或者依賴替換。根據第一步的分析結果服務單元改造分為三步：
刪除組件，包括網關，熔斷器，注冊中心，負載均衡，鏈路跟蹤組件，同時刪除對應client的SDK；
替換組件，采用httpClient 的SDK支持http協議的遠程調用（原來在Ribbon中），由原來基于注冊中心的調用，轉變成http直接調用；
配置信息變更，修改與刪除組件管理的配置信息以及必要的組件交互代碼（根據實際應用情況操作）；
當然服務單元改造過程中，還會涉及到很多的細節問題，都需要根據應用特點進行處理，這里不做深入分析。
服務容器化
服務容器化是目前應用部署的趨勢所在。服務容器化本身有很多不同的方式，例如基于Jenkins的pipeline實現，基于docker-maven-plugin + dockerfile實現，當然還有很多不同的方式。這里以Spring Cloud一個demo服務通過docker-maven-plugin+dockerfile實現說明為例：
簡易的一個服務的Dockerfile如下所示：
????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
文件中定義了服務端口以及運行命令。
Maven-docker-plugin的插件配置如下所示：
????<finalName>microservice-demo</finalName>
????<plugins>
????????......
????????<plugin>
????????????<groupId>com.spotify</groupId>
????????????<artifactId>docker-maven-plugin</artifactId>
????????????<version>1.2.0</version>
????????????<executions>
????????????????<execution>
????????????????????<id>build-image</id>
????????????????????<phase>package</phase>
????????????????????<goals>
????????????????????????<goal>build</goal>
????????????????????</goals>
????????????????</execution>
????????????????<execution>
????????????????????<id>tag-image</id>
????????????????????<phase>package</phase>
????????????????????<goals>
????????????????????????<goal>tag</goal>
????????????????????</goals>
????????????????????<configuration>
????????????????????????<image>${project.build.finalName}:${project.version}</image>
????????????????????????<newName>${docker.registry.name}/${project.build.finalName}:${project.version}</newName>
????????????????????</configuration>
????????????????</execution>
????????????????<!--暫時不添加推送倉庫的配置-->
????????????</executions>
????????????<configuration>
????????????????<dockerDirectory>${project.basedir}/src/main/docker</dockerDirectory>
????????????????<imageName>${project.build.finalName}:${project.version}</imageName>
????????????????<resources>
????????????????????<resource>
????????????????????????<targetPath>/</targetPath>
????????????????????????<directory>${project.build.directory}</directory>
????????????????????????<include>${project.build.finalName}.${project.packaging}</include>
????????????????????</resource>
????????????????</resources>
????????????</configuration>
????????</plugin>
????</plugins>
</build>
通過增加docker-maven-plugin，在執行mvn package的時候可以加載Dockerfile，自動構建服務的容器鏡像（需要說明的前提是本地安裝docker運行環境，或者通過環境變量在開發工具中配置Docker的遠程連接環境），從而完成服務容器化改造。
容器環境構建
容器環境決定這Service Mesh的部署形態，這里不詳細描述容器環境的部署過程。感興趣的朋友，可以參考https://github.com/easzlab/kubeasz 開源項目，提供了Kubernetes基于ansible的自動化部署腳本。我們也建議選擇Kubernetes來構建容器環境。這里說明容器環境構建的考慮因素：
1. 集群部署方案
集群部署方案主要考慮多集群，跨數據中心，存儲選擇，網絡方案，集群內部主機標簽劃分，集群內部網絡地址規劃等多方面因素。
2. 集群規模
集群規模主要考慮etcd集群大小，集群內運行實例規模（用來配置ip范圍段），集群高可用節點規模等因素。
基于以上兩點來考慮容器化環境的部署方案，關鍵是合理規劃，避免資源浪費。
Service Mesh環境構建
Service Mesh環境構建依賴于容器環境構建，主要考慮兩個方面，以Isito為例：
1. 部署插件
Istio部署插件需要根據需要的場景，考慮采用的插件完整性，例如prometheus，kiali，是否開啟TLS等，具體安裝選項可以參考https://preliminary.istio.io/zh/docs/reference/config/installation-options/。
2. 跨集群部署
依據容器環境考慮是否需要支持Isito的跨集群部署方案.
服務注入
服務注入用于將容器化的服務接入到Service Mesh的平臺中，目前主要有兩種方式。以Isito為例說明，主要包括自動注入和手動入住。選擇手動注入的目的在于可以根據企業內部上線流程，對服務接入進行人為控制。而自動注入則能夠更加快捷，方便。到此實際上已經完成服務遷移工作。
服務管理控制臺
由于Service Mesh目前而言，多是基于聲明式的配置文件，達到服務治理的效果，因此無法實時傳遞執行結果。基于這種原因，需要一個獨立的Service Mesh的管理控制臺，一方面能夠查看各個服務的運行狀態以及策略執行情況，另外一方面能夠支持服務運行過程中策略的動態配置管理。目前而言，可以在Isito安裝過程中選擇kiali作為一個控制臺實現，當然未來也會有大量的企業提供專門的服務。
通過以上七個步驟，能夠在一定程度上幫助企業應用，從Spring Cloud遷移到Service Mesh上，但遷移過程中必然存在不斷踩坑的過程，需要根據應用特點，事前做好評估規劃。
遷移優缺點分析
Spring Cloud遷移到Service Mesh是不是百利而無一害呢？
首先，從容器化的環境出發，后續Knative，Kubernetes，Service Mesh必然會構建出一套相對完整的容器化PaaS解決方案，從而完成容器化PaaS支撐平臺的構建。Service Mesh將為容器運行態提供保駕護航的作用。
其次，就目前Service Mesh的落地實現而言，對于一些特定需求的監測粒度有所欠缺，例如調用線程棧的監測（當然，從網絡層考慮，或者不在Service Mesh的考慮范圍之內），但是恰恰在很多服務治理場景的要求范圍之中。我們也需要針對這種情況，考慮實現方案。
最后，大家一直詬病的性能和安全問題。目前已經有所加強，但是依然被吐槽。
整體而言，Spring Cloud是微服務實現服務治理平臺的現狀，而Service Mesh卻是未來，當然也不能完全取而代之，畢竟設計思路和側重點不同，是否遷移需要根據業務場景而定。
福利
掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！
推薦閱讀：
如何快速深入理解監控知識？ | 技術干貨
為什么說深耕AI領域繞不開知識圖譜？
ARM 發布新一代 CPU 和 GPU，實現 20% 性能提升！
比特幣沖到9000美元, 你就能找個好工作?
1000 萬個“AI 名師”：用機器算法“解剖”應試教育
阿里面試，我掛在了第四輪……
10個爬蟲工程師必備的工具了解一下
真香，朕在看了！
總結
以上是生活随笔為你收集整理的服务迁移之路 | Spring Cloud向Service Mesh转变 | 技术干货的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 通信设备sdh是什么 全面了解一下
- 下一篇： 聊聊我是如何在面试别人Spring事务时