# **业界常用的服务注册与发现组件对比** 了解服务注册与发现的基本原理后，如果你要在项目中使用服务注册与发现组件，当面对众多的开源组件该如何进行技术选型？ 在互联网公司里，有研发实力的大公司一般会选择自研或者基于开源组件进行二次开发，但是对于中小型公司来说直接选用一款开源软件会是一个不错的选择。 常用的注册与发现组件有eureka，zookeeper，consul，etcd等，由于eureka在2018年已经宣布放弃维护，这里就不再推荐使用了。  业界开源组件 下面结合各个维度对比一下各组件。 **组件优点缺点接口类型一致性算法**zookeeper1.功能强大，不仅仅只是服务发现； 2.提供watcher机制可以实时获取服务提供者的状态； 3.广泛使用，dubbo等微服务框架已支持；1.没有健康检查； 2.需要在服务中引入sdk，集成复杂度高； 3.不支持多数据中心；sdkPaxosconsul1.开箱即用，方便集成； 2.带健康检查； 3.支持多数据中心； 4.提供web管理界面；不能实时获取服务变换通知restful/dnsRaftetcd1.开箱即用，方便集成； 2.可配置性强1.没有健康检查； 2.需配合三方工具完成服务发现功能； 3.不支持多数据中心；restfulRaft 从整体上看consul的功能更加完备和均衡。接下来以consul为例详细介绍一下。 # **Consul——值得推荐的服务注册与发现开源组件** # **简单认识一下Consul** Consul是HashiCorp公司推出的开源工，使用Go语言开发，具有开箱即可部署方便的特点。Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。 # **Consul有哪些优势？** * 服务注册发现：Consul提供了通过DNS或者restful接口的方式来注册服务和发现服务。服务可根据实际情况自行选择。 * 健康检查：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联，也可以与本地节点相关联。 * 多数据中心：Consul支持多数据中心，这意味着用户不需要担心Consul自身的高可用性问题以及多数据中心带来的扩展接入等问题。 # **Consul的架构图**  Consul架构 Consul 实现多数据中心依赖于gossip protocol协议。这样做的目的： * 不需要使用服务器的地址来配置客户端；服务发现是自动完成的。 * 健康检查故障的工作不是放在服务器上，而是分布式的。 # **Consul的使用场景** Consul的应用场景包括**服务注册发现**、**服务隔离**、**服务配置**等。 **服务注册发现场景**中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check。 **服务隔离场景**中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密。 **服务配置场景**中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息。 # 完结 Redis**基于内存**，常用作于**缓存**的一种技术，并且Redis存储的方式是以key-value的形式。Redis是如今互联网技术架构中，使用最广泛的缓存，在工作中常常会使用到。Redis也是中高级后端工程师技术面试中，面试官最喜欢问的问题之一，因此作为Java开发者，Redis是我们必须要掌握的。 Redis 是 NoSQL 数据库领域的佼佼者，如果你需要了解 Redis 是如何实现高并发、海量数据存储的，那么这份腾讯专家手敲《Redis源码日志笔记》将会是你的最佳选择。  **感兴趣的朋友可以通过[点赞+戳这里的方式免费获取](https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB)腾讯专家手写Redis源码日志笔记pdf版本！**