正确使用LoadbalanceRSocketClient和Spring的RSocketRequester
我试图了解LoadbalanceRSocketClient SpringBoot 应用程序 ( RSocketRequester)上下文中的正确配置和使用模式。
我有两个 RSocket 服务器后端(SpringBoot、RSocket 消息传递)RSocketRequester在客户端上运行和配置,如下所示:
List<LoadbalanceTarget> servers = new ArrayList<>();
for (String url: backendUrls) {
HttpClient httpClient = HttpClient.create()
.baseUrl(url)
.secure(ssl ->
ssl.sslContext(SslContextBuilder.forClient().trustManager(InsecureTrustManagerFactory.INSTANCE)));
servers.add(LoadbalanceTarget.from(url, WebsocketClientTransport.create(httpClient, url)));
}
// RSocketRequester.Builder is autowired by Spring boot
RSocketRequester requester = builder
.setupRoute("/connect")
.setupData("test")
//.rsocketConnector(connector -> connector.reconnect(Retry.fixedDelay(60, Duration.ofSeconds(1))))
.transports(Flux.just(servers), new RoundRobinLoadbalanceStrategy());
配置完成后,请求者将在计时器循环中重复使用,如下所示:
@Scheduled(fixedDelay = 10000, initialDelay = 1000)
public void timer() {
requester.route("/foo").data(Data).send().block();
}
它工作 - 客户端启动,连接到其中一台服务器并将消息推送到它。如果我终止客户端连接的服务器,客户端会在下一个计时器事件中重新连接到另一台服务器。如果我再次启动第一个服务器并杀死第二个服务器,客户端将不再连接,并且在客户端观察到以下异常:
java.util.concurrent.CancellationException: Pool is exhausted
at io.rsocket.loadbalance.RSocketPool.select(RSocketPool.java:202) ~[rsocket-core-1.1.0.jar:na]
at io.rsocket.loadbalance.LoadbalanceRSocketClient.lambda$fireAndForget$0(LoadbalanceRSocketClient.java:49) ~[rsocket-core-1.1.0.jar:na]
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:125) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.FluxContextWrite$ContextWriteSubscriber.onNext(FluxContextWrite.java:107) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.FluxContextWrite$ContextWriteSubscriber.onNext(FluxContextWrite.java:107) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.FluxMap$MapConditionalSubscriber.onNext(FluxMap.java:220) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1784) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.MonoZip$ZipCoordinator.signal(MonoZip.java:251) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.MonoZip$ZipInner.onNext(MonoZip.java:336) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1784) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.MonoCallable.subscribe(MonoCallable.java:61) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.Mono.subscribe(Mono.java:3987) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.MonoZip.subscribe(MonoZip.java:128) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.Mono.subscribe(Mono.java:3987) ~[reactor-core-3.4.0.jar:3.4.0]
at reactor.core.publisher.Mono.block(Mono.java:1678) ~[reactor-core-3.4.0.jar:3.4.0]
我怀疑我没有正确配置请求者或没有正确使用它。希望任何提示,因为文档和测试在这方面似乎非常薄弱。
理想情况下,我希望客户端在服务器/连接失败时透明地切换到任何下一个可用的服务器。现在重新连接尝试似乎只在下一次调用timer()方法时发生,这并不理想,因为客户端需要处理来自服务器的传入消息。我观察到的另一件事是,即使如此"/foo",FnF 路由也是如此,除非我block()在send()服务器从未收到呼叫之后这样做。
回答
不断更新端点列表
LoadbalanceClient旨在与负责保持 a Listof alive Instances的 Discovery 服务集成。也就是说,如果其中一项服务从集群中消失,Discovery 服务会更新其List可用的Instances。
另一方面,要实现客户端负载均衡,我们必须知道集群中可用服务的列表。很明显,要设置负载均衡,我们可以检索服务列表并将其提供给负载均衡器 API。
ReactiveDiscoveryClient discoveryClient = ...
Mono<List<LoadbalanceTarget>> serversMono = discoveryClient
.getInstances(serviceGroupName)
.map(si -> {
HttpClient httpClient = HttpClient.create()
.baseUrl(si.getUri())
.secure(ssl -> ssl.sslContext(
SslContextBuilder.forClient()
.trustManager(InsecureTrustManagerFactory.INSTANCE)
));
return LoadbalanceTarget.from(si.getUri(), WebsocketClientTransport.create(httpClient, "/rsocket")));
})
.collectList()
// RSocketRequester.Builder is autowired by Spring boot
RSocketRequester requester = builder
.setupRoute("/connect")
.setupData("test")
.transports(serversMono.flux(), new RoundRobinLoadbalanceStrategy());
然而,想象一下我们在一个完全分布式的环境中,现在每一个消失和再次出现的服务都运行在全新的主机和端口上(例如,不依赖于特定 IP 地址的 kubernates 集群)。也就是说,Loadbalancing 必须考虑这种情况,并且为了避免池中的死节点,它会从池中完全删除不健康的节点。
现在,如果所有节点消失并在一段时间后出现,则它们不再包含在池中(如果Flux提供更新的Flux<List<LodbalanceTarget>>.
但是,节点将自己注册到 Discovery 服务中并可供观察。综上所述,我们必须定期从 Discovery 服务中提取信息以保持最新状态并持续更新池状态
ReactiveDiscoveryClient discoveryClient = ...
Flux<List<LoadbalanceTarget>> serversFlux = discoveryClient
.getInstances(serviceGroupName)
.map(si -> {
HttpClient httpClient = HttpClient.create()
.baseUrl(si.getUri())
.secure(ssl -> ssl.sslContext(
SslContextBuilder.forClient()
.trustManager(InsecureTrustManagerFactory.INSTANCE)
));
return LoadbalanceTarget.from(si.getUri(), WebsocketClientTransport.create(httpClient, "/rsocket")));
})
.collectList()
.repeatWhen(f -> f.delayElements(Duration.ofSeconds(1))) // <- continuously retrieve new List of ServiceInstances
// RSocketRequester.Builder is autowired by Spring boot
RSocketRequester requester = builder
.setupRoute("/connect")
.setupData("test")
.transports(servers, new RoundRobinLoadbalanceStrategy());
有了这样的设置,RSocketPool即使所有节点都从集群中消失,也不会耗尽,因为Flux<List<LoadbalanceTraget>>还没有完成,最终可能会提供新的更新。
请注意,该实现足够智能,可以在来自发现服务的每次更新时保持活动节点。也就是说,如果池中有这样的服务实例,您将不会同时获得 2 个连接。
关于重新连接功能的旁注
您可能会注意到,它RSocketConnector提供了一个名为.reconnect. 乍一看,似乎使用reconnect将使您的连接保持无限畅通。不幸的是,事实并非如此。该.reconnect功能旨在Mono<RSocket>通过缓存语义保持您的可重用性,这意味着您可以@Bean Mono<RSocket> ...在不同的地方subscribe多次创建并自动装配它,而不必担心RSocket instance每个Mono<RSocket>.subscribe. 另一方面,.reconnect如果给定RSocket断开连接(例如丢失连接的情况),则对此类的下一次订阅Mono<RSocket>将RSocket仅针对所有并发.subscribe调用抵抗一次新的调用。
虽然这听起来很有用,RSocketPool但我们并不太依赖它,Mono<RSocket>只使用一次来解析和缓存 RSocketPool 中的 RSocket 实例。也就是说,如果这样的 RSocket 将断开连接,我们将不会尝试Mono<RSocket>再次订阅给定的(我们假设,设置的主机和端口将被更改)