An article that explains the HTTP protocol in Dubbo in detail

The sun is red, the flowers are colorful, hello readers and friends, it's time to share Dubbo knowledge points again. Speaking of the protocols supported by the Dubbo framework, what is your first reaction? There will probably be the dubbo protocol supported by Dubbo by default, and the old-fashioned rest protocol contributed to Dubbo by Dangdang, or today's protagonist http. As of now, the latest version of Dubbo has evolved to 2.7.3, and it already supports: dubbo, hessain, http, injvm, jsonrpc, memcached, native-thrift, thrift, redis, rest, rmi, webservice, xml and other protocols. The usage of some protocols has not yet been completed in the official documentation. It turns out that Dubbo supports so many protocols. Is it a bit unexpected for you?

[[278760]]

With so many RPC protocols, some people may have the following questions: Don't rest, jsonrpc, and webservice all rely on http communication? Why is there a separate http protocol? Don't rush to answer this question, but instead introduce today's topic and first introduce the so-called http protocol in the Dubbo framework.

http protocol in Dubbo

Using the http protocol in Dubbo is basically the same as using other protocols. You only need to specify the protocol.

 <dubbo:protocol name = "http" port= "8080" server= "jetty" /> 

Optional values ​​for the server attribute: jetty, tomcat, servlet.

After configuration, when the service consumer initiates a call to the service provider, the underlying layer will use the standard http protocol for communication. You can find the official sample directly at https://github.com/apache/dubbo-samples, where the submodule: dubbo-samples-http builds an example of http protocol call.

To avoid misunderstanding, we hereby declare that in this article, all http protocols refer specifically to the http protocols in dubbo, not the general http protocols that everyone is familiar with.

The underlying principle of the http protocol

It is very simple to change from the default dubbo protocol to the http protocol. The above is all the content seen from the user's perspective. Next, we will explore its underlying implementation principles.

Looking through the source code of Dubbo, you may be surprised to find the implementation of HttpProtocol. Basically, the http protocol is implemented by relying on the HttpProtocol class.

You should know that there are nearly 30 classes to implement a custom dubbo protocol! There are two main reasons why the http protocol is so simple to implement:

• The remoting layer uses http communication and does not require custom codecs
• With the help of HttpInvoker provided by Spring, the logic of refer and exporter is encapsulated

What is the HttpInvoker provided by Spring? It is indeed a relatively unfamiliar concept, but it is not complicated. In short, it uses Java serialization to convert objects into bytes and send them through http. On the server side, Spring can find the corresponding Bean reflection call process in the container based on the Url mapping. It doesn't matter if you have never seen it. You can quickly grasp this concept through the following examples.

Spring HttpInvoker

For more information about this section, see the Spring documentation: https://docs.spring.io/spring/docs/4.3.24.RELEASE/spring-framework-reference/htmlsingle/#remoting-httpinvoker-server

The following example will show how to use Spring's native HttpInvoker to implement remote calls.

Creating a Service Provider

 public class AccountServiceImpl implements AccountService {
 @Override
 public Account findById( int id) {
 Account account = new Account(id, new Date ().toString());
 return account;
 }
 }
 @Bean
 AccountService accountService(){
 return new AccountServiceImpl();
 }
 @Bean( "/AccountService" )
 public HttpInvokerServiceExporter accountServiceExporter(AccountService accountService){
 HttpInvokerServiceExporter exporter = new HttpInvokerServiceExporter();
 exporter.setService(accountService);
 exporter.setServiceInterface(AccountService.class);
 return exporter;
 }

The code for exposing the service is quite simple, but there are two points to note:

1. org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter is a service exposer encapsulated by Spring. It uses serviceInterface as the public interface and service as the implementation class to provide services to the outside world.
2. @Bean("/AccountService") not only specifies the name of the bean in the IOC container, but also acts as a path mapping. If the local server is exposed on port 8080, the access path of the example service is http://localhost:8080/AccountService

