![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/1fdd8b77700a41e4b42db670cfcbb77a.png)

作者 | 雷卷
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/6PrBjWKf8O6IugSI6y9VUg)

RSocket 分散式通訊協議是 Spring Reactive 的核心內容，從 Spring Framework 5.2 開始，RSocket 已經是 Spring 的內建功能，Spring Boot 2.3 也新增了 spring-boot-starter-rsocket，簡化了 RSocket 的服務編寫和服務呼叫。RSocket 通訊的核心架構中包含兩種模式，分別是 Broker 代理模式和服務直連通訊模式。

Broker 的通訊模式更靈活，如 Alibaba RSocket Broker，採用的是事件驅動模型架構。而目前更多的架構則是面向服務化設計，也就是我們常說的服務註冊發現和服務直連通訊的模式，其中最知名的就是 Spring Cloud 技術棧，涉及到配置推送、服務註冊發現、服務閘道器、斷流保護等等。在面向服務化的分散式網路通訊中，如 REST API、gRPC 和 Alibaba Dubbo 等，都與 Spring Cloud 有很好地整合，使用者基本不用關心服務註冊發現和客戶端負載均衡這些底層細節，就可以完成非常穩定的分散式網路通訊架構。

RSocket 作為通訊協議的後起之秀，核心是二進位制非同步化訊息通訊，是否也能和 Spring Cloud 技術棧結合，實現服務註冊發現、客戶端負載均衡，從而更高效地實現面向服務的架構？這篇文章我們就討論一下 Spring Cloud 和 RSocket 結合實現服務註冊發現和負載均衡。

# 服務註冊發現

服務註冊發現的原理非常簡單，主要涉及三種角色：服務提供方、服務消費者和服務註冊中心。典型的架構如下：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/e3ca6787434e4374a24d0c4c226c2f4d.png)

服務提供方，如 RSocket Server，在應用啟動後，會向服務註冊中心註冊應用相關的資訊，如應用名稱，ip 地址，Web Server 監聽埠號等，當然還會包括一些元資訊，如服務的分組(group)，服務的版本號(version)，RSocket 的監聽埠號，如果是 WebSocket 通訊，還需要提供 ws 對映路徑等，不少開發者會將服務提供方的服務介面列表作為 tags 提交給服務註冊中心，方便後續的服務查詢和治理。

在本文中，我們採用 Consul 作為服務註冊中心，主要是 Consul 比較簡單，下載後執行 `consul agent -dev` 就可以啟動對應的服務，當然你可以使用 Docker Compose，配置也非常簡單，然後 `docker-compose up -d` 就可以啟動 Consul 服務。

當我們向服務中心註冊和查詢服務時，都需要有一個應用名稱，對應到 Spring Cloud 中，也就是 Spring Boot 對應的 `spring.application.name` 的值，這裡我們稱之為應用名稱，也就是後續的服務查詢都是基於該應用名稱進行的。如果你呼叫 `ReactiveDiscoveryClient.getInstances(String serviceId);` 查詢1服務例項列表時，這個 serviceId 引數其實就是 Spring Boot 的應用名稱。考慮到服務註冊和後續的 RSocket 服務路由的配合以及方便大家理解，這裡我們打算設計一個簡單的命名規範。

假設你有一個服務應用，功能名稱為 calculator，同時提供兩個服務: 數學計算器服務(MathCalculatorService)和匯率計算器服務(ExchangeCalculatorService),  那麼我們該如何來命名該應用及其對應的服務介面名？

這裡我們採用類似 Java package 命名規範，採用域名倒排的方式，如 calculator 應用對應的則為 `com-example-calculator` 樣式，為何是中劃線，而不是點？`.` 在 DNS 解析中作為主機名是非法的，只能作為子域名存在，不能作為主機名，而目前的服務註冊中心設計都遵循 DNS 規約，所以我們採用中劃線的方式來命名應用。這樣採用域名倒排和應用名結合的方式，可以確保應用之間不會重名，另外也方便和 Java Package 名稱進行轉換，也就是 `-`  和 `.` 之間的相互轉換。

那麼應用包含的服務介面應該如何命名？服務介面全名是由應用名稱和 interface 名稱組合而成，規則如下：

`String serviceFullName = appName.replace("-", ".") + "." + serviceInterfaceName; `

例如以下的服務命名都是合乎規範的：

- com.example.calculator.MathCalculatorService

- com.example.calculator.ExchangeCalculatorService

