在我們部署具有多個服務的分布式業務時，必須要考慮的一點就是如何處理服務之間的通信問題，那麼當我們将業務部署到Rainbond 上時，又是如何去處理的呢？
Rainbond 開箱即用的ServiceMesh架構預設通過 Sidecar 代理的方式，為我們透明的解決了分布式場景下元件間的通訊問題。
例如A元件需要通路B元件，可以讓A元件依賴B元件，這樣A元件啟動時會同時以插件方式啟動一個 envoy 服務，而 envoy 服務會将B元件的對内端口映射到A元件 Pod 網絡空間的本地回環位址
127.0.0.1
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 進行端口代理，從根本上避免出現端口沖突的問題。
方式四：使用 Istio 網絡治理模式
在 Rainbond 的後續版本中也将會支援
Istio 網絡治理模式，在這種網絡治理模式下，隻會監聽 Istio 配置的固定 Pod 端口，而不去監聽需要通路的元件端口，需要通路的其他元件都會由 Pilot 設定流量規則和配置後交由 Envoy 通過 15001/15006 進行轉發。
Rainbond 雲原生應用管理平台，實作微服務架構不用改代碼，管理 Kubernetes 不用學容器，幫企業實作應用上雲，一站式将任何企業應用持續傳遞到 Kubernetes 叢集、混合雲、多雲等基礎設施。是 Rainstore 雲原生應用商店的支撐平台。1. Rainbond 官網 2. Rainbond 安裝使用 3. Rainbond 參考手冊全集
本文作者：劉帥