Consul初探-在深交之前先认识

Consul 是什么？

Consul 官方站点：https://www.consul.io/

首先，官方介绍是：Consul 是一种服务网格的解决方案，在 Consul 中，提供了服务发现、配置、分段等控制管理平台，Consul 中的每项功能都可以单独使用，也可以一起使用来构建完整的服务网格；在 Consul 内部，有一个简单的代理服务，所以在安装 Consul 后，马上就可以开始使用 Consul ；当然，Consul 也支持集成第三方代理，比如 Envoy。

以上，是官方的介绍，我第一次看的时候也是非常的懵逼，因为这里面涉及了太多的专业词汇，下面就说说自己的理解。

Consul 是一个服务组件，在用户下载 Consul 的安装包后，可以立即运行它，或者通过其它托管程序运行它，Consul 只有一个程序包，无需另行安装；当运行 Consul 的时候，需要为其指定一些必须的参数，以供 Consul 在运行时使用；
比如参数 -data-dir 表示指定 Consul 存放数据的目录。

服务注册

Consul 内部侦听 8500 端口，提供给 Consul 的客户端注册服务，比如张三开发了一个购物车程序，该购物车程序包含了“加入购物车”、“清空购物车” 两个接口，张三在开发购物车程序的时候，使用了 Consul 的客户端包组件，在程序运行起来以后，购物车程序就自动的连接到 Consul 的 8500 端口，注册了一个服务，该服务被命名为“购物车程序”，此时，Consul 并不知道 “购物车程序”有多少个接口，Consul 只知道 “购物车程序”的服务地址、端口。

服务发现

在“购物车程序”注册到 Consul 后，Consul 也仅仅知道有这么一个服务注册进来了，并且还配置了健康检查， Consul 会定时的去连接 “购物车程序”，确保其还处于可提供服务的状态，任何人（程序）都可以通过 Consul 的外部地址访问 Consul 内部的已注册的服务列表，从而获得真实的服务地址，然后调用该真实地址，获得结果。

集群

Consul 是一个分布式的解决方案，可以部署多个 Consul 实例，确保数据中心的持续稳定，在 Consul 集群中，内部采用投票的方式选举出 leader，然后才开始运行整个集群，只有正确选举出 leader 后，集群才开始工作，当一个服务注册到 Consul 后，集群将该服务进行同步，确保 Consul 集群内的每个节点都存储了该服务的信息；然后，Consul 集群将对该服务进行健康检查和投票，超过半数通过，即认为该服务为正常（或者异常）；一旦被投票认定为异常的服务，该服务将不会被外部发现（不可访问），在此过程中，Consul 将持续的对该异常的服务进行检查，一旦服务恢复，Consul 即刻将其加入正常服务。

服务器和客户端

Consul 支持两种运行的方式，即 server 和 client 模式，当一个 Consul 节点以 server 模式运行的时候，就表示该 Consul 节点会存储服务和配置等相关信息，并且参与到健康检查、leader 选举等服务器事务中，与之相反的是，client 模式不会存储服务信息。

数据中心

每个 Consul 节点都需要加入一个命名的数据中心（DataCenter），一个节点上，可以运行多个数据中心，数据中心的作用在于应用隔离，相当于服务分组

键值存储

在 Consul 内部，提供了简单的数据存储，也就是 key/value 系统，kv 系统非常强大，它的作用包括允许节点动态修改配置、执行 leader 选举、服务发现、集成健康检查、或者其它你想要存储到 Consul 中的内容

Consul 的架构

好了，现在可以来看一下官方的这张架构图了

上图有两个数据中心，这两个数据中心内部的数据是不会同步的，他们是独立运行的，包括其内部的健康检查、leader 选举等等都是独立的，结合上面的介绍，应该可以很容易的读懂这张图。

Consul 能做什么？

通过上面的介绍，我们了解到了 Consul 其实就是一个分布式的服务管理平台，Consul 本身不具备网关的能力，所以，在一般的业务系统中，如果要应用 Consul ，通常的做法是在 Consul 的 server 节点上安装一个 nginx，在 Consul 的服务注册完成后，生成 nginx 的配置文件并重新加载它；此时，Consul 看上去好像是通过 nginx 具有了网关的能力，实际上，他们直接毫无关系；Consul 生成的 nginx 配置文件和我们手写的 nginx 配置文件没有太多的不同，都是一样的，其实就是把手写 nginx 这种体力活给自动化了。

如果不想这么麻烦的话怎么办呢？这就引入了服务网关的概念，以 .NETCore 为例子，目前比较火热的就是 ocelot+consul 的搭配，通过在服务中嵌入 ocelot 和 consul 的客户端，自动的完成服务注册到（Consul）和服务发现（ocelot读取Consul中的服务）；当用户访问某个 url 的时候，ocelot 将会根据路由将用户请求转发到从 Consul 拉取到的真正的服务中；对于 ocelot ，篇幅较长，这里不作展开。

结束语

开篇纯理论了，下一篇再上点实战的干活，就当学习记录吧