服务发现

consul 简介

做服务发现的框架常用的有

  • zookeeper
  • eureka
  • etcd
  • consul

consul是分布式的、高可用、横向扩展的。consul提供的一些关键特性:

  • service discovery:consul通过DNS或者HTTP接口使服务注册和服务发现变的很容易,一些外部服务,例如saas提供的也可以一样注册。
  • health checking:健康检测使consul可以快速的告警在集群中的操作。和服务发现的集成,可以防止服务转发到故障的服务上面。
  • key/value storage:一个用来存储动态配置的系统。提供简单的HTTP接口,可以在任何地方操作。
  • multi-datacenter:无需复杂的配置,即可支持任意数量的区域。

架构图及解析

让我们把这幅图分解描述。首先,我们可以看到有两个数据中心,分别标记为“1”和“2”。Consul拥有对多个数据中心的一流支持,这是比较常见的情况。

在每个数据中心中,我们都有客户机和服务器。预计将有三到五台服务器。这在故障情况下的可用性和性能之间取得了平衡,因为随着添加更多的机器,一致性会逐渐变慢。但是,客户端的数量没有限制,可以很容易地扩展到数千或数万。

Consul 实现多个数据中心都依赖于gossip protocol协议。这样做有几个目的:首先,不需要使用服务器的地址来配置客户端;服务发现是自动完成的。其次,健康检查故障的工作不是放在服务器上,而是分布式的。这使得故障检测比单纯的心跳模式更具可伸缩性。为节点提供故障检测;如果无法访问代理,则节点可能经历了故障。

每个数据中心中的服务器都是一个筏对等集的一部分。这意味着它们一起工作来选举单个leader,一个被选中的服务器有额外的职责。领导负责处理所有的查询和事务。事务还必须作为协商一致协议的一部分复制到所有对等方。由于这个需求,当非leader服务器接收到RPC请求时,它会将其转发给集群leader。
Consul的使用场景

Consul的应用场景包括服务发现、服务隔离、服务配置:

  •     服务发现场景中consul作为注册中心,服务地址被注册到consul中以后,可以使用consul提供的dns、http接口查询,consul支持health check。
  •     服务隔离场景中consul支持以服务为单位设置访问策略,能同时支持经典的平台和新兴的平台,支持tls证书分发,service-to-service加密。
  •     服务配置场景中consul提供key-value数据存储功能,并且能将变动迅速地通知出去,借助Consul可以实现配置共享,需要读取配置的服务可以从Consul中读取到准确的配置信息。
  •     Consul可以帮助系统管理者更清晰的了解复杂系统内部的系统架构,运维人员可以将Consul看成一种监控软件,也可以看成一种资产(资源)管理系统。

    比如:docker实例的注册与配置共享、coreos实例的注册与配置共享、vitess集群、SaaS应用的配置共享、Consul与confd服务集成,动态生成nginx和haproxy配置文件或者Consul结合nginx构建高可用可扩展的Web服务。

docker安装

 第一个server启动

docker run -d --name=consul-server1 --net=host -e CONSUL_BIND_INTERFACE=ens33 -v /consul/config:/consul/config -v /consul/data:/consul/data consul:latest agent -server -node=agent128 -bootstrap-expect=3 -client=0.0.0.0 -ui

剩下两个Server启动并加入集群

docker run -d --name=consul-server2 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -server -node=agent129 -client=0.0.0.0 -join 192.168.30.128

docker run -d --name=consul-server3 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -server -node=agent130 -client=0.0.0.0 -join 192.168.30.128

Client启动并加入集群

docker run -d --name=consul-client1 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -node=agent131 -client=0.0.0.0 -join 192.168.30.128

查看集群:

docker exec consul-server1 consul members

Node      Address              Status  Type    Build  Protocol  DC   Segment
agent128  192.168.30.128:8301  alive   server  1.8.3  2         dc1  <all>
agent129  192.168.30.129:8301  alive   server  1.8.3  2         dc1  <all>
agent130  192.168.30.130:8301  alive   server  1.8.3  2         dc1  <all>
agent131  192.168.30.131:8301  alive   client  1.8.3  2         dc1  <default>

访问ui:

访问192.168.30.128:8500/ui

参考:https://www.imooc.com/article/296209/

https://www.imooc.com/article/284030/

https://blog.csdn.net/a312586670/article/details/105337943/

首先Consul支持多数据中心,在上图中有两个DataCenter,他们通过Internet互联,同时请注意为了提高通信效率,只有Server节点才加入跨数据中心的通信。

作者:KaliArch
链接:https://www.imooc.com/article/296209/
来源:慕课网
本文首次发布于慕课网 ,转载请注明出处,谢谢合作

首先Consul支持多数据中心,在上图中有两个DataCenter,他们通过Internet互联,同时请注意为了提高通信效率,只有Server节点才加入跨数据中心的通信。

