An explanation of the protocols that are proficient in Dubbo--dubbo support

Dubbo supports Dubbo, RMI, Hessian, HTTP, WebService, Thrift, Redis and many other protocols, but the Dubbo website is recommended that we use the Dubbo protocol. Here we explain each of the protocols for Dubbo so that we can make the right choice in the actual application. Dubbo Protocol

The default protocol, using mina1.1.7+hessian3.2.1-based tbremoting interactions.
Number of connections: Single connection
Connection mode: Long connection
Transport protocol: TCP
Transmission mode: NIO asynchronous transmission
Serialization: Hessian binary serialization
Scope of application: Incoming outgoing parameter packet smaller (less than 100K recommended), consumers than the number of providers, a single consumer can not be full of providers, try not to use the Dubbo protocol to transfer large files or large strings.
Applicable scenario: General remote Service method invocation

1, Dubbo Default adoption of Dubbo protocol, Dubbo protocol with a single long connection and NIO asynchronous communication, suitable for small data volume of large concurrent service calls, and the number of service consumer machines is much larger than the number of service provider machines
2, he is not suitable for transmitting large data volume of services, such as transmitting files, video, etc., unless the volume of requests is very low.
The configuration is as follows:

<dubbo:protocol name= "Dubbo" port= "20880"/>
<!--Set Default protocol:--
<dubbo:provider Protocol= "Dubbo"/>
<~--Set Service Protocol--
<dubbo:service protocol= "Dubbo"/>
<! --Multi Port-to
<dubbo:protocol id= "Dubbo1" Name= "Dubbo" port= "20880"/> <dubbo:protocol id=
" Dubbo2 "Name=" Dubbo "port=" 20881 "/>".
<!--Dubbo Protocol options:--
<dubbo:protocol name= "Dubbo" port= "9090" server= "Netty" client= "Netty" Codec= "Dubbo" 
serialization= "hessian2" charset= "UTF-8" threadpool= "fixed" threads= "+" queues= "0" iothreads= "9 " 
buffer=" 8192 "accepts=" "payload=" 8388608 "/>"

3, Dubbo protocol default per service per provider per consumer use a single long connection, if the amount of data is large, you can use multiple connections.

<dubbo:protocol name= "Dubbo" connections= "2"/>

<dubbo:service connections= "0" > or <dubbo:reference connections= "0" > indicates that the service uses a JVM to share long connections. Default
<dubbo:service connections= "1" > or <dubbo:reference connections= "1" > indicates that the service uses an independent long connection.
<dubbo:service connections= "2" > or <dubbo:reference connections= "2" > indicates that the service uses separate two long connections.
4, in order to prevent a large number of connections to hang, the service provider can limit the number of large receive connections in order to achieve the service provider self-protection

<dubbo:protocol name= "Dubbo" accepts= "/>"

Why consumers are more than the number of providers.
Because the Dubbo protocol uses a single long connection, assuming that the network is a gigabit network card (1024mbit=128mbyte), according to the Test experience data per connection can only be up to 7MByte (different environments may not be the same, for reference), Theoretically 1 service providers require 20 service consumers to be able to fill the network card
Why not send a big bag.
Because the Dubbo protocol uses a single long connection, if each request packet size is 500KByte, assuming that the network is a gigabit NIC (1024mbit=128mbyte), each connection maximum 7MByte (different environments may not be the same, for reference), the TPS for a single service provider ( The maximum number of transactions processed per second) is: 128mbyte/500kbyte = 262. The maximum number of TPS (processing transactions per second) that a single consumer invokes for a single service provider is: 7mbyte/500kbyte = 14. If you can accept it, consider using it, or the network will become a bottleneck.
why asynchronous single-long joins are used.
Because the service is mostly the service provider of less, usually only a few machines, and the service of more consumers, may be the entire site access to the service, such as Morgan's provider only 6 providers, but there are hundreds of consumers, There are 150 million calls per day, and if a regular Hessian service is used, the service provider is easily compressed across a single connection to ensure that a single consumer does not crush the provider, long connect, reduce connection handshake verification, and use asynchronous IO to reuse the thread pool to prevent c10k problems.
interface addition method, no impact on the client, if the method is not required by the client, the client does not need to redeploy;
Adding attributes to input parameters and result sets has no effect on the client, and if the client does not require a new attribute, do not re-
Deployment
The input parameter and result set attribute name changes have no effect on client serialization, but if the client does not redeploy, regardless of the input or output, the property value of the property name changes is not obtained.
Summary: The server side and the client do not need to be fully consistent with domain objects, but are based on the maximum matching principle.
If you are not integrating spring, configure the following separately

