CoreOS 发布 etcd v2.3.0，重点提升稳定性和可靠性
发布于 2016-03-28 01:25:21 | 148 次阅读 | 评论: 0 | 来源: 网友投递
etcd 高可用的 Key/Value 存储系统
etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处 理日志复制以保证强一致性。Raft是一个来自Stanford的新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性，在 Raft中，任何一个节点都可能成为Leader。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。
Etcd v2.3.0正式发布了！这次更新不仅伴随着稳定性和可靠性方面的提升，还为我们带来了新的v3版本API的预览版以及新的存储引擎，除此之外还有哪些诱人的特性呢？赶紧来看看吧！
今天，我们很高兴地宣布etcd v2.3.0正式发布了，这次更新的重点放在稳定性和可靠性方面的改进。这个版本里同样也推出了一个实验性的下一代v3版本API的实现，包括一个客户端和命令行工具，为开发者们提供未来版本etcd的提前体验。
etcd是一款开源的分布式一致性键值存储。数以百计的项目使用etcd来完成共享配置，服务发现，协同调度等，同时etcd也是CoreOS栈的一个重要组成部分。它还是Kubernetes集群编排系统主要的调度和服务发现的数据存储。
你可以转到etcd社区来了解关于etcd的更多内容，并且可以在Github上找到新版本的可执行程序（https://github.com/coreos/etcd/releases/tag/v2.3.0）。想了解关于这次最新更新的详细内容请接着往下看。
我们在几个月前推出了V2版授权API的实验版本。自那以后，通过实际环境的测试使得etcd的认证API变得稳定，并且在生产环境使用的可靠性以及和开发的集成方面已然就绪。该认证API提供了一个识别用户并基于该身份在etcd集群里授权对应功能的机制。
为了确保持久性，一个etcd集群会在每个请求过来时在答复它之前先将其持久化到该集群里大部分成员的磁盘里。此前，这一磁盘I/O在etcd领导者和它的追随者之间是以顺序执行的方式发生，因此最小的延迟会是2 * fsync latency + network latency。为了减少这样潜在的瓶颈，我们实现了一个在Raft论文中提到过的优化策略。etcd 2.3.0版本取而代之的是在领导者和它的追随者之间以并行的方式完成磁盘I/O，因为追随者写的时候不需要再事先等领导者的写操作完成，所以也就意味着最小延迟为fsync latency + network latency。
在 过去的一年里，我们把etcd放到了长期运行的功能测试中。我们的etcd集群已经通过了成千上万次这样的功能性测试，这里面包括杀掉节点以及丢弃网络包 等测试。这些工作在检测运行时问题方面特别有帮助，我们可以借此先于用户发现这些问题，并且由此可以显著提高etcd正式版本的可靠性。
这些功能测试的最新结果如今能够在新的etcd测试仪表盘里公开可见。
该面板视图里包含了一些必不可少的统计数据，例如在这个etcd集群上自它最后一次重启起执行的所有功能测试的总共回合数。
这些测试的失败率通常低于0.1％。etcd团队会去调研每一个失败的功能测试，然后利用分析结果来驱动改进etcd或者是测试基础设施本身。这些功能测试甚至能够帮助我们发现etcd依赖里面的一个有趣bug，然后使得我们创建一个上游的修复，惠及广大的开源社区。
最近高比例的测试失败实际上已经揭露了测试和测试环境的短板，而并非etcd。例如，在一个商业的云基础设施上运行etcd测试集群的话有时也意味着超分的虚拟资源会错误地触发一些带时序假设的测试用例失败。这些误报甚至会延伸到报告机制本身，它本来应再等两秒可是却已经将误报发送了出去。我们正在不断地努力改善它，接下来我们还会继续测试并使用这个基础设施。
etcd 2.3版本推出了一个实验性的全新v3版本API的实现。etcd的v3版本API旨在使得etcd能够更高效地扩展到更多的客户端。为了能够更好地支持这些新的API特性，这一版本里也加入了一个新的实验性存储引擎。这一新的存储引擎采用的是带有全MVCC支持的一个基于b+树结构的磁盘存储格式。这使得etcd能够支持增量的快照和低成本的”时间旅行”式的查询，例如像访问一个key的之前版本等操作。所有v2版本的API请求则仍然延续使用稳定的现有存储引擎和磁盘格式。只有v3版本的API操作会落在新的b+树存储系统上。v2和v3版本的API在数据模型上有很大的不同，并且不是那么容易做到v2和v3 API操作相同键值命名空间的同时保证API不受这两个版本的影响。因此，尽管理论上来说为这两个API使用统一的数据存储层并非不可能，但是它给现有的v2版本的用户实际带来的收益非常有限。就目前而言，分别为两个API版本维护各自的存储引擎显得更有价值，并且也简化了实现的难度。
我们并没有打算废弃v2版本的API，并且如果etcd v3版本发布的话这两个API也将会继续并排存在。我们还会为那些希望将他们的应用从etcd v2版本API平滑迁移到v3版本的开发者和用户们提供一个迁移指南。
The etcd v2 and v3 API使用不同的存储引擎
我们非常希望得到你的反馈和参与到指导V3 API的持续开发中来。如果想尝试新的v3版本特性的话，可以在启动etcd时带上额外的–experimental-v3demo和–experimental-gRPC-add参数。如果打算将etcd v3版本集成到你的应用的话，不妨看一下客户端库的相应文档（https://godoc.org/github.com/coreos/etcd/clientv3）。
如果有Go的开发环境，你可以轻松地通过以下6个步骤来上手体验etcd v3版本的API：
go get github.com/coreos/etcd cd $GOPATH/src/github.com/coreos/etcd ./build go build -o bin/etcdctlv3 ./etcdctlv3 goreman start -f V3DemoProcfile start ./bin/etcdctlv3 put hello "v3 API"
请确认已经加入etcd-dev邮件列表以确保收到及时的更新推送。我们将继续致力于etcd的更新迭代并且持续开发所需的功能特性，我们也非常欢迎你的贡献！还没有使用etcd？从这里（https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/）开始吧。
稿源：Docker微信号
历史版本 :
etcd 3.0.14 发布，高可用 Key/Value 存储系统
etcd 3.0 发布，高可用 Key/Value 存储系统
etcd v2.3.2 发布，高可用 Key/Value 存储系统
CoreOS 发布 etcd v2.3.0，重点提升稳定性和可靠性
etcd 2.2 发布，高可用 Key/Value 存储系统
etcd 2.1 发布，高可用 Key/Value 存储系统
etcd 2.0 发布，官方首个主要稳定版