非理性繁荣!

我最喜欢的一些技术论文。

4月7日,2018。根据基础设施软件工程

我一直是它的粉丝举办读书会,一群人坐下来讨论有趣的技术论文。第一步就是找出一些值得讨论的论文,下面是一些我看过的论文的列表,这些论文将带来精彩的讨论!

Dynamo:Amazon的高可用性密钥价值商店

只看摘要,你不必对发电机论文过于兴奋,这是可以原谅的:本文介绍了发电机的设计和实现,一个高度可用的关键价值存储系统,一些亚马逊的核心服务使用它来提供一个永远在线的体验。为了达到这一可用性水平,在某些故障情况下,Dynamo会牺牲一致性。它广泛地使用了对象版本控制和应用程序辅助的冲突解决方法,为开发人员提供了一个可以使用的新接口。

也就是说,从某种意义上说,这就是经典的现代系统纸。不止一次,我遇到的工程师在他们的职业生涯中只读过一篇系统论文,那张纸就是发电机纸。本文是对最终一致性的一个显著介绍,跨分布式存储协调状态,当数据在多个副本或更多副本之间发散时,协调数据。

计算机系统设计提示

巴特勒兰普森是ACM转弯奖获得者(除其他奖项外)在施乐公司工作。本文简要总结了他在系统设计方面的许多想法,是一本伟大的读物。

用他的话说:

研究了多台计算机的设计与实现,为系统设计提供了一些一般性的提示。这里对它们进行了描述,并通过许多例子加以说明,从硬件如Alto和Dorado到应用程序如Bravo和Star。

这篇论文本身也承认,它的目标不是要开辟任何新的领域,但这是一个惊人的概述。

大泥球

对华丽设计模式的华丽论文的反应,本文将最常见的建筑图案称为“大泥球”。并探讨了为什么在一个系统从概念到解决方案的过程中,优雅的初始设计很少保持完整。

从抽象:

虽然很多注意力都集中在高级软件架构模式上,是什么,实际上,事实上的标准软件架构很少被讨论。本文研究了最经常部署的软件架构:大泥球。一大团泥巴是一种随意,即使偶然,结构化的系统。它的组织,如果可以这样说,与其说是设计,不如说是权宜之计。然而,它经久不衰的受欢迎程度不能仅仅表明人们普遍忽视建筑。

虽然这篇论文中充满了幽默,同样,软件设计非常差,很少有系统具有设计阶段,很少有类似于初始设计的系统(很少更新文档以反映以后的决策)。这是一个需要考虑的重要话题。

谷歌文件系统

从抽象:

文件系统已成功满足我们的存储需求。它被广泛部署在谷歌中,作为生成和处理我们的服务使用的数据的存储平台,以及需要大数据集的研究和开发工作。迄今为止最大的集群在超过1000台机器上的数千个磁盘上提供数百兆兆字节的存储空间,同时被数百个客户机访问。

在这篇文章中,我们提供了文件系统接口扩展,旨在支持分布式应用程序,讨论我们设计的许多方面,并报告来自微型基准测试和实际应用的度量。谷歌在定义硅谷的技术主题方面做了一些相当了不起的事情,至少在整个科技行业中都是如此,在过去的十多年里(直到最近Facebook和Twitter的规模达到了显著的水平,他们加入的程度才更小)。这主要是通过他们卓越的技术论文来实现的。谷歌文件系统(GFS)论文是该战略的早期条目之一,同时也值得注意的是,这篇论文很大程度上启发了Hadoop文件系统(HFS)。

大规模系统

我们并不总是把微软看作是最大的互联网技术公司之一,尽管越来越多的天蓝色使得这种比较变得明显和直接,这当然不是一个在2007年必然想到的名字。这篇来自詹姆斯·汉密尔顿的优秀论文,探索在超大规模建设可操作系统的技巧,明确表示,不将微软视为一个大型互联网玩家,是我们集体判断的失误。

从抽象:

