First of all, then why are not suitable for zookeeper service registry it?
From the point of view of CAP
There is a thinking, consider the perspective from the CAP, the service registry system is CP or AP system?
First, the service registry for services between service calls, then definitely not registered as service center there is a problem caused by problems between service calls.
Furthermore, if there is node1, node2, node3, cluster nodes. Save the list of available services ip1, ip2, ip3, imagine if this time is inconsistent, such as node1 only saved ip1, ip2, this time reading service node node1, then what are the implications?
Node1 calling service, at most, there will be no traffic hit ip3, then sync back after node1 and other ip3, but also a consistent load balancing, this service is in fact nothing much impact.
Therefore, the introduction of the service center should be a registered AP system.
zookeeper was a CP system, strong consistency .
Scene 1, when master hung up, this time, zookeeper cluster need to re-election at a time when services need to read the available services are not available. Affect the availability of the service
Of course, you can say there cached locally available service list. However, following this way even it is impossible to deal with.
Scenario 2, the partition is available. Just think, there are three rooms, and if one room 3 room 1,2 network is broken, then the registration center 3 room can not register new machine yet, which is obviously unreasonable
From the point of view health check
zookeeper is available through TCP is the heartbeat of judgment Service
But TCP activity does not mean that the service is available, but it shows active TCP services are available to it, the answer is clearly no, for example: connection pool is full, DB hung up, etc.
Under less than ideal registry is what it, thinking
1, at least an automatic service registration, discovery. But also pushed to end calls when best to have the new service up registration
2, can be managed conveniently up to a registered machine can eliminate manual (service sends a signal to let off the assembly line elegant), restore the machine
3, health check services, can actually detect service is available
4, if even the best point, you can see whether there are other subscription services are registered up call service
5, if we can take some other information in addition to IP outside, so much the better
ZooKeeper fact, even more than I thought bottleneck, said at a recent encounter
1. ZooKeeper write is not extensible, when registering a certain node, the write performance bottleneck, queues when you publish, the phenomenon is manifested, launch applications become very slow
2. ZooKeeper does not support routing across the room, unlike eureka, the concept of zone, giving priority to local routing, routing when this room, in this room when there is a problem, can be routed to another room
When too many nodes, service nodes if there is change, you need to notify 3. ZooKeeper machine, "thundering herd effect" will occur, and instantly played cards, and easy to repeat notice
