Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about what the RSocket load balancer based on service registration discovery is like. Many people may not know much about it. In order to make you understand better, the editor summarizes the following contents. I hope you can get something from this article.

RSocket distributed communication protocol is the core content of Spring Reactive. Since Spring Framework 5.2, RSocket has been the built-in function of Spring, and Spring Boot 2.3 has also added spring-boot-starter-rsocket, which simplifies the service writing and service invocation of RSocket. There are two modes in the core architecture of RSocket communication, namely, Broker proxy mode and service directly connected communication mode.

Broker's communication mode is more flexible, such as Alibaba RSocket Broker, using an event-driven model architecture. At present, more architectures are service-oriented design, that is, we often talk about the mode of service registration discovery and service directly connected communication, of which the most famous is the Spring Cloud technology stack, which involves configuration push, service registration discovery, service gateway, outage protection and so on. In the service-oriented distributed network communication, such as REST API, gRPC and Alibaba Dubbo, they are well integrated with Spring Cloud, and users can complete a very stable distributed network communication architecture without paying attention to the underlying details such as service registration discovery and client load balancing.

As a rising star of the communication protocol, the core of RSocket is binary asynchronous message communication. Can it also be combined with the Spring Cloud technology stack to achieve service registration discovery and client load balancing, so as to achieve a more efficient service-oriented architecture? In this article, we will discuss the combination of Spring Cloud and RSocket to achieve service registration discovery and load balancing.

Service registration discovery

The principle of service registration discovery is very simple, which mainly involves three roles: service provider, service consumer and service registry. A typical architecture is as follows:

Service providers, such as RSocket Server, register application-related information with the service registry, such as application name, ip address, Web Server listening port number, etc., of course, it also includes some meta-information, such as service grouping (group), service version number (version), RSocket listening port number, and if it is WebSocket communication, the ws mapping path is also required. Many developers will submit the service provider's service interface list as tags to the service registry to facilitate subsequent service query and governance.

In this article, we use Consul as the service registry, mainly Consul is relatively simple, after download, execute consul agent-dev to start the corresponding service, of course, you can use Docker Compose, the configuration is also very simple, and then docker-compose up-d can start the Consul service.

When we register and query the service with the service center, we need an application name, which corresponds to the Spring Cloud, that is, the value of the spring.application.name corresponding to Spring Boot. Here we call it the application name, that is, subsequent service lookups are based on the application name. If you call ReactiveDiscoveryClient.getInstances (String serviceId); when looking up the list of service instances, this serviceId parameter is actually the name of the Spring Boot application. Considering the coordination of service registration and subsequent RSocket service routing and ease of understanding, here we intend to design a simple naming convention.

Suppose you have a service application with the function name calculator and two services: mathematical Calculator Service (MathCalculatorService) and Exchange rate Calculator Service (ExchangeCalculatorService). How should we name the application and its corresponding service interface name?

Here, we use a naming convention similar to Java package, using the method of domain name inversion. For example, the calculator application corresponds to a com-example-calculator style. Why is it a dash instead of a dot? . It is illegal to be a host name in DNS resolution, it can only exist as a sub-domain name, not as a host name, and the current service registry design follows the DNS specification, so we use the underscore method to name the application. In this way, the combination of domain name inversion and application name can ensure that there is no duplicate name between applications, and it is also convenient to convert with Java Package names, that is,-and. The conversion between them.

So how should the service interface included in the application be named? The full name of the service interface is composed of the application name and the interface name. The rules are as follows:

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

For example, the following service names are in line with the specification:

Com.example.calculator.MathCalculatorService

Com.example.calculator.ExchangeCalculatorService

Com.example.calculator.math.MathCalculatorService is wrong because there is an extra math between the application name and the interface name. Why should this naming convention be adopted? First, let's look at how the service consumer invokes the remote service. Suppose the service consumer gets a service interface, such as com.example.calculator.MathCalculatorService, how should he initiate a service call?

First of all, the corresponding application name (appName) is extracted according to the Service. For example, the appName corresponding to the com.example.calculator.MathCalculatorService service is com-example-calculator. If there is no relationship between the application and the service interface, you may also need the application name to get the service provider information corresponding to the service interface, which will be relatively troublesome. If the interface name contains the corresponding application information, it will be much easier, you can understand that the application is part of the overall service.

