微服务注册中心Consul服务发现
系列文章：
微服务架构：网关概念与zuul
微服务网关：SpringCloudGateway——Zuul
微服务网关：SpringCloudConfig-配置中心
微服务网关方案：KongNacos
Nacos实践
微服务网关：Nacos源码实践（二）
微服务注册中心：Consul——概念与基础操作
微服务注册中心：Consul——服务注册
一概述说完了Consul的服务注册，那么就该到服务发现了。大家有过rpc框架使用经验的，例如nacos、euka、dubbo等，就会了解服务中的角色，也就是生产者和消费者，也可以理解为服务的提供方和服务使用方。服务注册，是服务提供方把自己的信息（ip、端口、方法、参数返回值信息）注册到一个中心；服务发现就是服务使用方，从中心获取到可用的服务提供方信息，并像本地方法调用一样调用其方法（远程方法），这也就是RPC（远程方法调用）的过程。
二Consul宏观架构这里先说一下consul的架构，Consul的宏观架构如下图所示：
其中"DATACENTER"和“DATACENTER”代表两个数据中心（Consul对多数据中心天然有比较好的支持）。
在每个数据中心内有Client和Server的混合。通常我们会部署~5台Server。具体数量由可用性和性能之间取得平衡，因为随着机器的增加，共识的速度会逐渐变慢。不过对Client的数量通常没有限制，可以轻松地扩展到数千或数万的量级。
所有在数据中心的代理都会参与一个Gossip协议，这意味着有一个Gossip池，其中包含了某个数据中心的所有Agent。这有几个目的：
第一，客户端不需要配置Server的地址，发现工作是自动完成的。
第二，检测代理故障的工作不放在Server上，而是分布式的。这使得故障检测的扩展性比原生的心跳方案要强得多。同时，它还为节点提供了故障检测，如果代理无法到达，那么该节点可能已经发生了故障。
第三，它被用作消息层，当发生重要事件（如Leader选举）时进行通知。
每个数据中心的Server都是单一Raft对等集的一部分。这意味着它们共同选出一个单一的Leader，一个被选中的Server，它有额外的职责。Leader负责处理所有查询和事务。事务也必须复制到所有参与共识协议的分片。由于这一要求，当None-LeaderServer收到RPC请求时，它会将其转发给集群Leader。
一般情况下，不同的Consul数据中心之间不会复制数据。当对另一个数据中心的资源进行请求时，本地Consul服务器会将该资源的RPC请求转发给远程Consul服务器，并返回结果。如果远程数据中心不可用，那么这些资源也将不可用，但这不会以其他方式影响本地数据中心。
三Consul服务发现.Consul已注册服务查看大概了解了Consul的架构，接下来回到本篇的主题，我们先搞清楚怎样获取到已注册的服务，来供调用。
如果还不了解服务注册怎样实现，大家先再看一下这篇文章：微服务注册中心：Consul——服务注册，可以直接拉取gitee代码到本地，本地启动Consul服务后，再启动springboot-consul下的SpringBootConsulApplication，即可完成注册。注意一下consul服务端口，默认使用的是。
如果上述操作完成且没有问题，那么我们在浏览器中查看
转载请注明：http://www.sonphie.com/jbby/14548.html
