游戏微服务架构设计：etcd

为什么是etcd

服务发现解决方案有很多，为什么不是zookeeper，consul等。马蜂窝技术做了个压测：

可以发现，etcd性能稳定，资源占用最少。此外，etcd相比其它还使用简单，部署方便。而且也是go开发的，同源。

服务发现

etcd不是一个高可用的分布式键值(key-value)数据库吗？它是怎么实现服务发现的？
实现机制是这样的：服务节点可以在etcd中注册服务名和节点地址，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果。使用节点直接查询etcd数据库得到key-value。很简单，两句话就说明白了。
etcd很方便集群，Raft强一致性共识性算法保证每个etcd节点数据同步。

当然，这只是etcd的一个应用场景。

etcd安装

mac安装

brew install etcd

centos安装

yum install -y etcd

下载下来只有这么几个文件：

$ ls
Documentation  etcd  etcdctl  README-etcdctl.md  README.md  READMEv2-etcdctl.md

etcd是server端，etcdctl是客户端。
运行：

$ ./etcd

etcd目前默认使用2379端口（客户端请求端口）和2380端口（其它节点连接端口）。etcd后面废了配置文件，推崇使用环境变量和命令行的配置。
查看配置：

$ etcd -h

docker安装

$docker run -p 2379:2379 -p 2380:2380 -v /etc/ssl/certs/:/etc/ssl/certs/ quay.io/coreos/etcd:v3.3.1

etcd使用

etcd有两种操作方式，一种是基于HTTP的REST API操作方式，另一种是通过etcdctl客户端。
而对etcd的操作命令又可分为两大类，一类是数据库操作，另一类是非数据库操作。

数据库操作

数据库操作围绕对键值和目录的CRUD完整生命周期的管理。
etcd在键的组织上采用了层次化的空间结构(类似于文件系统中目录的概念)，用户指定的键可以为单独的名字，如:testkey，此时实际上放在根目录/下面，也可以为指定目录结构，如/cluster1/node2/testkey，则将创建相应的目录结构。

非数据库操作

非数据类操作不直接对数据本身进行管理，而是负责围绕集群自身的一些配置。主要是备份、监测、集群管理等。

这些不是本文重点，网上文章很多。

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来定位数据。

集群

因为共识性算法原因，要选出master。所以集群中节点个数最好为奇数个，最少为3个。
构建集群有三种方式：

静态配置集群信息
动态发现
DNS域名服务发现
方式网上也很多，不作过多介绍

集群配置注意事项

时钟同步
集群各个节点时钟差异不超过1s,否则可能会导致raft协议异常。
节点操作
无论是添加、删除还是迁移节点，都要一个一个地进行，等集群中状态稳定后，再操作下一个节点。
故障处理
如果是某个节点出现故障了，可能本地数据已经过期甚至是格式破坏了。保险做法是先通过命令删除该节点，然后清空数据目录，再重新作为空节点加入。
重启集群
找到一个数据记录完整且比较新的节点，先以它为唯一节点创建新的集群，然后将其它节点一个一个地添加进来。