(转)微服务注册中心:Consul——服务发现
Posted liujiacai
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了(转)微服务注册中心:Consul——服务发现相关的知识,希望对你有一定的参考价值。
原文:https://xie.infoq.cn/article/4fe6f02b220fb009844861b56
https://www.cnblogs.com/myitnews/p/13655000.html
一 概述
说完了 Consul 的服务注册,那么就该到服务发现了。大家有过 rpc 框架使用经验的,例如 nacos、eureka、dubbo 等,就会了解服务中的角色,也就是生产者和消费者,也可以理解为服务的提供方和服务使用方。服务注册,是服务提供方把自己的信息(ip、端口、方法、参数 &返回值信息)注册到一个中心;服务发现就是服务使用方,从中心获取到可用的服务提供方信息,并像本地方法调用一样调用其方法(远程方法),这也就是 RPC(远程方法调用)的过程。
二 Consul 宏观架构
这里先说一下 consul 的架构,Consul 的宏观架构如下图所示:
其中"DATACENTER1"和 “DATACENTER2”代表两个数据中心(Consul 对多数据中心天然有比较好的支持)。
在每个数据中心内有 Client 和 Server 的混合。通常我们会部署 3~5 台 Server。具体数量由可用性和性能之间取得平衡,因为随着机器的增加,共识的速度会逐渐变慢。不过对 Client 的数量通常没有限制,可以轻松地扩展到数千或数万的量级。
所有在数据中心的代理都会参与一个 Gossip 协议,这意味着有一个 Gossip 池,其中包含了某个数据中心的所有 Agent。这有几个目的:
-
第一,客户端不需要配置 Server 的地址,发现工作是自动完成的。
-
第二,检测代理故障的工作不放在 Server 上,而是分布式的。这使得故障检测的扩展性比原生的心跳方案要强得多。同时,它还为节点提供了故障检测,如果代理无法到达,那么该节点可能已经发生了故障。
-
第三,它被用作消息层,当发生重要事件(如 Leader 选举)时进行通知。
每个数据中心的 Server 都是单一 Raft 对等集的一部分。这意味着它们共同选出一个单一的 Leader,一个被选中的 Server,它有额外的职责。Leader 负责处理所有查询和事务。事务也必须复制到所有参与共识协议的分片。由于这一要求,当 None-Leader Server 收到 RPC 请求时,它会将其转发给集群 Leader。
一般情况下,不同的 Consul 数据中心之间不会复制数据。当对另一个数据中心的资源进行请求时,本地 Consul 服务器会将该资源的 RPC 请求转发给远程 Consul 服务器,并返回结果。如果远程数据中心不可用,那么这些资源也将不可用,但这不会以其他方式影响本地数据中心。
三 Consul 服务发现
3.1 Consul 已注册服务查看
大概了解了 Consul 的架构,接下来回到本篇的主题,我们先搞清楚怎样获取到已注册的服务,来供调用。
如果还不了解服务注册怎样实现,大家先再看一下这篇文章:微服务注册中心:Consul——服务注册,可以直接拉取 gitee 代码到本地,本地启动 Consul 服务后,再启动 springboot-consul 下的 SpringBootConsulApplication,即可完成注册。注意一下 consul 服务端口,默认使用的是 8500。
如果上述操作完成且没有问题,那么我们在浏览器中查看 http://localhost:8500/,可以看到 Consul 下的 Services 信息如下:
会有两个 Service,一个是 consul——这个是 Consul 服务启动后就有的,自带的 service; 下面的 first-consul-client 就是我们启动并注册的服务。
3.2 建立消费者工程
3.2.1 创建工程
创建一个名为 springboot-consul-consumer 的 maven 工程。
3.2.2 依赖配置
主要是 spring-cloud,spring boot,以及 spring-cloud-starter-consul-discovery,用于做 consul 的服务发现。pom.xml 内容如下:
3.2.3 application 属性配置
这里尝试使用 application.yml,zipkin 不是必须,所以暂时注释掉:
3.2.4 核心代码
1)必不可少的启动文件 ConsulConsumerApplication:
2)访问服务方法
至此,工程建立完毕。可见,核心逻辑还是在引入的依赖包 spring-cloud-starter-consul-discovery 中。consul 服务配置在了 application.yml 中的 consul 属性,controller 中通过设置的 serviceId 来定位我们要使用的服务。
3.3 启动验证
启动 ConsulConsumerApplication,完成后,通过/services 来验证是否能够获取到服务列表,浏览器中输入: http://localhost:8521/services,返回信息为:
可见确实得到了预期的结果。
再次查看 Consul 的 ui 页面(http://localhost:8500/ui/dc1/services):
标红的就是我们刚刚启动的消费者,也注册到了 Consul 的 services 列表中。
上述代码已提交至 gitee: https://gitee.com/flamingskyline/spring-boot-integration,可自行拉取并做调整。
四 小结
至此,我们从本地安装启动 Consul,到服务注册和发现,可以简单的使用起来了,但还是非常简单的应用,并未深入到原理和架构,后面的文章中,将会对其原理进行分析,敬请期待。
微服务注册中心Consul转Nacos实践
参考技术A 先说下为什么要从Consul 换到Nacos?当然最主要的原因是需要使用Nacos的配置和管理微服务的能力,配置中心之前用过携程开源的Apollo,个人感觉环境搭建起来比较复杂。
下面开始:
具体可以看下 https://nacos.io/zh-cn/docs/quick-start.html 这个是Nacos的官方文档网址,里面有Nacos功能的详细介绍和集成教程。
3.修改项目原来的配置文件 ,将原来的application.yml 改成 bootstrap.yml配置内容大致如下
common.yaml 内容如下
到这里改造就基本完成了,如有问题可以在评论区讨论。
以上是关于(转)微服务注册中心:Consul——服务发现的主要内容,如果未能解决你的问题,请参考以下文章
.Net Core with 微服务 - Consul 注册中心