业界常用的服务注册与发现组件对比
了解服务注册与发现的基本原理后,如果你要在项目中使用服务注册与发现组件,当面对众多的开源组件该如何进行技术选型?
在互联网公司里,有研发实力的大公司一般会选择自研或者基于开源组件进行二次开发,但是对于中小型公司来说直接选用一款开源软件会是一个不错的选择。
常用的注册与发现组件有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中读取到准确的配置信息。
总结:绘上一张Kakfa架构思维大纲脑图(xmind)
其实关于Kafka,能问的问题实在是太多了,扒了几天,最终筛选出44问:基础篇17问、进阶篇15问、高级篇12问,个个直戳痛点,不知道如果你不着急看答案,又能答出几个呢?
若是对Kafka的知识还回忆不起来,不妨先看我手绘的知识总结脑图(xmind不能上传,文章里用的是图片版)进行整体架构的梳理
CodeChina开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】
梳理了知识,刷完了面试,如若你还想进一步的深入学习解读kafka以及源码,那么接下来的这份《手写“kafka”》将会是个不错的选择。
-
Kafka入门
-
为什么选择Kafka
-
Kafka的安装、管理和配置
-
Kafka的集群
-
第一个Kafka程序
-
Kafka的生产者
-
Kafka的消费者
-
深入理解Kafka
-
可靠的数据传递
-
Spring和Kafka的整合
-
SpringBoot和Kafka的整合
-
Kafka实战之削峰填谷
-
数据管道和流式处理(了解即可)