Table of contents
When they are used together, the relationship between
What is Dubbo?
Dubbo is an open source, high-performance, lightweight distributed service framework. It is committed to providing reliable RPC (remote procedure call) communication so that different applications can call each other through the network to achieve communication between distributed systems. Communicate and collaborate efficiently.
In layman's terms, we can compare Dubbo to a courier company. Suppose there is an e-commerce platform that needs to handle operations such as user ordering, payment, and delivery, and these operations are handled by different subsystems (such as the order system, payment system, and logistics system). In the traditional architecture, complex interface docking and data transmission are required between these subsystems, which is very cumbersome.
With the Dubbo framework, we can call each subsystem a service, which is like calling each subsystem a courier site. The Dubbo framework provides the functions of service registration, discovery and invocation, just like there is a central dispatch center in an express delivery company. Each subsystem will register the services it provides with the central dispatch center, and other subsystems can query and call these services through the central dispatch center.
For example, when a user places an order, the order system will submit the order information to Dubbo's central dispatch center. The payment system will monitor the central dispatch center. When it finds that there is a new order that needs to be paid, it will actively call the payment service provided by the order system to complete the payment operation. The logistics system will also monitor the central dispatch center. When it finds that there is a new order that needs to be shipped, it will actively call the shipping service provided by the order system to complete the logistics operation.
Through the Dubbo framework, communication and collaboration between these subsystems become simple and efficient. Each subsystem only needs to focus on its own business logic without having to care about the implementation details of other systems.
What are the benefits of turning system modules into distributed ones? Why do we need to call them remotely when they can run on one machine?
Transforming system modules into a distributed architecture has the followingseveral benefits:
-
Improve performance and scalability: By distributing system modules across multiple machines, each machine can independently handle a portion of the workload, thereby improving overall system performance and throughput. If the system needs to handle larger amounts of data or concurrent requests, the system's capabilities can be expanded by adding more machines.
-
Improve the reliability and fault tolerance of the system: Modules in the distributed architecture can be deployed on different machines. When one of the machines fails, the other machines can still continue to provide services, thus improving the reliability and fault tolerance of the system. . Additionally, a distributed architecture can use data replication, backup, and redundancy mechanisms to prevent data loss and single points of failure.
-
Realize resource sharing and load balancing: Resource sharing and load balancing between different machines can be achieved through remote calls. For example, in a distributed system, computing-intensive tasks can be assigned to machines with higher performance, and storage tasks can be assigned to machines with rich storage resources, thereby making full use of the characteristics and advantages of each machine.
-
Reduce development and maintenance costs: By splitting system modules into distributed services, different teams can independently develop and maintain the services they are responsible for, thereby reducing the coupling between various modules and development coordination costs. In addition, since each module is relatively independent, the system can be upgraded and expanded more easily.
What is Zookeeper?
ZooKeeper is an open source distributed coordination service framework designed to provide highly reliable distributed coordination functions for building and managing distributed systems.
ZooKeeper provides a simple and powerful set of distributed coordination primitives, including data publishing/subscription, distributed locks, distributed queues, elections, etc. It uses a tree-shaped data structure to organize and store data, similar to the directory structure of a file system. Each node (called a ZNode) can store a small piece of data and can also have child nodes.
ZooKeeperMain featuresinclude:
-
High performance: ZooKeeper's memory-based data model and asynchronous data replication mechanism have low latency and high throughput, and perform well in large-scale distributed systems.
-
Reliability: ZooKeeper adopts a multi-copy replication mechanism to replicate data on multiple nodes. When some nodes fail, the reliability and availability of the data can still be maintained.
-
Sequential consistency: ZooKeeper provides strong consistency data access guarantees, that is, the client has a global linear order in the data state it sees.
-
High scalability: ZooKeeper supports cluster mode, and its performance and capacity can be expanded by adding more nodes.
ZooKeeper is often used to build distributed applications, such as distributed databases, distributed caches, distributed locks, etc. It provides a simple but powerful API that can help developers achieve coordination and synchronization operations in distributed systems.
When they are used together, the relationship between
When Dubbo and Zookeeper are used together, their relationship can be divided into three aspects: service registration, service discovery and dynamic address management.
Service registration
DubboRegister the service provider's information to the Zookeeper center so that service consumers can discover and call services. The service provider first starts its own service, and then registers its own service provider's information (including IP address, port number, service interface, etc.) to the designated node on Zookeeper to complete the service registration process. In this way, the service consumer can obtain the list of available services from Zookeeper.
service discovery
Dubbo’s service consumer subscribes to Zookeeper for a specific service interface, Zookeeper will The list of available providers under the interface is returned to the consumer. Consumers can choose to call from one of these providers based on custom routing rules or load balancing policies. After the service consumer subscribes to the service interface, the Dubbo framework will monitor changes in the Zookeeper registration center node. Once a new service provider registers or logs off, Zookeeper will automatically notify the Dubbo framework, and the Dubbo framework will update the local server based on the updated service provider list. Cached service provider list, ensuring that the service provider list is up-to-date and accurate.
Dynamic address management
Dubbo uses Zookeeper as the registration center to realize dynamic management of service addresses. When a new service provider comes online or goes offline, Zookeeper will notify Dubbo of the corresponding event. Dubbo will automatically update the available services after receiving the event. The address list enables the caller to discover new service address information.