**而 `com.example.calculator.math.MathCalculatorService` 則是錯誤的,  因為在應用名稱和介面名稱之間多了 `math`**。為何要採用這種命名規範？首先讓我們看一下服務消費方是如何呼叫遠端服務的。假設服務消費方拿到一個服務介面，如 `com.example.calculator.MathCalculatorService`，那麼他該如何發起服務呼叫呢？

- 首先根據 Service 全面提取處對應的應用名稱(appName)，如 `com.example.calculator.MathCalculatorService` 服務對應的 appName 則為 `com-example-calculator`。如果應用和服務介面之間不存在任何關係，那麼想要獲取服務介面對應的服務提供方資訊，你可能還需要應用名稱，這會相對來說比較麻煩。如果介面名稱中包含對應的應用資訊，則會簡單很多，你可以理解為應用是服務全面中的一部分。

- 呼叫 `ReactiveDiscoveryClient.getInstances(appName)` 獲取應用名對應的服務例項列表(ServiceInstance)，ServiceInstance 物件會包含諸如 IP 地址，Web 埠號、RSocket 監聽埠號等其他元資訊。

- 根據 `RSocketRequester.Builder.transports(servers)` 構建具有負載均衡能力的 RSocketRequester 物件。

- 使用服務全稱和具體功能名稱作為路由進行 RSocketRequester 的 API 呼叫，樣例程式碼如下：

`rsocketRequester .route("com.example.calculator.MathCalculatorService.square")  .data(number)  .retrieveMono(Integer.class)`

透過上述的命名規範，我們可以從服務介面全稱中提取出應用名，然後和服務註冊中心互動查詢對應的例項列表，然後建立和服務提供者的連線，最後基於服務名稱進行服務呼叫。該命名規範，基本做到到了最小化的依賴，開發者完全是基於服務介面呼叫，非常簡單。

# RSocket 服務編寫

有了服務的命名規範和服務註冊，編寫 RSocket 服務，這個還是非常簡單，和編寫一個 Spring Bean 沒有任何區別。引入 `spring-boot-starter-rsocket` 依賴，建立一個 Controller 類，新增對應的 MessagMapping annotation 作為基礎路由，然後實現功能介面新增功能名稱，樣例程式碼如下：

`@Controller @MessageMapping("com.example.calculator.MathCalculatorService") public class MathCalculatorController implements MathCalculatorService {     @MessageMapping("square")     public Mono<integer> square(Integer input) {         System.out.println("received: " + input);         return Mono.just(input * input);     } }`

上述程式碼看起來好像有點奇怪，既然是服務實現，新增 @Controller 和 @MessageMapping，看起來好像有點不倫不類的。當然這些 annotation 都是一些技術細節體現，你也能看出，RSocket 的服務實現是基於 Spring Message 的，是面向訊息化的。這裡我們其實只需要新增一個自定義的 @SpringRSocketService annotation 就可以解決這個問題，程式碼如下：

`@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Controller @MessageMapping() public @interface SpringRSocketService {     @AliasFor(annotation = MessageMapping.class)     String[] value() default {}; }`

回到服務對應的實現程式碼，我們改為使用 @SpringRSocketService annotation，這樣我們的程式碼就和標準的 RPC 服務介面完全一模一樣啦，也便於理解。此外 @SpringRSocketService 和 @RSocketHandler 這兩個 Annotation，也方便我們後續做一些 Bean 掃描、IDE 外掛輔助等。

`@SpringRSocketService("com.example.calculator.MathCalculatorService") public class MathCalculatorImpl implements MathCalculatorService {     @RSocketHandler("square")     public Mono<integer> square(Integer input) {         System.out.println("received: " + input);         return Mono.just(input * input);     } }`

最後我們新增一下 spring-cloud-starter-consul-discovery 依賴，設定一下 bootstrap.properties，然後在 application.properties 設定一下 RSocket 監聽的埠和元資訊，我們還將該應用提供的服務介面列表作為 tags 傳給服務註冊中心，當然這個也是方便我們後續的服務管理。樣例如下：

`spring.application.name=com-example-calculator spring.cloud.consul.discovery.instance-id=com-example-calculator-${random.uuid} spring.cloud.consul.discovery.prefer-ip-address=true server.port=0 spring.rsocket.server.port=6565 spring.cloud.consul.discovery.metadata.rsocketPort=${spring.rsocket.server.port} spring.cloud.consul.discovery.tags=com.example.calculator.ExchangeCalculatorService,com.example.calculator.MathCalculatorService`

