摘要:并不會在微服務框架中有其它的注冊機制。微服務框架本身不會維護服務組件的啟動順序,這一問題可以由來解決。啟動先后邏輯為被依賴的服務先啟動,只有當前服務所依賴的服務全部正常啟動后,才會開始啟動流程。
概述
這篇文檔,著重解決一個問題:Spring Cloud 融合于 Rainbond 原生 Service Mesh 的正確姿勢是什么樣子的。
Rainbond 原生支持 Service Mesh 微服務架構。也就是說,無論原來是什么,只要部署在 Rainbond 上,那么就天然的成為了 Service Mesh 微服務。這也是 Service Mesh 微服務架構的一大特點:對原應用無侵入。
Spring Cloud 部署在 Rainbond 上后,整套業務即是完整的 Spring Cloud 微服務,又是一套 Service Mesh 微服務。那么如何使業務系統即保留了原有 Spring Cloud 微服務架構的特點,又能享受到 Service Mesh 帶來的種種好處呢?這就涉及到了Spring Cloud 微服務與 Service Mesh 的融合。
融合的核心思想,就是 Spring Cloud 框架維護的功能,保持不變; Spring Cloud 框架無法維護的功能,交給 Service Mesh 和 Rainbond。
Spring Cloud 不維護什么
我不會去深入討論 Spring Cloud 微服務框架都維護了什么,這樣的帖子網上有很多。
在這里,我想說明的是,當讀者選擇將自己原有的 Spring Cloud 微服務部署在 Rainbond 時,有哪些工作應該由 Rainbond 來完成。
向 eureka 的注冊
eureka 注冊中心,是 Spring Cloud 微服務框架中,標準的注冊中心解決方案。微服務框架中的 Service provider(服務提供者) 將自己的服務地址注冊于 eureka 中,供 Service consumer(服務消費者) 遠程調用。這種服務注冊與發現的機制,是微服務架構中為了將原來的一站式服務拆解為若干個獨立的服務并相互解耦,卻又能相互交互所設計的。基于這種機制,所有的 Spring Cloud 微服務組件,可以動態的獲悉自己需要的 Service Provider 的服務地址;也可以搖身一變,將自己注冊為 Service Provider 對其他組件提供服務。
然而,就是這么一種靈活的服務注冊/發現機制,卻不會維護其它服務組件向 eureka 自身注冊這一動作。向 eureka 注冊的地址,往往是在配置文件里配置的,例如碼云6K+星Spring Cloud項目 PIG后臺管理框架 中,設定的 eureka 注冊方式如下:
https://gitee.com/log4j/pig/b...
# 注冊中心配置 eureka: instance: prefer-ip-address: true client: service-url: defaultZone: http://pig:pig@pig-eureka:8761/eureka/
{{% notice info %}}
Rainbond 中會將無法解析的域名,如 pig-eureka 解析為 127.0.0.1
{{% /notice %}}
在 Rainbond 中,可以借助于依賴關系,將微服務組件和 eureka 連接起來,幫助 Spring Cloud 完成注冊這一動作:
eureka 本身開啟端口對內服務,向 Rainbond 平臺完成自身 Service Mesh 層的服務注冊
其它微服務組件通過依賴關系連接 eureka ,即可在不做任何變更的情況下,完成向 eureka 的服務注冊以及服務訂閱
對接各類中間件
一套完整的 Spring Cloud 微服務體系中,必然會采用多種數據中間件。以 PIG 為例,搭配使用 MySQL 作為數據存儲、 REDIS 作為緩存。而在 Spring Cloud 中,這類中間件的對接方式也是通過配置文件配置的。并不會在微服務框架中有其它的注冊機制。那么同理可以由 Rainbond 的依賴關系來將微服務與服務中間件連接起來。
服務組件啟動順序
Spring Cloud 微服務組件的啟動順序是比較重要的,一個組件在所依賴的服務沒有啟動前自行啟動,是可能引起錯誤的。Spring Cloud 微服務框架本身不會維護服務組件的啟動順序,這一問題可以由 Rainbond 來解決。
在 Rainbond 5.1 版本后,我們支持了基于依賴關系的啟動順序控制。啟動先后邏輯為被依賴的服務先啟動,只有當前服務所依賴的服務全部正常啟動后,才會開始啟動流程。
{{% notice warning %}}
必須指出的是,在這個啟動控制鏈條中,pig-gateway 指向 pig-auth 的依賴關系,其意義只作為啟動順序控制策略,不作為正常的依賴關系使用。
{{% /notice %}}
Spring Cloud 適配 Rainbond
為了將 Spring Cloud 更好的融入到 Rainbond 的體系中來,建議使用下面的配置來進行適配:
注冊IP
在保留了 eureka 這種 Spring Cloud 原生的服務注冊發現機制的前提下,我們需要所有的微服務組件組冊自己的真實IP作為服務地址。微服務組件間的組網策略,Rainbond 會自行解決,關鍵配置類比如下:
https://gitee.com/log4j/pig/b...
# 注冊中心配置 eureka: instance: prefer-ip-address: true
心跳檢測與快速下線
Rainbond 支持每個微服務組件的全生命周期管理。在我們對某個組件進行配置并點擊更新后,我們希望在 eureka 中,在新實例上線后,已經被關閉銷毀的舊實例可以快速下線,確保注冊中心中的服務注冊地址沒有不可用項。關鍵配置如下:
# eureka server配置 eureka: server: enable-self-preservation: false #關閉自我保護 eviction-interval-timer-in-ms: 4000 #清理間隔(單位毫秒,默認是60*1000) # eureka client配置 eureka: instance: lease-expiration-duration-in-seconds: 30 #服務過期時間配置,超過這個時間沒有接收到心跳EurekaServer就會將這個實例剔除 lease-renewal-interval-in-seconds: 10 #服務刷新時間配置,每隔這個時間會主動心跳一次
{{% notice warning %}}
上述配置適用于于測試場景以及調試場景。如果服務已經趨于穩定,并決定應用于生產環境,則建議自行設置合適的配置方案。
{{% /notice %}}
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/27797.html
摘要:小編一哥們和我吐槽自家的煩惱原本一個有錢有閑的證券行業經理一年前被老板派去支持創新業務探索因為新型業務在不斷加速鋪開當前的單體式應用復雜度越來越高業務上線過程繁瑣流程冗長資源分配耗時較多更新頻率越來越低人員也越來越顯得捉襟見肘這哥們于是開始 小編一哥們和我吐槽自家的煩惱原本一個有錢有閑的證券行業IT經理一年前被老板派去支持創新業務探索因為新型業務在不斷加速鋪開當前的單體式應用復雜度越來...
摘要:服務網關服務網關涵蓋的功能包括路由,鑒權,限流,熔斷,降級等對入站請求的統一攔截處理。具體可以進一步劃分為外部網關面向互聯網和內部網關面向服務內部管理。應用服務應用服務是企業業務核心。到此實際上已經完成服務遷移工作。 導讀 Spring Cloud基于Spring Boot開發,提供一套完整的微服務解決方案,具體包括服務注冊與發現,配置中心,全鏈路監控,API...
摘要:原文鏈接時代,架構該怎么跟進,來自于微信公眾號次靈均閣作為核心開發者,請先簡單介紹下自己答大家好,我是小馬哥,一名學習當爸爸的父親,勸退師,項目架構師,編程思想的作者。因此,需求的來源不再已阿里為絕對主導,社區共建和共制的發展模式已成事實。 原文鏈接:Service Mesh 時代,Dubbo 架構該怎么跟進?,來自于微信公眾號:次靈均閣 作為 Duboo 核心開發者,請先簡單介紹下...
摘要:原文鏈接時代,架構該怎么跟進,來自于微信公眾號次靈均閣作為核心開發者,請先簡單介紹下自己答大家好,我是小馬哥,一名學習當爸爸的父親,勸退師,項目架構師,編程思想的作者。因此,需求的來源不再已阿里為絕對主導,社區共建和共制的發展模式已成事實。 原文鏈接:Service Mesh 時代,Dubbo 架構該怎么跟進?,來自于微信公眾號:次靈均閣 作為 Duboo 核心開發者,請先簡單介紹下...
閱讀 778·2023-04-25 20:47
閱讀 2542·2019-08-30 15:53
閱讀 951·2019-08-26 14:05
閱讀 899·2019-08-26 11:59
閱讀 1685·2019-08-26 11:43
閱讀 1684·2019-08-26 10:57
閱讀 1363·2019-08-23 18:23
閱讀 2668·2019-08-23 12:57