Summary: Spring’s official RSocket Broker has been in development for a long time, and I thought it would be released with Spring Cloud 2021.0, but it didn’t happen. The latest version of Spring RSocket Broker has been released as a preview, but it is currently available. This article is intended to help you get started with the latest version of Spring RSocket Broker. Also parse the features of RSocket Broker.

The author | ray volume source | ali technology to the public

Spring’s official RSocket Broker has been in development for a long time and I thought it would be released with Spring Cloud 2021.0, but it didn’t happen. The latest version of Spring RSocket Broker has been released as a preview, but it is currently available. This article is intended to help you get started with the latest version of Spring RSocket Broker. Also parse the features of RSocket Broker.

A Spring RSocket Broker architecture

Let’s first look at the architecture diagram of Spring RSocket Broker, as follows:

RSocket Brokers serve a cluster. Their main services are application registration and forwarding of RSocket requests. Each Broker in the cluster maintains a unified global routing table. RSocket Broker has two listening ports: port 8001 is responsible for providing external RSocket services, such as long connections between brokers, and then sending and receiving RSocket requests over that long connection. Port 7001 is responsible for the communication between Broker nodes in the cluster, such as synchronizing application access metadata information, ensuring the unification of the global service routing table, and forwarding requests between brokers. Of course, the communication protocol between brokers is RSocket.

When a service application establishes a connection with the Broker, it sends some basic information to the Broker. The corresponding properties include the routeId, sevice-name, and tags.

• Route node ID(routeId): This is a unique identifier that applies to long connections created by the broker. It is usually a UUID, but can also be specified by the user. The uniqueness of the connection facilitates global routing table processing for each cluster of brokers. Note that routeId is the id of a long connection, not the id of an application. The id of an application is identified by tags. If an application creates two long connections with the broker, there are two different Routeids, in which case each connection can provide a different service name.
• Service Name: This is the DNS Name of the service. If other applications want to call the RSocket service provided by the application, they need to specify this service Name. Spring RSocket provides messageMapping, but the mapping key is internal and cannot be globally unique. Only Service Name + RSocket Mapping key can locate the specified Service. The Mapping Key is similar to the HTTP Path, and the Service Name is similar to the domain Name.
• Tags: Tags are used to identify RSocket services provided by applications. The RSocket Broker specification also provides default tags such as InstanceName, ClusterName, Region, MajorVersion, and so on. Tags are not only meta information about services, but also participate in service routing. For example, you can set the service version, cluster name, etc., so that the previously difficult directional routing can be easily solved by the label, for example, you can put InstanceName=app-leijuan label on the service, and then set InsanceName in the call can call the service instance started by a developer. Don’t worry about tag-based routing performance, with Roaring BitMap support on the back, which is very fast.

An application can register with one or more RSocket Broker nodes in a cluster, depending on the configuration of the Broker Client, which we will cover later.

Note: you don’t understand the ServiceName only as the full name of the Java Interface, such as com. Example. User. UserService, so when a Java application has more than one such service, then to handle more troublesome. In fact, serviceName is mainly used for routing requests. If a service application contains both UerService and UserExtraService, you can set serviceName to com.example.user. Ensure that the ServiceName is unique. Replace the RSocket routing key with userService. findUserById (Interface name + Method name).

After registering with the Broker, if an application wants to invoke an RSocket Service, it can initiate an RSocket call to the Broker based on the Service Name + Routing key. The Broker then invokes the RSocket call according to its internal global Routing table. Find the service node (RouteId) that can provide the service and forward the request to the corresponding service node. After the service node completes the processing, the response is returned to the Broker, which in turn returns the response to the caller.

If there is no corresponding service route on the current Broker node, the Broker will forward the request to the Broker with the service node, this is the request forward, and then return the result of that Broker to the caller. Some of you might ask, maybe there’s a call chain dead loop, so broker1 forwards a request to Broker3, broker3’s service suddenly goes offline and doesn’t exist, Broker3 might send back to Broker1, and Broker1 finds another broker to send? Broker1 forwards messages to Broker2, broker2 must have a route connection to the corresponding service, and even if something happens to Broker2, If no route is found, the request will be held by the broker and an error will be returned after a timeout.

A sample Spring RSocket Broker project

Let’s look at a real development sample of three applications: a Broker Server, a service provider, and a service caller. The corresponding development package for Spring RSocket Broker has been submitted to the Maven repository, which you can view at the end of this article.

1 RSocket Broker Server

RSocket Broker Server is a standard Spring Boot application, you just need to add the following dependencies to the Spring Boot application:

Then add the following configuration to the application.yaml file:

Then start the Spring Boot application, the Broker starts, and listens on ports 7001 and 8001. Some students may ask, why not provide a separate application to start RSocket Broker? This may be related to the starting point of the Spring Cloud project. Like Spring Config Server and Registry Server, all of them are embedded by the application, mainly for the convenience of developers to customize Broker functions, such as adding Web Console, docking Ops system, etc. Flexibility will be very high.

2 RSocket Service Provider