系统与管理员的比率通常被用作了解大规模服务中管理成本的粗略指标。较小的,自动化程度较低的服务,这个比例可以低至2:1,鉴于行业领先,高度自动化的服务,我们看到比率高达2500:1。在微软内部服务,自动驾驶[1]经常被认为是Windows Live搜索团队成功实现高系统管理员比的神奇之处。虽然自动管理很重要,最重要的因素实际上是服务本身。自动化服务是否高效?它是我们通常所说的操作友好型吗?操作友好的服务几乎不需要人工干预,而且,在没有行政干预的情况下,除了最模糊的故障之外,两者都能检测到并从中恢复。本文总结了多年来在扩展MSN和Windows Live中一些最大的服务方面积累的最佳实践。

这是一个如何设计和评估大规模系统的真实清单(几乎像十二因子应用程序希望成为可操作应用程序的检查表)。

第十二章十二年后:规则是如何改变的

Eric Brewer假设上限定理在21世纪初,12年后,他写了这篇关于cap的出色概述和评论(认为分布式系统必须在分区期间在可用性和一致性之间进行选择)。部分原因是:

在其推出后的十年里,设计人员和研究人员使用(有时滥用)CAP定理作为一个理由来探索各种各样的新型分布式系统。NoSQL运动也将其作为反对传统数据库的论据加以应用。CAP很有趣,因为它没有“开创性的CAP论文”,但这篇文章很好地代替了这篇论文。这些想法在收获与产量纸.

收获,产量,以及可扩展的容忍系统

本文建立在以下概念的基础上:第十二章十二年后,介绍收获和产量的概念,为AP与CP的讨论增添更多的细微差别:

由于当今Internet应用程序的空前规模和健壮性要求,协调一致性和状态管理与高可用性之间的成本被极大地放大了。我们提出了两种策略来改进总体可用性,使用简单的机制在输出行为允许适当降级的大型应用程序上扩展可用性。我们用收获和产量来描述这种退化,并将其直接映射到通过改进故障隔离提高可用性的工程机制上,在某些情况下还可以简化编程。通过收集文献中相关技术的实例并说明从这些方法中获益的惊人应用范围,我们希望在这个领域激发更广泛的研究项目。

收获和产量概念特别有趣,因为它们都是自证的,很少被明确使用,相反,分布式系统继续以未定义的方式失败。希望当我们不断重读这篇论文时,我们还将开始将it的设计概念合并到随后构建的系统中!

MapReduce:简化大型集群上的数据处理

MapReduce论文是一个很好的例子,它已经非常成功,现在似乎不言而喻。把函数编程的概念应用到大规模的概念变成了一个号角,引发数据仓库向数据分析新范式的转变:

MapReduce是一个编程模型,是处理和生成大型数据集的相关实现。用户指定一个映射函数,该函数处理一个键/值对以生成一组中间键/值对,以及一个reduce函数,它合并与同一个中间键关联的所有中间值。许多现实世界的任务都可以在这个模型中表达,如本文所示。

很像Google文件系统论文是Hadoop文件系统的灵感来源,这篇论文本身就是Hadoop的主要灵感来源。

衣冠楚楚的,大规模分布式系统跟踪基础设施

Dapper论文介绍了一种跨多个服务跟踪请求的性能方法,随着越来越多的公司将核心的单片应用程序重构为数十或数百个微服务,这一点变得越来越重要。

从抽象:

这里我们介绍了DAPPER的设计,谷歌的生产分布式系统跟踪基础设施,并描述我们低开销的设计目标,应用程序级透明度,在一个非常大的系统上实现了无处不在的部署。Dapper与其他跟踪系统在概念上有相似之处,尤其是喜鹊和X-trace,但我们做出了一些设计选择,这些选择是其在我们的环境中成功的关键,例如使用抽样并将检测工具限制在相当少的公共库中。

从那时起,dapper的想法就已经进入了开源领域,尤其是在斯普肯OpenTracing.

Kafka:用于日志处理的分布式消息系统

阿帕奇·卡夫卡已经成为许多互联网公司的核心基础设施。它的多才多艺赋予了许多角色,作为“数据土地”的入口点对一些人来说,一个为其他人准备的持久队列,这只是表面上的划痕。

不仅是工具箱的一个有用的补充,卡夫卡也是一个设计精美的系统:

