Spider RPC Development Guide and spiderrpc Guide

Spider RPC Development Guide and spiderrpc Guide
Protocol and compatibility

Spider is developed using the java language, uses Spring as the IoC container, and adopts the TCP/IP protocol. On this basis, it carries out targeted and key designs based on the features of the SaaS system model, to meet the requirements of Multi-tenant systems, high availability, and distributed deployment more flexibly and efficiently.

JSON is used as the serialization mechanism. protobuf may be supported in later versions (java/c ++/c # supports class libraries ).

To maximize performance and stability, spider is compiled based on Sun JDK1.8 and should avoid using deprecated features.

To adapt to different environments and Internet applications as much as possible, spider should be able to run at least under the tomcat/jboss application server.

Deployment mode

Spider can run in a centralized or independent management mode at any time.

Centralized management mode: the centralized mode requires that the service center be enabled. For large-scale deployment of dozens of running nodes, a large number of configuration files are usually required to increase or decrease the number of configuration files required for a node/shard service, generally, each node on the upstream of the new node needs to modify the corresponding route and corresponding server parameters. In the centralized management mode, you only need to log on to the service center to modify the configuration. node changes are automatically pushed to the corresponding upstream nodes. When running in centralized management mode, you can view the health status of all nodes on the platform, TPS, and response time of each service in the service center.

Independent Management Mode: you do not need to enable the service center in independent management mode. When the number of nodes is small, for example, the entire platform has no more than 10 nodes, it is generally easier to use the independent mode than the centralized management mode. When running in standalone management mode, you can view the running status of the current node through the restful api provided by spider.

Service ID

Spider supports two types of service release annotations.

Spider defines two custom annotations used to identify the spider service.

Service Module

@Retention(RetentionPolicy.RUNTIME)public @interface ServiceModule {    String subSystemId() default "0";}

 

@ ServiceModule is only a class annotation. interfaces with this annotation are considered to be spider service interface classes and are defined as necessary conditions for being identified as spider services.

Service Interface

@ Retention (RetentionPolicy. RUNTIME) @ Target ({ElementType. METHOD}) public @ interface Service {String serviceId (); // Service number, which is an eight-character ASCII character. The Parameter bytes -00000099 is reserved for the spider, and the parameter value-is reserved for the Service center String desc (); // service description int timeout () default 0; // timeout time, in milliseconds boolean needLog () default false; // set whether to record the log int broadcast () default 0; // set whether the request is broadcast. Value 0: No broadcast; value 1: broadcast, but no corresponding broadcast; value 2: Broadcast and response}

 

@ Service is a method annotation. It contains three attributes, which are used to set the spider Service number, spider Service description, and spider Service timeout time. The timeout value is optional. The default value is the timeout value set in spider. xml. If spider. xml is not defined, the default value is 300 seconds.

Only the @ Service annotation methods defined in the @ ServiceModule annotation interface are identified as spider services. After the method is published correctly, the interface can be used to provide services or call remote services by a proxy.

For a broadcast = 2 service, the return value must be packaged in the data attribute of com.ld.net. spider. pojo. BroadcastResult. For details, see the javadoc description of this class.

 

Environment Variable

Spider has some environment variables used to control related options. Currently, the following environment variables are available:

L SPIDER_LOG, default/tmp/spider/stat/$ {nodeName}

L SPIDER_HOME, default/usr/local/spider/$ {nodeName}

L SPIDER_CONFIG: Specifies the spider. xml Startup file. The default classpath is spider. xml. See the configuration file section.

 

Configuration File

See the configuration file section.

Service Release and proxy

Service Release: The serviceExportPackage element in the spider. localService plug-in defines the path of the spider service package automatically released when the spider node is used as a server, separated by; or. As long as the server sets the relevant path on this parameter, the java client can directly call the corresponding service provided under the remote server package by setting the corresponding path on the serviceProxyPackage parameter through @ Autowired dependency injection.

Service Proxy: for java clients, spider provides the automatic proxy function. developers can call the spider service on a remote server just as they call the local Spring service. the serviceExportPackage element under the localService plug-in defines the path of the spider service that requires automatic proxy, separated by; or. For non-java clients such as C # Or C ++ clients, developers need to call the corresponding SDK Client.

The published service cannot overlap with the proxy service. If a service needs to be processed locally and forwarded to a downstream server by the spider proxy, It is configured in the release list. In this case, these services cannot be remotely called through User Programming. These services are usually used for special purposes and marked as broadcast.

PS: Technically, as long as the method signature of the same service on the client and server is the same as the service number, it can be called (that is, the method name is irrelevant). However, we do not recommend that you do this, in future versions, exact match may also be required.

It should also be noted that if a spider node Wants To Be a nb role, the release path is configured in serviceExportPackage, and the implementation of a service is also included, if the routing entries of the service are resolved to the Local Machine for processing, the service will be processed on the NB node, but will not continue forwarding. Therefore, for NB roles, we recommend that you do not configure the service under serviceExportPackage in addition to the broadcast service.

Support for various data types

The current version of spider supports all data types except byte [], including generic objects.

 

Service Interface Definition requirements

Considering flexibility, performance, and development efficiency, it is recommended that the service parameters and return values adopt objects (the existing RPC framework basically adopts this mode, such as gRPC and ICE ), meanwhile, parameters inherit from the SpiderBizHead class (including information about dynamic routing settings ). As follows:

Input parameter DTO:

Public class ServiceReq extends SpiderBizHead/* do not inherit SpiderBizHead */{

}

Service signature:

@ ServiceModule ()

Public interface DemoService {

@ Service ()

Public ServiceResp addServer (ServerReq req );

}

 

The simplicity of C ++ and other dynamic proxies in programming languages should also be considered.

For C #, see the implementation of the System. Runtime. Remoting. Proxies. RealProxy class.