服务发现 etcd Consul

发表于 | 分类于 | 阅读次数

介绍

https://blog.csdn.net/bandaoyu/article/details/108097313

https://www.cnblogs.com/InCsharp/p/6810114.html

https://www.ibm.com/cloud/learn/etcd#toc-etcd-and-k-mtaLVchu

代码

http://ldaysjun.com/2019/01/14/Microservice/micro3/

etcd

etcd是一个开源的分布式键值对存储工具。在每个coreos节点上面运行的etcd，共同组建了coreos集群的共享数据总线。etcd可以保证coreos集群的稳定，可靠。当集群网络出现动荡，或者当前master节点出现异常时，etcd可以优雅的进行master节点的选举工作，同时恢复集群中损失的数据。

  • 完全复制： etcd 集群中的每个节点都可以访问完整的数据存储。
  • 高可用： etcd 被设计为没有单点故障，并且可以优雅地容忍硬件故障和网络分区。
  • 可靠一致每次“读取”数据都会返回所有集群中“写入”的最新数据。
  • 快速： etcd 的基准测试为每秒 10,000 次写入。
  • 安全： etcd 支持自动传输层安全 (TLS) 和可选的安全套接字层 (SSL) 客户端证书身份验证。由于 etcd 存储重要且高度敏感的配置数据，管理员应在部署中实施基于角色的访问控制，并确保与 etcd 交互的团队成员仅限于执行工作所需的最低权限级别的访问权限。
  • 简单：任何应用程序，从简单的 Web 应用程序到高度复杂的容器编排引擎（如 Kubernetes），都可以使用标准的 HTTP/JSON 工具读取或写入数据到 etcd。

请注意，由于 etcd 的性能在很大程度上取决于存储磁盘速度，因此强烈建议在 etcd 环境中使用 SSD。

场景

ETCD有很多使用场景，包括：

  • 配置管理
  • 服务发现
  • 选主
  • 应用调度
  • 分布式队列
  • 分布式锁

Etcd的底层数据存储上与一个NoSQL的数据库基本没有差别，但更准确的说法说是一个高可用的键值存储系统。Etcd在设计的初衷主要用于是共享配置和服务发现

服务发现

etcd应用比较多的应用场景是用于服务发现，服务发现(Service Discovery)要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。

从本质上说，服务发现就是要了解集群中是否有进程在监听upd或者tcp端口，并且通过名字就可以进行查找和链接。

要解决服务发现的问题，需要下面三大支柱，缺一不可。

  • 一个强一致性、高可用的服务存储目录。 基于Ralf算法的etcd天生就是这样一个强一致性、高可用的服务存储目录。

  • 一种注册服务和健康服务健康状况的机制。 用户可以在etcd中注册服务，并且对注册的服务配置key TTL，定时保持服务的心跳以达到监控健康状态的效果。

  • 一种查找和连接服务的机制。 通过在etcd指定的主题下注册的服务也能在对应的主题下查找到。

etcd 是一个 分布式 的高一致性的 键值存储系统。我们每次网关后面加一个服务，只需要向etcd 注册 该服务（其实就是 存一个值）然后向etcd 发送心跳，当etcd 没有检测到心跳就会 把这个键值对 删了(这整个动作是etcd里的租约模式)，网关那边 就只需要 watch 这个 key ，就能够知道 所有服务的所有动态了。

共识算法

etcd 建立在 Raft 共识算法之上，以确保集群中所有节点的数据存储一致性

对比

etcd vs redis

Redis 是一种内存数据存储，可用作数据库、缓存或消息代理。Redis 支持比 etcd 更广泛的数据类型和结构，并且具有更快的读/写性能。

但是 etcd 具有超强的容错能力、更强的故障转移和持续数据可用性能力，最重要的是，etcd 将所有存储的数据持久化到磁盘，从本质上牺牲了速度以获得更高的可靠性和保证的一致性。由于这些原因，Redis 更适合用作分布式内存缓存系统，而不是存储和分布式系统配置信息。

  • redis 主从是异步复制的机制，这就导致了其有丢失数据的风险。

  • 分布式系统最重要的就是一致性协议，redis 是不支持的。如果发生脑裂，可能两个微服务都会声称自己对某段 IP 的请求负责。

etcd vs zookeeper

etcd 具有 ZooKeeper 没有的一些重要功能。例如，与 ZooKeeper 不同，etcd 可以执行以下操作：

  • 允许动态重新配置集群成员资格。
  • 在高负载下执行读/写操作时保持稳定。
  • 维护多版本并发控制数据模型。
  • 提供可靠的密钥监控，不会在不发出通知的情况下丢弃事件。
  • 使用将连接与会话分离的并发原语。
  • 支持广泛的语言和框架（ZooKeeper 有自己的自定义 Jute RPC 协议，支持有限的语言绑定）。

Zookeeper有如下缺点

  • 复杂。Zookeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世；另外，Zookeeper的使用也比较复杂，需要安装客户端，官方只提供了java和C两种语言的接口。

  • Java编写。这里不是对Java有偏见，而是Java本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望机器集群尽可能简单，维护起来也不易出错。

  • 发展缓慢。Apache基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。

etcd的优点：

  • 简单。使用Go语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解。

  • 数据持久化。etcd默认数据一更新就进行持久化。

  • 安全。etcd支持SSL客户端安全认证。

etcd vs consul

Consul 是分布式系统的服务网络解决方案，其功能介于 etcd 和Istio 服务网格之间。与 etcd 一样，Consul包含一个基于 Raft 算法的分布式键值存储，并支持 HTTP/JSON 应用程序编程接口（API）。两者都提供动态集群成员配置，但 Consul 对配置数据的多个并发版本没有那么强的控制，并且它可以可靠工作的最大数据库大小更小。