When do microservices use the Http protocol to communicate, and when do they use Lrpc?

Let me first state the following conclusion.

1 Spring cloud microservices, as well as the second-generation microservices, spring cloud alibaba, can be called using openfeign, that is, using the http or https protocol, or through dubbo, which is the so-called rpc, which is called remote method call. It is an implementation method. The underlying implementation generally relies on communication protocols such as tcp or udp.

2 Since the http protocol contains information such as the request header, its efficiency is somewhat slower than that of the tcp protocol. However, if the concurrency is not high, the so-called inefficiency of http can be ignored. Since the https protocol has additional security verification actions based on SSL, its communication efficiency is slightly lower than that of http. However, if the concurrency is not high, this is acceptable.

3 In the microservice architecture, you can also use the resttemplate method for remote calls, or the restful method, but restful is also a calling method, and the underlying implementation uses http or https.

4 It can be said that in most scenarios, especially for projects developed by small and medium-sized companies, using spring cloud + http protocol is sufficient to handle concurrent requests of the project. And once the concurrency is high, it can be handled by means such as nacos-based expansion and redis-based cache. If you want to further explore the performance potential, then use tcp-based communication protocols, such as dubbo or netty, but this requires programmers, and using spring cloud + http-based openfeign can basically be used by most junior developers.

The detailed description is as follows.

1 The interaction between microservice modules is generally based on the HTTP protocol, or RPC (TCP), such as Dubbo, but the performance difference between the two is not much. Moreover, to cope with high concurrency, such as payment scenarios, generally three instances are started, managed by Nacos, and external gateways such as Gateway are used for load balancing.

In this case, two instances (hot standby to avoid single point failure) can handle hundreds of concurrent requests per second. In fact, most projects cannot reach 100 concurrent requests per second. In other words, spring cloud alibaba+nacos+gateway+2 instances, even if using http protocol, or even introducing https with ssl security verification, can really meet the concurrency requirements of most projects.

2 If you want to optimize performance, for example, to achieve a concurrency of 2k or even higher per second, the most direct way is to stack machines. For example, deploy an instance on multiple machines. If one machine can handle a concurrency of 500 per second, then deploy 4 machines. Generally, projects or companies with high concurrency requirements are not short of money, so it is common to deploy 4 instances.

Moreover, coping with high concurrency actually depends more on the database level and business interaction level. If you introduce redis or redis cluster, or sub-library components, or introduce kafka for asynchronous business processing in the project, with 3 or 4 instances, even if you use openfeign based on the http protocol, it will not be a big problem to cope with 2,3k concurrency.

3 Another point you need to pay attention to is that the spring cloud alibaba component is ready to use out of the box, so using openfeign based on the http protocol to implement calls between components is generally something that any junior developer with half a year of project experience can do. Or you can introduce SSL and use the https protocol to communicate, which is not difficult to develop.

4 For communication between microservice modules, in addition to http, you can actually use tcp. The efficiency of tcp is higher than that of http. I have done optimization in this aspect in high-concurrency projects before. Under the same conditions, the efficiency of using tcp protocol for communication is generally about 1/3 higher than that of https and http protocols.

However, if you use TCP interaction, although you do not need to transmit business-independent HTTP request headers and return header information during the communication process, you have to ensure the integrity of the data yourself during the development interaction process. For example, if you use md5, you have to write the data message protocol yourself. Generally, you also need to use the thread model of Netty or other components to handle TCP requests in high-concurrency situations. The difficulty of these tasks is not something that junior developers can do.

Therefore, even if the http protocol is used for interaction between microservice modules, the performance is actually not slow, it can meet the needs of most projects, and it is quite convenient to develop. Therefore, many small companies give priority to using http-based components when doing projects with average profits.

Of course, if there are higher requirements for performance, improvements must be made at the protocol layer, such as using TCP. This is already a very later thing. It must be done after exhausting capacity expansion and introducing components such as redis and kafka before using TCP and other protocols, but this places higher demands on programmers.

If someone says during an interview that they use http or rpc, it's not a big problem, but most people generally only use apis, such as dubbo, openfeign, or resttemplate apis. Going a step further, you can say that you use http or rpc, but through performance testing, you find that you need to introduce components such as redis into the project to ensure the concurrency required by the business.

For a more advanced level, you can combine dubbo or netty underlying layer to talk about the details of rpc. That’s not all. You can also talk about the details of rpc in combination with the tuning scenarios of your own projects, such as the process of implementing tcp communication or the problems that have been solved.