preface

When I don’t know anything about a technology, I hate mystifying words in technical documentation because they discourage me from learning. After I mastered a technique, I discovered that they were all paper tigers. As I dig deeper into a technology, I realize that these words are not mystifying, because there is no more concise expression. This series will illustrate every aspect of Dubbo in the most literal way possible

1. What is service exposure

Take a look at the configuration of Dubbo Provider

<bean id= "xxxService" class= "com.xxx.XxxServiceImpl" /> // A common Java bean in Spring <dubbo:service Interface = "com.xxx.XxxService" ref= "XxxService" /> // Convert common Java beans in Spring to Dubbo ProviderCopy the code

This is a very common Spring Dubbo configuration (annot-based, API programming is equivalent), and in many articles that analyze the logic behind this configuration, one word often pops up — service exposure

2. Explain “service exposure” in plain English

Let me start by thinking of you as a beginner. Let’s start at the beginning…

Local method calls vs Remote method calls (RPC)

public class Test { @Autowired UserService userService ; public void addUser(){ User user = new User(); userService.addUser(user); }}Copy the code

This is a very simple code, userService addUser method is responsible for adding users

Userservice.adduser (user); Where is the userService object in this line of code? It could be in the current JVM heap, or it could just be a puppet, and the real execution would be remotely, say, on a computer in the United States

If userService is in the current JVM, then this line of code is the most common call — a local method call

If the actual logical execution of the userService is remote and the local is just a puppet, then this line of code is a remote method call

The method calls in Dubbo are RPC remote calls such as userService.adduser (user); If userService is dubbo’s consumer, then userService is essentially a dummy, and the real addUser(user) action is to be performed remotely

The local dubbo consumer executes userService.adduser (user); After serializing the collected information into a byte stream, the userService puppet is responsible for transmitting the byte stream to a remote location over the network. When the information is received remotely, it is deserialized and restored. So the remote real userService knows which method of which class to call, what the input parameter is, and so on, and the remote actually performs the addUser(user) logic

The emergence of a problem

How does the local userService puppet know where the remote is? At the very least, he needs to know the remote IP address and port number. Otherwise, how can he initiate a network connection and transmit the collected byte stream?

The simplest idea is that the remote real userService needs to expose itself to the outside world. It needs to listen for an IP address or port number remotely, and then put the IP address or port number in a public place (accessible to all) so that when the local puppet initiates a network connection, Can go to this public place to check first, according to check IP, port initiated network connection

3. The nature of exposure

To sum up, the exposed essence is: Dubbo Provider listens to an IP, port number, and registers in a public place (ZK).

Know this essence, look at the source code is not simple, the next one with you to read the source code