（二十五）java版spring cloud+spring boot 社交电子商务平台-服务发现consul

电子商务平台源码请加企鹅求求：一零三八七七四六二六。 Consul是分布式的、高可用、横向扩展的。

consul提供的一些关键特性：

service discovery：consul经过DNS或者HTTP接口使服务注册和服务发现变的很容易，一些外部服务，例如saas提供的也能够同样注册。

health checking：健康检测使consul能够快速的告警在集群中的操做。和服务发现的集成，能够防止服务转发到故障的服务上面。

key/value storage：一个用来存储动态配置的系统。提供简单的HTTP接口，能够在任何地方操做。

multi-datacenter：无需复杂的配置，便可支持任意数量的区域。

Consul使用Go语言编写，所以具备自然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与Docker等轻量级容器可无缝配合 。

Consul内部原理

下面这张图来源于Consul官网，很好的解释了Consul的工做原理，先大体看一下。

首先Consul支持多数据中心，在上图中有两个DataCenter，他们经过Internet互联，同时请注意为了提升通讯效率，只有Server节点才加入跨数据中心的通讯。

在单个数据中心中，Consul分为Client和Server两种节点（全部的节点也被称为Agent），Server节点保存数据，Client负责健康检查及转发数据请求到Server；Server节点有一个Leader和多个Follower，Leader节点会将数据同步到Follower，Server的数量推荐是3个或者5个，在Leader挂掉的时候会启动选举机制产生一个新的Leader。

集群内的Consul节点经过gossip协议（流言协议）维护成员关系，也就是说某个节点了解集群内如今还有哪些节点，这些节点是Client仍是Server。单个数据中心的流言协议同时使用TCP和UDP通讯，而且都使用8301端口。跨数据中心的流言协议也同时使用TCP和UDP通讯，端口使用8302。

集群内数据的读写请求既能够直接发到Server，也能够经过Client使用RPC转发到Server，请求最终会到达Leader节点，在容许数据轻微陈旧的状况下，读请求也能够在普通的Server节点完成，集群内数据的读写和复制都是经过TCP的8300端口完成。

如今咱们只看DataCenter，能够看出Consul的集群是由N个SERVER，加上M个CLIENT组成的。而不论是SERVER仍是CLIENT，都是consul的一个节点，全部的服务均可以注册到这些节点上，正是经过这些节点实现服务注册信息的共享。除了这两个，在看下面的一些小细节。

CLIENT

CLIENT表示Consul的client模式，就是客户端模式。是Consul节点的一种模式，这种模式下，全部注册到当前节点的服务会被转发到SERVER，自己是不持久化这些信息。

SERVER

SERVER表示Consul的server模式，代表这个Consul是个server，这种模式下，功能和CLIENT都同样，惟一不一样的是，它会把全部的信息持久化的本地，这样遇到故障，信息是能够被保留的。

SERVER-LEADER

中间那个SERVER下面有LEADER的字眼，代表这个SERVER是它们的老大，它和其它SERVER不同的一点是，它须要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。

其它信息

其它信息包括它们之间的通讯方式，还有一些协议信息，算法。它们是用于保证节点之间的数据同步，实时性要求等等一系列集群问题的解决。这些有兴趣的本身看看官方文档。

Consul服务发现原理

下面这张图基本描述了服务发现的完整流程，先大体看一下。

首先须要有一个正常的Consul集群，有Server，有Leader。这里在服务器Server一、Server二、Server3上分别部署了Consul Server，假设他们选举了Server2上的Consul Server节点为Leader。这些服务器上最好只部署Consul程序，以尽可能维护Consul Server的稳定。

而后在服务器Server4和Server5上经过Consul Client分别注册Service A、B、C，这里每一个Service分别部署在了两个服务器上，这样能够避免Service的单点问题。服务注册到Consul能够经过HTTP API（8500端口）的方式，也能够经过Consul配置文件的方式。Consul Client能够认为是无状态的，它将注册信息经过RPC转发到Consul Server，服务信息保存在Server的各个节点中，而且经过Raft实现了强一致性。

最后在服务器Server6中Program D须要访问Service B，这时候Program D首先访问本机Consul Client提供的HTTP API，本机Client会将请求转发到Consul Server，Consul Server查询到Service B当前的信息返回，最终Program D拿到了Service B的全部部署的IP和端口，而后就能够选择Service B的其中一个部署并向其发起请求了。若是服务发现采用的是DNS方式，则Program D中直接使用Service B的服务发现域名，域名解析请求首先到达本机DNS代理，而后转发到本机Consul Client，本机Client会将请求转发到Consul Server，Consul Server查询到Service B当前的信息返回，最终Program D拿到了Service B的某个部署的IP和端口。

图中描述的部署架构笔者认为是最普适最简单的方案，从某些默认配置或设计上看也是官方但愿使用者采用的方案，好比8500端口默认监听127.0.0.1，固然有些同窗不赞同，后边会提到其余方案。