etcd，或者，为什么现代软件让我难过？

在2013年的某个时候，有一款名为etcd的工具，它是围绕RAFT共识算法编写的一个非常轻量级的数据库。这个工具最初是在2013年为一个叫CoreOS Container Linux的垃圾项目编写的，这个项目在几年前是EOL'；D，但那并不重要--etcd比它最初的用例更重要。Etcd提供了一组方便而简单的原语(设置密钥、获取密钥、仅在未更改的情况下设置、监视更改)，上面有一个简单的HTTP API。我已经使用etcd构建了许多工具，将其作为它们背后的一个轻量级共识存储库，使用它绝对是一件令人愉快的事情。

2015年，谷歌(Google)发布了一个名为Kubernetes的无关工具(但实际上是由Xoogler发布的)。我甚至可以说，Kubernetes(或者，就像酷孩子们说的，K8)是自systemd以来发生在系统管理方面最糟糕的事情。它是一个全面的套件，承诺简化软件集群的操作，并提供类似于谷歌博格集群管理器的体验。它真正做的是：

将您从编写可移植软件配置转移到编写数千行特定于K8s的YAML。

如果您正在运行一个真正庞大的系统，并且希望有现成的编排，那么Kubernetes可能是您的工具。对于99.9%的人来说，这只是一层额外的复杂性，几乎没有增加任何价值。

不过，我离题了；这是一个关于etcd的故事。不幸的是，我们的故事走到了一起，因为Kubernetes很快被更改为使用etcd作为其状态存储。这样就开始了etcd的快速下降。

随着Kubernetes用户的大量涌入，当然，大量Xoogler决定用谷歌技术感染etcd，这是他们的方式2 3。etcd的简单HTTP API被GRPC 4版本取代，简单的内部数据模型被密集的、非正交的数据模型取代，这些数据模型具有不同类型的租赁、锁定、交易和普通密钥。ETCD3.2通过gRPCGateway重新添加了HTTP API的一小部分，但还不足以实现构建在原始API之上的任何丰富的应用程序。v2API目前还存在，但是上游威胁要在每一个新版本中移除它，而且总有一天它会被完全移除。

就是这样。这就是故事的来龙去脉。流行的现代技术被一家大公司的外籍人士接管，而在高度专业化(和纯粹过度炒作)的编排平台的服务下，情况变得更糟。这就是当今的世界。任何简单而优雅的功能设置最终都会被那些只想构建庞大而笨拙的体系结构，并结束继承来自任何巨型公司的功能的人所吸引。软件开发界更愿意使用运行在ElectronJS上的数十亿字节IDE来构建千依赖Java应用程序，目标是在难以操作的系统上针对笨拙的API，而不是支持更简单、更好的东西。唉，质量是一门垂死的艺术。

在我的职业生涯中，我和很多Xoogler一起工作过(见鬼，我自己也在那里工作过)。我现在认为这对曾在谷歌工作的人的简历是一个严重的负面影响。我的许多前谷歌同事都比他们年轻得多的同胞在非谷歌系统上工作的能力要差得多。所有的大公司都有自己的专有技术堆栈，但谷歌员工在不涉及协议缓冲区、Bigtable和一英里高的其他专有工具堆栈的情况下，从未学会如何做任何事情的程度是不同寻常的。他们把这一点传播到他们接触到的每一件新事物上。任何开源项目都不可避免地会收到从JSON或BSON切换到协议缓冲区的Pull请求；现在每个Web服务器都需要支持在嘲弄ietf过程中传递的有害用户的协议：http/2 6和http/3 8。-↩

是的，我知道，GRPC是由该项目的原始作者李翔添加到etcd中的。这并不意味着他们受到了来自山景城的糟糕想法的影响，也没有受到他们的项目在Xoogler的土地上新获得的人气的影响。-↩。

GRPC是运行在HTTP/2 6上的协议缓冲区5。它的名字开头有一个字母，用来提醒你，只有当你在谷歌所有的大楼里吃着谷歌品牌的食物，呼吸着谷歌品牌的空气时，它才是可以接受的。。(注：↩。--译注：GRPC是一种基于HTTP6的协议缓冲器5。它的名字开头有一个字母)，提醒你，只有当你在谷歌所有的大楼里吃谷歌品牌的食物，呼吸谷歌品牌的空气时，它才是可以接受的。-GRPC。

HTTP/2(又名：HTTP/2)。SPDY是一个夸张得可笑的第4/5/7层百万组合协议，旨在取代HTTP。它需要一些简单的东西(最重要的是！)。对于初级程序员来说，它是可理解和可调试的，取而代之的是一个极其复杂的7系统，该系统需要数万行代码才能实现最小版本的，但一旦达到每秒处理数百万个请求的程度，就会略微减少页面加载时间和服务器成本。一想到我们是如何把互联网的一个基本部分，简单到任何人都可以实现的超文本传输协议服务器，替换成这个由大型公司推动的垃圾协议，我就怒不可遏。这个协议不能解决任何真正的问题，但会完全切断未来几代人对网络系统编程的依赖。--↩↩。

我最喜欢的HTTP/2交互就是在haproxy中找到并报告这个bug。Http/2中的压缩方案太差劲了，以至于RFC7541§AA中的压缩表只是来自谷歌属性的61个最受欢迎的头的列表。/↩。

HTTP/3是HTTP/2的所有缺点，但是运行在一个更糟糕的名为Quic的第3层协议上，它完全破坏了每个人的网络，以便为Google获得稍微多一点的优化。这就是它的全部功能。严格来说，它使互联网对每个人都更糟糕，但对最庞大的网络资产略有改善。在现实的互联网中，没有人会对来自tcp的队头拦截有丝毫的顾虑，很多人都希望tcp状态感知防火墙和负载均衡器能够工作。-↩。

我说了很多关于谷歌的狗屎，但脸书和微软在培养大批前员工方面几乎一样糟糕，他们不能把键盘单独留在房间里，以免他们试图重现前雇主的技术堆栈，效果很差。--↩