初识Consul

最新推荐文章于 2021-08-30 12:06:14 发布

西瓜游侠

最新推荐文章于 2021-08-30 12:06:14 发布

阅读量275

点赞数

分类专栏：微服务合集

本文链接：https://blog.csdn.net/hbtj_1216/article/details/104148342

版权

微服务合集专栏收录该内容

43 篇文章 5 订阅

订阅专栏

参考：
http://blog.didispace.com/consul-service-discovery-exp/
https://www.fangzhipeng.com/springcloud/2019/02/14/sc-consul-g.html

1 Consul是什么

Consul是基于GO语言开发的开源工具，主要面向分布式系统提供服务注册/发现和配置管理的功能等。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网格。Consul不仅具有服务治理的功能，而且使用分布式一致协议RAFT算法实现，有多数据中心的高可用方案，并且很容易和Spring Cloud等微服务框架集成，使用起来非常的简单，具有简单、易用、可插排等特点。使用简而言之，Consul提供了一种完整的服务网格解决方案。

Consul的功能都很实用，其中包括：

服务注册/发现：可以通过consul的客户端向consul的服务端注册应用服务信息，其他应用服务可以通过consul的客户端来发现服务的提供者。consul提供了DNS和HTTP API来注册/发现服务。
运行时健康检查：consul客户端可以提供任意数量的运行状况检查机制，这些检查机制可以是给定服务或本地节点相关联。这些信息可以用来监控群集的运行状况，服务发现组件可以使用这些监控信息来路由流量，可以使流量远离不健康的服务。
Key/Value存储：应用程序可以将consulc的键/值存储用于任何需求，包括动态配置，功能标记，协调，领导者选举等。它采用HTTP API`使其易于使用。
安全服务通信：consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。
多数据中心：consul支持多个数据中心。这意味着consul的用户不必担心构建额外的抽象层以扩展到多个区域。
分布式一致性保证：consul使用分布式一致协议RAFT算法来保证多个节点数据的一致性。

Consul本身只是一个二进制的可执行文件，所以安装和部署都非常简单，只需要从官网下载后，在执行对应的启动脚本即可。

2 Consul工作原理

引用官网的一张图：
在这里插入图片描述
工作原理：

每个Consul实例都通过agent启动。agent是一个守护进程，可以指定client或server模式，支持DNS或HTTP API接口，并负责运行时检查和保持服务同步。
Consul支持多数据中心。在上图中有两个DataCenter，他们通过网络互连，同时请注意为了提高通信效率，只有Server节点才加入跨数据中心的通信。
在单个数据中心中，Consul分为Server和Client两种节点（所有的节点也被称为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端口完成。

3 Consul服务注册/发现的原理

Consul可用于分布式系统中的服务注册/发现。
图片来源：http://blog.didispace.com/consul-service-discovery-exp/
在这里插入图片描述
服务注册/发现原理：

首先在Server1、Server2、Server3三个服务器上面分别部署了一个Consul Server，组成一个Consul集群。这个集群中有leader，也有follower，假设他们选举了Server2上的Consul Server节点为leader。这些服务器上最好只部署Consul程序，以尽量维护Consul Server的稳定。
然后在服务器Server4和Server5上通过Consul Client分别注册Service A、Service B、Service C，这里每个Service分别部署在了两个服务器上，这样可以避免Service的单点问题。服务注册到Consul可以通过HTTP API（8500端口）的方式，也可以通过Consul配置文件的方式。Consul Client可以认为是无状态的，它将注册信息通过RPC转发到Consul Server，注册过的服务信息真实的保存在Consul Server的各个节点中，并且通过Raft算法实现了强一致性。
最后在服务器Server6中有一个Service D服务，需要访问Service B。这时候Service D首先会访问本机Consul Client提供的HTTP API，本机的Consul Client会将请求转发到Consul Server（由集群中的leader来处理请求），Consul Server查询到Service B当前的服务信息并返回，最终Service D拿到了Service B的所有部署的IP和端口，然后就可以从中选择Service B的其中一个部署实例并向其发起请求了。
如果服务发现采用的是DNS方式，则Service D中直接使用Service B的服务发现域名，域名解析请求首先到达本机DNS代理，然后转发到本机Consul Client，本机Consul Client会将请求转发到Consul Server，Consul Server查询到Service B当前的信息返回，最终Service D拿到了Service B的某个部署的IP和端口。