RSocket 服務應用啟動後，我們在 Consul 控制檯就可以看到服務註冊上來的資訊，截圖如下：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/da8091295e7c416cbde88bcc888d48c6.png)

# RSocket 客戶端接入

客戶端接入稍微有一點複雜，主要是要基於服務介面全面要做一系列相關的操作，但是前面我們已經有了命名規範，所以問題也不大。客戶端應用同樣會接入服務註冊中心，這樣我們就可以獲得 `ReactiveDiscoveryClient` bean，接下來就是根據服務介面全名，如 `com.example.calculator.ExchangeCalculatorService` 構建出具有負載均衡的 RSocketRequester。

原理也非常簡單，前面說過，根據服務介面全稱，獲得其對應的應用名稱，然後呼叫 `ReactiveDiscoveryClient.getInstances(appName)` 獲得服務應用對應的例項列表，接下來將服務例項(ServiceInstance）列表轉換為 RSockt 的 LoadbalanceTarget 列表，其實就是 POJO 轉換，最後將轉 LoadbalanceTarget 列表進行 Flux 封裝(如使用 Sink 介面)，傳遞給 RSocketRequester.Builder 就完成具有負載均衡能力的 RSocketRequester 構建，詳細的程式碼細節大家可以參考專案的程式碼庫。

這裡要注意的是接下來如何感知服務端例項列表的變化，如應用上下線，服務暫停等。這裡我採用一個定時任務方案，定時查詢服務對應的地址列表。當然還有其他的機制，如果是標準的 Spring Cloud 服務發現介面，目前是需要客戶端輪詢的，當然也可以結合 Spring Cloud Bus 或者訊息中介軟體，實現服務端列表變化的監聽。如果客戶端感知到服務列表的變化，只需要呼叫 Reactor 的 Sink 介面傳送新的列表即可，RSocket Load Balance 在感知到變化後，會自動做出響應，如關閉即將失效的連線、建立新的連線等工作。

在實際的應用之間的相互通訊，會存在一些服務提供方不可用的情況，如服務方突然當機或者其網路不可用，這就導致了服務應用列表中部分服務不可用，那麼 RSocket 這個時候會如何處理？不用擔心，RSocket Load Balance 有重試機制，當一個服務呼叫出現連線等異常，會重新從列表中獲取一個連線進行通訊，而那個錯誤的連線也會標識為可用性為 0，不會再被後續請求所使用。服務列表推送和通訊期間的容錯重試機制，這兩者保證了分散式通訊的高可用性。

最後讓我們啟動 client-app，然後從客戶端發起一個遠端的 RSocket 呼叫，截圖如下：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/6c1a63d6e86747b7b9e423825eff6c0c.png)

上圖中 `com-example-calculator` 服務應用包括三個例項，服務的呼叫會在這三個服務例項交替進行(RoundRobin 策略)。

# 開發體驗的一些考量

雖然服務註冊和發現、客戶端的負載均衡這些都完成啦，呼叫和容錯這些都沒有問題，但是還有一些使用體驗上的問題，這裡我們也闡述一下，讓開發體驗做的更好。

## 1. 基於服務介面通訊

大多數 RPC 通訊都是基於介面的，如 Apache Dubbo、gRPC 等。那麼 RSocket 能否做到？答案是其實完全可以。在服務端，我們已經是基於服務介面來實現 RSocket 服務啦，接下來我們只需要在客戶端實現基於該介面的呼叫就可以。對於 Java 開發者來說，這不是大問題，我們只需要基於 Java Proxy 機制構建就可以，而 Proxy 對應的 InvocationHandler 會使用 RSocketRequester 來實現 invoke() 的函式呼叫。詳細的細節請參考應用程式碼中的的 `RSocketRemoteServiceBuilder.java` 檔案，而且在 client-app module 中也已經包含了解基於介面呼叫的 bean 實現。

## 2. 服務介面函式的單引數問題

使用 RSocketRequester 呼叫遠端介面時，對應的處理函式只能接受單個引數，這個和 gRPC 的設計是類似的，當然也考慮了不同物件序列化框架的支援問題。但是考慮到實際的使用體驗，可能會涉及到多參函式的情況，讓呼叫方開發體驗更好，那麼這個時候該如何處理？其實從 Java 1.8 後，interface 是允許增加 default 函式的，我們可以新增一些體驗更友好的 default 函式，而且還不影響服務通訊介面，樣例如下：