Dubbo.service.protocol=dubbo

RMI Protocol

The Java standard Remote invocation protocol.
Number of connections: multiple connections
Connection mode: Short connection
Transport protocol: TCP
Transmission mode: Synchronous transmission
Serialization: Java standard binary serialization
Scope of application: Incoming outgoing parameter packet size mixed, the number of consumers and providers are similar, can be transmitted files.
Scenario: General remote Service method invocation, interop with native RMI service

1, RMI protocol using JDK standard java.rmi.* implementation, using blocking short connection and JDK standard serialization method
Note:
If you are using RMI to provide services to external access (the company intranet environment should not be at risk of attack), while the application relies on the old Common-collections package (Dubbo does not rely on this package, please check if your application is not used), there is a deserialization security risk.
Please check the application:
Upgrade COMMONS-COLLECTIONS3 to 3.2.2 version:
Https://commons.apache.org/proper/commons-collections/release_3_2_2.html
Upgrade COMMONS-COLLECTIONS4 to version 4.1: https://commons.apache.org/proper/commons-collections/release_4_1.html
The new version of commons-collections resolves the issue
If the service interface inherits the Java.rmi.Remote interface, it can interoperate with the native RMI, namely:
The provider exposes the service with the Dubbo RMI Protocol, the consumer is called directly with the standard RMI interface, or the provider exposes the service with a standard RMI, and the consumer uses the Dubbo RMI protocol. If the service interface does not inherit the Java.rmi.Remote interface, the default Dubbo will automatically generate an Com.xxx.xxxservice$remote interface and inherit the Java.rmi.Remote interface and expose the service with this interface, but if the <dubbo:protocol name= "RMI" codec= "Spring"/> the $remote interface will not be generated, but the service is exposed using spring's Rmiinvocationhandler interface, and spring is compatible.

<!--Define RMI protocol
--and <dubbo:protocol name= "RMI" port= "1099"/>.
<!--Set Default protocol:
--<dubbo:provider protocol= "rmi"/>
<!--set Service protocol:-- >
<dubbo:service protocol= "rmi"/>
<!--Multi Port-to-
<dubbo:protocol id= "Rmi1" Name= " RMI "port=" 1099 "/>
<dubbo:protocol id=" rmi2 "name=" RMI "port=" 2099 "/>
<dubbo:service protocol=" Rmi1 "/>
<!--Spring compatible:--
<dubbo:protocol name=" rmi "codec=" Spring "/>

Hessian Protocol

Remote invocation protocol based on Hessian.
Number of connections: multiple connections
Connection mode: Short connection
Transport protocol: HTTP
Transmission mode: Synchronous transmission
Serialization: Serialization of Forms
Scope of application: Incoming outgoing parameter packet size mixed, the provider than the number of consumers, can be viewed by the browser, can be used in the form or URL parameters, and temporarily do not support the transfer of files.
Scenario: A service that needs to be used for both application and browser JS.

1, Hessian protocol for integration of Hessian services, hessian the bottom of the HTTP communication, the use of servlet exposure services, Dubbo the default embedded jetty as a server implementation.
2, Hessian is an Caucho open source RPC framework: http://hessian.caucho.com, its communication efficiency is higher than WebService and Java comes from the serialization.
Depend on

<dependency>
    <groupId>com.caucho</groupId>
    <artifactid>hessian</artifactid >
    <version>4.0.7</version>
</dependency>

Can interoperate with native Hessian services, i.e.:
The provider exposes the service with the Dubbo Hessian protocol, the consumer is called directly with the standard Hessian interface, or the provider uses the standard Hessian exposure service, and the consumer uses Dubbo's Hessian protocol.
Constraints
1, parameters and return values need to implement Serializable interface
2, parameters and return values can not be customized to implement the list, Map, number, Date, calendar and other interfaces, only with the implementation of the JDK, because Hessian will do special processing, the custom implementation of the property values in the class will be lost.

