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

背景

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

多数据中心

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

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

1. Cosnul 分为 Server 和 Client，多数据中心的实现主要依靠两个数据中心的 Server 进行通讯，而且每一个数据中心有各自的主节点，也就是各自选举。
2. Client 与 Server 之间经过8300端口，TCP协议进行RPC交互。
3. 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 时，具体的调用顺序时怎样的：

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

1. 每台机器上都须要部署 Consul Client
2. 服务请求链路成倍增长了

问题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种通知方式：

1. script：当发生变化时执行一段脚本（能够是放在服务器中的任何可执行脚本，例如 py sh 等）
2. 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/
http://www.javashuo.com/article/p-fhmgwuqp-cs.html
https://blog.csdn.net/iamonlyme/category_9266562.html