`public interface ExchangeCalculatorService {     double exchange(ExchangeRequest request);     default double rmbToDollar(double amount) {         return exchange(new ExchangeRequest(amount, "CNY", "USD"));     } }`

透過 interface 的 default method，我們可以為呼叫方提供給便捷函式，如在網路傳輸的是位元組陣列 (byte[])，但是在 default 函式中，我們可以新增 File 物件支援，方便呼叫方使用。Interface 中的函式 API 負責服務通訊規約，default 函式來提升使用方的體驗，這兩者的配合，可以非常容易解決函式多參問題，當然 default 函式在一定程度上還可以作為資料驗證的前哨來使用。

## 3. RSocket Broker 支援

前面我們說到，RSocket 還有一種 Broker 架構，也就是服務提供方是隱藏在 Broker 之後的，請求主要是由 Broker 承接，然後再轉發給服務提供方處理，架構樣例如下：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/cfd8b9c4c3374bd489a6c30a3fcb6cf4.png)

那麼基於服務發現的機制負載均衡，能否和 RSocket Broker 模式混合使用呢？如一些長尾或者複雜網路下的應用，可以註冊到 RSocket Broker，然後由 Broker 處理請求呼叫和轉發。這個其實也不不復雜，前面我們說到應用和服務介面命名規範，這裡我們只需要新增一個應用名字首就可以解決。假設我們有一個 RSocker Broker 叢集，暫且我們稱之為 broker0 叢集，當然該 broker 叢集的例項也都註冊到服務註冊中心（如 Consul）啦。那麼在呼叫 RSocket Broker 上的服務時，服務名稱就被調整為 `broker0:com.example.calculator.MathCalculatorService`，也就是服務名前新增了 `appName:` 這樣的字首，這個其實是 URI 的另一種規範形式，我們就可以提取冒號之前的應用名，然後去服務註冊中心查詢獲得應用對應的例項列表。

回到 Broker 互通的場景，我們會向服務註冊中心查詢 broker0 對應的服務列表，然後和 broker0 叢集的例項列表建立連線，這樣後續基於該介面的服務呼叫就會傳送給 Broker 進行處理，也就是完成了服務註冊發現和 Broker 模式的混合使用的模式。

藉助於這種定向指定服務介面和應用間的關聯，也方便我們做一些 beta 測試，如你想將 `com.example.calculator.MathCalculatorService` 的呼叫導流到 beta 應用，你就可以使用 `com-example-calculator-beta1:com.example.calculator.MathCalculatorService` 這種方式呼叫服務，這樣服務呼叫對應的流量就會轉發給 `com-example-calculator-beta1` 對應的例項，起到 beta 測試的效果。

回到最前面說到的規範，如果應用名和服務介面的繫結關係你實在做不到，那麼你可以使用這種方式實現服務呼叫，如 `calculator-server:com.example.calculator.math.MathCalculatorService`，只是你需要更完整的文件說明，當然這種方式也可以解決之前系統接入到目前的架構上，應用的遷移成本也比較小。如果你之前的面向服務化架構設計也是基於 interface 介面通訊的，那麼透過該方式遷移到 RSocket 上完全沒有問題，對客戶端程式碼調整也最小。

# 總結

透過整合服務註冊發現，結合一個實際的命名規範，就完成了服務註冊發現和 RSocket 路由之間的優雅配合，當然負載均衡也是包含其中啦。對比其他的 RPC 方案，你不需要引入 RPC 自己的服務註冊中心，複用 Spring Cloud 的服務註冊中心就可以，如 Alibaba Nacos， Consul， Eureka 和 ZooKeeper 等，沒有多餘的開銷和維護成本。如果你想更多瞭解 RSocket RPC 相關的細節，可以參考 Spring 官方部落格 [《Easy RPC with RSocket》](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247501232&idx=1&sn=e81090bb6bb835997895f7f940f87f98&chksm=fae6ce7fcd9147690c060abde0e53c1246b1d9d3612ba82760d8aae8718da9045ebab0deb225&token=2125368952&lang=zh_CN)。

**更多詳細的程式碼細節，可以**[**點選連結檢視文章對應的程式碼庫！**](https://github.com/alibaba-rsocket-broker/rsocket-load-balance)</integer></integer>

Spring RSocket：基於服務註冊發現的 RSocket 負載均衡

相關文章