Create a Spring Boot application to provide RSocket services. Spring-boot-starter-rsocket is a standard rsocket for spring boot applications. Rsocket-broker-client-spring is a standard rsocket for spring boot applications. Rsocket-broker-client-spring is a standard rsocket for spring boot applications. Responsible for completing the connection to the RSocket Broker.

Then add the following Broker Client configuration to the application. Yaml of the service application, specifying service-name. It is recommended to use the DNS naming method described earlier to ensure that the service names do not conflict. Here’s the brokers’ address list, as follows:

Next we need to write a RSocket service, this is the standard Spring RSocket, code as follows:

We then start the service application and see the application registered with the Broker in the log output of the RSocket Broker. The RSocket service has been registered with the Broker.

3 RSocket Service Consumer

Create an application that calls the RSocket service. Add the same dependencies as the application that calls the RSocket service. Since the application does not provide the RSocket service, change the name of the service to Namespace + the name of the application.

The next step is to write a Web Controller to access the RSocket service, just inject BrokerRSocketRequester Bean and call the RSocket service, This is similar to Spring RSocket RSocketRequester.

Using the curl command, you can see the familiar Hello ping output.

You may think this client call is primitive, but all you have to do is integrate spring-RetroSocket, and then you have the Familiar Java interface, for example:

Some thoughts on Spring RSocket Broker

1 RSocket Broker features

Spring RSocket Broker has been in development for a long time. The developers are all members of the Spring Cloud team. Oleh is very experienced in Reactive and RSocket, and Spencer is the core architect of Spring Cloud. Spencer spoke at several conferences about the changes RSocket has brought to Spring Cloud, and it’s completely disruptive. As you can see from the example of Reactive, you don’t need to register a service, you don’t need to start a local answer port, and you can use the Broker to call each other. Spring RSocket Broker has a description of the benefits of RSocket Broker, as follows:

Routing and forwarding are used to forward RSocket requests between two RSocket connections via broker. In some cases, point-to-point interactions between a client and server are enough, in an enterprise environment, it is useful to decouple the client and server from each other. Some examples of why decoupling is necessary include blue/green deployments, load balancing, A/B testing, feature toggles, etc. Additionally, providing an intermediary can help with security and scalability. Finally, with the load balancing, routing and QoS, better overall application latency and throughput can be achieved than by direct connections.

Direct communication solutions in RSocket Broker

Some students may have questions, there will be a certain performance loss through RSocket Broker, MY application QPS is very high, there can be no delay ah. That doesn’t matter. Remember the spring-boot-starter-rsocket dependency added to the service application? Yaml simply adds the following configuration items to open RSocket’s service listening port, then use the meta information provided by the RSocket Broker, and then use RSocketRequester to create a connection to the target service. There was some work, but it was minimal, and we just needed to use reactor-pool to automatically manage the connection pool for direct connections.

3 RSocket Broker requests waiting

Another feature of Spring RSocket Broker is service online delay support. For example, suppose that app-1 and service-1 are both running properly online, and all instances of service-1 go offline. Then, the request sent from app-1 cannot find the destination node. What should be done?

• Reject requests and fail immediately: This is often referred to as fail-fast design, and is often used in enterprise architecture design. If you are using synchronous communication and Thread Pool, you basically have to use this design, otherwise a long Thread block will immediately render your service unresponsive.
• Waiting for a service to come online: The Broker holds a request and waits for the service to come online before forwarding it to the online service. This design can be very useful, such as in FaaS scenarios, where the Gateway already validates that the function exists and is currently only offline, so just trigger the function to go online and ask to wait. In addition, there is the problem of network jitter, which will lead to the interruption of the connection. At this time, you can also choose to wait for service online. Another scenario is service publishing, where a long-tail service has only one instance. If you can restart the application in 3-5 seconds, Broke can hold the request and retry the application. Even if there is only one instance, the service will not be interrupted. For example, in K8S, set the image of the application to Last, and then set it to get the latest, so a Redploy button will do. Of course, this request wait time is not infinite, you can set a timeout, and then return an error.

Returning to the above scenario, Broker-1 holds the request at this point, and when Service-1 comes online, the request is immediately forwarded to the online node for processing. Unlike synchronous communication, asynchronous wait has no system stress on Reactive systems, so waiting for services to come online is no problem. Of course, you can choose which mode to use depending on your actual technical needs, and RSocket Broker supports both modes.

4 Message broadcast model

Spring RSocket Broker also supports message broadcasting, which forwards RSocket requests to a number of service nodes. Message broadcast mainly includes the following models:

