在咱們部署具備多個服務的分佈式業務時，必需要考慮的一點就是如何處理服務之間的通訊問題，那麼當咱們將業務部署到Rainbond 上時，又是如何去處理的呢？java
Rainbond 開箱即用的ServiceMesh架構默認經過 Sidecar 代理的方式，爲咱們透明的解決了分佈式場景下組件間的通信問題。web
例如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端口將訪問對應域名的請求轉發至對應的後端組件端口，再也不監聽開通插件的組件網絡空間的對應端口，具體配置流程以下：dom
-
創建依賴關係分佈式
-
開通A組件網絡治理插件ide
-
配置下游服務訪問域名微服務
-
更新組件並測試域名訪問效果測試
-
注意事項
網絡治理類插件會監聽服務網絡的
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 進行端口代理，從根本上避免出現端口衝突的問題。
方式四：使用 Istio 網絡治理模式
在 Rainbond 的後續版本中也將會支持 Istio 網絡治理模式，在這種網絡治理模式下，只會監聽 Istio 配置的固定 Pod 端口，而不去監聽須要訪問的組件端口，須要訪問的其餘組件都會由 Pilot 設置流量規則和配置後交由 Envoy 經過 15001/15006 進行轉發。
Rainbond 雲原生應用管理平臺，實現微服務架構不用改代碼，管理 Kubernetes 不用學容器，幫企業實現應用上雲，一站式將任何企業應用持續交付到 Kubernetes 集羣、混合雲、多雲等基礎設施。是 Rainstore 雲原生應用商店的支撐平臺。
本文做者：劉帥