服务发现框架选型

Zookeeper

1. 确保有所选语言的sdk,理论上github上第三方的库有一些,仔细筛选一下应该可以用。

2. 调用zookeeper接口连接zookeeper服务器。

3. 注册自身服务

4. 通过watcher获取监听服务的状态

5. 服务提供者需自行保持与zookeeper服务器的心跳。

总得来说,ZooKeeper需要胖客户端,每个客户端都需要通过其SDK与ZooKeeper服务保活,增加了编写程序的复杂性。此外,还提供api实现服务注册与发现逻辑,需要服务的消费者实现服务提供者存活的检测。

Etcd

etcd是一个采用http协议的分布式键值对存储系统,因其易用,简单。很多系统都采用或支持etcd作为服务发现的一部分,比如kubernetes。但正事因为其只是一个存储系统,如果想要提供完整的服务发现功能,必须搭配一些第三方的工具。

比如配合etcd、Registrator、confd组合,就能搭建一个非常简单而强大的服务发现框架。但这种搭建操作就稍微麻烦了点,尤其是相对consul来说。所以etcd大部分场景都是被用来做kv存储,比如kubernetes。

consul

相比于zookeeper的服务发现使用,consul并不需要专门的sdk集成到服务中,因此它不限制任何语言的使用。我们看看consul一般是怎么使用的。

1. 每台服务器上都要安装一个consul agent。

2. consul agent支持通过配置文件注册服务,或者在服务中通过http接口来注册服务。

3. 注册服务后,consul agent通过指定的健康检查方式,定期检查服务是否存活。

4. 如果服务想查询其他服务的存活状态,只需要与本机的consul agent发起一次http请求或者dns请求即可。

简单点说,consul的使用不依赖任何sdk,依靠简单的http请求就能满足服务发现的所有逻辑。

不过,服务每次都从consul agent获取其他服务的存活状态,相比于zookeeper的watcher机制,实时性稍差一点,需考虑如何尽可能提高实时性,问题不会很大。

名称 优点 缺点 接口 一致性算法
zookeeper 1.功能强大,不仅仅只是服务发现
2.提供watcher机制能实时获取服务提供者的状态
3.dubbo等框架支持
1.没有健康检查
2.需在服务中集成sdk,复杂度高
3.不支持多数据中心
sdk Paxos
consul 1.简单易用,不需要集成sdk
2.自带健康检查
3.支持多数据中心
4.提供web管理界面
1.不能实时获取服务信息的变化通知 http/dns Raft
etcd 1.简单易用,不需要集成sdk
2.可配置性强
1.没有健康检查
2.需配合第三方工具一起完成服务发现
3.不支持多数据中心
http Raft

原文地址:https://www.cnblogs.com/yizhou35/p/12164160.html

时间: 2024-11-09 10:04:07

服务发现框架选型的相关文章

服务发现框架选型,Consul还是Zookeeper还是etcd

本文并不介绍服务发现的基本原理.除了一致性算法之外,其他并没有太多高深的算法,网上的资料很容易让大家明白上面是服务发现. 想直接查看结论的同学,请直接跳到文末. 目前,市面上有非常多的服务发现工具,<Open-Source Service Discovery>一文中列举了如下开源的服务发现工具.(http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/) 上面表格中,前三个是通用的,后面都是各大公司自己造的轮子

SpringCloud系列四:Eureka 服务发现框架(定义 Eureka 服务端、Eureka 服务信息、Eureka 发现管理、Eureka 安全配置、Eureka-HA(高可用) 机制、Eureka 服务打包部署)

1.概念:Eureka 服务发现框架 2.具体内容 对于服务发现框架可以简单的理解为服务的注册以及使用操作步骤,例如:在 ZooKeeper 组件,这个组件里面已经明确的描述了一个服务的注册以及发现操作流程,在整个 Rest 架构里面,会存在有大量的微服务的信息. 在 SpringCloud 之中使用了大量的 Netflix 的开源项目,而其中 Eureka 就属于 Netflix 提供的发现服务组件,所有的微服务在使用之中全部向 Eureka 之中进行注册,而后客户端直接利用 Eureka 进

Eureka(服务发现框架)

