深入浅出之etcd（二）

系列文章目录

浅谈分布式系统与一致性协议（一）
浅谈分布式系统与一致性协议（二）
浅谈分布式系统与一致性协议（三）
深入浅出之etcd
深入浅出之etcd(二)
etcd版本之v3
etcd之安全性阐述
etcd的多版本并发控制

---

etcd典型应用场景

etcd的定位是通用的一致性key/value存储，但也有服务发现和共享配置的功能。。因此，典型的etcd应用场景包括但不限于分布式数据库，服务注册与发现，分布式锁，分布式消息队列，分布式系统选主等。

服务注册与发现

服务发现（Service Discovery）要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或者服务如何才能找到对方并且建立链接。从本质上将，服务发现就是了集群中是否有进程在监听UDP或者TCP端口，并且通过名字就可以进性查找和链接。实现服务发现功能通常具备三个条件

• 一个强一致性，高可用性的服务存储目录。而基于Raft算法的etcd天生就是这样一个强一致性，高可用性的服务存储目录。
• 一种注册服务和检查服务健康状况的机制。用户可以在etcd中注册服务，并且对注册的服务配置key
  TTL，定时保持服务的心跳以达到健康监控的效果
• 一种查找和链接服务的机制。在etcd指定的主题下注册服务能在对应的主题下查找。为了确保链接，我们可以在各个服务器上都部署一个代理的etcd，这样确保访问etcd集群的服务都能互相链接。

下图代表着服务发现与服务注册的基本原理图

etcd提供微服务注册与发现

随着Docker容器的流行，多种微服务共同协作，使项目功能多样化，并且可以动态的在服务注册中心添加功能以满足我们的需求。而服务发现机制可用于在etcd中注册某个服务名字的目录，并且在该目录下存储可用服务节点的Ip。在使用服务过程中，只要从服务目录夏查找可用的服务节点进性使用即可，这样通过etcd就可以左到各微服务之间的自动添加和协同。

消息发布和订阅

在分布式系统中，最为适用的组件之间的通信机制是消息的发布和订阅机制。具体而言，设置一个配置共享中心，消息提供者在这个配置中心发布消息，消息使用者订阅他们关心的主题，一旦主题的消息发布，就会通知订阅者。通过这种方式我们可以实现分布式系统配置的集中式管理和实时动态更新

• etcd管理应用配置信息更新：这类场景的使用方式通常是，应用在启动时候主动从etcd获取一次配置信息，同时，在etcd节点注册一个watcher并等待，以后每当配置有更新的时候，etcd都会定时通知订阅者，以此达到获取最新配置的目的
• 分布式日志收集系统：这个系统的核心工作是收集分布在不同机器上的日志。收集器通常按应用或者主题来分配收集任务单元，因此，可以在etcd上创建一个以应用或者目录为名目的目录，并将这个应用或者主题相关的所有机器的IP以子目录的形式存储在目录上。然后设置一个递归的etcd Watcher，递归式监控应用或者主题目录下的所有信息变动。这样就可以实现在机器IP发生变动时，系统接受收集器调整任务分配
• 系统中心需要动态获取与人工干预修改信息的请求内容：在etcd中只需要将信息存放在指定的etcd目录下，即可以通过HTTP接口直接被外访问

发布-订阅的流程如如下：

负载均衡

分布式系统中，为了保证服务的高可用性以及数据的一致性，通常会把数据和服务部署多份，以此达到对等服务，即使其中某一个服务失效了，也不会影响使用。

etcd分布式架构存储的信息支持负载均衡，etcd集群化后，每个分布式的核心节点都可以处理用户的请求。etcd可以监控一个集群中多个节点的状态，若有一个请求发过来，则可以轮询式的把请求转发给存活的多个节点。

分布式通知与协调

分布式通知与协调与消息的订阅与发布相似，都使用了etcd的watcher机制，通过注册于异步通知机制实现分布式环境下不同系统之间的通知与协调，进而对数据变更进行实时处理。

实现方式通常为不同的系统都在etcd的同一个目录注册并且设置Watcher监控该目录的变化。若目录被更新，那么设置可Watcher的系统就会收到通知，并且做出响应的通知，然后进行相应的处理。

分布式锁

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

保持独占：即所有试图获取锁的用户最终只有一个可以获得。etcd提供了一套实现分布式锁原子操作CAS的API。通过设置prevExist值，可以保证在多个节点同时创建某个目录，然后只有一个节点能够成功，成功的那个即可获取分布式锁

控制时序：试图获取所得所有用户都会进入等待队列，获取锁的顺序是全局唯一的，同时还能决定队列的执行顺序。etcd提供的API会将一个目录的键值作为POST动作，这样，etcd会在目录夏生成一个当前最大值作为键，并且存储这个新的值。同时还可以使用API按顺序列出所有目录下的键值，此时这些键的值就是客户端的时序，而这些键中存储的值则可以代表客户端的编号。

总结

etcd经典的应用场景包括服务注册于发现，分布式锁以及Leader选主等，比如直接当分布式数据库使用，为分布式消息服务中消息队列的实现提供服务发现，服务协调和选主。相较于etcd v2 ，etcd v3版本的接口是通过gRPC提供的RPC接口使用的的，它放弃了v2版本的HTTP接口，这种改变明显的提升了链接的效率，但是便利性不如v2，不利于维护长连接。此外，etcd的定位是通用性的一致性的key-value存储，但是在面向服务注册与发现的应用场景，这种通用性可能会使每个服务的注册都有自己的元数据格式，不利于互相整合，受限于元数据格式的兼容性问题，不利于实现更高级的功能