• FireAndForget Model: If push is configured, send the configuration update request to the service list corresponding to service-name.
• RequestResponse model: Send requests to multiple services and then return the response of the first response to the caller, whether the response results in success or failure, which is similar to JavaScript promise.race (). The promise.race () feature, which seems to have few business scenarios, adds a timeout to make it easier to understand, and converts it to “return the correct result as soon as possible within the specified time”. As in the scenario of data synchronization, the data will be synchronized to multiple backup servers, but for various reasons, may lead to backup the data on the server synchronization delays or lost, so I query data to multiple backup server, if there is no the data backup server, and agreed in the 1 second timeout after abnormal returns, This ensures that the correct data can be retrieved from the backup server cluster as quickly as possible. Of course, in the actual architecture, we will add a layer of cache support, to avoid multiple requests to the service at the same time, which will waste a lot of resources.
• RequestStream model: Send requests to multiple servers, summarize the returned streams, and return the merged message flows to the caller. This is especially useful in monitoring scenarios where you want each service or application to report logs within 5 minutes and then count them.
• Channel model: Continuously sending information to channels of multiple servers, and then summarizing the sent information. You can use this model if you have multiple designations to send out and then aggregate the results of the specified responses across each application.

From the above models, you can basically cover a large number of broadcast requirements. If your company asks you to make a Config server for configuration push, RSocket Broker can do it in minutes. Use RSocket Broker + Agent to complete operation and maintenance operations, log collection, etc. In Prometheus’ metrics timing collection scenario, metrics on all machines can be collected with a single command rather than an HTTP request to a single node.

5 the Gateway and the Broker

Most Gateway designs adopt the mode of active connection, that is, Gateway actively connects to the Proxy mode of upstream services. Of course, to connect to upstream services, we also need to use service registration and discovery, intelligent DNS, etc., the principle of which will not be described. The Broker architecture is passive, waiting for the service to connect to the Broker. That is, when the service is Ready, it actively connects to the Broker and then forwards requests based on the long connection established between the application and the Broker. Compared with Gateway architecture, Broker mode is much simpler. There is no internal management of upstream service connection pool, service registration and discovery is not required, of course, there is no special network access requirements, and hybrid cloud scenarios are also applicable.

The RSocket Broker is based on the RSocket protocol, but can also support various protocols through Bridges, such as the RSocket HTTP Bridge, which extends HTTP access.

6 Embedded RSocket Broker

To answer the previous question, RSocket Broker is embedded in the application. You need to add the corresponding dependencies and configuration, and then launch the corresponding application. This is similar to Spring Config Server, etc., in order to facilitate developers to extend the corresponding features of Broker and integrate with other systems. Combined with the RSocket Broker features introduced earlier, we can immediately implement some typical business scenarios by embedding RSocket Broker:

• Config/Registry Server: Now that the application has established a long connection with the Broker and the meta information is sent to the Broker, Registry Server comes into its own. RSocket Broker supports various message broadcast models, so Config Server is almost ready. The configuration push of a single application is based on an independent tag push, and the overall push is based on the Service Name. There is no problem in all of them.
• Web Console: Developing a Web console after embedding the Broker is simple for Spring Boot.
• Data Gateway: If you want to be a Data Gateway that provides Data access services, all Data worker nodes connect to the Broker, which then provides services.
• Ops system integration: Spring Boot can be used for this integration, and other applications, such as health check, can only be sent a message to the application.
• Graceful offline of brokers and applications: By pushing brokers’ configuration information, an application can connect to a new brokers node to complete the offline of the brokers cluster. To go offline, send a ROUTE_REMOVE message to the Broker cluster and then go offline 3-5 days after the application.

7 Spring RSocket Broker Client

The Client SDKS of RSocket Broker include Java and Node.js, but there is no need to worry about Broker Client SDKS of other languages. Broker Client just RSocket SDK Composite the Metadata to add a new message/x.r socket. The Broker. Frame. Where v0 Metadata specification, with the aid of RSocket multilingual SDK, Applications developed in major languages can be quickly plugged into brokers.

Four summarizes

Finally, someone asked, is RSocket mature now? In the Spring ecosystem, it is very mature. The RSocket Java SDK is developed by the Spring team. Spring RSocket provides the integration of RSocket and Spring. The rsocket-starter is built into Spring Boot. Spring Cloud Function also adds RSocket support for Java developers, as well as spring-RetroSocket. Other Spring products support Reactive, so you can connect to Reactive. Now that the RSocket periphery is in place, everyone is waiting for the RSocket Broker to appear, making integration and deployment much easier. In addition, the current variety of various services, such as REST API, GraphQL or RPC framework, migrate to RSocket trouble? If this is what Spring does, add an @messagemapping thing and you can access these services via RSocket. Dubbo/HSF services, add Annotation provided by Spring-Retrosocket to Interface, and then access these services via RSocket protocol. The REST API simply adds @Messagemapping on top of Controller. As for GraphQL, you don’t need any tweaks, just add a new GraphqlController to connect to the GraphQL underlying service. With the current Spring RSocket Broker features, a mid-sized enterprise can do just fine without any adjustments. This is Spring Config Server. Spring Registry Server and Spring Cloud Gateway are positioned the same.

As the Spring Cloud team has been talking about the impact of RSocket on The Spring Cloud and development experience, read this and you’ll have your own judgment. But still the old saying: “There are bole in the world, and then there are swift horses. Swift horse often, but bole not often.”

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.