云原生如何改变电信标准：自上而下与自下而上的对决

当一个自下而上驱动的生态系统与一个以自上而下开发为特征的社区相遇时，会发生什么？第三代合作伙伴项目（3GPP）的 5G 宽带蜂窝网络标准、欧洲电信标准协会（ETSI）的网络功能虚拟化（NFV）标准以及互联网工程任务组（IETF）的服务功能链 RFC（征求意见稿）都是电信界创建标准的例子。通常，这些标准的制定都是采用了一种粗放的、自上而下的方式，详细定义了一些关系密切的互补的特性。云原生社区采用了自下而上的方式，从生态系统的需求出发，并经由细粒度的实现所证明后产生规范。OpenMetrics 标准就是这方面的一个例子，它产生于可观察性和 Prometheus 云原生社区。这种标准开发的反差使得将所期望的可用性、弹性、可扩展性和互操作性等云原生特性整合到电信标准中变得非常困难。

敏捷开发取代大量前期设计（也称为瀑布法）的其中一个主要原因是，在敏捷中，客户与实现者之间有一个更紧密的反馈循环。实现驱动的反馈回路可以将交付物更早地暴露在客户面前，因此可以更快地进行调整。

像政府改写^[1] 这样昂贵的的大型项目已经慢慢被敏捷方法所取代，但这是否影响了我们开发标准的方式？

有两种类型的标准设计：自上而下和自下而上。从历史上看，标准机构是由来自学术界、工业界和企业界的人士组成。然后，行业对标准的采用取决于对标准有贡献的主要参与者的支持、标准的营销以及标准本身的有效性。在这种模式下，对标准的控制是自上而下的。

有机孳生的软件标准产生于社区所采用的代码库。这些代码库需要可互换（通过库）、可互操作（通过 API）或便于通信（通过协议），它们的开发、审查和采用都是公开的，这也是它们的优势所在。

无论是自上而下还是自下而上，对于标准而言，除了有效性之外，另一个最重要的事情就是控制权在哪里。在这种模式下，标准的控制权根据用户的采用情况和分叉威胁自下而上地流动。在自下而上的模式中，生态系统有最后的决定权。这并不是说，自下而上的控制不会过度。实际上，自下而上的控制可以比自上而下的更强大，我们将在后面讨论。

通常，电信协议和标准是自上而下的，由 3GPP、ETSI 和 IETF 等标准机构制定。云原生标准是自下而上的，产生于诸如可观察性社区这样的子社区。

自上而下和自下而上的设计或控制的区别很多地方都有描述。其中一个地方就是敏捷方法论中的拉动法和推动法。在推动法中，任务是自上而下分配的，从项目经理到实现者。在拉动法中，任务由团队创建并确定优先级后放入一个队列，然后实现者从队列中选择任务。另一个值得注意的事实是，设计研究人员认为，用户设计的很大一部分是自下而上的^[2] 。Christopher Alexandre（就是其思想成为软件模式运动基础的那位建筑师）也指出，实现者经常选择架构（例如，农民建造谷仓），而建筑师只是提供便利^[3]。这些建筑师通过提供模式语言来提供最好的帮助。Peter Kropotkin 有一个更有说服力的建筑学观点，他说，欧洲城市的伟大技艺^[4] 并不是通过“正式的建筑设计委托”单独完成的[5] ，而是在行会的相互竞争中发展起来的，他将这个论点作为互助过程的一个示例。

CNCF 技术监督委员会（TOC）的原则可以避免挑选赢家和输家，即：

没有造王者。类似或竞争性的项目不会因为存在重叠而被排除在外。

没有造王者的环境允许竞争性的解决方案和实现存在，而不管供应商的政治影响力如何。这是因为对供应商的偏袒会扼杀创新，特别是在开源社区。虽然在传统商业世界里，创造进入壁垒被认为是一种好的做法，但在开源社区，进入壁垒是不受欢迎的。开源社区反映的是思想的市场，每个想法都应该在一个公平的竞争环境中得到公平的机会。