日志处理已经成为消费者互联网公司数据管道的一个重要组成部分。我们介绍卡夫卡,我们开发的一个分布式消息传递系统,用于以低延迟收集和交付大量日志数据。我们的系统融合了现有日志聚合器和消息传递系统的思想,适用于离线和在线消息消费。为了提高系统的效率和可扩展性,我们在卡夫卡做了很多非常规但实用的设计选择。实验结果表明,与两种流行的消息传递系统相比,Kafka具有更好的性能。我们在生产中使用卡夫卡已有一段时间了,它每天处理数百GB的新数据。

特别地,卡夫卡的分区做了一个非凡的工作,迫使应用程序设计者在性能上做出明确的权衡,以获得可预测的消息排序。

虫洞:可靠的pub sub,支持地理复制的互联网服务

在许多方面类似于卡夫卡,Facebook的虫洞是另一种高度可扩展的消息传递方法:

虫洞是一个发布-订阅(发布-订阅)系统,开发用于Facebook的地理复制数据中心。它用于可靠地复制包括Tao在内的几个Facebook服务的变化,图形搜索和memcache。本文描述了虫洞的设计和实现,以及扩展系统以支持Facebook部署的多个数据存储系统所面临的操作挑战。我们的虫洞生产部署在所有部署中以稳定状态(每秒5千万条消息或每天5万亿条消息)传输超过35千兆字节/秒,在故障恢复期间爆发高达200千兆字节/秒。我们证明,虫洞以低延迟向订阅服务器发布更新,这些订阅服务器可能会以不同的速率失败或使用更新,不影响效率。

特别地,注意在不牺牲整个系统吞吐量的情况下支持滞后用户的方法。

Borg,ω,和Kubernetes

