Dubbo implements service invocation through RPC, that is, the client and server share an interface (make the interface into jar package, and introduce jar package into the client and server), the client writes the call for the interface, the server writes and implements the interface, and the network communication in the middle is handed over to the framework for implementation.
Let's take a look at the Spring configuration statement exposure service, provider.xml file.
Let's look at the service consumer.xml file.
This is a typical point-to-point service call. Of course, for high availability, we can configure multiple service providers in consumer.xml and configure the response load balancing policy.
Configure multiple service callers, and add multiple addresses in the url attribute of the dubbo:reference tag of comsumer.xml, separated by semicolons; To configure the load balancing policy, just add the loadbalance attribute in the dubbo:reference tag of comsumer.xml Values can be of the following four types:
So what's wrong with the current architecture?
1. When a service provider adds a node, the configuration file needs to be modified.
2. When one of the service providers goes down, the service consumers can't perceive it in time and send a request to the down service.
At this time, it is necessary to introduce a registration center. Dubbo currently supports four types of registration centers (multicast, zookeeper, redis and simple). Recommend Zookeeper registration center. To use the registry, simply change provider.xml and consumer.xml as follows:
If zookeeper is a cluster, multiple addresses can be separated by commas.
Delete the direct connection mode configured in consumer.xml
How to save registration information in zookeeper?
After starting the above services, we observed that the root node of zookeeper has a dubbo node and other nodes, as shown below.
Why is the address of the service in the last node marked green? Because the last node is a temporary node and other nodes are persistent nodes, when the service goes down, this node will automatically disappear, no longer provide services, and service consumers will not request it again. If more than one demoservice is deployed, there will be several nodes under providers, and each node will save a service address of demo service.
In fact, a zookeeper cluster can be shared by multiple applications, because different frameworks will build different nodes on zookeeper without affecting each other. For example, dubbo will create a /dubbo node, and storm will create a /storm node.
City zoo introduced:
Zookeeper is a subproject of Apacahe Hadoop. It is a tree directory service that supports change push. It is suitable as the registration center of Dubbo service, with high industrial intensity and can be used in production environment. Suggestions.
Process description:
The following functions are supported:
Supplement:
What serialization framework does dubbo's protocol use?
Dubbo has many protocols, and different protocols use different serialization frameworks by default. For example, the dubbo protocol uses Hessian2 serialization by default (note: Hessian2 is Ali's secondary development based on Hessian, named Hessian2). Rmi protocol defaults to java local serialization, blogs.com/iisme/p/10620125.html. 。