Spider RPC Development Guide

Protocol and Compatibility

spider is developed using Java language, uses Spring as IoC container, and adopts TCP/IP protocol. On this basis, combined with the characteristics of the SaaS system model, targeted and focused design is carried out to meet more flexible and efficient needs. Requirements for multi-tenant systems, high availability, and distributed deployment.

Using JSON as the serialization mechanism, subsequent versions may consider supporting protobuf (java/c++/c# are supported by class libraries).

             In order to maximize performance and stability, spider is compiled based on Sun JDK1.8 and should avoid using the deprecated feature.

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

Deployment Mode

At any time, Spider can run in either the centralized management mode or the independent management mode.

Centralized management mode: The centralized mode requires that the service center must be enabled. For large-scale deployments with dozens of running nodes, usually adding or reducing a node/splitting a service requires a large number of configuration files. Usually, each node located upstream of the new node needs to modify the corresponding routing and mapping server parameters. Using the centralized management model, you only need to log in to the service center to modify relevant configurations, and node changes will be automatically pushed to the corresponding upstream nodes. When running in the centralized management mode, you can view the health status of all nodes in the entire platform, TPS, response time, etc. of each service in the service center.

Independent management mode: Independent management mode does not require enabling the service center. When the number of nodes is small, for example, when the entire platform does not exceed ten nodes, it is usually simpler to adopt an independent mode than a centralized management mode. When running in independent management mode, you can view the running status of the current node through the restful api provided by spider.

Service identification

Spider supports two types of service publishing annotations.

Spider defines two custom annotations for identifying spider services.

Service module

@Retention(RetentionPolicy.RUNTIME)

public @interface ServiceModule {

String subSystemId() default "0";

}

@ServiceModule is just a class annotation, and the interface with this annotation will be It is considered to be a spider service interface class. The definition in this interface is a necessary condition for being identified as a spider service.

Service interface

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface Service {
    String serviceId(); // 服务编号，8位ASCII字符，其中00000000-00000099为spider内部保留，00000100-00000199为服务中心保留
    String desc(); //服务描述
    int timeout() default 0; //超时时间，单位毫秒
    boolean needLog() default false; //设置是否记录日志
    int broadcast() default 0;  //设置该请求是否广播，0：不广播；1：广播但无需相应；2：广播并响应
}

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

Only methods annotated with @Service defined in the interface annotated with @ServiceModule will be identified as spider services. After being published correctly, the interface can be used to provide services or proxy calls to remote services. C For the service of Broadcast = 2, its return value must be packaged in the data properties of com.ld.net.spider.pojo.BroadCastResult. See the Javadoc description of this class.

Environment variables

spider has some environment variables for controlling related options. Currently, there are the following settable environment variables, as shown below:

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

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

l SPIDER_CONFIG, specify spider.xml startup file, default classpath: spider.xml, see the configuration file section.

Configuration file

Refer to the configuration file section.

Service publishing and agency

Service publishing: The serviceExportPackage element under the spider.localService plug-in defines the package path of the spider service automatically published when the spider node serves 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 by the remote server package through @Autowired dependency injection as long as it sets the corresponding path on the serviceProxyPackage parameter.

Service proxy: For java clients, spider provides an automatic proxy function. Developers can call the spider service on the remote server just like calling the local Spring service. The developer only needs to call the serviceExportPackage element under the spider.localService plug-in. Define the package path of the spider service that requires automatic proxying, separated by; or,. For non-java clients such as C# or C++ clients, developers need to call the corresponding SDK Client.

The published service and the agent's service cannot overlap. If a service needs to be processed locally and forwarded to downstream servers by spider agents, configure it in the release list. At this time these services cannot be called remotely through user programming. Usually these services are used for special purposes and are labeled broadcast.

PS: Technically speaking, as long as the method signature and service number of the same service on the client and server are the same, it can be called (that is, the method name has nothing to do with it), but this is not recommended, and it may be possible in future versions. An exact match is required.

It should also be noted that if a spider node wants to play the role of NB, the publishing path is configured in serviceExportPackage, and it also contains the implementation of a certain service. If the routing entry of the service is parsed to local processing, then the The service will be processed at the NB node and will not be forwarded further. This needs to be noted. Therefore, for the role of NB, it is recommended not to configure it under serviceExportPackage except for broadcast services.

Support for various data types

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

Service interface definition requirements

Taking into account flexibility, performance, and development efficiency, it is recommended that both service parameters and return values ​​use objects (existing RPC frameworks basically adopt this mode, such as gRPC, ICE), while parameters Inherit the SpiderBizHead class (which contains related information such as setting dynamic routing). As shown below:

Input parameter DTO:

public class ServiceReq extends SpiderBizHead /*If you do not need dynamic routing function, you do not need to inherit SpiderBizHead*/ {

}

Service signature:

@ServiceModule()

public interface DemoService {

         @Service()

                                          public ServiceResp addServer(ServerReq req);

For C#, please refer to System.Runtime.Remoting.Proxies.RealProxy class implementation.

================================================ ==========================

Good at large-scale high-concurrency j2ee soa system architecture design and implementation, proficient in j2ee system performance analysis and optimization

Proficient in oltp&dss oracle&mysql database design, performance analysis and optimization, HA, sub-database and sub-table application architecture design and implementation

My open source projects mysqlawr, dlcache, logpool, drpcp. https://git.oschina.net/zhjh256

Provide Intelligent Technology medical device management system that meets the GSP regulatory requirements of each province