Rainbond的ServiceMesh架構元件埠衝突處理解決

2022-04-20 19:00:38

元件間的通訊問題

在我們部署具有多個服務的分散式業務時，必須要考慮的一點就是如何處理服務之間的通訊問題，那麼當我們將業務部署到Rainbond 上時，又是如何去處理的呢？

Rainbond 開箱即用的ServiceMesh架構預設通過 Sidecar 代理的方式，為我們透明的解決了分散式場景下元件間的通訊問題。

例如A元件需要存取B元件，可以讓A元件依賴B元件，這樣A元件啟動時會同時以外掛方式啟動一個 envoy 服務，而 envoy 服務會將B元件的對內埠對映到A元件 Pod 網路空間的本地迴環地址127.0.0.1的相同埠，也就是說B元件開通了對內的8080埠，那麼在建立了A到B的依賴關係後，在A元件記憶體取127.0.0.1:8080會由 envoy 將相關請求轉發到B元件的8080埠。

但是我們實際的業務中經常會出現一種情況，那就是一個元件需要和多個其他元件通訊，而這些元件使用的伺服器埠有可能會相同，這就會導致 envoy 在本地迴環地址127.0.0.1起監聽時出現埠衝突。

我們可以通過以下方式解決這個問題：

方式一：通過HTTP 7層網路治理進行埠複用

這一型別的元件，通過Rainbond網路治理外掛設定下游元件的域名（Domain）、請求路徑、請求頭等路由條件，由envoy通過80埠將存取對應域名的請求轉發至對應的後端元件埠，不再監聽開通外掛的元件網路空間的對應埠，具體設定流程如下：

建立依賴關係

開通A元件網路治理外掛

設定下游服務存取域名

更新元件並測試域名存取效果

注意事項

網路治理類外掛會監聽服務網路的127.0.0.1:80，因此如果A元件本身再監聽80埠的，會出現因80埠已被佔用服務無法啟動而導致的元件狀態執行異常

方式二：動態變更元件的監聽埠

Rainbond上執行的元件在啟動時會自動注入一個環境變數PORT，值為元件設定的第一個埠，可以設定元件啟動時參照PORT變數設定服務的監聽埠，將服務監聽的埠由平臺控制，即可不修改程式碼實現監聽埠變更。這樣依賴的不同服務設定不同的埠就可以避免衝突問題了，以Java專案原始碼構建為例，具體設定流程如下：

設定構建源的啟動命令為

web: java -Dserver.port=$PORT $JAVA_OPTS -jar target/*.jar

新增元件埠並構建元件。

驗證服務監聽埠

不同的開發語言和中介軟體設定監聽埠的方式不同，開發者需要根據實際的設定方式進行開發設定。

方式三：使用 Kubernetes 原生 Service 治理模式

在 Rainbond 即將到來的5.3版本中，將支援直接使用 Kubernetes 原生 Service 模式，並提供友好的設定方式，在這種網路治理模式下，每個對內埠都可以設定自定義存取域名，設定之後會生成對應的 Service 資源，這樣元件間就可以直接通過內部域名+埠的方式進行存取，不再由 envoy 進行埠代理，從根本上避免出現埠衝突的問題。