etcd应用

etcd组件做为一个高可用、强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，若是让服务快速透明地接入到计算集群中。若是让共享配置信息快速被集群中的全部机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切须要解决的问题。
etcd：A highly-available key value store for shared configuration and service discovery.
实际上，etcd做为一个受到zk和docker启发而催生的项目，除了拥有与之相似的功能外，更具备如下4个特色。
（1）简单：基于HTTP+JSON的API让你用curl命令就能够轻松使用。
（2）安全：可选SSL客户认证机制
（3）快速：每一个实例每秒支持一千多写操做
（4）可信：使用Raft算法充分实现了分布式

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

1. 服务发现

服务发现（Service Discovery）要解决的是分布式系统中最经常使用的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并创建链接。从本质上说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，而且经过名字就能够进行查找和链接。要解决服务发现的问题，须要有三大支柱：
（1）一个强一致性、高可用的服务存储目录。基于Raft算法的etcd天生就是这样一个强一致性高可用的服务存储目录。
（2）一种注册服务和监控服务健康状态的机制。用户能够在etcd中注册服务，而且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果
（3）一种查找和链接服务的机制。经过在etcd指定的主题下注册的服务也能在对应的主题下查找到。为了确保链接，能够在每一个服务器上部署一个proxy模式的etcd，这样就能够确保能访问etcd集群的服务都能互相链接。

下面咱们一块儿看服务发现对应的具体应用场景。
（1）微服务协同工做架构中，服务动态添加。
多种微服务共同协做，构成一个功能相对强大的架构的案例愈来愈多。透明化的动态添加这些服务的需求也日益强烈。经过服务发现机制，在etcd中注册某个服务名字的目录，在该目录下存储可用的服务节点的IP。在使用服务的过程当中，只要从服务目录下查找可用的服务节点进行使用便可。
（2）PaaS平台中应用多实例与实力故障重启透明化。
PaaS平台中的应用通常都有多个实例，经过域名，不只能够透明地对多个实例进行访问，并且还能够实现负载均衡。可是应用的某个实例随时都有可能故障重启，这时就须要动态地配置域名解析中的信息。经过etcd的服务发现功能就能够轻松解决这个动态配置的问题。

2. 信息发布与订阅

在分布式系统中，最为适用的组件见通讯方式是消息发布与订阅机制。具体而言，即构建一个配置共享中心，数据提供者在这个配置中心发布信息，而信息使用者则订阅他们关心的主题，一旦相关主题有信息发布，就会实时通知订阅者。经过这种方式能够实现分布式系统配置的集中式管理与实时动态更新。
（1）应用中用到的一些信息存放在etcd上进行集中管理。这类场景的使用方式一般是这样的：应用在启动的时候主动从etcd获取一次配置信息，同时，在etcd节点上注册一个watcher并等待，之后每次配置有更新的时候，etcd都会实时通知订阅者，以此达到获取最新配置信息的目的。
（2）分布式搜索服务中，索引的源信息和服务器集群的节点状态信息存放在etcd中，供各个客户端订阅使用。使用etcd的key TTL供能够确保机器状态是实时更新的。
（3）分布式日志收集系统。这个系统的核心工做是收集分布在不一样机器上的日志。收集器一般按照应用（或主题）来分配收集任务单元，所以能够在etcd上建立一个以应用（或主题）命名的目录P，并将这个应用相关的全部机器IP，以子目录的形式存储在目录P下，而后设置一个递归的etcd Watcher，递归式地监控应用目录下全部信息的变更。这样就试下了在机器IP（信息）发生变更时，可以实时通知收集器调整任务分配。
（4）系统中信息须要动态自动获取与人工干预修改信息请求内容的状况。一般的解决方案是对外暴露接口，来获取一些运行时的信息或提交修改的请求，而引入etcd以后，只须要将这些信息存放到指定的etcd目录中，便可经过HTTP接口直接被外部访问。

3. 负载均衡

本节的负载均衡指软负载均衡。在分布式系统中，为了保证服务的高可用以及数据的一致性，一般都会把数据和服务部署多份，以此达到对等服务，即便其中的某一个服务失效了，也不影响使用。这样的实现虽然会致使必定程度上数据写入性能的降低，可是却能实现数据访问时的负载均衡。由于每一个对等服务节点上都存有完整的数据，因此用户的访问流量就能够分流到不一样的机器上。
（1）etcd自己分布式架构存储的信息访问支持负载均衡。etcd集群化之后，每一个etcd的核心节点均可以处理用户的请求。因此，把数据量小可是访问频繁的消息数据直接存储到etcd中也是个不错的选择。
（2）利用etcd维护一个负载均衡节点表。etcd能够监控一个集群中多个节点的状态，当有一个请求发过来后，能够轮询式地把请求转发给存活着的多个节点。

4. 分布式通知与协调

与消息发布和订阅有些类似。二者都使用了etcd的watcher机制，经过注册于异步通知截止，实现分布式环境下不一样系统之间的通知与协调，从而对数据变动进行实时处理。实现方式一般为：不一样系统都在etcd上对同一个目录进行注册，同时设置watcher监控该目录的变化，当某个系统更新了etcd的目录，那么设置了watcher的系统就会收到通知，并做出相应处理。
（1）经过etcd记性低耦合的心跳检测。检测系统和被检测系统经过etcd上某个目录关联而非直接关联起来，这样能够大大减小系统的耦合性。
（2）经过etcd完成系统调度。某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工做。管理人员在控制台作的一些操做，实际上只须要修改etcd上某些目录节点的状态，而etcd就会自动把这些变化通知给注册了watcher的推送客户端，推送系统再作出相应的推送任务。
（3）经过etcd完成工做汇报。大部分相似的任务分发系统，子任务启动后，到etcd来注册一个临时工做目录，而且定时将本身的精度进行汇报（将精度写入到这个临时目录），这样任务管理者就可以实时知道任务进度。

5. 分布式锁

由于etcd使用Raft算法保持了数据的强一致性，某次操做存储到集群中的值必然是全局一致的，因此很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。
（1）保持独占，即全部试图获取锁的用户最终只有一个能够获得。etcd为此提供了一套实现分布式锁原子操做CAS的API。经过设置prevExist值，能够保证在多个节点同时建立某个目录时，只有一个成功，而该用户便可认为是得到了锁。
（2）控制时序，即全部试图获取锁的用户都会进入等待队列，得到锁的顺序是全局惟一的，同时决定了队列执行顺序。etcd为此也提供了一套API。

6. 分布式队列