etcd

ETCD

Knowledge Sharing

etcd for service discover

Introduction

definition

A highly-available key value store for shared configuration and service discovery.

subproject under CoreOS

written in Go

widely used in server side programming for distributed systems

key features

Simple: curl'able user-facing API (HTTP+JSON)

GRPC API for v3

Secure: optional SSL client cert authentication

Fast: benchmarked 1000s of writes/s per instance

Performance

https://coreos.com/etcd/docs/latest/benchmarks/etcd-3-demo-benchmarks.html

Reliable: properly distributed using Raft

Communication between etcd machines is handled via the Raft consensus algorithm

Projects using etcd

Kubernete

etcd is the backend for service discovery and stores cluster state and configuration

Could Foundry

etcd stores cluster state and configuration and provides a global lock service

Usage

V2

Restful API（HTTP+Json）

Reading and Writing

Client API

Setting the value of a key

curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value=\"Hello world\"

{\u00A0 \u00A0 \"action\": \"set\

Using key TTL

curl http://127.0.0.1:2379/v2/keys/foo -XPUT -d value=bar -d ttl=5

Get the value of a key

curl http://127.0.0.1:2379/v2/keys/message

{\u00A0 \u00A0 \"action\": \"get\

Deleting a key

curl http://127.0.0.1:2379/v2/keys/message -XDELETE

{\u00A0 \u00A0 \"action\": \"delete\

Creating Directories

curl http://127.0.0.1:2379/v2/keys/dir -XPUT -d dir=true

Listing a directory

.......

Admin

List members

Add a member

Delete a member

Change the peer urls of a member

Listening for Changes

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

watch for a change on a key and receive a notification by using long polling.\u00A0

This also works for child keys by passing recursive=true in curl.

how to use

using language-specific libraries that wrap the HTTP API

problems

unnecessary notification

watchers would get notification even when just updating TTL of the Key

cause performance issues

V3

new version design

Flatten binary key-value space

no directory

prefix

grpc api

more efficient than JSON/HTTP

grpc is a RPC framework from google

over HTTP2

protobuf as Interface description language(IDL)

Google's data interchange format

smaller，faster，simpler

https://www.ibm.com/developerworks/cn/linux/l-cn-gpb/

introduce new features

lease

replace TTL Key

more efficient/ low cost keep alive

Txn....

......

fully compatible with etcd V2

RPC API supports the completed set of APIs

HTTP API supports a subset of APIs.

https://coreos.com/etcd/docs/latest/rfc/v3api.html

Protobuf Defined API

rpc.proto

service HelloService {\u00A0 rpc SayHello(HelloRequest) returns\u00A0 (HelloResponse);}

message HelloRequest {\u00A0 string greeting = 1;}message HelloResponse {\u00A0 string reply = 1;}

language specific

JAVA

gRPC-Java

\u00A0 io.grpc\u00A0 grpc-all\u00A0 0.13.1

compile 'io.grpc:grpc-all:0.13.1'

compile the proto to generate stub code

put your proto files in the src/main/proto and src/test/proto directories along with an appropriate plugin.

gradle

implement a etcd client

encapsulate RPC APIs

follow the protobuf

dependent on the generated code

implement a service registry

register

put keys with leases

heartbeats \u00A0the lease

subscribe

watch for prefix

get notification when changes happen under the prefix\u00A0

prerelease not stable

Demo

For dubbo

more

简介

定义

特点

\u00A0简单：基于HTTP+JSON的API让你用curl就可以轻松使用。(V2)安全：可选SSL客户认证机制。\u00A0快速：每个实例每秒支持一千次写操作。可信：使用Raft算法充分实现了分布式。

用途

With etcd you can easily manage cluster coordination and state management.

应用例子

Cloud Foundry

场景

分布式系统中的数据分为控制数据和应用数据。使用etcd的场景默认处理的数据都是控制数据，对于应用数据，只推荐数据量很小，但是更新访问频繁的情况。

服务发现

是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接

本质上，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口

三大支柱

一个强一致性、高可用的服务存储目录

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

一种注册服务和监控服务健康状态的机制

用户可以在etcd中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果

一种查找和连接服务的机制

通过在etcd指定的主题下注册的服务也能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个Proxy模式的etcd，这样就可以确保能访问etcd集群的服务都能互相连接。

微服务协同工作架构中，服务动态添加。随着Docker容器的流行，多种微服务共同协作，构成一个相对功能强大的架构的案例越来越多

PaaS平台中应用多实例与实例故障重启透明化。PaaS平台中的应用一般都有多个实例，通过域名，不仅可以透明的对这多个实例进行访问，而且还可以做到负载均衡

消息发布与订阅

在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅

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

1.应用中用到的一些配置信息放到etcd上进行集中管理

应用在启动的时候主动从etcd获取一次配置信息，同时，在etcd节点上注册一个Watcher并等待，以后每次配置有更新的时候，etcd都会实时通知订阅者，以此达到获取最新配置信息的目的

2.分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在etcd中，供各个客户端订阅使用。使用etcd的key TTL功能可以确保机器状态是实时更新的。

3.分布式日志收集系统。

这个系统的核心工作是收集分布在不同机器的日志

收集器通常是按照应用（或主题）来分配收集任务单元，因此可以在etcd上创建一个以应用（主题）命名的目录P，并将这个应用（主题相关）的所有机器ip，以子目录的形式存储到目录P上，然后设置一个etcd递归的Watcher，递归式的监控应用（主题）目录下所有信息的变动。这样就实现了机器IP（消息）变动的时候，能够实时通知到收集器调整任务分配

4.系统中信息需要动态自动获取与人工干预修改信息请求内容的情况

通常是暴露出接口，例如JMX接口，来获取一些运行时的信息。引入etcd之后，就不用自己实现一套方案了，只要将这些信息存放到指定的etcd目录中即可，etcd的这些目录就可以通过HTTP的接口在外部访问。

负载均衡

软负载均衡

坏处是数据写入性能下降，而好处则是数据访问时的负载均衡。因为每个对等服务节点上都存有完整的数据，所以用户的访问流量就可以分流到不同的机器上

etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后，每个etcd的核心节点都可以处理用户的请求

把数据量小但是访问频繁的消息数据直接存储到etcd中也是个不错的选择

利用etcd维护一个负载均衡节点表。etcd可以监控一个集群中多个节点的状态，当有一个请求发过来后，可以轮询式的把请求转发给存活着的多个状态。

分布式通知与协调

与消息发布和订阅有些相似。都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理

实现方式通常是这样：不同系统都在etcd上对同一个目录进行注册，同时设置Watcher观测该目录的变化（如果对子目录的变化也有需要，可以设置递归模式），当某个系统更新了etcd的目录，那么设置了Watcher的系统就会收到通知，并作出相应处理。

应用

通过etcd完成系统调度。某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了etcd上某些目录节点的状态，而etcd就把这些变化通知给注册了Watcher的推送系统客户端，推送系统再作出相应的推送任务。

通过etcd完成工作汇报。大部分类似的任务分发系统，子任务启动后，到etcd来注册一个临时工作目录，并且定时将自己的进度进行汇报（将进度写入到这个临时目录），这样任务管理者就能够实时知道任务进度。

通过etcd进行低耦合的心跳检测。检测系统和被检测系统通过etcd上某个目录关联而非直接关联起来，这样可以大大减少系统的耦合性。

分布式锁

因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。

锁服务有两种使用方式

保持独占即所有获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS（CompareAndSwap）的API。通过设置prevExist值，可以保证在多个节点同时去创建某个目录时，只有一个成功。而创建成功的用户就可以认为是获得了锁。

控制时序，即所有想要获得锁的用户都会被安排执行，但是获得锁的顺序也是全局唯一的，同时决定了执行顺序

etcd为此也提供了一套API（自动创建有序键），对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。

分布式队列

创建一个先进先出的队列，保证顺序

另一种比较有意思的实现是在保证队列达到某个条件时再统一按顺序执行。这种方法的实现可以在/queue这个目录中另外建立一个/queue/condition节点。condition可以表示队列大小。比如一个大的任务需要很多小任务就绪的情况下才能执行，每次有一个小任务就绪，就给这个condition数字加1，直到达到大任务规定的数字，再开始执行队列里的一系列小任务，最终执行大任务。condition可以表示某个任务在不在队列。这个任务可以是所有排序任务的首个执行程序，也可以是拓扑结构中没有依赖的点。通常，必须执行这些任务后才能执行队列中的其他任务。condition还可以表示其它的一类开始执行任务的通知。可以由控制程序指定，当condition出现变化时，开始执行队列任务。

集群监控与Leader竞选

通过etcd来进行监控实现起来非常简单并且实时性强

前面几个场景已经提到Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户

节点可以设置TTL key，比如每隔30s发送一次心跳使代表该机器存活的节点继续存在，否则节点消失

这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。

使用分布式锁，可以完成Leader竞选

这种场景通常是一些长时间CPU计算或者使用IO操作的机器，只需要竞选出的Leader计算或处理一次，就可以把结果复制给其他的Follower。从而避免重复劳动，节省计算资源。这个的经典场景是搜索系统中建立全量索引。如果每个机器都进行一遍索引的建立，不但耗时而且建立索引的一致性不能保证。通过在etcd的CAS机制同时创建一个节点，创建成功的机器作为Leader，进行索引计算，然后把计算结果分发到其它节点。

优点

简单。使用Go语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解。数据持久化。etcd默认数据一更新就进行持久化。安全。etcd支持SSL客户端安全认证。最后，etcd作为一个年轻的项目，真正告诉迭代和开发中，这既是一个优点，也是一个缺点。优点是它的未来具有无限的可能性，缺点是无法得到大项目长时间使用的检验。然而，目前CoreOS、Kubernetes和CloudFoundry等知名项目均在生产环境中使用了etcd，所以总的来说，etcd值得你去尝试。

原理

架构

HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。

Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。

Raft：Raft强一致性算法的具体实现，是etcd的核心。

WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。

协作过程

通常，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的etcd节点以确认数据提交，最后进行数据的提交，再次同步。

\u00A0新版etcd重要变更列表

获得了IANA认证的端口，2379用于客户端通信，2380用于节点通信，与原先的（4001 peers / 7001 clients）共用。每个节点可监听多个广播地址。监听的地址由原来的一个扩展到多个，用户可以根据需求实现更加复杂的集群环境，如一个是公网IP，一个是虚拟机（容器）之类的私有IP。etcd可以代理访问leader节点的请求，所以如果你可以访问任何一个etcd节点，那么你就可以无视网络的拓扑结构对整个集群进行读写操作。etcd集群和集群中的节点都有了自己独特的ID。这样就防止出现配置混淆，不是本集群的其他etcd节点发来的请求将被屏蔽。etcd集群启动时的配置信息目前变为完全固定，这样有助于用户正确配置和启动。运行时节点变化(Runtime Reconfiguration)。用户不需要重启 etcd 服务即可实现对 etcd 集群结构进行变更。启动后可以动态变更集群配置。重新设计和实现了Raft算法，使得运行速度更快，更容易理解，包含更多测试代码。Raft日志现在是严格的只能向后追加、预写式日志系统，并且在每条记录中都加入了CRC校验码。启动时使用的_etcd/* 关键字不再暴露给用户废弃集群自动调整功能的standby模式，这个功能使得用户维护集群更困难。新增Proxy模式，不加入到etcd一致性集群中，纯粹进行代理转发。ETCD_NAME（-name）参数目前是可选的，不再用于唯一标识一个节点。摒弃通过配置文件配置 etcd 属性的方式，你可以用环境变量的方式代替。通过自发现方式启动集群必须要提供集群大小，这样有助于用户确定集群实际启动的节点数量。

etcd概念词汇表

Raft：etcd所采用的保证分布式系统强一致性的算法。Node：一个Raft状态机实例。Member： 一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。Cluster：由多个Member构成可以协同工作的etcd集群。Peer：对同一个etcd集群中另外一个Member的称呼。Client： 向etcd集群发送HTTP请求的客户端。WAL：预写式日志，etcd用于持久化存储的日志格式。snapshot：etcd防止WAL文件过多而设置的快照，存储etcd数据状态。Proxy：etcd的一种模式，为etcd集群提供反向代理服务。Leader：Raft算法中通过竞选而产生的处理所有数据提交的节点。Follower：竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。Candidate：当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。Term：某个节点成为Leader到下一次竞选时间，称为一个Term。Index：数据项编号。Raft中通过Term和Index来定位数据。

同类比较

Zookeeper

起源于Hadoop\u00A0其数据存储的格式类似于文件系统，如果运行在一个服务器集群中，Zookeper将跨所有节点共享配置状态，每个集群选举一个领袖，客户端可以连接到任何一台服务器获取数据。

优势是其成熟、健壮以及丰富的特性

缺点，其中采用Java开发以及复杂性是罪魁祸首。尽管Java在许多方面非常伟大，然后对于这种类型的工作还是太沉重了，Zookeeper使用Java以及相当数量的依赖使其对于资源竞争非常饥渴

非常复杂，维护它需要比我们期望从这种类型的应用程序中获得的收益更多的知识

etcd

采用HTTP协议的健/值对存储系统，它是一个分布式和功能层次配置系统，可用于构建服务发现系统

很容易部署、安装和使用，提供了可靠的数据持久化特性。它是安全的并且文档也十分齐全。

然而

它需要搭配一些第三方工具才可以提供服务发现功能。

这个工具应该监视所有节点上的Docker容器，并且每当有新容器运行或者现有的一个容器停止的时候更新etcd

Registrator

通过检查容器在线或者停止运行状态自动注册和去注册服务

每当我们打开一个容器，所有数据将被存储在etcd并传播到集群中的所有节点。我们将决定什么信息是我们的。

Confd

轻量级的配置管理工具

用法

通过使用存储在etcd、consul和其他一些数据登记处的数据保持配置文件的最新状态，它也可以用来在配置文件改变时重新加载应用程序。

我们可以用存储在etcd（或者其他注册中心）的信息来重新配置所有服务。

当etcd、Registrator和Confd结合时，可以获得一个简单而强大的方法来自动化操作我们所有的服务发现和需要的配置

www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle

Consul

强一致性的数据存储，使用gossip形成动态集群。它提供分级键/值存储方式，不仅可以存储数据，而且可以用于注册器件事各种任务，从发送数据改变通知到运行健康检查和自定义命令，具体如何取决于它们的输出

Consul的方案更\"一站式\"，内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具

优势特点

内嵌实现了服务发现系统，所以这样就不需要构建自己的系统或使用第三方系统

用来发现已部署的服务以及其驻留的节点信息

客户只需要注册服务并通过DNS或HTTP接口执行服务发现

还包括节点健康检查和运行在其上的服务

通过HTTP请求、TTLs（time-to-live）和自定义命令提供了易于扩展的健康检查特性

Consul有一个简单的、优雅的但功能强大的方式进行健康检查，当健康阀值达到一定数目时，帮助用户定义应该执行的操作

Zookeeper和etcd只提供原始的键/值队存储，要求应用程序开发人员构建他们自己的系统提供服务发现功能

配置信息

Consul有自己的模板服务，其更适配Consul。通过从Consul获得的信息，Consul-template是一个非常方便的创建文件的途径，还有一个额外的好处就是在文件更新后可以运行任意命令

Consul Web界面

除了存储简单的键/值对，它还有一个服务的概念以及所属的数据。它还可以执行健康检查，因此成为一个好的候选dashboard，在上面可以看到我们的节点的状态和运行的服务

用户可以查看所有的服务和节点、监控健康检查状态以及通过切换数据中心读取设置键/值对数据。

这是从内心深处为了服务架构和发现而设计的方案，简单而强大。它提供了一个完整的同时不失简洁的解决方案，在许多情况下，这是最佳的服务发现以及满足健康检查需求的工具。

http://www.cnblogs.com/shanyou/p/4695131.html

结论

Zookeeper是其中最老态龙钟的一个，使用年限显示出了其复杂性、资源利用和尽力达成的目标，它是为了与我们评估的其他工具所处的不同时代而设计的（即使它不是老得太多）。

etcd、Registrator和Confd是一个非常简单但非常强大的组合，可以解决大部分问题，如果不是全部满足服务发现需要的话。它还展示了我们可以通过组合非常简单和特定的工具来获得强大的服务发现能力，它们中的每一个都执行一个非常具体的任务，通过精心设计的API进行通讯，具备相对自治工作的能力，从架构和功能途径方面都是微服务方式。

Consul的不同之处在于无需第三方工具就可以原生支持多数据中心和健康检查，这并不意味着使用第三方工具不好，如果工具引入了工作不需要的特性，那么工作效率反而会下降，另一方面，如果工具没有提供工作所需要的特性也是没有用的，Consul很好地权衡了权重，用尽量少的东西很好的达成了目标。

Consul使用gossip来传播集群信息的方式，使其比etcd更易于搭建，特别是对于大的数据中心。将存储数据作为服务的能力使其比etcd仅仅只有健/值对存储的特性更加完整、更有用（即使Consul也有该选项）。虽然我们可以在etcd中通过插入多个键来达成相同的目标，Consul的服务实现了一个更紧凑的结果，通常只需要一次查询就可以获得与服务相关的所有数据。除此之外，Registrator很好地实现了Consul的两个协议，使其合二为一，特别是添加Consul-template到了拼图中。Consul的Web UI更是锦上添花般地提供了服务和健康检查的可视化途径。

http://www.wtoutiao.com/p/Fde8BW.html

spring cloud

http://cloud.spring.io/spring-cloud-config/

集群化应用实践

由于Raft算法在做决策时需要多数节点的投票，所以etcd一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群。

集群启动

静态配置

这种方式比较适用于离线环境，在启动整个集群之前，你就已经预先清楚所要配置的集群大小，以及集群上各节点的地址和端口信息。那么启动时，你就可以通过配置initial-cluster参数进行etcd集群的启动。

在初始化完成后，etcd还提供动态增、删、改etcd集群节点的功能，这个需要用到etcdctl命令进行操作。

etcd自发现模式

通过自发现的方式启动etcd集群需要事先准备一个etcd集群。如果你已经有一个etcd集群，首先你可以执行如下命令设定集群的大小，假设为3.$ curl -X PUT http://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83/_config/size -d value=3然后你要把这个url地址http://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83作为-discovery参数来启动etcd。节点会自动使用http://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83目录进行etcd的注册和发现服务。所以最终你在某个机器上启动etcd的命令如下。$ etcd -name infra0 -initial-advertise-peer-urls http://10.0.1.10:2380 \\\u00A0 -listen-peer-urls http://10.0.1.10:2380 \\\u00A0 -discovery http://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83如果你本地没有可用的etcd集群，etcd官网提供了一个可以公网访问的etcd存储地址。你可以通过如下命令得到etcd服务的目录，并把它作为-discovery参数使用。$ curl http://discovery.etcd.io/new?size=3http://discovery.etcd.io/3e86b59982e49066c5d813af1c2e2579cbf573de同样的，当你完成了集群的初始化后，这些信息就失去了作用。当你需要增加节点时，需要使用etcdctl来进行操作。为了安全，请务必每次启动新etcd集群时，都使用新的discovery token进行注册。另外，如果你初始化时启动的节点超过了指定的数量，多余的节点会自动转化为Proxy模式的etcd。

DNS自发现模式

etcd还支持使用DNS SRV记录进行启动。关于DNS SRV记录如何进行服务发现，可以参阅RFC2782，所以，你要在DNS服务器上进行相应的配置。(1) 开启DNS服务器上SRV记录查询，并添加相应的域名记录，使得查询到的结果类似如下。$ dig +noall +answer SRV _etcd-server._tcp.example.com_etcd-server._tcp.example.com. 300 IN \u00A0 SRV 0 0 2380 infra0.example.com._etcd-server._tcp.example.com. 300 IN \u00A0 SRV 0 0 2380 infra1.example.com._etcd-server._tcp.example.com. 300 IN \u00A0 SRV 0 0 2380 infra2.example.com.(2) 分别为各个域名配置相关的A记录指向etcd核心节点对应的机器IP。使得查询结果类似如下。$ dig +noall +answer infra0.example.com infra1.example.com infra2.example.cominfra0.example.com. 300 IN \u00A0A \u00A0 10.0.1.10infra1.example.com. 300 IN \u00A0A \u00A0 10.0.1.11infra2.example.com. 300 IN \u00A0A \u00A0 10.0.1.12做好了上述两步DNS的配置，就可以使用DNS启动etcd集群了。配置DNS解析的url参数为-discovery-srv，其中某一个节点地启动命令如下。$ etcd -name infra0 \\-discovery-srv example.com \\-initial-advertise-peer-urls http://infra0.example.com:2380 \\-initial-cluster-token etcd-cluster-1 \\-initial-cluster-state new \\-advertise-client-urls http://infra0.example.com:2379 \\-listen-client-urls http://infra0.example.com:2379 \\-listen-peer-urls http://infra0.example.com:2380当然，你也可以直接把节点的域名改成IP来启动。

references

http://www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle