Distributed field CAP theory,
Consistency (consistency), consistent data update, all data changes are synchronous
Availability (availability), good response performance
Partition tolerance (partition tolerance) Reliability
theorem: any distributed system can only simultaneously Satisfying two points, it is impossible to take care of all three.
Advice: architects should not waste energy on how to design the perfect distributed system that satisfies all three, but should make trade-offs.
Original link address:
Here is a comparison of the characteristics of the products that are often used in service discovery. First of all, let's look at the conclusions:
Feature Consul zookeeper etcd euerka| Service Health Check | Service status, memory, hard disk, etc. | (Weak) long connection, keepalive | connection heartbeat | Configurable support |
| Multiple data centers | support | — | — | — |
| kv storage service | support | support | support | — |
| consistency | raft | paxos | raft | — |
| cap | that | cp | cp | ap |
| Using the interface (multilingual capability) | Support http and dns | client | http/grpc | http（sidecar） |
| watch support | Full/support long polling | support | Support long polling | Supports long polling/most increments |
| self-monitoring | metrics | — | metrics | metrics |
| Safety | acl /https | acl | https support (weak) | — |
| spring cloud integration | supported | supported | supported | supported |
- Service Health Check
Euraka needs to explicitly configure health check support when using it; Zookeeper and Etcd have unhealthy tasks when the connection to the service process is lost, while Consul is relatively more detailed, such as whether the memory has been used 90%, and the space of the file system is Not nearly enough.
- Multiple data center support
Consul completes synchronization across data centers through the WAN's Gossip protocol; and other products require additional development work to achieve;
- KV Storage Service
In addition to Eureka, other models can support kv storage services externally, so the important reasons for these products to pursue high consistency will be discussed later. The provision of storage services can also be better transformed into dynamic configuration services.
- The trade-off of CAP theory in product design
Eureka's typical AP is suitable as a service discovery product in distributed scenarios. The availability priority of service discovery scenarios is high, and consistency is not particularly fatal. Secondly, in the CA type of scenario Consul, it can also provide high availability and ensure consistency with the kv store service. Zookeeper and Etcd are CP types that sacrifice availability and do not have much advantage in service discovery scenarios;
- Multilingual ability and access agreement for external service provision
Zookeeper's cross-language support is weak, and several other models support http11 to provide access. Euraka generally provides access support for multilingual clients through sidecars. Etcd also provides Grpc support. In addition to the standard Rest service API, Consul also provides DNS support.
- Watch support (clients observe service provider changes)
Zookeeper supports server-side push changes, and Eureka 2.0 (in development) is also planned to support it. Eureka 1, Consul, and Etcd all realize change perception through long polling;
- Monitoring of own cluster
In addition to Zookeeper, several other models support metrics by default, and operators can collect and alert these metrics for monitoring purposes;
- Safety
Consul, Zookeeper support ACL, and Consul, Etcd support secure channel https.
- Integration with Spring Cloud
Currently, there are corresponding boot starters that provide integration capabilities.
In general, at present, Consul's own functions and spring cloud's support for its integration are relatively complete, and the complexity of operation and maintenance is relatively simple (no detailed discussion is listed). Eureka's design is more in line with the scene, but it needs to continue of perfection.