总结

ETCD到目前为止经历了三个阶段：

· V1：概念验证阶段，Raft协议层和存储实现都比较粗糙

· V2：形成了稳定、可扩展的Raft协议层和存储层

· V3：增加了V3存储实现，这一阶段关注性能、安全性和运维成本

ETCD的存储在V2之后形成了稳定可扩展的Raft协议层，在V3中又加入了在本地持久化的BoltDB实现，支持了更大的数据集，并对客户端的访问做了一些优化，系统也更可靠了，但整体数据模型并没有变化，V3存储扩展了消息类型，同时增加了对这些消息的处理逻辑（对V3存储的读/写操作），整个Raft协议层改动不大。

另外不得不提的是它的监控方案。ETCD从V2开始引入原生的Prometheus支持，V3中又增加了很多Metrics，基于Metrics可以从宏观的角度来刻画整个集群的状态和变化，相比基于日志的监控手段，这样的方案减少了大量的I/O操作。

为什么减少I/O操作对ETCD这么重要？这是因为ETCD本身是一个对磁盘高度敏感的系统，如果存在大量的日志读写，可能导致节点在I/O上出现阻塞，进而丢失“心跳”，集群就会出现频繁的主从切换，影响稳定性。

而基于Prometheus的监控，完全在内存中维护一个最新的状态，由Prometheus定时主动Pull某个时间点的数据。Fig 5.1是基于Prometheus监控的架构。

Fig 5.1 Prometheus监控系统架构

当然它还支持由被监控对象自己Push Metrics，但通常来讲，都是让Prometheus Server主动Pull Metrics。这样的好处是显然的，被监控对象不需要在内存中维护历史数据，只维护当前最新的数据即可。

另外，让人爱不释手的是与Prometheus完美集成的Grafana，尽管以前接触得不多，但在Prometheus的应用中，它发挥了非常关键的作用，提供了非常丰富的可视化功能，非常容易上手。

实践中，我们也发现Prometheus默认的启动配置存在优化空间，如果没有独立的服务器部署，一定要注意控制它的资源占用，比较可控的部署方式是通过容器或Systemd，在Systemd中可以通过加Fig 5.2中的配置来控制它的RAM/CPU占用率。这里限制CPU占用最多20%，内存最多8G。

Fig 5.2 Systemd限制Prometheus的RAM/CPU占用

内存还有一处优化，就是“-storage.local.target-heap-size 8589934592”启动参数，这个非常重要。官方文档中建议将这个参数设置为可用内存的2/3，我限制了8G的内存，其实这里最好设置为5G左右。这个参数可以将数据直接加载到内存中，让分析计算变得更加高效。如果查询的时间跨度比较大，建议给大一点的值。

最后就是磁盘的优化了。Prometheus在启动时，可以指定仅保留过去多长时间内的数据：“-storage.local.retention 120h0m0s”，这是非常美妙的，结合这个参数，可以让磁盘占用总是处在可控的范围内。