Call ReactiveDiscoveryClient.getInstances (appName) to get the list of service instances (ServiceInstance) corresponding to the application name. The ServiceInstance object will contain other meta-information such as IP address, Web port number, RSocket listener port number and so on.

Build a RSocketRequester object with load balancing ability according to RSocketRequester.Builder.transports (servers).

Use the full name of the service and the specific feature name as the route to make the API call to RSocketRequester. The sample code is as follows:

RsocketRequester .route ("com.example.calculator.MathCalculatorService.square") .data (number) .acquieMono (Integer.class)

Through the above naming convention, we can extract the application name from the full name of the service interface, then interact with the service registry to find the corresponding instance list, then establish a connection with the service provider, and finally invoke the service based on the service name. The naming specification basically achieves the minimum dependency, and the developer is completely based on the service interface call, which is very simple.

RSocket service authoring

With the naming convention and service registration of the service, writing a RSocket service is still very simple, no different from writing a Spring Bean. Introduce spring-boot-starter-rsocket dependency, create a Controller class, add the corresponding MessagMapping annotation as the basic route, and then implement the function API to add the feature name. The sample code is as follows:

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

The above code seems a little strange, but since it's a service implementation, adding @ Controller and @ MessageMapping looks a little irrelevant. Of course, these annotation are some technical details, you can also see that the service implementation of RSocket is based on Spring Message and message-oriented. Here, we only need to add a custom @ SpringRSocketService annotation to solve this problem. The code is as follows:

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

Going back to the corresponding implementation code for the service, we use @ SpringRSocketService annotation instead, so that our code is exactly the same as the standard RPC service interface and easy to understand. In addition, @ SpringRSocketService and @ RSocketHandler these two Annotation, also convenient for us to do some Bean scanning, IDE plug-in assistance, and so on.

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

Finally, we add the spring-cloud-starter-consul-discovery dependency, set the bootstrap.properties, and then set the port and meta-information for RSocket listening in application.properties. We also pass the list of service interfaces provided by the application to the service registry as tags, which is also convenient for our subsequent service management. Examples are as follows:

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

After the RSocket service application is launched, we can see the registered information of the service on the Consul console. Screenshot is as follows:

RSocket client access

Client access is a little complicated, mainly to do a series of related operations based on the service interface, but we already have a naming convention, so it's not a big problem. The client application will also access the service registry so that we can get the ReactiveDiscoveryClient bean, and then build a RSocketRequester with load balancing based on the full name of the service interface, such as com.example.calculator.ExchangeCalculatorService.

The principle is also very simple. As mentioned earlier, according to the full name of the service interface, get the corresponding application name, then call ReactiveDiscoveryClient.getInstances (appName) to get the corresponding instance list of the service application, and then convert the service instance (ServiceInstance) list into the LoadbalanceTarget list of RSockt, which is actually POJO transformation. Finally, the LoadbalanceTarget list is encapsulated by Flux (such as using Sink interface), and the construction of RSocketRequester with load balancing capability is completed by passing it to RSocketRequester.Builder. You can refer to the code base of the project for detailed code details.

What we should pay attention to here is how to perceive the changes in the list of server instances, such as application online and offline, service suspension and so on. Here I use a scheduled task scheme to regularly query the address list corresponding to the service. Of course, there are other mechanisms. If it is a standard Spring Cloud service discovery interface, it currently requires client polling. Of course, it can also be combined with Spring Cloud Bus or message middleware to listen for server list changes. If the client is aware of the change in the service list, it only needs to call the Sink API of Reactor to send a new list. After perceiving the change, RSocket Load Balance will automatically respond, such as closing invalid connections, creating new connections, and so on.

In the communication between actual applications, there will be some situations in which the service provider is unavailable, such as a sudden outage of the service provider or the unavailability of its network, which leads to the unavailability of some services in the service application list. What will RSocket do at this time? Don't worry, RSocket Load Balance has a retry mechanism. When an exception such as a connection occurs in a service call, it will re-obtain a connection from the list for communication, and the wrong connection will be marked as 0 for availability and will not be used by subsequent requests. The service list push and the fault-tolerant retry mechanism during communication ensure the high availability of distributed communication.

Finally, let's start client-app, and then make a remote RSocket call from the client. Take a screenshot as follows:

