服务发现与consul

引言

　　为什么要学习consul服务发现? 因为一套微服务架构中有很多个服务需要管理，也就是说会有很多对grpc。 如果一一对应的进行管理会很繁琐所以我们需要有一个管理发现的机制。

 

Consul的介绍

　　Consul是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与服务注册配置功能。 Consul是分布式的、高可用 的、可横向扩展的。

　　它具备以下特性 :

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

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

　　　　3. key/value storage：支持key-value存储。提供简单的HTTP接口，可以在任何地方操作。

　　　　4. multi-datacente：无需复杂的配置，即可支持多数据中心。

 

 

什么是服务发现

　　微服务的框架体系中，服务发现是不能不提的一个模块。我相信了解或者熟悉微服务的童鞋应该都知道它的重要性。我们看下面的一幅图片:

 

 

图中，客户端的一个接口，需要调用服务A-N。客户端必须要知道所有服务的网络位置的，以往的做法是配置是配 置文件中，或者有些配置在数据库中。这里就带出几个问题:

　　需要配置N个服务的网络位置，加大配置的复杂性 服务的网络位置变化，都需要改变每个调用者的配置 集群的情况下，难以做负载(反向代理的方式除外)

　　总结起来一句话:服务多了，配置很麻烦，问题多多 既然有这些问题，那么服务发现就是解决这些问题的。话说，怎么解决呢?我们再看一张图:

 

 

与之前一张不同的是，加了个服务发现模块。图比较简单，这边文字描述下。服务A-N把当前自己的网络位置注册 到服务发现模块(这里注册的意思就是告诉)，服务发现就以K-V的方式记录下，K一般是服务名，V就是 IP:PORT。服务发现模块定时的轮询查看这些服务能不能访问的了(这就是健康检查)。客户端在调用服务A-N的 时候，就跑去服务发现模块问下它们的网络位置，然后再调用它们的服务。这样的方式是不是就可以解决上面的问 题了呢?客户端完全不需要记录这些服务网络位置，客户端和服务端完全解耦。

 

下面的例子有助于我们理解服务发现的形式:

　　例如邮递员去某公司一栋大楼投递快件，向门卫询问员工甲在哪一个房间，门卫拿起桌上的通讯录查询，告知邮递员员工甲在具体什么位置。假如公司来了一个员工乙，他想让邮递员送过来，就要先让门卫知道自己在哪一个房
间，需要去门卫那边登记，员工乙登记后，当邮递员向门卫询问时，门卫就可以告诉邮递员员工乙的具体位置。门卫知道员工乙的具体位置的过程就是服务发现，员工乙的位置信息可以被看作服务信息，门卫的通讯录就是上文中
提到的数据交换格式，此例中员工乙就是上文的已方，门卫就是服务发现的提供者。

 

 

其他的注册中心解决方案及对比

　　现在注册中心的解决方案很多，比如zookeeper，etcd等等，相关技术的特性见如下：

项目	特点	CAP支持	通信协议	一致性算法	开发语言
CoreOS Etcd	分布式key/value存储系统，服务发现功能需要第三方支持	AP/CP	http/grpc	raft	golang
Apache ZooKeeper	功能强大，技术成熟，但是比较重	CP	sdk	zab	java
HashiCorp Consul	支持多数据中心，内嵌实现了服务发现功能	CP	http	raft	golang

 

  consul 架构

　　官方给出的架构图：

　　

 

 

  Consul的服务发现

　　consul 支持两种服务发现的方式：

1. 通过 HTTP API 方式，这种方式需要额外编程，适用于不安装 consul agent 的情况，文档地址。
2. 通过 consul agent 配置的方式，agent 启动的时候会读取一个配置文件目录，通过配置进行服务的发现，文档地址。

 Consul和Gossip协议

　　Consul使用gossip协议去管理和广播消费给集群中的成员。gossip协议是一种去中心化的利用随机的方式在节点之间进行信息交换的协议。

　　1. Consul提供两个不同的gossip池，LAN和WAN。单个数据中心的所有Client和Server作为LAN pool的成员。LAN pool被用于服务发现，提供可靠和快速的事件广播。

　　2. WAN被用于数据中心间的服务发现，每个数据中心的所有的server是WAN pool的成员。

 Consul 对比etcd

　　Consul 是一个端到端的服务发现框架，用于提供健康检查、故障检测和 DNS 服务 从巳tcd 的角度来看， Consul key-value 存储的性能偏弱， Consul的存储系统尚不能进行很好的扩展， 当系统中有上百万的 key 时，内存消耗和时延就会变得很高 一些重要的特性 会缺失， 比如 ，多版本控 、条件事务和可靠的流 watch 等， 而这些特性在分 布式系统里都是非常重要的 etcd Consul 可用于解决不同的问题 如果是为了分布式系统的一致性 key-value 存储的话，那么 etcd 将会是更好的选择 如果是端到端的集群服务发现，那么 etcd 就没有足够的特性， Consul 会是更好的选择。

　　

 

 Consul ACL访问权限控制

　　Consul通过ACLS 来确保安全的访问 UI, API, CLI, servie 通信，Agent通信。

　　使用场景：

　　　　1. Agent的访问控制。

　　　　2. Service服务注册/发现访问控制。

　　　　3. Key/Value访问控制。

      官网也有ACL方面的说明，文档地址：https://learn.hashicorp.com/tutorials/consul/access-control-setup-production?utm_source=consul.io&utm_medium=docs

　　

 

 

Consul的安装
　　Consul用Golang实现，因此具有天然可移植性 (支持 Linux、windows和macOS)。安装包仅包含一个可执行文件。 Consul安装非常简单，只需要下载对应系统的软件包并解压后就可使用。

　　可以去Consul官网下载 https://www.consul.io/downloads.html
　　

　　 

 　　我说Mac系统直接安装，使用命令：brew install consul

　　

 

 　　安装好之后查看版本，如下说明安装好了

　　

 

 Consul的使用

 　　1. 启动Consul，使用命令：consul agent -dev

　　　　

 

 　　　　然后在浏览器中输入http://localhost:8500，就可以看到Consul Web界面。