最大的区别是Eureka保证AP, Consul为CP。
Consul强一致性(C)带来的是:
- 服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
- Leader挂掉时,重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性:
- 服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功
- 当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性。
其他方面,eureka就是个servlet程序,跑在servlet容器中; Consul则是go编写而成。
这里就平时经常用到的服务发现的产品进行下特性的对比,首先看下结论:
Feature | Consul | zookeeper | etcd | euerka |
---|---|---|---|---|
服务健康检查 | 服务状态,内存,硬盘等 | (弱)长连接,keepalive | 连接心跳 | 可配支持 |
多数据中心 | 支持 | — | — | — |
kv存储服务 | 支持 | 支持 | 支持 | — |
一致性 | raft | paxos | raft | — |
cap | cp | cp | cp | ap |
使用接口(多语言能力) | 支持http和dns | 客户端 | http/grpc | http(sidecar) |
watch支持 | 全量/支持long polling | 支持 | 支持 long polling | 支持 long polling/大部分增量 |
自身监控 | metrics | — | metrics | metrics |
安全 | acl /https | acl | https支持(弱) | — |
spring cloud集成 | 已支持 | 已支持 | 已支持 | 已支持 |
- 服务的健康检查
Euraka 使用时需要显式配置健康检查支持;Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康,而 Consul 相对更为详细点,比如内存是否已使用了90%,文件系统的空间是不是快不足了。
- 多数据中心支持
Consul 通过 WAN 的 Gossip 协议,完成跨数据中心的同步;而且其他的产品则需要额外的开发工作来实现;
- KV 存储服务
除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务,所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务,也能够较好的转化为动态配置服务哦。
- 产品设计中 CAP 理论的取舍
Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适,服务发现场景的可用性优先级较高,一致性并不是特别致命。其次 CA 类型的场景 Consul,也能提供较高的可用性,并能 k-v store 服务保证一致性。 而Zookeeper,Etcd则是CP类型 牺牲可用性,在服务发现场景并没太大优势;
- 多语言能力与对外提供服务的接入协议
Zookeeper的跨语言支持较弱,其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。 Consul除了标准的Rest服务api,还提供了DNS的支持。
- Watch的支持(客户端观察到服务提供者变化)
Zookeeper 支持服务器端推送变化,Eureka 2.0(正在开发中)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知;
- 自身集群的监控
除了 Zookeeper ,其他几款都默认支持 metrics,运维者可以搜集并报警这些度量信息达到监控目的;
- 安全
Consul,Zookeeper 支持ACL,另外 Consul,Etcd 支持安全通道https.
- Spring Cloud的集成
目前都有相对应的 boot starter,提供了集成能力。
总的来看,目前Consul 自身功能,和 spring cloud 对其集成的支持都相对较为完善,而且运维的复杂度较为简单(没有详细列出讨论),Eureka 设计上比较符合场景,但还需持续的完善。
转自:https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/
服务治理
在简单介绍了Spring Cloud和微服务架构之后,下面回归本文的主旨内容,如何使用Spring Cloud来实现服务治理。
由于Spring Cloud为服务治理做了一层抽象接口,所以在Spring Cloud应用中可以支持多种不同的服务治理框架,比如:Netflix Eureka、Consul、Zookeeper。在Spring Cloud服务治理抽象层的作用下,我们可以无缝地切换服务治理实现,并且不影响任何其他的服务注册、服务发现、服务调用等逻辑。
所以,下面我们通过介绍两种服务治理的实现来体会Spring Cloud这一层抽象所带来的好处。
Spring Cloud Eureka
首先,我们来尝试使用Spring Cloud Eureka来实现服务治理。
Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。而Spring Cloud Netflix项目是Spring Cloud的子项目之一,主要内容是对Netflix公司一系列开源产品的包装,它为Spring Boot应用提供了自配置的Netflix OSS整合。通过一些简单的注解,开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括:服务发现(Eureka),断路器(Hystrix),智能路由(Zuul),客户端负载均衡(Ribbon)等。
下面,就来具体看看如何使用Spring Cloud Eureka实现服务治理。
创建“服务注册中心”
创建一个基础的Spring Boot工程,命名为eureka-server
,并在pom.xml
中引入需要的依赖内容:
|
通过@EnableEurekaServer
注解启动一个服务注册中心提供给其他应用进行对话。这一步非常的简单,只需要在一个普通的Spring Boot应用中添加这个注解就能开启此功能,比如下面的例子:
|
在默认设置下,该服务注册中心也会将自己作为客户端来尝试注册它自己,所以我们需要禁用它的客户端注册行为,只需要在application.properties
配置文件中增加如下信息:
|
为了与后续要进行注册的服务区分,这里将服务注册中心的端口通过server.port属性设置为1001。启动工程后,访问:http://localhost:1001/,可以看到下面的页面,其中还没有发现任何服务。
创建“服务提供方”
下面我们创建提供服务的客户端,并向服务注册中心注册自己。本文我们主要介绍服务的注册与发现,所以我们不妨在服务提供方中尝试着提供一个接口来获取当前所有的服务信息。
首先,创建一个基本的Spring Boot应用。命名为eureka-client
,在pom.xml
中,加入如下配置:
|
其次,实现/dc请求处理接口,通过DiscoveryClient对象,在日志中打印出服务实例的相关内容。
|
最后在应用主类中通过加上@EnableDiscoveryClient
注解,该注解能激活Eureka中的DiscoveryClient实现,这样才能实现Controller中对服务信息的输出。
|
我们在完成了服务内容的实现之后,再继续对application.properties
做一些配置工作,具体如下:
|
通过spring.application.name
属性,我们可以指定微服务的名称后续在调用的时候只需要使用该名称就可以进行服务的访问。eureka.client.serviceUrl.defaultZone
属性对应服务注册中心的配置内容,指定服务注册中心的位置。为了在本机上测试区分服务提供方和服务注册中心,使用server.port
属性设置不同的端口。
启动该工程后,再次访问:http://localhost:1001/。可以如下图内容,我们定义的服务被成功注册了。
当然,我们也可以通过直接访问eureka-client
服务提供的/dc
接口来获取当前的服务清单,只需要访问:http://localhost:2001/dc,我们可以得到如下输出返回:
|
其中,方括号中的eureka-client
就是通过Spring Cloud定义的DiscoveryClient
接口在eureka的实现中获取到的所有服务清单。由于Spring Cloud在服务发现这一层做了非常好的抽象,所以,对于上面的程序,我们可以无缝的从eureka的服务治理体系切换到consul的服务治理体系中区。
Spring Cloud Consul
Spring Cloud Consul项目是针对Consul的服务治理实现。Consul是一个分布式高可用的系统,它包含多个组件,但是作为一个整体,在微服务架构中为我们的基础设施提供服务发现和服务配置的工具。它包含了下面几个特性:
- 服务发现
- 健康检查
- Key/Value存储
- 多数据中心
由于Spring Cloud Consul项目的实现,我们可以轻松的将基于Spring Boot的微服务应用注册到Consul上,并通过此实现微服务架构中的服务治理。
以之前实现的基于Eureka的示例(eureka-client)为基础,我们如何将之前实现的服务提供者注册到Consul上呢?方法非常简单,我们只需要在pom.xml
中将eureka的依赖修改为如下依赖:
|
接下来再修改一下application.properites
,将consul需要的配置信息加入即可,比如:(下面配置是默认值)
|
到此为止,我们将eureka-client转换为基于consul服务治理的服务提供者就完成了。前文我们已经有提到过服务发现的接口DiscoveryClient
是Spring Cloud对服务治理做的一层抽象,所以可以屏蔽Eureka和Consul服务治理的实现细节,我们的程序不需要做任何改变,只需要引入不同的服务治理依赖,并配置相关的配置属性就能轻松的将微服务纳入Spring Cloud的各个服务治理框架中。
下面可以尝试让consul的服务提供者运行起来。这里可能读者会问,不需要创建类似eureka-server的服务端吗?由于Consul自身提供了服务端,所以我们不需要像之前实现Eureka的时候创建服务注册中心,直接通过下载consul的服务端程序就可以使用。
我们可以用下面的命令启动consul的开发模式:
|
consul服务端启动完成之后,我们再将之前改造后的consul服务提供者启动起来。consul与eureka一样,都提供了简单的ui界面来查看服务的注册情况:
更多关于Consul的使用指南,读者可查看官方文档:https://www.consul.io/
代码示例
样例工程将沿用之前在码云和GitHub上创建的SpringCloud-Learning项目,重新做了一下整理。通过不同目录来区分Brixton和Dalston的示例。
具体工程说明如下:
- eureka的服务注册中心:eureka-server
- eureka的服务提供方:eureka-client
- consul的服务提供方:consul-client
转自:http://blog.didispace.com/spring-cloud-starter-dalston-1/
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/14240.html