什么是服务发现,不了解的可以自行百度或googleEureka是netfix开发的一个框架,定位于中间层,用于保障负载均衡和中间层的故障转移,它是基于RESET开发的服务框架基本组件:Eureka Server 和Eureka Client简单框架如下图:Eureka Server:主要提供存放注册的信息,它也提供了web界面可以查看有哪些服务,他的可用性通过复制来实现,可以通过keeplived来实现高可用Eureka Client:是一个Java客户端,放在各个服务中,用于跟server端进

微服务化之服务拆分与服务发现

本文章为<互联网高并发微服务化架构实践>系列课程的第六篇 前五篇为: 微服务化的基石--持续集成 微服务的接入层设计与动静资源隔离 微服务化的数据库设计与读写分离 微服务化之无状态化与容器化 微服务化之缓存的设计 一.服务拆分的前提 说到微服务,服务拆分是绕不过去的话题,但是微服务不是说拆就能拆的,有很多的前提条件,需要完成前面几节所论述的部分. 首先要有一个持续集成的平台,使得服务在拆分的过程中,功能的一致性,这种一致性不能通过人的经验来,而需要经过大量的回归测试集,并且持续的拆分,持续的演

微服务:实现服务发现与服务注册

一.服务发现的方式: 1.客户端发现:Eureka.ZooKeeper(存在缺陷)原因:http://blog.csdn.net/whereismatrix/article/details/53305045 2.服务端发现:consul+nginx 描述:Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的.SpringCloud将它集成在其子项目spring-cloud-netflix中

服务发现的基础概念

服务发现与服务发现组件的基本原理 什么是服务发现 在传统的系统部署中,服务运行在一个固定的已知的 IP 和端口上,如果一个服务需要调用另外一个服务,可以通过地址直接调用,但是,在虚拟化或容器话的环境中,服务实例的启动和销毁是很频繁的,服务地址在动态的变化,如果需要将请求发送到动态变化的服务实例上,至少需要两个步骤: 服务注册 - 存储服务的主机和端口信息 服务发现 - 允许其他用户发现服务注册阶段存储的信息 服务发现的主要优点是可以无需了解架构的部署拓扑环境,只通过服务的名字就能够使用服务,提供

atitit.RESTful服务的概览and框架选型

1. REST基础概念: 1 2. URL说明: 1 3.  1 4. RESTful框架选型 2 1. spring mvc( recomm) 2 2. Jersey 2 5. 参考 3 1.  REST基础概念: · 在REST中的一切都被认为是一种资源. · 每个资源由URI标识. · 使用统一的接口.处理资源使用POST,GET,PUT,DELETE操作类似创建,读取,更新和删除(CRUD)操作. · 无状态.每个请求是一个独立的请求.从客户端到服务器的每个请求都必须包含所有必要的信息,

深入浅出高性能服务发现、配置框架Nacos系列 3: 服务发现:Nacos客户端初始化流程

上一章节,我们从全局了解了一下Nacos项目的模块架构,做到了心中有数,现在,我们去逐步去挖掘里面的代码细节,很多人在学习开源的时候,无从下手,代码那么多,从哪个地方开始看呢?我们可以从一个接口开始入手,这个接口是你使用过的,知道它大概做什么事,有体感的,大家还记得第一章时,我们写的HelloWorld吗,对,就从里面的接口开始剥洋葱. 这个是Nacos的github代码地址,开始之前先start关注一下,加上watch,后续Nacos的邮件列表也会通知到你,可以关注到Nacos的最新实时消息,

深入浅出高性能服务发现、配置框架Nacos系列 2: Nacos项目结构介绍

今天,我们分析一下Nacos工程的包模块结构,都是负责什么功能的,从全局看一下整个工程,从整体到细节,还没下载源码的同学,赶紧动起来!https://github.com/alibaba/nacos,这个是github代码地址,开始之前先start关注一下,加上watch,后续的邮件列表也会通知到你,可以关注到Nacos的最新实时消息,及各大牛之间的精彩讨论. 截止本文发出,代码最新是master分支上0.2.0版本的,新开源版迭代会比较频繁,很可能某个类,或者模块依赖关系,下个版本就不一样了,