公平性也是标准设计的一部分。在《设计的正义》一书中，Sasha Costanza-Chock 揭示了设计功劳的归属在自上而下的等级制度中如何被错误地认定^[6]。归属是开源工作的一个重要的激励因素[7] 。归属和注意力的错误认定会对开源社区造成破坏^[8] 。由于注意力和归属都是竞争性资源（即将资源分配给一个人时，另一个人就会被排除在外），所以无故对这种资源进行重新分配不利于创新。在市场环境中，重新分配公开开发的资源会被视为玩弄市场^[9]，事实已经证明，那对创新的影响是消极的^[10]。

CNCF TOC 的一个立场是，不应该有架构师受托在开源社区的领导下开发杰出的标准。社区的强大之处在于，它不是集中规划的，而是以项目为中心的：

我们是以项目为中心的。原则：如果它可以放在现代公共源码控制系统上，那么它就能成为一个项目。我们把项目放在最重要的位置。

因此，项目开发人员是他们推动解决云原生问题的实现模式的教育者。

有一种观点认为，编程语言是最容易被重用的软件[11]。如果是这样的话，编程语言的设计就是所有软件的基础，因此其设计可能颇具启发性。

编程语言 Ada 是受美国国防部自上而下的委托^[12] 开发出来并成为国际标准的。Ada 是一个标准制定 11 年后^[13] 造王者法令（国防部）才开始生效[14] 的例子。可以将其与另一种通用语言 C++ 做个比较，后者出现的比较晚，虽然是商业性的，但发展得更加有机，并在流行程度上超过了 Ada。最初，C++ 更多的是一个事实上的标准^[15]，而不是像 Ada 那样是一个法律上的标准。有趣的是，这两种语言都在努力夺取主流面向对象语言的王冠。C++ 更早地实现了面向对象，但并不符合 ISO 标准。Ada 在 1995 年成为第一个国际标准化的面向对象语言。尽管如此，C++ 在那时已经获得了如此多的商业应用，以至于它实际上已经赢得了王冠之争，即使 Ada 的造王者法令发布在五年前。

20 世纪 90 年代出现了基于开源实现的语言。在采用这些语言时，其中一个主要的区别是，解释器或编译器是开源的，而实现（通常由创始人构建）被用作标准。评价其他实现时都是和原始实现进行比较。根据实现情况，可以在各自的语言社区内与语言的创始人就事实上的标准进行辩论，但有一个关键的区别：社区现在可以生成源代码的分叉，并对仁慈的独裁者的决定提供可信的威胁。

HTTP 的发展是另一个代码实现驱动标准的例子。Web 服务器 Apache 和 Netscape 的代码被传来传去，这样，HTTP 的行为就可以在不同的开发者之间共享^[16]。HTTP 1.0 的架构与其他 Web 架构相结合，可以说是世界上最大的分布式应用，而它直到 1996 年才被标准化。

我们可以从自下而上、社区驱动的开放实现中得出什么？首先，开源实现不是专利驱动的。每个人都能够使用、修改和贡献代码，也只有这样，它才能受社区的影响和驱动。第二，尽早采用胜过标准编纂。在标准广泛成功应用的早期阶段，代码传递是主要的沟通形式。

当我们考虑云原生实现原则、事实标准和模式时，我们应该描述一下模式到底是什么。首先，事件或重复性活动是模式的驱动因素。事件，当进行治理或提供处理便利时，就为用户驯化了一个环境。这样一来，一个模式就是一系列反复出现的提供便利的步骤。这适用于物理和数字架构。多种模式，或为处理重复性事件提供便利的方法，可以是一种相互联系的通用模式语言的一部分[17]。

在云原生架构中，重复性事件的一个例子是一个部署中众多节点和容器的大量日志。一种为处理这些日志提供便利的方法是将它们视为事件流。将日志数据路由到标准输出，让执行环境中的工具捕获它们，并以此作为一种最佳实践。这种行为是一种云原生模式，一种最佳实践，并被云原生社区所接受，不管是否有标准机构将这种实践编纂成条款。在云原生社区的项目中实现这种模式就足够了。云原生模式不是自上而下的法令，而是社区讨论中的一种首选通信形式。