Creating a Service Consumer

 @Configuration
 public class HttpProxyConfig {
 @Bean( "accountServiceProxy" )
 public HttpInvokerProxyFactoryBean accountServiceProxy(){
 HttpInvokerProxyFactoryBean accountService = new HttpInvokerProxyFactoryBean();
 accountService.setServiceInterface(AccountService.class);
 accountService.setServiceUrl( "http://localhost:8080/AccountService" );
 return accountService;
 }
 }
 @SpringBootApplication
 public class HttpClientApp {
 public   static void main(String[] args) {
 ConfigurableApplicationContext applicationContext = SpringApplication.run(HttpClientApp.class, args);
 AccountService accountService = applicationContext.getBean(AccountService.class);
 System. out .println(accountService.findById(10086));
 }
 }

There are also two points to note when quoting services on the consumer side:

1. org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean is a service referencer encapsulated by Spring. serviceInterface specifies the interface for generating the proxy, and serviceUrl specifies the address of the service, which needs to correspond to the path of the previously configured service exposer.
2. When HttpInvokerProxyFactoryBean is registered in the container, a proxy class of the AccountService interface is generated at the same time, and Spring encapsulates the logic of remote calls.

Call details analysis

There is no need to delve into the underlying implementation of Spring HttpInvoker, but everyone will definitely be curious about some details: How is the HTTP message body organized in Dubbo? How to serialize objects?

We can use Wireshark to capture the request sent by the client and the response message of the server.

By tracking the message flow, you can see the detailed request and response content

From ContentType:application/x-java-serialized-object and the ASCII code of the message Body, we can see that Java Serialize is used for serialization. We export the Body to a file and use Java Serialize to deserialize the response to verify its true appearance:

The message can be deserialized normally using Java Serialize, and the result is Spring's built-in wrapper class RemoteInvocationResult, which is decorated with the actual business return result.

The significance of http protocol

The many protocols provided by Dubbo have their own applicable scenarios, such as

• dubbo://, dubbo protocol is the default protocol, a custom binary protocol; a single long connection saves resources; based on TCP, built on netty, the performance is decent; the protocol design is not forward-looking enough, not suitable for service-mesh, and not very elegant, but at least it has been used for so many years, and there are many supporting components around it, such as dubbo2.js, dubbo-go, and dubbo-cpp, which have solved the problem of multiple languages ​​to a certain extent.
• Protocols such as webservice://, hession://, thrift://, etc. are basically for adapting to the server/client of existing protocols. With the help of the API of the dubbo framework, its functional features can be used, which is not particularly meaningful.
• Protocols such as redis:// and memcached:// are not exposed to user configuration. They are usually used by Dubbo itself. The corresponding extensions are used in the registration center module.

I may write a separate article to analyze the specific usage scenarios and characteristics of all protocols. Now we need to think about what problems Dubbo solves by providing the http protocol and in what scenarios users will consider using Dubbo's http protocol.

I personally think that Dubbo's current http protocol is relatively useless. The advantage of native http communication lies in its versatility. Basically all languages ​​have supporting http clients and servers, but Dubbo's http protocol uses the application/x-java-serialized-object format as the default payload, which makes it lose its cross-language advantage. Some readers may argue that HttpInvoker supports configuring serialization formats, so we can't criticize it so hastily. But in fact, what we are concerned about is the default implementation, just as the dubbo:// protocol can also configure fastjson as a serialization solution, but we also don't think that the dubbo:// protocol is an excellent cross-language solution for the same reason. Of course, to evaluate whether an application layer protocol is excellent, whether it is suitable for mesh, etc., it requires multiple directions to analyze, which I will not analyze in this article.

After all, this article has spent a certain amount of space to introduce Dubbo's http protocol to you, but in the end I want to tell you: this is a relatively useless protocol. Are you disappointed? Don't be disappointed. Dubbo may abandon the existing http protocol in version 2.7.4 and use the jsonrpc protocol instead. In fact, it is just a name change for the jsonrpc protocol. I will introduce the details of jsonrpc in the next article. At that time, I will also analyze why jsonrpc is more suitable for wearing the hat of the http protocol than the existing http protocol. As for the existing http protocol, I prefer to call it: spring-httpinvoker protocol.

Summarize

What is the significance of dubbo's existing http protocol? If you are used to using Spring HttpInvoker, then perhaps the existing http protocol is still useful, but judging from the length of time spent on it in the Dubbo discussion group and Spring documentation, it is still very niche. At the same time, it can also help us better understand the history of protocol development, and know why a protocol exists and why it is eliminated.