consul–基础–1.1–理论1
1、什么是Consul?
- 是微服务的插件,用于实现分布式系统的服务发现与配置。
- 由Go语言开发
- 部署容易
- 特点
- 分布式
- 高可用
- 可横向扩展
2、特点
2.1、服务发现(Service Discovery)
- 提供了通过DNS或者HTTP接口的方式来注册服务和发现服务。
- 一些外部的服务通过Consul很容易的找到它所依赖的服务。
2.2、健康检查(Health Checking)
- Consul的Client可以提供任意数量的健康检查.
- 可以与给定的服务相关联(“webserver是否返回200 OK”)
- 可以与本地节点相关联(“内存利用率是否低于90%”)。
- 操作员可以使用这些信息来监视集群的健康状况,服务发现组件可以使用这些信息将请求从不健康的主机路由出去。
2.3、K/V存储
- 提供的Key/Value存储。
- 提供了简单易用的HTTP接口
- 可以实现如下功能
- 动态配置
- 功能标记
- 领袖选举等等功能。
2.4、安全服务通信
-
可以为服务生成和分发TLS证书,以建立相互的TLS连接。
- 意图用于定义允许哪些服务通信。
-
服务分割可以很容易地进行管理
- 目的是可以实时更改的,而不是使用复杂的网络拓扑和静态防火墙规则。
2.5、多数据中心
- 支持开箱即用的多数据中心。用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。
3、架构图
3.1、架构图分析
-
可以看到有两个数据中心,分别标记为"DATACENTER 1"和"DATACENTER 2"
-
Consul支持多个数据中心,在每个数据中心中,我们都有客户机(CLIENT)和服务器(SERVER)。
- 服务区端一般为3~5个。这样可以在稳定和性能上达到平衡,因为更多的机器会使数据同步很慢,一致性会很慢。
- 客户端是没有限制的,可以有成千上万个。
-
数据中心到所有节点都使用的时候Gossip协议。这就意味着有一个Gossip池,其中包含给定数据中心所有的节点。
- 客户端不需要去配置服务器地址信息,发现服务会自动完成
- 检测故障节点的工作不是放在服务器端,而是分布式的。这使得故障检测比单纯的心跳模式更具可伸缩性。
- 数据中心被用作消息层,以便在选择leader这种重要的事情发生的时候做通知。
-
每个数据中心都是都是单个Raft对等设备的一部分。它们一起工作来选举单个leader
-
leader额外的职责
- leader负责处理所有查询和事物。
- 事物也必须作为同步协议的一部分复制到所有对等体。
- 非leader服务器接收到RPC请求时,它会将其转发给集群leader。
- leader负责处理所有查询和事物。
-
服务器端节点作为WANGossip池的一部分运行,WAN池和LAN池不同的是,针对网络高延迟做了优化,而且只包含其他Consul服务器的节点。
- 这个池的目的是允许数据中心以最少的消耗方式发现对方。在线启动新的数据中心与加入现有的WAN Gossip一样简单。
- 因为这些服务器都在这个池中运行,它还支持跨数据中心请求。
- 当服务器收到对不同数据中心的请求时,它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给本地的leader。
- 这个池的目的是允许数据中心以最少的消耗方式发现对方。在线启动新的数据中心与加入现有的WAN Gossip一样简单。
-
数据中心的耦合非常低,由于故障检测,连接缓存和复用,跨数据中心请求相对快速可靠。
4、使用场景
- 服务发现场景
- 服务隔离场景
- 服务配置场景
4.1、服务发现场景
- consul作为注册中心,服务地址被注册到consul以后,可以使用consul提供的dns、http接口查询
- consul支持health check。
4.2、服务隔离场景
- consul支持以服务为单位设置访问策略,能同时支持经典的平台和新兴的平台
- 支持tls证书分发
- 支持service-to-service加密。
4.3、服务配置场景
- consul提供key-value数据存储功能,并且能将变动迅速地通知出去。
- Consul可以实现配置共享,从Consul中读取配置信息。
4.4、运维工具
- 可以帮助系统管理者了解系统内部的系统架构
- 可以看成一种监控软件
- 可以看成一种资产(资源)管理系统。