将云原生社区的接口实现描述为一种通用语言是有帮助的，因为自然语言是自下而上驱动的。我们后面还会讨论这个问题。

在始于 90 年代末延续至 2000 年的浏览器大战中，闭源的 IE 浏览器与多个开源 HTML 浏览器展开了竞争，包括 Firefox、Safari、Chrome 和 Opera（2013 年转为基于 Chromium）。激烈的竞争催生了以专有扩展形式出现的差异化，一再产生 HTML 标准和浏览器世界分化的危险。事实证明，重用库中实现的开放标准，如 Safari 和 Chrome 使用的 WebKit 渲染引擎，是浏览器实现中的一个卓越策略。到 2020 年，甚至微软的新浏览器 Edge 也是基于 Chromium 的开源引擎。

由于开放实现和标准可以免费使用，所以便于推广使用，产生网络效应。这可能是采用开放实现和标准的最实际的理由。

因为开放，所以就会有更多的人，不仅评判标准的设计，还评判标准的实现。这就为源于代码库的标准带上了合法性的光环。人们可以看到标准是如何实现的，所以它似乎因此得到了更彻底的检验。此外，当标准公开实现时，例如 Apache、BSD 或 GPL 许可，采纳、扩展和废除的难度会更大。

之前，我们已经讨论过，自下而上的社区是由一些项目组成的，这些项目通过一种通用模式语言相互通信。这些模式的性质是什么，它们是如何实现的？云原生模式（如调和器模式）实现为接口通过开源库暴露出来。流行的上游 / 生产者项目和下游 / 消费者项目之间的接口会激励存在竞争关系的生产者项目对已成为公共接口的粗糙的事实标准进行“标准化”。也就是说，如果受到鼓励，那么最好的接口应该就会从上游生产者项目的多种实现中出现。CNCF TOC 是这样说的：

不鼓励单一技术栈。我们鼓励多种技术栈和模式以及它们之间的互操作性，为社区和采用者提供服务。

接口的实现由社区在会议上提出。这对于人们参与项目开发是一种鼓励。在这里，Eric S. Raymond 的名言“只要眼睛够多，所有的 Bug 都会被发现”再次得到了验证。

有一点需要注意的是，接口仍然可以采取控制的形式，但那要么太慢，无法满足用户的需求，要么控制太强，扼杀了竞争。这就是 CNCF TOC 要避开由标准机构制定的、成文的硬性标准的原因：

原则：促成供现实世界使用的接口和事实上的实现，而不是标准... 我们希望由市场和用户推动互操作，而不是委员会。我们希望可以帮助加速现实世界的使用，并促进合作。我们不希望成为委员会的门控。

标准文档仍然可以作为生产者之间或生产者与消费者之间的通信形式，甚至可以采用 RFC 的形式。尽管如此，在项目之外，这种文档并没有得到正式的认可：

举例来说，CNCF 可以按当前 CNI 接口文档或 IETF RFC 的风格来开发书面材料。这些 CNCF “规范 ”资料不是“标准”。[将来可能有] 一个独立的、公认的国际标准机构将 CNCF 的文档作为“上游”，并通过（例如）IETF 程序将其演变成标准。CNCF 会在道义上支持独立的第三方这样做，但并不认为这项工作是它自己的职责。

以下是一些粗糙的事实上的实现的例子：CNI（网络）、CSI（存储）、CRI（运行时）、OpenMetrics 和 CLI（日志）。

最后，在云原生社区中，调和模式被看作是基础设施与托管在该基础设施上的应用程序进行通信的一种方式。如果项目支持应用程序的基础设施，那么极其重要的一点是，到那个项目的接口要支持声明式配置，而不是可以达到正确状态的指令性步骤。这支持通信，因为声明式配置更容易推理。[20]

