[Note: This article refers to "Introduction to Dubbo---Building a Simplest Demo Framework" , thanks to the original author for his knowledge exploration and dedication]
1. Dubbo background and introduction
Dubbo started in the e-commerce system, so here we start with the evolution of the e-commerce system.
1. Single application framework (ORM)
When the website traffic is very small, only one application is needed, and all functions (such as order payment, etc.) are deployed together to reduce deployment nodes and costs. At this point, a data access framework (ORM) that simplifies the CRUD workload is key.
Disadvantages: The single system architecture makes more and more resources occupied during the development process, and becomes more and more difficult to maintain as the traffic increases.
2. Vertical Application Framework (MVC) The
vertical application architecture solves the expansion problem faced by a single application architecture. The traffic can be dispersed among various subsystems, and the volume of the system is controllable, which reduces the collaboration and maintenance between developers to a certain extent. cost and improve development efficiency. At this point, a web framework (MVC) for accelerating front-end page development is key.
Disadvantages: The same logic code in the vertical architecture needs to be copied continuously and cannot be reused.
3. Distributed application architecture (RPC)
When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, and a stable service center is gradually formed. At this time, the distributed service framework (RPC) for improving business reuse and integration is the key.
RPC (Remote Procedure Call Protocol): Remote Procedure Call:
Two servers A and B deploy different applications a and b respectively. When server A wants to call a function or method provided by application b on server B, it cannot be called directly because it is not in a memory space. It needs to express the semantics of the call and convey the data of the call through the network.
To put it bluntly, you wrote a program on your machine, which I cannot call directly. At this time, the concept of a remote service call appears.
RPC is a protocol for requesting services from a remote computer program over a network without requiring knowledge of the underlying network technology. The RPC protocol assumes the existence of some transport protocol, such as TCP or UDP, to carry information data between communicating programs. In the OSI network communication model, RPC spans the transport layer and the application layer. RPC makes it easier to develop applications including network distributed multiprogramming.
RPC uses a client/server model. The requestor is a client, and the service provider is a server. First, the client calling process sends a call message with process parameters to the server process, and then waits for a reply message. On the server side, the process stays asleep until the call message arrives. When a call message arrives, the server obtains the process parameters, calculates the result, sends a reply message, and then waits for the next call message. Finally, the client calls the process to receive the reply message, obtain the process result, and then the call execution continues.
Problems that RPC needs to solve:
Communication problems: Mainly by establishing a TCP connection between the client and the server, all the exchanged data of the remote procedure call are transmitted in this connection. The connection can be an on-demand connection that is disconnected after the call ends, or it can be a persistent connection, where multiple remote procedure calls share the same connection.
Addressing problem: How does the application on the A server tell the underlying RPC framework how to connect to the B server (such as a host or IP address) and a specific port, what is the name of the method, so that the call can be completed. For example, for RPC based on the Web service protocol stack, it is necessary to provide an endpoint URI, or to find it from the UDDI service. If it is called by RMI, an RMI Registry is also required to register the address of the service.
Serialization and deserialization: When the application on the A server initiates a remote procedure call, the parameters of the method need to be passed to the B server through the underlying network protocol such as TCP. Since the network protocol is based on binary, the value of the parameters in the memory must be Serialize into binary form, that is, serialize (Serialize) or marshal (marshal), and send the serialized binary to the B server through addressing and transmission.
In the same way, the B server needs to deserialize the parameters to receive the parameters. The result returned by the B server application after calling its own method for processing should also be serialized to the A server, and the reception by the A server should also go through the process of deserialization.
4.
With the further development of service-oriented architecture (SOA), there are more and more services, and the invocation and dependencies between services are becoming more and more complex. The service-oriented architecture system (SOA) was born, and thus derived A series of corresponding technologies have been developed, such as service boxes that encapsulate behaviors such as service provision, service invocation, connection processing, communication protocols, serialization methods, service discovery, service routing, and log output. At this point, a Resource Scheduling and Governance Center (SOA) for improving machine utilization is key.
From the evolution of the above e-commerce system, we can see the process of architecture evolution:
So, what is Dubbo?
Dubbo is:
A distributed service framework
High-performance and transparent RPC remote service invocation scheme
SOA Service Governance Solution
So far, Dubbo has provided more than 3 billion visits per day for more than 2,000 services, and has been widely used in Alibaba Group's member sites and other companies' businesses.
Dubbo Architecture:
Provider: The service provider that exposes the service. Consumer: The service consumer that invokes the remote service. Registry: A registry for service registration and discovery. Monitor: The monitoring center that counts service calls and call times.
Calling process
① The service container is responsible for starting, loading, and running the service provider.
② When the service provider starts, it registers the service it provides with the registration center.
③ When the service consumer starts, it subscribes to the registration center for the services it needs.
④ The registration center returns the service provider address list to the consumer. If there is a change, the registration center will push the change data to the consumer based on the long connection.
⑤Service consumers, from the provider address list, based on the soft load balancing algorithm, select a provider to call, and if the call fails, select another provider to call.
⑥ Service consumers and providers, accumulate the number of calls and call time in memory, and regularly send statistical data to the monitoring center every minute
Dubbo Registration Center
For service providers, it needs to publish services, and due to the complexity of the application system, the number and types of services are also expanding;
For the service consumer, it is most concerned about how to obtain the services it needs, and in the face of complex application systems, it needs to manage a large number of service calls.
Moreover, for service providers and service consumers, they may also have both roles, that is, they need to provide services and consume services.
Through unified management of services, the process and management of service publishing/use by internal applications can be effectively optimized. The service registry can complete the external unification of services through specific protocols.
The registration center provided by Dubbo has the following types to choose from:
Multicast Registry
Zookeeper Registry
Redis registry
Simple Registry
Advantages and disadvantages of Dubbo:
(1) Advantages:
①Transparent remote method invocation. Remote methods can be called just like local methods; simple configuration without any API intrusion.
②Soft load balancing and fault tolerance mechanism. It can replace hardware load balancers such as nginx lvs in the intranet.
③The service registration center automatically performs registration and configuration management. There is no need to hard-write the service provider address. The registry automatically queries the provider ip based on the interface name. Using distributed coordination services such as zookeeper as the service registry, most project configurations can be moved into the zookeeper cluster.
④Service interface monitoring and management. Dubbo-admin and Dubbo-monitor provide complete service interface management and monitoring functions. For different interfaces of different applications, multi-version, multi-protocol, and multi-registry management can be performed.
(2) Disadvantage:
Only JAVA language is supported.
2. Dubbo Getting Started Demo
After learning about Dubbo, let's build a simple Demo implementation next. This article adopts the integration of Dubbo with Zookeeper and Spring framework.
Mainly the following steps: 1. Install Zookeeper and start it; 2. Create a MAVEN project and build a simple Demo implemented by Dubbo+Zookeeper+Spring; 3. Install Dubbo-admin for monitoring.
1. Install Zookeeper
Zookeeper is a distributed service framework. It is a tree-type directory service data store. It can manage data in clusters. It can be used as a registration center for Dubbo services.
Dubbo can be deployed in clusters with Zookeeper. When the provider experiences abnormal shutdowns such as power failure, the Zookeeper registry can automatically delete provider information. When the provider restarts, it can automatically restore registration data and subscription requests.