在单个数据中心中,Consul分为Client和Server两种节点(所有的节点也被称为Agent),Server节点保存数据,Client负责健康检查及转发数据请求到Server;Server节点有一个Leader和多个Follower,Leader节点会将数据同步到Follower,Server的数量推荐是3个或者5个,在Leader挂掉的时候会启动选举机制产生一个新的Leader。

集群内的Consul节点通过gossip协议(流言协议)维护成员关系,也就是说某个节点了解集群内现在还有哪些节点,这些节点是Client还是Server。单个数据中心的流言协议同时使用TCP和UDP通信,并且都使用8301端口。跨数据中心的流言协议也同时使用TCP和UDP通信,端口使用8302。

集群内数据的读写请求既可以直接发到Server,也可以通过Client使用RPC转发到Server,请求最终会到达Leader节点,在允许数据轻微陈旧的情况下,读请求也可以在普通的Server节点完成,集群内数据的读写和复制都是通过TCP的8300端口完成。


作者:KaliArch
链接:https://www.imooc.com/article/296209/
来源:慕课网
本文首次发布于慕课网 ,转载请注明出处,谢谢合作

首先Consul支持多数据中心,在上图中有两个DataCenter,他们通过Internet互联,同时请注意为了提高通信效率,只有Server节点才加入跨数据中心的通信。

在单个数据中心中,Consul分为Client和Server两种节点(所有的节点也被称为Agent),Server节点保存数据,Client负责健康检查及转发数据请求到Server;Server节点有一个Leader和多个Follower,Leader节点会将数据同步到Follower,Server的数量推荐是3个或者5个,在Leader挂掉的时候会启动选举机制产生一个新的Leader。

集群内的Consul节点通过gossip协议(流言协议)维护成员关系,也就是说某个节点了解集群内现在还有哪些节点,这些节点是Client还是Server。单个数据中心的流言协议同时使用TCP和UDP通信,并且都使用8301端口。跨数据中心的流言协议也同时使用TCP和UDP通信,端口使用8302。

集群内数据的读写请求既可以直接发到Server,也可以通过Client使用RPC转发到Server,请求最终会到达Leader节点,在允许数据轻微陈旧的情况下,读请求也可以在普通的Server节点完成,集群内数据的读写和复制都是通过TCP的8300端口完成。

Consul 集群间使用了 Gossip 协议通信和 raft 一致性算法

  • Gossip —— Gossip protocol 也叫 Epidemic Protocol (流行病协议),实际上它还有很多别名,比如:“流言算法”、“疫情传播算法”等。 这个协议的作用就像其名字表示的意思一样,非常容易理解,它的方式其实在我们日常生活中也很常见,比如电脑病毒的传播,森林大火,细胞扩散等等。
  • Client —— 一个 Client 是一个转发所有 RPC 到 server 的代理。这个 client 是相对无状态的。client 唯一执行的后台活动是加入 LAN gossip 池。这有一个最低的资源开销并且仅消耗少量的网络带宽。
  • Server —— 一个 server 是一个有一组扩展功能的代理,这些功能包括参与 Raft 选举,维护集群状态,响应 RPC 查询,与其他数据中心交互 WAN gossip 和转发查询给 leader 或者远程数据中心。
  • DataCenter —— 虽然数据中心的定义是显而易见的,但是有一些细微的细节必须考虑。例如,在 EC2 中,多个可用区域被认为组成一个数据中心。我们定义数据中心为一个私有的,低延迟和高带宽的一个网络环境。这不包括访问公共网络,但是对于我们而言,同一个 EC2 中的多个可用区域可以被认为是一个数据中心的一部分。
  • Consensus —— 一致性,使用 Consensus 来表明就 leader 选举和事务的顺序达成一致。为了以容错方式达成一致,一般有超过半数一致则可以认为整体一致。Consul 使用 Raft 实现一致性,进行 leader 选举,在 consul 中的使用 bootstrap 时,可以进行自选,其他 server 加入进来后 bootstrap 就可以取消。
  • LAN Gossip —— 它包含所有位于同一个局域网或者数据中心的所有节点。
  • WAN Gossip —— 它只包含 Server。这些 server 主要分布在不同的数据中心并且通常通过因特网或者广域网通信。
  • RPC——远程过程调用。这是一个允许 client 请求 server 的请求/响应机制。

1.3.2 Consul服务发现原理

1.3.2.1 原理图


作者:KaliArch
链接:https://www.imooc.com/article/296209/
来源:慕课网
本文首次发布于慕课网 ,转载请注明出处,谢谢合作
架构图及解析

作者:KaliArch
链接:https://www.imooc.com/article/296209/
来源:慕课网
本文首次发布于慕课网 ,转载请注明出处,谢谢合作
架构图及解析

作者:KaliArch
链接:https://www.imooc.com/article/296209/
来源:慕课网
本文首次发布于慕课网 ,转载请注明出处,谢谢合作
原文地址:https://www.cnblogs.com/fat-girl-spring/p/14832268.html