Robert Chisholm 指出了一个在试图创建一套规则时遇到的问题。这个问题是，你需要另一套规则来判断这些规则的有效性、有用性以及它们产出成果和事实真相的能力。这就引发了无限倒退（infinite regress），也就是所谓的标准问题。

在讨论标准时，我们必须决定自上而下的制定规则是否比自下而上的更可取。纯从实用主义的角度来看，如果你希望得到支持，那么自下而上的制定方式就会胜出。一些最难的、看似难以解决的问题已经通过自下而上的方法得到了解决。Elinor Olstrom 发现，最长久的制度（定义为一套规则）已经有 500 多年的历史，那是自下而上产生的，没有集中的规划者。在《惯例》一书中，David Lewis 提出，语言的发展是自下而上的，基于一个名为聚点（focal points）的博弈论概念，而不是由任何委员会决定的[19]。另一方面，如果乍一看控制是主要标准，那么自上而下的规则制定似乎就会胜出，但即便如此也可能不是这样。

自上而下的标准制定更倾向于命令和控制，分散的权力结构让人想起 Melvin Conway 在其论文 “How do committees invent”中所谈到的内容。他说软件的结构是按照开发它的组织的结构构造的，运用到我们这里讨论的主题，可以说标准机构更倾向于按照它的权力结构的组织方式来制定标准。DNS 就是一个完美的例子。DNS 的结构是去中心化的[20]，就像创建它的自上而下的机构。DNS 的权力构建在一个服务器的层次结构中，每台服务器的权力都比较小，从这个意义上说，它是去中心化的。相比之下，像 TCP-IP 这样的分布式标准则没有控制中心^[21]。康威说，鉴于所有的大型组织都有子组织，而这些子组织之间会有通信接口。这些子组织的职责受到母组织的制约。这些接口和约束是进行架构选择的首选位置，不仅在软件中如此，在母组织的任何工件中皆是如此。由于标准机构的工件是协议和规范，子组织受到的约束和它本身的利益将主导协议内权力实现方式的设计。鉴于对组织的这种看法和对控制的渴望，自上而下的设计似乎容易实现闭源的标准（权力掌握在一名实现者的手中），而自下而上的设计则倾向于开放的标准（权力掌握在有能力生成分叉的人手中）。另外，即使是开放，相比于 TCP-IP 这种分布式标准 [22]，自上而下的标准机构似乎还是更喜欢像 DNS 这样的去中心化标准（如果去中心化的节点代表了标准机构的利益）。鉴于康威定律的这一延伸，自下而上、实现驱动的工作所具有的组织结构是这两种结构中更有可能产生分布式控制协议和规范的。

对于那些渴望拥有更多控制权的人来说，分布式标准有一个违反直觉的事实是，控制水平实际上是提高了的，因为每个节点都完全接受了标准的权力结构。这就是为什么像 OpenMetrics 这样的自下而上的标准的出现是如此的具有颠覆性。在这里，标准的合法性得到更多的认可。使用自下而上的标准，可以加强对标准和标准所产生的东西（通常是分布式实现）的控制。自下而上的标准就像减速带。社区采用这些标准是因为他们认为采用这些标准符合他们自己的利益，就像司机看到减速带时放慢速度符合自己的利益，而不是符合立法者的利益。[23]

我们描述了云原生、自下而上开发原则、最佳实践和事实标准的逻辑。我们也描述了自上而下的、由委员会驱动的标准，如电信行业的标准。自上而下和自下而上的标准制定这两个世界是否会中途相遇？当协议的管理者与云原生标准相遇时会发生什么？可能会出现由技术监督委员会、特殊利益集团和工作小组组成的治理机构。它看起来可能会像 Web 架构的出现，在标准机构编纂标准之前就已经实施了多年。

要了解更多关于云原生原则的信息，请加入CNCF 云原生网络功能工作小组。要了解有关 CNCF CNF 认证计划的信息（可以验证你的网络功能中的云原生最佳实践），请参阅这里。