consul和eureka的区别是：1.集群部署不同；2. 节点健康检查的方式不同。其中，consul提供了cp一致性、分区容错性，对于consul集群来说，consul注册中心分为leader和fellow，服务注册和发现会落地到leader去提供。
一、consul和eureka的区别
1.集群部署不同
consul提供了cp一致性、分区容错性，对于consul集群来说，consul注册中心分为leader和fellow，服务注册和发现会落地到leader去提供，当一个项目A想要注册到consul时，leader需要保证A服务注册信息同步到半数以上的fellow consul节点才算注册成功，之后才可以被其他服务发现并调用。当leader挂掉后，需要选举出新的leader节点，选举过程中consul集群不可用；eureka提供ap可用性、分区容错性，eureka集群并没有leader和follow的概念，当一个服务注册到其中一个eureka节点后，它可能在其他eureka节点并没有该服务的注册信息，eurake节点之间会相互注册，同时会互相同步注册信息。由上可以看出，consul服务注册信息的数据一致性较高，但是它的注册过程会慢一些，因为需要将注册信息同步到其他节点，而eureka的注册比较快，因为不需要实时同步注册信息。并且一般在服务的defaultZone字段会配置集群中的多个eureka节点（注册到任意一个都可以，并且节点之间会互相注册同步注册信息），eureka集群保证服务的可用性，可以容忍一段时间内的注册信息不一致。
2. 节点健康检查的方式不同
Eureka集群中每个client服务隔一段时间就需要发送心跳到erueka server，用于表示自己可以正常提供服务，该erueka节点会将心跳信息同步到其他erueka节点，eureka会定时(30S)进行检查，如果发现一段时间(90S)内没有收到服务心跳，就认为这个服务宕机。在这种情况下，如果有大量服务同时发送心跳，就有可能对erueka节点造成较大的心跳请求压力。
Consul中在每一个服务上都有一个consul agent，使用该agent不断发送请求检查服务是否健康，当服务出现故障时，会发送消息通知consul server leader，这样就避免了短时间内向注册中心server发送大量的心跳请求。
延伸阅读：
二、服务注册中心解决方案
设计或者选型一个服务注册中心，首先要考虑的就是服务注册与发现机制。纵观当下各种主流的服务注册中心解决方案，大致可归为三类：
应用内：直接集成到应用中，依赖于应用自身完成服务的注册与发现，最典型的是Netflix提供的Eureka
应用外：把应用当成黑盒，通过应用外的某种机制将服务注册到注册中心，最小化对应用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul
DNS：将服务注册为DNS的SRV记录，严格来说，是一种特殊的应用外注册方式，SkyDNS是其中的代表
以上就是关于consul和eureka的区别的内容希望对大家有帮助。
