Dubbo+zokeeper basic explanation

The essence of dubbo: a Jar package, a distributed framework, and a distributed framework for remote service calls.

1. What is dubbo?

#1) Since this is a tutorial for novices, many students must not understand what distributed and remote service calls are, why they need to be distributed, and why they need remote calls. I will simply draw a comparison chart to illustrate (see Figure 1 in Figure 2. It is drawn on a drawing board, please do not spray).

Think about it, everything used to be on the same server, and the calling method was called directly and naturally, no problem. Now due to the increase in demand, so many of them have been split and deployed on different servers. Is it different from the fact that they were all on one server before? Now that they are distributed, the services of the web layer calling the service layer have become remote calls? So how can we naturally call methods on the same server as before? dubbo to solve it. This is the benefit of dubbo below.

2. What are the benefits of Dubbo?

1. Transparent remote method invocation, just like calling local methods, requires simple configuration without any API intrusion.

2. Soft load balancing and fault tolerance mechanisms can replace hardware load balancers such as F5 on the intranet, reducing costs and single points.

3. Automatic service registration and discovery, no longer need to hard-code the service provider address. The registration center queries the IP address of the service provider based on the interface name, and can smoothly add or delete service providers. (Explained below)

Dubbo uses a full Spring configuration method to transparently access applications without any API intrusion into the application. You only need to use Spring to load Dubbo's configuration. Dubbo loads based on Spring's Schema extension.

3. Dubbo architecture diagram is as follows:

Before explaining his architecture diagram, let’s popularize a few concepts.

Node role description:

Provider (producer): The service provider that exposes services.

Consumer: The service consumer that calls the remote service.

As shown in the figure, we can simply understand that web1234 needs to call the service of service1234, so web1234 is the consumer and service1234 is the producer.

If the consumer calls the producer's service according to the above, is it as shown below:

You Are you dizzy looking at it? Faint or not? Faint or not? Anyway, I was dizzy, what if it was distributed even more? , so we need him:

Registry (registration center): the registration center for service registration and discovery. Dubbo recommends zookeeper. What is zookeeper? Zookeeper is a framework for consistency processing in distributed systems. For more information, you can check out my previous article: Let’s put it this way, zookeeper is very simple. In fact, it is just a framework, used for consistency processing. To put it simply, ZooKeeper is an intermediary. Property sellers (producers) put property information on the intermediary (registration center), and people who want to buy properties (consumers) go to the intermediary to obtain a list of property resources. So, our picture becomes like this:

Isn’t it much better? If it's not enough, we also need a monitoring center (what is it used for? Of course it is for monitoring. What should I do if the call fails? What should I do if it hangs?): Monitor: Monitoring center that counts the number of calls and the call time of the service. (No more drawing)

Then, the Provider is run in the container, which is called the Container service to run the container. (No more drawing)

The final dubbo architecture, as shown in the picture (starting from 0):

Related recommendations:

Taobao Amoeba architecture MySQL distributed database environment_MySQL

Daily average million PV architecture fourth bullet (distributed monitoring)_MySQL

The above is the detailed content of Dubbo+zokeeper basic explanation. For more information, please follow other related articles on the PHP Chinese website!