服务发现系统etcd介绍

本文内容纲要:

- etcd命令行接口使用

- 场景一:服务发现(Service Discovery)

- 场景二:消息发布与订阅

- 场景三:分布式通知与协调

- 场景四:分布式锁

-

一、概述

etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。在分布式系统中,如何管理节点间的状态一直是一个难题,etcd像是专门为集群环境的服务发现和注册而设计,它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能,可以方便的跟踪并管理集群节点的状态。

etcd的特性如下:

  • 简单: 支持curl方式的用户API(HTTP+JSON)
  • 安全: 可选的SSL客户端证书认证
  • 快速: 单实例每秒 1000 次写操作
  • 可靠: 使用Raft保证一致性

二、安装和使用

安装etcd

etcd的安装非常简单,可以直接下载编译后的可执行文件,下载地址:https://github.com/coreos/etcd/releases

curl -L https://github.com/coreos/etcd/releases/download/v3.0.6/etcd-v3.0.6-linux-amd64.tar.gz -o etcd-v3.0.6-linux-amd64.tar.gz

tar xzvf etcd-v3.0.6-linux-amd64.tar.gz && cd etcd-v3.0.6-linux-amd64

./etcd --version

etcd命令行接口使用

etcd支持http RESTful API,支持get查询,post,delete,put等操作。为了便于理解,可将它存储数据的框架看做一个文件系统,可以创建目录和“文件”,每个“文件”名就是一个key,每个“文件”的内容就是它的value,目录没有value只能包含子目录或者“文件”,可以通过RESTful API来获取这些key的值或者设置这些key的值。

*设置一个key的value

curl -s http://127.0.0.1:2379/v2/keys/message -X PUT -d value="Hello world" |jq .

Image

*获取一个key的value

curl -s http://127.0.0.1:2379/v2/keys/message |jq .

Image

*改变一个key的value

curl -s http://127.0.0.1:2379/v2/keys/message -X PUT -d value="Hello etcd" |jq .

Image

*删除一个key节点

curl -s http://127.0.0.1:2379/v2/keys/message -X DELETE |jq .

Image

*使用ttl(即设置一个key的值并给这个key加一个生命周期,当超过这个时间该值没有被访问则自动被删除)

curl -s http://127.0.0.1:2379/v2/keys/foo -X PUT -d value=bar -d ttl=5 |jq .

Image

*watch一个值的变化

curl -s http://127.0.0.1:2379/v2/keys/foo?wait=true

该命令调用之后会阻塞进程,直到这个值发生变化才能返回,当改变一个key的值,或者删除等操作发生时,该等待就会返回结果。

*创建一个目录

curl -s http://127.0.0.1:2379/v2/keys/dir -XPUT -d dir=true |jq .

Image

*列举一个目录

curl -s http://127.0.0.1:2379/v2/keys/dir

*递归列举一个目录

curl -s http://127.0.0.1:2379/v2/keys/dir?recursive=true

监控一个目录下的所有key的变化,包括子目录的。可以使用命令:

curl -s http://127.0.0.1:2379/v2/keys/dir?recursive=true&wait=true

*删除一个目录

curl -s http://127.0.0.1:2379/v2/keys/dir?dir=true -XDELETE

三、应用场景

场景一:服务发现(Service Discovery)

服务发现要解决的也是分布式系统中最常见的问题之一,即在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。本质上来说,服务发现就是想要了解集群中是否有进程在监听udp或tcp端口,并且通过名字就可以查找和连接。

Image

图1 服务发现示意图

微服务协同工作架构中,服务动态添加。随着Docker容器的流行,多种微服务共同协作,构成一个相对功能强大的架构的案例越来越多。透明化的动态添加这些服务的需求也日益强烈。通过服务发现机制,在etcd中注册某个服务名字的目录,在该目录下存储可用的服务节点的IP。在使用服务的过程中,只要从服务目录下查找可用的服务节点去使用即可。

Image

图2 微服务协同工作

场景二:消息发布与订阅

在分布式系统中,最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息使用者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。

Image

图3 消息发布与订阅

场景三:分布式通知与协调

这里说到的分布式通知与协调,与消息发布和订阅有些相似。都用到了etcd中的Watcher机制,通过注册与异步通知机制,实现分布式环境下不同系统之间的通知与协调,从而对数据变更做到实时处理。实现方式通常是这样:不同系统都在etcd上对同一个目录进行注册,同时设置Watcher观测该目录的变化(如果对子目录的变化也有需要,可以设置递归模式),当某个系统更新了etcd的目录,那么设置了Watcher的系统就会收到通知,并作出相应处理。

场景四:分布式锁

因为etcd使用Raft算法保持了数据的强一致性,某次操作存储到集群中的值必然是全局一致的,所以很容易实现分布式锁。锁服务有两种使用方式,一是保持独占,二是控制时序。

  • 保持独占即所有获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS(CompareAndSwap)的API。通过设置prevExist值,可以保证在多个节点同时去创建某个目录时,只有一个成功。而创建成功的用户就可以认为是获得了锁。
  • 控制时序,即所有想要获得锁的用户都会被安排执行,但是获得锁的顺序也是全局唯一的,同时决定了执行顺序。etcd为此也提供了一套API(自动创建有序键),对一个目录建值时指定为POST动作,这样etcd会自动在目录下生成一个当前最大的值为键,存储这个新的值(客户端编号)。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序,而这些键中存储的值可以是代表客户端的编号。

Image

图4 分布式锁

本文内容总结:etcd命令行接口使用,场景一:服务发现(Service Discovery),场景二:消息发布与订阅,场景三:分布式通知与协调,场景四:分布式锁,,

原文链接:https://www.cnblogs.com/xigang8068/p/5786027.html

以上是 服务发现系统etcd介绍 的全部内容, 来源链接: utcz.com/z/297033.html

回到顶部