<!--Define Hessian protocol:--
<dubbo:protocol name= "Hessian" port= "8080" server= "jetty"/>
<!--Set Default protocol:
--<dubbo:provider protocol= "Hessian"/>
<!--set Service protocol:-
<dubbo:service protocol= "Hessian"/>
<!--Multi Port:--
<dubbo:protocol id= " Hessian1 "Name=" Hessian "port=" 8080 "/>
<dubbo:protocol id=" hessian2 "name=" Hessian "port=" 8081 "/>
<!--Directly provider:--
<dubbo:reference id= "HelloService" interface= "HelloWorld" url= "hessian:// 10.20.153.10:8080/helloworld "/>
<!--Jetty Server--<dubbo:protocol ... server=" Jetty "/>
<!--servlet Bridge Server--
<dubbo:protocol server= "servlet"/>

Web. XML configuration

<servlet>
         <servlet-name>dubbo</servlet-name>
         <servlet-class> Com.alibaba.dubbo.remoting.http.servlet.dispatcherservlet</servlet-class>
         <load-on-startup>1 </load-on-startup>
</servlet>
<servlet-mapping>
         <servlet-name>dubbo</ servlet-name>
         <url-pattern>/*</url-pattern>
</servlet-mapping>

Note: If you use the servlet to distribute the request
The port of the protocol <dubbo:protocol port= "8080"/> must be the same as the port of the servlet container.
The context path of the protocol <dubbo:protocol contextpath= "foo"/> must be the same as the context path applied by the servlet. HTTP protocol

Remote invocation protocol based on an HTTP form. See also: [Instructions for using HTTP protocol]
Number of connections: multiple connections
Connection mode: Short connection
Transport protocol: HTTP
Transmission mode: Synchronous transmission
Serialization: Serialization of Forms
Scope of application: Incoming outgoing parameter packet size mixed, the provider than the number of consumers, can be viewed by the browser, can be used in the form or URL parameters, and temporarily do not support the transfer of files.
Scenario: A service that needs to be used for both application and browser JS.

1, using Spring's httpinvoker realization
Configuration

<dubbo:protocol name= "http" port= "8080"/>
<!--Jetty Server--<dubbo:protocol
... server= " Jetty "/>
<!--servlet Bridge Server--
<dubbo:protocol ... server=" servlet "/>

Web. XML configuration

<servlet>
         <servlet-name>dubbo</servlet-name>
         <servlet-class> Com.alibaba.dubbo.remoting.http.servlet.dispatcherservlet</servlet-class>
         <load-on-startup>1 </load-on-startup>
</servlet>
<servlet-mapping>
         <servlet-name>dubbo</ servlet-name>
         <url-pattern>/*</url-pattern>
</servlet-mapping>

Note: If you use the servlet to distribute the request
The port of the protocol <dubbo:protocol port= "8080"/> must be the same as the port of the servlet container.
The context path of the protocol <dubbo:protocol contextpath= "foo"/> must be the same as the context path applied by the servlet. WebService Protocol

Remote invocation protocol based on WebService.
Number of connections: multiple connections
Connection mode: Short connection
Transport protocol: HTTP
Transmission mode: Synchronous transmission
Serialization: Soap text serialization
Application scenarios: System integration, cross-language invocation

1, based on the CXF frontend-simple and transports-http implementation.
2, CXF is an Apache open source RPC framework: http://cxf.apache.org, by Xfire and Celtix merged.
Depend on

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId> cxf-rt-frontend-simple</artifactid>
    <version>2.6.1</version>
</dependency>
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId> cxf-rt-transports-http</artifactid>
    <version>2.6.1</version>
</dependency>

Can interoperate with native webservice services, i.e.:
The provider exposes the service with the Dubbo WebService protocol, the consumer is called directly with the standard WebService interface, or the provider uses the standard WebService exposure service, and the consumer uses Dubbo's WebService protocol.
Constraints:
Parameters and return values need to implement Serializable interface
Parameters use basic types and pojo as much as possible.

<!--Define WebService protocol-
<dubbo:protocol name= "WebService" port= "8080" server= "jetty"/>
<!--Set Default protocol--
<dubbo:provider protocol= "WebService"/>
<!--set Service Protocol--
<dubbo:service protocol= "WebService"/>
<!--Multi Port-to-
<dubbo: Protocol id= "WebService1" name= "WebService" port= "8080"/>
<dubbo:protocol id= "Webservice2" Name= " WebService "port=" 8081 "/>
<!--Directly provider-
<dubbo:reference id=" HelloService " Interface= "HelloWorld" url= "Webservice://10.20.153.10:8080/com.foo.helloworld"/>
<!--WSDL--
http://10.20.153.10:8080/com.foo.HelloWorld?wsdl
<!--Jetty Server: (default)--
<dubbo: Protocol server= "Jetty"/>
<!--Servlet Bridge server: (recommend)--
<dubbo:protocol ... server= "Servlet"/>

Xml

<servlet>
         <servlet-name>dubbo</servlet-name>
         <servlet-class> Com.alibaba.dubbo.remoting.http.servlet.dispatcherservlet</servlet-class>
         <load-on-startup>1 </load-on-startup>
</servlet>
<servlet-mapping>
         <servlet-name>dubbo</ servlet-name>
         <url-pattern>/*</url-pattern>
</servlet-mapping>

Note: If you use the servlet to distribute the request:
The port of the protocol <dubbo:protocol port= "8080"/> must be the same as the port of the servlet container.
The context path of the protocol <dubbo:protocol contextpath= "foo"/> must be the same as the context path applied by the servlet. Thrift Protocol

The current Dubbo supported thrift protocol is an extension of the Thrift native protocol, adding additional header information, such as service name,magic number, based on the native protocol. Using the Dubbo Thrift Protocol also requires the use of thrift IDL compiler compilation to generate the appropriate Java code, in subsequent versions will do some enhancements in this area
Depend on

<dependency>
    <groupId>org.apache.thrift</groupId>
    <artifactid>libthrift</ artifactid>
    <version>0.8.0</version>
</dependency>

Configuration

<dubbo:protocol name= "Thrift" port= "3030"/>

Thrift does not support null values and cannot pass NULL memcached protocol in Protocol

You can register the address of the memcached service by manually filling out the form via script or monitoring center:

Registryfactory registryfactory = Extensionloader.getextensionloader (Registryfactory.class). GetAdaptiveExtension ( );
Registry Registry = Registryfactory.getregistry (url.valueof ("zookeeper://10.20.153.10:2181"));
Registry.register (url.valueof ("memcached://10.20.153.11/com.foo.barservice?category=providers&dynamic= False&application=foo&group=member&loadbalance=consistenthash "));

Then, when using the client, you do not need to perceive the memcached address:

<dubbo:reference id= "Cache" interface= "Http://10.20.160.198/wiki/display/dubbo/java.util.Map" group= "member"/ >

or point-to-point direct connection

<dubbo:reference id= "Cache" interface= "Http://10.20.160.198/wiki/display/dubbo/java.util.Map" url= "memcached:/ /10.20.153.10:11211 "/>

Custom Interfaces

<dubbo:reference id= "Cache" interface= "Com.foo.CacheService" url= "memcached://10.20.153.10:11211"/>

The method name recommendation is the same as the standard method name for memcached, which is: Get (key), set (key, value), delete (key).
If the method name and memcached standard method names are not the same, you need to configure the mapping relationship: (where "p:xxx" is the standard p label for spring)

<dubbo:reference id= "Cache" interface= "Com.foo.CacheService" url= "memcached://10.20.153.10:11211" p:set= "Putfoo "P:get=" Getfoo "p:delete=" Removefoo "/>

Redis Protocol

You can register the address of the Redis service by manually filling out the form with a script or monitoring center:

Registryfactory registryfactory = Extensionloader.getextensionloader (Registryfactory.class). GetAdaptiveExtension ( );
Registry Registry = Registryfactory.getregistry (url.valueof ("zookeeper://10.20.153.10:2181"));
Registry.register (url.valueof ("Redis://10.20.153.11/com.foo.barservice?category=providers&dynamic=false &application=foo&group=member&loadbalance=consistenthash "));

Then, when using the client, you do not need to perceive the Redis address:

<dubbo:reference id= "Store" interface= "Http://10.20.160.198/wiki/display/dubbo/java.util.Map" group= "member"/ >

Point-to-point direct connection

<dubbo:reference id= "Store" interface= "Http://10.20.160.198/wiki/display/dubbo/java.util.Map" url= "redis:// 10.20.153.10:6379 "/>

Custom Interfaces

<dubbo:reference id= "Store" interface= "Com.foo.StoreService" url= "redis://10.20.153.10:6379"/>

The method name recommendation is the same as the standard method name for Redis, which is: Get (key), set (key, value), delete (key).
If the method name differs from the standard method name for Redis, you need to configure the mapping relationship: (where "p:xxx" is the standard P-label for spring)

<dubbo:reference id= "Cache" interface= "Com.foo.CacheService" url= "memcached://10.20.153.10:11211" p:set= "Putfoo "P:get=" Getfoo "p:delete=" Removefoo "/>