Dubbo Learning (i)-dubbo based on SPI idea implementation

What is SPI


The SPI is the service Provider Interface, which provides the interface.


SPI thought


Abstract in our system of the various modules, often have a lot of different implementations, such as the program of the log module, XML parsing module, the JDBC module scheme. In the object-oriented design, we generally recommend that the modules are based on interface programming, and that the modules do not hard code the implementation class. Once a specific implementation class is involved in the code, it violates the pluggable principle, and if you need to replace an implementation, you need to modify the code.
This requires a service discovery mechanism in order to be able to not dynamically specify in the program when the module is assembled. Java SPI provides a mechanism for finding service implementations for an interface. A bit like the IOC idea is that the control of the assembly is moved outside the program, which is particularly important in modular design.


The conventions of SPI in Java
When the provider of the service provides an implementation of the service interface, a file named after the service interface is created in the meta-inf/services/directory of the jar package. The file is the implementation class that implements the service interface. When the external program assembles the module, it can find the specific implementation class name through the configuration file in the jar package meta-inf/services/, and load the instantiation to complete the injection of the module.
Based on such a convention, it is very good to find the implementation class of the service interface without having to make it in code. The JDK provides a tool class for service implementation lookups: Java.util.ServiceLoader.


Representative examples


JDBC: Before JDBC4, developers also need to load drivers based on class.forname ("xxx"). JDBC4 also based on the SPI mechanism to discover the driver provider, can be specified in the Meta-inf/services/java.sql.driver file implementation class way to expose the driver provider, such as the following figure in the OJDBC6.






DEMO


Suppose there is a content search system, the search module is based on interface programming. The implementation of the search might be a file system-based search or a database-based search.
Search.java: Search Interface
[Java] View plain copy
Package SPI;
Public interface Search {
public void search ();
}




Filesearch.java: Implementation of File System search
[Java] View plain copy
Package SPI;
public class FileSearch implements Search {
@Override
public void Search () {
System.out.println ("Brother is a file search");
}
}




The search implementation of Databasesearch.java database system
[Java] View plain copy
Package SPI;
public class Databasesearch implements Search {
@Override
public void Search () {
System.out.println ("elder brother is Database Search");
}
}




Dosearch.java
[Java] View plain copy
public class Dosearch {
public static void Main (string[] args) {
serviceloader<search> SL = serviceloader.load (Search.class);
iterator<search> s = sl.iterator ();
if (S.hasnext ()) {
Search ss = S.next ();
Ss.search ();
}
}
}




Finally, create the SPI in the Meta-inf/services directory. Search (package name + interface name) file,
When the file content is SPI. FileSearch (Package name + implementation class name), the program output is: Brother is a file search
When the content is SPI. Databasesearch, the program output is: Elder brother is Database search.
It can be seen that the Dosearch class does not have any code related to the implementation, but the SPI-based mechanism to find the implementation of the service.

Realization of Dubbo based on SPI theory


Dubbo extension point loading is enhanced from the JDK standard SPI (Service Provider Interface) extensibility Point discovery mechanism.
Dubbo improves the following issues with the SPI of the JDK standard:
The JDK standard SPI will instantiate all implementations of the extension point at once, and if it is time consuming to initialize the extension, it will be a waste of resources if it is not loaded.
If the extension point fails to load, the name of the extension point is not taken. For example: JDK standard ScriptEngine, through GetName (); Gets the name of the script type, But if rubyscriptengine because the dependent Jruby.jar does not exist, causing the Rubyscriptengine class to fail, the reason for this failure is eaten, and Ruby does not correspond, when the user executes the Ruby script, will not support Ruby, but not the reason for the true failure.
Added support for the extension point IOC and AOP, where an extension point can be injected directly into other extension points.

SPI Interface Definition
Dubbo defines annotations @spi for extended
[Java] View plain copy
Public @interface SPI {
/**
* Default extension name.
*/
String value () default "";
}




When the annotation is hit on the interface, Dubbo reads the extension point under the meta-inf/dubbo/internal/interface full name file.
Take the container interface as an example, the interface has SPI annotations,
[Java] View plain copy
@SPI ("Spring")
Public interface Container {
}




Various container such as Jettycontainer Log4jcontainer Springcontainer are implemented in Dubbo (The @SPI ("Spring") means the default execution Springcontainer), We can find a file named container full name in the Meta-inf/dubbo/internal folder (pictured below), and the content is the reality of each container saved in Key-value way, When Dubbo starts, it reads the contents of the file and loads the appropriate extension points.






Extensionloader class
When Dubbo is started, the implementation class in the extension point is read through the Extensionloader class,


As shown above, first read the value of the SPI annotation, if there is a value as the default extension implementation of the key,
Then read the line by LoadFile () sequentially
Meta-inf/dubbo/internal/com.alibaba.dubbo.xxx.xxx
Meta-inf/dubbo/com.alibaba.dubbo.xxx.xxx
Meta-inf/services/com.alibaba.dubb.xxx.xxx
The contents of the file.
The extension points are automatically adapted, and the packaging will be further described in a later section.