In the figure above, the com-example-calculator service application consists of three instances, and the service invocation will be carried out alternately in these three service instances (RoundRobin policy).

Some considerations of development experience

Although service registration and discovery, client-side load balancing are completed, invocation and fault tolerance are all right, but there are still some problems with the user experience, which we also explain here to make the development experience better.

1. Communication based on service interface

Most RPC communications are based on interfaces, such as Apache Dubbo, gRPC and so on. So can RSocket do it? The answer is, in fact, absolutely. On the server side, we have implemented the RSocket service based on the service interface, and then we only need to implement the call based on that interface on the client side. For Java developers, this is not a big problem, we just need to build based on the Java Proxy mechanism, and the corresponding InvocationHandler of Proxy will use RSocketRequester to implement the function call of invoke (). For details, please refer to the RSocketRemoteServiceBuilder.java file in the application code, and the bean implementation based on interface calls is also included in client-app module.

two。 Single parameter problem of service interface function

When using RSocketRequester to call a remote interface, the corresponding handler can only accept a single parameter, which is similar to the design of gRPC, and of course takes into account the support of different object serialization frameworks. However, considering the actual user experience, it may involve multi-parameter functions, so that the caller development experience is better, so what to do at this time? In fact, since Java 1.8, interface allows the addition of default functions. We can add some default functions that are more user-friendly without affecting the service communication interface. Examples are as follows:

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

Through interface's default method, we can provide convenience functions to callers, for example, a byte array (byte []) is transferred over the network, but in the default function, we can add File object support to facilitate callers to use. The function API in Interface is responsible for the service communication protocol, and the default function is used to enhance the user's experience. The cooperation of these two functions can easily solve the function multi-parameter problem. Of course, the default function can also be used as an outpost for data verification to a certain extent.

3. RSocket Broker support

As mentioned earlier, RSocket also has a Broker architecture, that is, the service provider is hidden behind the Broker, and the request is mainly accepted by the Broker and then forwarded to the service provider for processing. The architecture example is as follows:

So can load balancing based on service discovery be mixed with RSocket Broker pattern? For example, some applications with long tails or complex networks can be registered with RSocket Broker, and then the request can be called and forwarded by Broker. In fact, this is not complicated, we talked about the application and service interface naming specification, here we only need to add an application name prefix to solve the problem. Suppose we have a RSocker Broker cluster, which we temporarily call a broker0 cluster, and of course all the instances of the broker cluster are registered with a service registry (such as Consul). Then when calling the service on RSocket Broker, the service name is adjusted to broker0:com.example.calculator.MathCalculatorService, that is, the service name is preceded by appName: such a prefix, which is actually another standard form of URI, can be extracted from the application name before the colon, and then go to the service registry to query the application instance list.

Back to the scenario of Broker interconnection, we will query the service list corresponding to broker0 with the service registry, and then create a connection with the instance list of broker0 cluster, so that subsequent service calls based on this interface will be sent to Broker for processing, that is, the mixed use of service registration discovery and Broker pattern is completed.

With the help of this directed assignment of the relationship between service interfaces and applications, it is also convenient for us to do some beta tests. If you want to channel com.example.calculator.MathCalculatorService calls to beta applications, you can use com-example-calculator-beta1:com.example.calculator.MathCalculatorService to invoke services, so that the traffic corresponding to service calls will be forwarded to the corresponding instance of com-example-calculator-beta1, playing the effect of beta testing.

Back to the specification mentioned earlier, if you can't do the binding relationship between the application name and the service interface, then you can use this way to implement service calls, such as calculator-server:com.example.calculator.math.MathCalculatorService, but you need more complete documentation, of course, this way can also solve the problem that the previous system is connected to the current architecture, and the cost of application migration is relatively low. If your previous service-oriented architecture design is also based on interface interface communication, then it is no problem to migrate to RSocket in this way, and the client code adjustment is minimal.

Through the integration of service registration discovery, combined with an actual naming convention, the elegant coordination between service registration discovery and RSocket routing is completed, of course, load balancing is also included. Compared with other RPC schemes, you do not need to introduce RPC's own service registry, reuse Spring Cloud's service registry, such as Alibaba Nacos, Consul, Eureka and ZooKeeper, etc., without extra overhead and maintenance costs.

After reading the above, do you have any further understanding of RSocket load balancing based on service registration discovery? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.