etcd 是一个使用 raft 一致算法的 KV 数据库，产生于 2013 年。最早是为 CoreOS 开发的，但本文不关心这个烂货，它已经完蛋了。本文的主角，它的副产物 etcd 使用更广泛。etcd 提供了简洁的 HTTP API, 多年以来，我已经使用 etcd 开发了多个工具。

2015 年的时候，又诞生了另外一个与之没有关系的 Kubernetes 项目，很多人称它为 k8s. 在我看来，这是继 systemd 之后系统管理领域的最大灾难。它号称要简化集群管理，为大众带来 Google borg 集群管理软件的体验。但实际上：

1. 为你的软件添加了几百种出错的模式。
2. 把编写可移植的软件配置变成 k8s 专有的 YAML 配置文件。
3. 让你陷入容器化和软件定义网络这些可疑的设计模式里面。

如果真运行的是一个真正复杂的系统，那 k8s 可能是适合你的工具。但对 99.9% 的人来说，k8s 除了增加额外的复杂度，并没有带来真正的价值。

今天想讲的是 etcd，离题了对吗？很不幸的是，两个软件产生了联系。k8s 很快地决定用 etcd 作为它的状态存储，开始了 etcd 的快速堕落。

随着大量 k8s 用户的影响，一群 Xooglers[1] 决定给 etcd 带来 Google 的技术，正如它们以前经常干的。etcd 的简单HTTP API 被 gRPC 所代替[2]，简单内部数据结构被租约、锁、事务等大量非正交的数据模型所代替。etcd 3.2 又在 gRPC 网关之上加回了 HTTP API, 但只实现了最初版本的小部分功能，不足以支撑以前基于原始 API 编写的应用。v2 API 一直存活至今天，但上游总是威胁要在新版本里面删除这个 API. 估计早晚有一天真的会完全删除它。

这就是今天要讲的故事。现代流行软件总是被来自于大公司的“专家”所控制，极端优化各种特殊场景。这就是今天的世界。小而优雅的软件被那些想要建造大而笨拙软件的“专家”所终结，加上各种大公司所需要的特性集。软件开发者使用几个 G 大的 ElectronJS 开发上千个依赖的 JAVA 程序，调用难以操作的系统上各种笨拙的 API.  不愿意使用更简洁和更好的平台，软件质量，已经是正在死亡的艺术。

[1] 这个 Xooglers 是什么意思？Google 的前员工？还是一家公司的名字？译者问。
[2] gRPC 是被项目的最初作者 Xiang Li 所加入的。但这并不能说明这不是来自于山景城的坏主意，或者没有受到这些 Xooglers 项目的影响。

https://www.roguelazer.com/2020/07/etcd-or-why-modern-software-makes-me-sad/
--
FROM 112.47.122.*