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 ，篇幅较长，这里不做展开。

结束语

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