consul--基础--1.1--理论1

consul–基础–1.1–理论1

---

1、什么是Consul?

1. 是微服务的插件，用于实现分布式系统的服务发现与配置。
2. 由Go语言开发
3. 部署容易
4. 特点
   1. 分布式
   2. 高可用
   3. 可横向扩展

2、特点

2.1、服务发现（Service Discovery）

1. 提供了通过DNS或者HTTP接口的方式来注册服务和发现服务。
2. 一些外部的服务通过Consul很容易的找到它所依赖的服务。

2.2、健康检查(Health Checking)

1. Consul的Client可以提供任意数量的健康检查.
   1. 可以与给定的服务相关联(“webserver是否返回200 OK”)
   2. 可以与本地节点相关联(“内存利用率是否低于90%”)。
   3. 操作员可以使用这些信息来监视集群的健康状况，服务发现组件可以使用这些信息将请求从不健康的主机路由出去。

2.3、K/V存储

1. 提供的Key/Value存储。
2. 提供了简单易用的HTTP接口
3. 可以实现如下功能
   1. 动态配置
   2. 功能标记
   3. 领袖选举等等功能。

2.4、安全服务通信

1. 可以为服务生成和分发TLS证书，以建立相互的TLS连接。

   1. 意图用于定义允许哪些服务通信。

2. 服务分割可以很容易地进行管理

   1. 目的是可以实时更改的，而不是使用复杂的网络拓扑和静态防火墙规则。

2.5、多数据中心

1. 支持开箱即用的多数据中心。用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。

3、架构图

3.1、架构图分析

1. 可以看到有两个数据中心，分别标记为"DATACENTER 1"和"DATACENTER 2"

2. Consul支持多个数据中心，在每个数据中心中，我们都有客户机(CLIENT)和服务器(SERVER)。

   1. 服务区端一般为3~5个。这样可以在稳定和性能上达到平衡，因为更多的机器会使数据同步很慢，一致性会很慢。
   2. 客户端是没有限制的，可以有成千上万个。

3. 数据中心到所有节点都使用的时候Gossip协议。这就意味着有一个Gossip池，其中包含给定数据中心所有的节点。

   1. 客户端不需要去配置服务器地址信息，发现服务会自动完成
   2. 检测故障节点的工作不是放在服务器端，而是分布式的。这使得故障检测比单纯的心跳模式更具可伸缩性。
   3. 数据中心被用作消息层，以便在选择leader这种重要的事情发生的时候做通知。

4. 每个数据中心都是都是单个Raft对等设备的一部分。它们一起工作来选举单个leader

5. leader额外的职责

   1. leader负责处理所有查询和事物。
      1. 事物也必须作为同步协议的一部分复制到所有对等体。
      2. 非leader服务器接收到RPC请求时，它会将其转发给集群leader。

6. 服务器端节点作为WANGossip池的一部分运行，WAN池和LAN池不同的是，针对网络高延迟做了优化，而且只包含其他Consul服务器的节点。

   1. 这个池的目的是允许数据中心以最少的消耗方式发现对方。在线启动新的数据中心与加入现有的WAN Gossip一样简单。
      1. 因为这些服务器都在这个池中运行，它还支持跨数据中心请求。
   2. 当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给本地的leader。

7. 数据中心的耦合非常低，由于故障检测，连接缓存和复用，跨数据中心请求相对快速可靠。

4、使用场景

1. 服务发现场景
2. 服务隔离场景
3. 服务配置场景

4.1、服务发现场景

1. consul作为注册中心，服务地址被注册到consul以后，可以使用consul提供的dns、http接口查询
2. consul支持health check。

4.2、服务隔离场景

1. consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台
2. 支持tls证书分发
3. 支持service-to-service加密。

4.3、服务配置场景

1. consul提供key-value数据存储功能，并且能将变动迅速地通知出去。
2. Consul可以实现配置共享，从Consul中读取配置信息。

4.4、运维工具

1. 可以帮助系统管理者了解系统内部的系统架构
2. 可以看成一种监控软件
3. 可以看成一种资产(资源)管理系统。

5、其他同产品对比