而每个谷歌编配系统的独立论文(Borg,欧米伽和库伯奈特的作品本身就值得一读,本文是对这三个方面的极好概述:

尽管对软件容器的广泛兴趣是一个相对较新的现象,在谷歌,我们已经大规模管理Linux容器超过10年,并在此期间构建了三个不同的容器管理系统。每个系统都受到其前身的严重影响,尽管它们的发展原因不同。本文描述了我们从开发和操作它们中学到的经验教训。

幸运的是,并不是所有的编排都是在谷歌的支持下进行的,另外,Mesos的可选两层调度体系结构也是一本引人入胜的书。

使用Borg在谷歌进行大规模集群管理

博格已经策划了一段时间谷歌的大部分基础设施(明显早于欧米茄,虽然欧米茄纸比博格纸早了两年,但令人着迷的是:

谷歌的博格系统是一个集群管理器,可以运行数十万个工作岗位,从成千上万个不同的应用程序中,跨越多个集群,每个集群都有多达数万台机器。

本文研究了博格的集中调度模型,既有效又高效,尽管随着时间的推移,修改和扩展变得越来越具有挑战性,激发了谷歌内部的欧米茄和库伯内特(前者乐观地取代了后者,后来,他们似乎将学习成果商业化,或者至少防止介子捕获过多的思想份额)。

欧米茄:柔韧,大型计算集群的可伸缩调度程序

欧米茄是,在许多其他事情中,一个很好的例子第二系统效应,试图用更优雅的东西取代复杂的现有系统,结果比预期的更具挑战性。

特别地,欧米茄是对现实的反应,延长老化的博格系统:

不断增长的规模和对不断变化的需求的快速响应的需求很难满足当前的单片集群调度程序体系结构。这限制了新功能的部署速度,降低效率和利用率,最终会限制集群的增长。我们提出了一种新的方法来解决这些需要使用并行,共享状态,以及无锁乐观并发控制。

也许也是一个例子越坏越好又一次占用了一天的时间。

Mesos:数据中心细粒度资源共享平台

本文介绍了该系统的设计阿帕奇介子,尤其是其独特的两级调度程序:

我们呈现介子,在多个不同的集群计算框架之间共享商品集群的平台,比如Hadoop和MPI。共享提高了集群利用率,避免了每个框架的数据复制。Mesos以细粒度的方式共享资源,允许框架通过轮流读取存储在每台机器上的数据来实现数据本地化。为了支持当今框架中复杂的调度程序,Mesos引入了一种称为资源提供的分布式两级调度机制。介子决定每个框架提供多少资源,而框架决定接受哪些资源以及在这些资源上运行哪些计算。我们的结果表明,在不同的框架之间共享集群时,介子可以实现接近最优的数据局域性。可以扩展到50,000个(模拟的)节点,对失败有弹性。

Twitter和苹果大量使用,一段时间以来,Meos是唯一一个采用了大量的开源通用调度程序,现在正与库伯奈特展开一场精彩的Mindshare竞争。

基于容器的分布式系统的设计模式

转向基于容器的部署和协调已经引入了一套全新的词汇表,如SideCars和适配器,本文对过去十年来随着微服务和容器成为日益突出的基础设施组件而演变的模式进行了调查:

在20世纪80年代末和90年代初,面向对象编程彻底改变了软件开发,将构建应用程序的方法作为模块化组件的集合进行推广。今天,我们看到了分布式系统开发的类似革命,随着由集装箱化软件组件构建的微服务体系结构越来越流行。由于容器在容器边界处设置的墙,容器特别适合作为分布式系统中的基本对象。随着这种建筑风格的成熟,我们看到了设计模式的出现,就像我们在面向对象程序中所做的一样,出于同样的原因,从对象(或容器)的角度思考,抽象出代码的低级细节,最终揭示各种应用程序和算法所共有的高级模式。

“边车”特别是可能起源于这篇来自Netflix的博客文章,它本身就是一本值得一读的书。

RAFT:寻找一种可理解的共识算法

我们经常看到第二系统效应,相对于一个简单的初始系统,第二系统变得膨胀和复杂,在Paxos和Raft的情况下,角色是相反的。虽然人们通常认为帕克斯无法理解,raft是一个相当容易阅读的工具:

raft是管理复制日志的共识算法。它产生的结果相当于(多个)Paxos,它和帕克斯一样高效,但其结构不同于多环芳烃;这使得筏比PaxOS更易于理解,也为构建实用系统提供了更好的基础。为了增强可理解性,筏子分离了共识的关键因素比如说领袖选举,日志复制,和安全,它加强了更大程度的一致性,以减少必须考虑的国家数量。用户研究的结果表明,RAFT比Paxos更容易让学生学习。raft还包括一个改变集群成员的新机制,它使用重叠的多数来保证安全。

筏板被ETCD流入xdb和其他很多。

Paxos变得简单

莱斯利·兰波特众多有影响力的论文之一,《变简单的Paxos》在解释众所周知的复杂的Paxos算法方面是一颗宝石,因为即使是最简单的,Paxos并不是那么简单:

实现容错分布式系统的paxos算法一直被认为很难理解,也许是因为最初的演讲对许多读者来说是希腊语的。事实上,它是最简单和最明显的分布式算法之一。它的核心是一个共识算法synod算法。下一节将展示这种一致算法几乎不可避免地遵循我们希望它满足的属性。最后一部分解释了完整的paxos算法,这是通过将共识直接应用于构建分布式系统的状态机方法而获得的,这种方法应该是众所周知的,因为它是关于分布式系统理论最常被引用的文章的主题。

Paxos本身仍然是一个极具创新性的概念,这就是谷歌胖嘟嘟的背后的算法阿帕奇动物园管理员,和其他很多。

可伸缩的弱一致性感染类型进程组成员协议

大多数共识算法的重点是分区期间一致,SWIM则相反,它关注的是可用性:

一些分布式点对点应用程序需要对所有参与进程的进程组成员身份信息的弱一致性知识。SWIM是一个通用的软件模块,它为大型进程组提供这种服务。游泳运动的动力来自于传统的心脏跳动方案的不可分割性,它要么施加与组大小成四次方增长的网络负载,或折衷反应时间或假阳性频率w.r.t。正在检测进程崩溃。本文介绍了该设计方案。游泳子系统在大型商品PC集群上的实现与性能。

Swim用于Hashicorp的软件,以及超级的Ringpop.

拜占庭将军问题

另一篇关于共识的经典莱斯利·兰波特论文,拜占庭将军问题探讨了如何处理有意或无意提交错误消息的分布式参与者:

可靠的计算机系统必须处理那些向系统不同部分提供冲突信息的故障部件。这种情况可以抽象地用拜占庭军队的一批将军在敌城周围驻扎来表达。仅通过信差通信,将军们必须商定一个共同的作战计划。然而,其中一个或多个可能是叛徒,他们会试图迷惑其他人。问题是要找到一种算法来确保忠诚的将军们达成一致。结果表明,只用口头信息,只有三分之二以上的将军忠诚,这个问题才能解决;所以一个叛徒就能迷惑两个忠诚的将军。不可原谅的文字信息,这个问题对于任何数量的将军和可能的叛徒都是可以解决的。然后讨论了这些解在可靠计算机系统中的应用。

这篇论文主要关注形式证明,这是Lamport开发的一个主题血红蛋白+为了使正式证明更容易,但这也提醒我们,我们仍然倾向于假设我们的组件会可靠而诚实地运行,也许我们不应该!

出沥青坑

走出焦油坑哀叹软件的不必要复杂性,并提出函数式编程和更好的数据建模可以帮助我们减少意外复杂性(认为大多数不必要的复杂性来自状态)。

从抽象:

复杂度是大型软件系统成功开发的单一主要难点。在布鲁克斯之后,我们区分了偶然性和本质性的困难,但不同意他的前提,即当代系统中的大多数复杂性是必要的。我们确定了复杂性的常见原因,并讨论了在本质上是偶然的情况下,可以采取的一般方法来消除它们。为了使事情更具体化,我们然后给出了一个基于函数编程和Codd的数据关系模型的潜在复杂性最小化方法的概要。

当然是一本好书,尽管十年后阅读,但看到这两种方法都没有取得特别的进展是很有意思的,而不是最接近的“宇宙”降低复杂性的方法似乎是转向许多大多数都是无状态的服务,哪一种可能更少局部复杂性,以牺牲更大的系统复杂性为代价,然后将其维护委托给更专业的系统工程师。

(这是另一份让我许愿的报纸血红蛋白+感觉很自然,可以成为常用的工具。)

用于松耦合分布式系统的胖锁服务

分布式系统足够硬,不需要频繁地重新实现paxos或raft,Chubby提出的模式是在共享服务中实现一次共识,这将允许建立在它之上的系统通过遵循大大简化的模式共享分布的弹性。

从抽象:

我们描述了我们与胖乎乎的锁服务的经历,它旨在为松散耦合的分布式系统提供粗粒度的锁定和可靠的(尽管容量很小)存储。Chubby提供了一个接口,很像一个带有咨询锁的分布式文件系统,但设计的重点是可用性和可靠性,而不是高性能。该服务的许多实例已经使用了一年多,其中几个同时处理数万个客户。本文介绍了初步设计和预期用途。将其与实际使用情况进行比较,并解释如何修改设计以适应差异。

在开源世界中,的方式动物园管理员在卡夫卡和美索斯这样的项目中使用,与丘比有同样的作用。

Bigtable:用于结构化数据的分布式存储系统

谷歌最杰出的论文和技术之一就是Bigtable,那是互联网时代的早期,无论如何)nosql数据存储,运行在非常高的规模和建立在胖乎乎的顶部。

Bigtable是一个用于管理结构化数据的分布式存储系统,其设计可扩展到非常大的规模:数千台商品服务器上的千兆字节数据。谷歌的许多项目都将数据存储在Bigtable中,包括web索引、谷歌地球,以及谷歌金融。这些应用程序对Bigtable提出了不同的要求,无论是数据大小(从url到web页面到卫星图像)还是延迟需求(从后端批量处理到实时数据服务)。尽管有这些不同的要求,Bigtable成功地提供了一个灵活的,所有这些谷歌产品的高性能解决方案。本文描述了Bigtable提供的简单数据模型。它使客户能够动态控制数据布局和格式,介绍了Bigtable的设计与实现。

从SSTable设计到Bloom过滤器,Cassandra和从Bigtable论文中显著继承,很可能被正确地认为是发电机和大论文的合并。

扳手:谷歌的全球分布式数据库

许多早期的NoSQL存储系统利用最终的一致性来提高弹性,建立在最终一致的系统之上可能会很痛苦。扳手代表了一种从谷歌到提供强大的一致性和分布式可靠性的方法,部分依赖于一种新颖的时间管理方法。

扳手是谷歌的可扩展,多版本的,全球分布,和synchronously-replicated数据库。它是第一个在全球范围内分发数据并支持外部一致的分布式事务的系统。本文描述了扳手的结构。它的功能集,各种设计决策的基本原理,和一个新的时间API,暴露时钟的不确定性。此API及其实现对于支持外部一致性和各种强大功能至关重要:过去的非阻塞读取,锁定自由只读事务,原子模式改变,穿过所有的扳手。

我们还没有看到任何开源扳手等价物,但我想我们将在2018年开始见到他们。

安全密钥:现代Web的实用密码第二个因素

安全钥匙,比如雨衣已成为最安全的第二认证因素,这篇来自谷歌的论文解释了它们产生的动机,以及使它们工作的设计。

从抽象:

安全密钥是保护用户免受网络钓鱼和中间人攻击的第二要素设备。用户只携带一台设备,可以通过任何支持该协议的在线服务进行自注册。这些设备易于实现和部署,使用简单,隐私保护,并对强大的攻击者采取安全措施。我们已经在ChromeWeb浏览器和谷歌的在线服务中提供了对安全密钥的支持。我们通过分析从Google开始并扩展到面向消费者的Web应用程序的两年部署,证明了安全密钥可以提高安全性和用户满意度。安全密钥设计已由FIDO联盟标准化,一个拥有250多个成员公司的跨行业组织。目前,谷歌已经部署了安全密钥,升降箱,和Github。

它们也非常便宜!订购一些,一两天内就可以开始保障你的生命安全。

BeyondCorp:谷歌的设计到部署

建立在Beyondcorp原纸在2014年,本文更为详细,并从两年多的移民智慧中获益。也就是说,大的想法保持了相当一致,与Beyondcorp论文本身相比没有太多新的内容(尽管这是一篇很棒的论文,如果你没读过,这是一个同样好的起点):

谷歌的BeyondCorp计划的目标是提高我们对员工和设备如何访问内部应用程序的安全性。与传统的周边安全模式不同,BeyondCorp不会根据用户的物理位置或原始网络对服务和工具进行访问;相反,访问策略基于有关设备的信息,它的状态,及其关联用户。BeyondCorp认为内部网络和外部网络都是完全不可信的,盖茨通过动态声明和强制级别访问应用程序,或分层,访问权限。

就像阅读谷歌的论文一样,我最大的收获是想知道什么时候我们可以开始看到可重复使用,内部描述的技术的可插入开源版本。

全球分布式存储系统的可用性

本文探讨了如何考虑复制分布式系统中的可用性,对于那些试图确定正确方法来测量存储层或任何其他足够复杂的系统正常运行时间的人来说,这是一个有用的起点。

从抽象:

我们对谷歌的主要存储基础设施进行了为期一年的广泛研究,并在此基础上描述了云存储系统的可用性特性,并提出了统计模型,以进一步了解多种设计选择的影响,如数据放置和复制策略。通过这些模型,我们比较了各种系统参数下的数据可用性,给出了我们车队中观察到的实际故障模式。

特别有趣的是关注相关故障,构建在分布式系统的用户只在多个组件出现重叠故障时才会经历故障的前提下。另一个令人期待但令人安心的观察是,在谷歌的规模(以及资源分布在不同的机架和地区)上,大多数故障来自于调整和系统设计,不是来自底层硬件。

令我惊讶的是,在这种情况下,他们对可用性的定义竟然如此简单:

当存储节点无法对监视系统发送的定期健康检查ping信号作出积极响应时,该节点将不可用。在恢复响应或存储系统从其他幸存节点重建数据之前,该节点保持不可用。

关于可用性的讨论常常变得任意复杂(“实际上应该是响应速度超过X,但在正确的结果和我们的延迟SLO!”),令人欣慰的是,最简单的定义仍然可用。

仍然都在一台服务器上:按比例执行

随着公司的发展,代码托管性能成为整个开发人员生产力(以及构建和测试性能)的关键因素之一,但这是一个不常讨论的话题。谷歌的这篇文章讨论了他们的经验扩展性能:

谷歌运行着地球上最繁忙的单穿孔服务器,以及任何源代码管理系统中最大的存储库之一。从这个高度来看,本文着眼于服务器性能和其他规模问题,随著我们离题,我们是怎么来到这里的,以及我们如何继续领先于我们的用户一步。

当您考虑到企业在扩展Git monorepos时遇到的困难时,本文尤其令人印象深刻。

使用clangmr的大规模自动重构

大型代码库的老化程度较低,特别是在存储数百或数千个不同团队在不同项目上协作的情况下。本文介绍了Google的一个尝试,即通过工具减少维护大型Monorepo的负担,使在整个代码库中重写抽象语法树(AST)变得容易。

从抽象:

在这篇文章中,我们提供了一个实际的系统实现,以有效重构大型c++代码库。clang编译器框架和mapreduce并行处理器的组合,clangmr使代码维护人员能够轻松、正确地转换大型代码集合。我们描述了这种工具背后的动机,它的实现,然后介绍我们的经验,使用它在最近的API更新与谷歌的C++代码库。

类似的工作正在进行中.

源代码恢复不是重构

本文介绍了“代码更新”的概念。随着新的语言特性和库的出现,朝着更清晰的抽象的方向发展的单向过程,尤其适用于蔓延,旧代码库。

从抽象:

在这篇文章中,我们提出了源代码恢复的概念,传统代码的自动迁移,非常简单地提到了我们用来实现这一点的工具。虽然重构改进了结构上不充分的源代码,源代码更新通过查找和替换可以通过更高级别的软件抽象表示的编码模式,利用增强的程序语言和库设施。提高抽象级别有利于软件的可维护性,安全,和性能。

这一工作在美国有一些强烈的反响谷歌的Clangmr论文.

寻找积累债务:在谷歌管理技术债务的经验

本文是关于如何在活代码库中执行大规模迁移的一个有趣的封面。使用中断的构建作为运行示例,他们将战略分解为三大支柱:自动化、让做正确的事情变得容易,让你很难做错事。

从抽象:

随着代码库的快速变化,谷歌软件工程师不断地为各种形式的技术债务支付利息。谷歌工程师也在努力偿还债务,无论是度过特别的日子,或者通过专门的团队,被称为看门人,耕耘机,或拆迁专家。我们描述了几项相关的工作,以衡量和偿还在谷歌的构建文件和相关死代码中发现的技术债务。我们处理依赖规范中的债务,建造不能目标,以及不必要的命令行标志。这些努力往往暴露出必须首先管理的其他形式的技术债务。

软件工程中的无银弹本质与事故

《神秘人月》作者的一篇具有开创性的论文,“无银弹”扩展了对偶然复杂性与本质复杂性的讨论,并认为,不再有足够的偶然复杂性,以允许个别减少偶然复杂性,以显著提高工程师的生产力。

从抽象:

过去在软件生产率方面取得的巨大进步大部分来自于消除人为障碍,这些障碍使意外任务变得异常困难,比如严重的硬件故障,笨拙的编程语言,机器时间不足。软件工程师现在所做的工作中有多少仍然是致力于这个意外事件,与基本的相反?除非超过所有努力的9/10,将所有意外活动缩减到零时间并不能带来一个数量级的改善。

有趣的是,我认为我们确实看到了大型代码库中的意外复杂性变得足够大,足以进行数量级的改进(激励,例如,谷歌对Clangmr等公司的投资,因此,在向本质复杂性转变的过程中,我们可能并没有像我们想象的那样走得太远。

Unix分时系统

本文描述了UNIX在1974年的基本原理,真正值得注意的是,有多少设计决策至今仍在使用。从我们都用chmod操作过的权限模型到用来操作文件的系统调用,令人惊讶的是,有多少东西还完好无损。

从抽象:

Unix是通用的,多用户,数字设备公司的交互式操作系统PDP-11/40和11/45计算机。它提供了许多即使在大型操作系统中也很少发现的功能,包括:(1)包含可拆卸卷的分层文件系统;(2)兼容文件,设备,进程间的I / O;(3)启动异步进程的能力;(4)按用户选择的系统命令语言;(5)包括十多种语言在内的100多个子系统。本文讨论了文件系统和用户命令接口的性质和实现。

同样有趣的是,他们发现UNIX之所以成功,部分原因是它的作者设计它是为了解决一个一般性的问题(使用PDP-7令人沮丧),而不是更具体的目标。


分享了这篇文章之后,人们还推荐了大量令人惊叹的论文:

把你的寄给我!如果你想找更多的阅读材料,考虑看看我最喜欢的书!