ASP.NET CORE 使用Consul实现服务治理与健康检查(1)—

背景

笔者所在的公司正在进行微服务改造，这其中服务治理组件是必不可少的组件之一，在一番讨论之后，最终决定放弃 Zookeeper 而采用 Consul 作为服务治理框架基础组件。主要原因是 Consul 自带健康检查，通过该功能可以比较方便的监控应用的运行状态，从而更好的运维整个系统。但在实际实施过程中笔者发现，目前网络上所能看到的很多资料，没有比较清晰的解释 Consul 的运行方式，特别是当用户对于 Zookeeper 主动通知的方式比较熟悉之后，对于 Consul 这种每次都通过 HTTP 调用获取服务信息的方式还是存在很多疑惑的，比如：这样的方式在调用链中，不是会导致 HTTP 调用链增加一倍吗？

多数据中心

关于Consul，首先介绍最常见的一副图：

该图表示 Consul 支持的一个重要的功能———多数据中心，这也是很多服务注册发现工具所不具备的，通过上述图中我们可以解读出如下一些信息：

Cosnul 分为 Server 和 Client，多数据中心的实现主要依靠两个数据中心的 Server 进行通信，并且每个数据中心有各自的主节点，也就是各自选举。
Client 与 Server 之间通过8300端口，TCP协议进行RPC交互。
Client 与其他实例之间通过 8301 以 TCP/UDP 协议进行 LAN GOSSIP 交互

上图解释了 Consul 集群各个 Server 之间的关系，那么 Server 和 Client 之间的关系又是怎样呢？在理解这个问题之前，要先理解一个概念——反熵。

反熵

1. 概念

如果用一句话来概括那大概就是：分而治之，Server 将服务的管辖权（健康检查，服务注册等功能）层层下放给 Client，而 Client 在需要时（例如健康检查失败，新的服务注册等）将所管辖范围内的服务信息进行转发或上报。

关于反熵更加详细的内容，可以参考园子里波斯码所写的文章——Consul的反熵，此文对于反熵的解释非常到位, 感兴趣的同学可以进一步阅读。

这个特点也决定了 Consul 服务的注册和健康检查方式：所有操作都是通过 Consul Client 来实现的。如下图所示：

根据上图所示有个重要的概念：

1. 如果我们通过 Client 获取 Agent 上的服务时，则只能返回当前这个 Consul Client 中所注册的所有服务

2. 而如果我们通过 Client 获取 Catalog 上的服务时，则可以获取到所有注册服务。

事实上即使我们需要获取 Catalog 中的信息时，也不是直接与 Consul Server 交互，而是通过当前服务器 Consul Client 转发请求获取。同时取决于反熵概念，如果我们把每台服务器看作管理辖区的最小单位，那么则需要在每台机器上部署 Consul Client，用它来管理这台服器上所有的服务。

2. 问题

如果按照上述信息实施部署，那么我们来看下假如 APP1 调用 APP2 时，具体的调用顺序时怎样的：

如上图所示，这样的部署其实会带来一些问题：

每台机器上都需要部署 Consul Client

服务请求链路成倍增加了

问题1： 部署成本增加，实际上是一次性工作，况且假如你是容器化部署的话，那这个问题基本可以忽略。

问题2： 调用链路增加的确会带来很多问题，主要是在调用 APP2 之前增加了 ① ② 两步，其中步骤 ① 为本机 HTTP 调用，步骤 ② 为 Consul集群内部的 RPC 调用，经过笔者实际测试这个调用耗时在毫秒级，除非对于性能要求很高的情况下，普通的调用链路请求是可以容忍的，而笔者所在公司的方案目前也是基于此方案。如果不能容忍，那只能牺牲部分一致性，在本地进行缓存，并设定合理的同步周期。

上述问题笔者认为是 Consul 反熵机制所带来的缺陷：只有通过主动请求 Consul Server 才能获取所有服务的信息，而又缺少比较好的通知机制，导致应用程序无法缓存服务信息。 而相比较于 Zookeeper，由于有了更好的通知机制，使各个应用程序可以缓存服务列表信息，只有当收到通知时，才主动更新服务信息。同时 zookeeper 是长连接，当服务在出现问题时可以更加及时获取到变化，而Consul 必须要依赖健康检查，而健康检查是有周期性的。当然凡事都各有利弊，但我们要知晓个中优缺点，才能更加合理使用。

通知机制——Consul Watch

Consul 可以通过配置 Agent 对以下类型的数据进行监控，并且同样受反熵机制的影响，如果想监控集群下所有服务，那么需要将监控配置放在服务端：

key – 监视指定K/V键值对
keyprefix – Watch a prefix in the KV store
services – 监视服务列表
nodes – 监控节点列表
service – 监视服务实例
checks- 监视健康检查的值
event – 监视用户事件

Consul 主要提供2种通知方式：

script：当发生变化时执行一段脚本（可以是放在服务器中的任何可执行脚本，例如 py sh 等）
HTTP endpoint：当发生变化时请求配置的http地址

例如在 Consul 配置文件创建 watch.json ，重启 Consul 后生效

vi /data/consul/config/watch.json

{

  "watches": [

    {

      "type": "services",

      "handler_type": "http",

      "http_handler_config": {

        "path": "http://192.168.1.1:8080/services",

        "method": "POST"

      }

    },

    {

      "type": "nodes",

      "handler_type": "http",

      "http_handler_config": {

        "path": "http://192.168.1.1:8080/nodes",

        "method": "POST"

      }

    },

    {

      "type": "checks",

      "handler_type": "http",

      "http_handler_config": {

        "path": "http://192.168.1.1:8080/checks",

        "method": "POST"

      }

    }

  ]

}

结语

相信有了这些概念的初步理解，可以在初次接触 Consul 时减少一些疑惑。笔者在这个过程中，从博客园一些同学的文章中收益匪浅，特别是波斯玛同学的3篇文章，值得详细阅读，这里也推荐大家一并学习。

参考资料：

https://www.cnblogs.com/bossma/tag/Consul/

https://www.cnblogs.com/sunsky303/p/9209024.html

https://blog.csdn.net/iamonlyme/category_9266562.html