最新发布《数智时代的AI人才粮仓模型解读白皮书(2024版)》,立即领取! 了解详情
写点什么

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

作者:W. Watson

  • 2023-02-28
    北京
  • 本文字数:9672 字

    阅读完需:约 32 分钟

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

自下而上 vs. 自上而下


当一个自下而上驱动的生态系统与一个以自上而下开发为特征的社区相遇时,会发生什么?第三代合作伙伴项目(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 许可,采纳、扩展和废除的难度会更大。

 

API、接口和标准是社区的通信方式


之前,我们已经讨论过,自下而上的社区是由一些项目组成的,这些项目通过一种通用模式语言相互通信。这些模式的性质是什么,它们是如何实现的?云原生模式(如调和器模式)实现为接口通过开源库暴露出来。流行的上游/生产者项目和下游/消费者项目之间的接口会激励存在竞争关系的生产者项目对已成为公共接口的粗糙的事实标准进行“标准化”。也就是说,如果受到鼓励,那么最好的接口应该就会从上游生产者项目的多种实现中出现。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 认证计划的信息(可以验证你的网络功能中的云原生最佳实践),请参阅这里

 

尾注


1. ​”美国国税局昨天承认,他们已经花费了40亿美元开发现代计算机系统,而一位高级官员表示,‘那在现实世界中不起作用’,并提议将个人提交的纸质报税单通过外包的方式进行处理。

2. “在其著作《创新民主化》中,麻省理工学院管理学教授 Eric Von Hippel 从理论和实证两个方面证明,相当一部分创新实际上是由用户而不是制造商完成的。此外,他发现,特定类型的用户(最先使用的用户)最有可能进行创新,他们的创新更有可能对更多的用户产生吸引力”。Sasha Costanza-Chock,《设计的正义》(信息政策)(第 111 页),麻省理工学院出版社,Kindle 版。

3. 《建筑的永恒之道》描述了城镇和建筑物建造任务的基本性质。书中指出,城镇和建筑物将不会变得有生命力,除非它们是由社会上所有人建造的,除非这些人建造这些建筑时共用同一种模式语言,除非这种共用的模式语言本身就是有生命力的。克里斯托弗·亚历山大,《模式语言》(环境结构中心系列)(第 ix 页),牛津大学出版社,Kindle 版。

4. “人类在中世纪城市中所采取的这种新的行动,其成就是巨大的。在十一世纪初,欧洲的城镇还是一小群一小群的可怜茅屋,其间只点缀着一些低矮简陋的教堂,而修建教堂的人也几乎不知道怎样修造拱廊。工艺也很幼稚,大部分是纺织和铸造器皿;学术只能在很少数的寺院才可找到。三百五十年后,欧洲的面目改变了。陆地上星罗棋布地到处是富庶的城市,城的四周围绕着有碉楼和城门的巨大而厚实的墙垣,每一个碉楼和城门的本身就是一件艺术品,它们使得城墙十分壮丽。大教堂的样式雄伟,装饰华丽,它们的钟楼高耸入云,表现了庄严肃穆的气派和我们现在望尘莫及的大胆想象力。”彼得·克鲁泡特金,《互助论:进化的一个要素》(注释版)(克鲁泡特金文集第二卷)(第 114 页),Affordable Classics Limited,Kindle 版。

5. “一座教堂或公共大厦,象征着一个宏伟的有机体,每一个泥水匠和石匠就是这个有机体的建造者,中世纪的建筑看来不是千万的奴隶按照一个人的想象力的支配、各自听命而完成的孤独的个人杰作;所有城市中的人对它都有贡献。”彼得·克鲁泡特金,《互助论:进化的一个要素》(注释版)(克鲁泡特金文集第二卷)(第 115 页),Affordable Classics Limited,Kindle 版。

6. “典型的资本主义公司采用的是金字塔结构,因此,资源(时间、精力、信贷、金钱)都是从下往上流动。这也是大多数设计公司的情况。极端情况下,在大型跨国设计企业中,成果(概念、草图、原型)出自大量收入微薄的下层劳动者,而利益(金钱、归属、版权和专利)则向上流入上层少数高知名度的专业设计师手中。”Sasha Costanza-Chock,《设计的正义》(信息政策)(第 113 页),麻省理工学院出版社,Kindle 版。

7. “当人们谈论‘注意力经济’时,他们通常指的是消费者的有限注意力,因为会有多个应用争夺用户的时间。但生产者的有限注意力也同样需要考虑。”Nadia Eghbal,《在公共场所工作:开源软件的开发和维护》(第 214 页),Stripe 出版社,Kindle 版。

8. ”然而,源码开放的产品更像是一种公共资源——也就是说,它是非排他性和竞争性的——其中,注意力就是竞争性资源。维护者不能决定用户付出多少注意力,而他们的注意力可能会耗尽。“ Nadia Eghbal,《在公共场所工作:开源软件的开发和维护》(第 161-162 页),Stripe 出版社,Kindle 版。

9. ”......最终决策权和职责(即所有权)集中在中央规划委员会手中。“《战略、经济组织和知识经济》,Nicolai J Foss,第 174 页。

10. “首先,由于经理们常常被规划当局否决,所以他们不太可能把眼光放长远,特别是在投资决策中。其次,由于经理们不是最终的所有者,他们不是其决策的全额剩余索取者,因此,他们不会做出高效的决策。......问题产源于这样一个事实,即统治者很难做到不干预政策。”《战略、经济组织和知识经济》,Nicolai J Foss,第 175 页。

11. ”自下而上的编程方法意味着要把软件分成好几层,每一层都可以充当它上面那一层的开发语言。这种方法会产生的程序往往更小更灵活,这也是通往软件圣杯——可重用性——的最佳路线。从定义上看,语言是可重用的。在编程语言的帮助下,应用程序越是采用这种多层形式开发,它的可重用性就越好。“ Paul Graham,《黑客与画家》(Kindle Locations 2563-2566),O'Reilly Media,Kindle 版。

12.  ”Ada 标准于 1983 年 2 月 17 日获得批准。当时,它已成为 ANSI/MIL-STD 1815A-1983。随后,它又成为国际标准组织(ISO)的一项标准。该标准由一个国际委员会负责解释,而该委员会最初由美国国防部主持,称为语言维护委员会,但现在属于 ISO 的管辖范围,称为 Ada 报告员小组。“ Nelson Weiderman,《ADA 83 和 C++比较》。

13. “为了使 Ada 成为一个真实而非空洞的标准,人们已经付出了很高的代价。自 1980 年发布标准草案以来的 11 年间,为了实施这项技术,人们已经做了大量的工作。“ Nelson Weiderman,《ADA 83 和 C++比较》。

14. ”公法 101-511 第 8092 条规定,‘即使有任何其他法律规定,在 1991 年 6 月 1 日之后,只要具有成本效益,国防部的所有软件都应以 Ada 编程语言编写,除非有国防部长指定的官员特别豁免’。“ Nelson Weiderman,《ADA 83 和 C++比较》。

15. “像 C++这样的商业事实标准,其优势在于广泛的知名度和接受度。市场迅速发展,确保了 C++能与其他软件系统协同工作。在这方面,C++领先于 Ada。在工具基础设施和培训的方面已经有了很多商业投资。“ Nelson Weiderman,《ADA 83 和 C++比较》。

16. ”早期的 Web 架构以 SOLID 原则为基础,即关注点分离、简单性和通用性,但缺乏架构描述和理论说明。该设计是基于一套非正式的超文注释、两篇面向用户社区的早期论文,以及 Web 开发者社区邮件列表(www-talk@info.cern.ch)上的讨论档案。然而实际上,对于早期 Web 架构的唯一真实描述来自 libwww 实现(欧洲核子研究中心用于客户端和服务器的协议库)、Mosaic(NCSA 的浏览器客户端)以及与它们互操作的其他各种实现。“ Roy Thomas Fielding (2000),《架构风格和基于网络的软件架构设计》,第 90 页。

17.  ”这种语言的元素是称为模式的实体。每个模式都描述了一个在我们的环境中反复出现的问题,并描述了解决这个问题的核心,如此一来,你就可以无数次地使用这个解决方案,而不用以同样的方式做两次。“ 克里斯托弗·亚历山大,《模式语言》(环境结构中心系列)(第 x 页),牛津大学出版社,Kindle 版。

18. ”声明式配置与命令式配置不同,对于后者,你只需执行一系列动作(例如,apt-get install foo)来改变环境。多年的生产经验告诉我们,保持系统所需状态的书面记录可以使系统更容易管理、更可靠。声明式配置有许多优点,包括可以对配置做代码审查,以及为分布式团队记录环境的当前状态。此外,它还是 Kubernetes 所有自我修复行为的基础,这些行为可以保持应用程序的运行而无需用户操作。“ Brendan Burns ,Joe Beda ,Kelsey Hightower ,Kubernetes: Up and Running: Dive into the Future of Infrastructure(Kindle Locations 892-896),Kindle 版。

19. ”惯例即协议——但我们是否曾一致同意在使用语言时遵守既定的规则?我们没有。如果前人这样做了,这与我们这些已经忘记的人又有什么关系呢?在任何情况下,语言惯例不可能源于协议,因为它们中有一些是为了提供最基本的语言,而第一份协议就是用这种语言达成的。“ 大卫·刘易斯,《惯例:一项哲学层面的研究》(Kindle Locations 58-61),Kindle 版。

20. ”因为 DNS 系统的结构像一棵倒置树,树上的每个分支都对它下面的一切拥有绝对的控制权。“ Alexander R Galloway,Protocol(Leonardo)(Kindle Locations 540-541),麻省理工学院出版社,Kindle 版。

21.  ”一方面,TCP/IP(传输控制协议/互联网协议)使互联网能够实现从一台计算机到另一台计算机的横向信息分发。另一方面,DNS(域名系统)通过一系列管理互联网地址和名称的监管机构,垂直划分那种水平逻辑。理解互联网中的这两种动态,就意味着理解权力对社会的控制方式中存在的基本矛盾。“ Alexander R Galloway,Protocol(Leonardo)(Kindle Locations 189-193),麻省理工学院出版社,Kindle 版。

22. “分布式网络是德勒兹控制社会的产物。分布式网络中的每个点既不是中央枢纽,也不是卫星节点——既没有主干,也没有叶子。网络只包含‘智能端点系统,它们都是自决的,每个终端系统都可以与它选择的任何主机进行通信’。像根茎一样,分布式网络中的每个节点都可以与另一个节点直接建立通信,而不必求助于层级中介。“ Alexander R Galloway,Protocol(Leonardo)(Kindle Locations 581-585),麻省理工学院出版社,Kindle 版。

23. “遇到颠簸时,司机就会希望开得慢点。遇到颠簸时,开慢车就成了一种美德。但在警察在场的情况下,开慢车通常是被迫的行为。因此,标识牌吸引人们的注意力,而协议总是吸引人们的身体。协议不是一个超我(像警察一样);相反,它总是在欲望的层面上运行,在‘我们想要什么’的层面上。“ Alexander R Galloway,Protocol(Leonardo)(Kindle Locations 4880-4884),麻省理工学院出版社,Kindle 版。

 

原文链接:https://www.infoq.com/articles/cloud-native-telecom-standards/


相关阅读:

微服务进入深水区后该何去何从

谷歌发布云基础设施可靠性指南,帮助消费者做出正确决策

从用云焦虑到“深度云化”,新云原生时代带给我们哪些思考?

2023-02-28 08:002720

评论

发布
暂无评论
发现更多内容

ChatGPT大面积封号+停止注册?最火概念要凉?

这我可不懂

低代码 源代码 ChatGPT

openGauss 5.0.0版本正式发布!

openGauss

前端开发培训机构怎么样

小谷哥

云和恩墨大讲堂 x 长江鲲鹏 x openGauss Meetup(武汉站)圆满落幕!

openGauss

除了价格降70%,关于对象存储预留空间你还需要了解这些

云布道师

云存储

慌了?ChatGPT吃我的饭,还要掀我碗

引迈信息

AI 低代码 ChatGPT JNPF

vue3 +ts 如何安装封装axios

肥晨

Vue3 三周年连更

别再吐槽公厕了!杭州智慧公厕解决方案带来惊喜

光明源智慧厕所

智慧城市

大数据学习培训机构该怎么去选择

小谷哥

一文读懂域名注册

火山引擎边缘云

证书 域名 域名服务器

devops|中小公司不要做研发效能度量

laofo

DevOps 研发效能 效能度量 DevOps工具链 研发效能度量

加速文件传输协议如何工作

镭速

盘点 8 款好用的 API 接口文档管理工具

Liam

程序员 接口文档 API 接口规范 接口编写

一文读懂Annotation

老周聊架构

三周年连更

华中科技大学网络空间安全学院正式加入openGauss社区

openGauss

openGauss都做了哪些算子优化工作?

openGauss

软件测试/测试开发丨基于 JMeter 完成 Dubbo 接口的测试

测试人

dubbo 软件测试 Jmeter 自动化测试 测试开发

MobTech ShareSDK|如何从分享到回流

MobTech袤博科技

不会吧?该不会还有企业没实现员工赋能吧!绝对是你没选低代码的问题!

加入高科技仿生人

知识管理 低代码 系统开发 员工赋能

openGauss社区三月运作报告

openGauss

全球首个完全开源的指令跟随大模型;T5到GPT-4最全盘点

OneFlow

达观助手AI写作下载安装教程及特色功能详解,速速收藏体验!

NLP资深玩家

江苏智慧公厕:让厕所成为城市新名片

光明源智慧厕所

智慧园区

云原生时代全链路观测体系构建

嘉为蓝鲸

Node.js实现JWT应用到服务器

格斗家不爱在外太空沉思

node.js 三周年连更

DevOps系列之 —— 持续规划与设计(三)敏捷项目管理的方法【Kanban 与 Scrum】

若尘

DevOps #DevOps 三周年连更

车企外卷:一个关于智能手机的“围城故事”

脑极体

手机 车企

REST API 设计规范:最佳实践和示例

Apifox

程序员 协议 API 接口开发 REST API

便捷高效,Notion AI比ChatGPT更加香!

南城FE

人工智能 AI 前端 ChatGPT

openGauss社区用户委员会工作会议顺利召开

openGauss

HuggingGPT 强势来袭,LLM+ 专家模型,迈向更通用的AI

Zilliz

Zilliz Towhee ChatGPT LLM huggingface

云原生如何改变电信标准:自上而下与自下而上的对决_服务革新_InfoQ精选文章