BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Serkan Piantino谈Facebook的扩展
录制于:

| 受访者 Serkan Piantino 关注 0 他的粉丝 作者 Daniel Doubrovkine 关注 0 他的粉丝 发布于 2013年2月20日 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!
11:22

个人简介 Serkan Piantino是Facebook的一名工程技术经理,同时负责Facebook的纽约工程师办公室。他管理Facebook信息和聊天产品背后的团队。他此前的工作经验涉及News Feed基础架构的构建和排序算法,Facebook新版首页的开发,以及Timeline的开发。

软件正在改变世界。QCon旨在促进软件开发领域知识与创新的传播 。为了实现这个目标,QCon作为一个从业者导向型组织的会议,旨在影响人们在他们的团队中进行创新工作,而这些人大多是:团队领导、架构师、项目经理和工程总监 。

   

1. 大家好,我是Daniel Duobrovkine,我现在在QCon 2012的现场,在我身边的这位是Serkan Piantino。Serkan,很荣幸你能接受我们的采访,谢谢。你能简单的介绍下自己吗?

好的,如你所说,我叫Serkan Piantino,是Facebook的一名软件工程师。今天我将要跟大家详细探讨一下在我协助构建News feed基础架构的过程中所做的一些细节工作。最近,我在负责纽约新开设工程办公室的筹建工作。

   

3. 我一直以来的工作也与系统相关,但是我处理的那些系统一般都只有几百万用户的规模。当你打算开发像Facebook上那样大型产品的功能时,你都使用哪些数量指标作为借鉴?

我觉得基础设计的工作十分有意思,就算是只有一百万用户的系统也是会需要扩展的,因为单台主机已经无法处理这么多业务,你面临的问题是一样的,你可以联接表,或者做些用户可以在较小规模操作的事情。

即使是一百万的用户,由于查询操作的活跃度和困难度不同,你的工作量也会不同。

当你在讨论超大规模系统的时候,我觉得最大的不同的就是效率的价值——你要付出多少代价来把查询的时间再降低几个毫秒,你要花费多少精力去思考能保证事情能正常运行的真正本质;我们就是这样去设计系统的。这些天来,我们一直在关注硬件运行的基本时间周期,你也知道的,访问RAM需要几纳秒的时间,访问磁盘需要8毫秒的时间。

你需要了解你所有的硬件以及其相关的各种基本信息。有了这些数字,我们就能了解服务器在不同配置条件下的不同表现,以及我们大概需要多少台服务器。

我们对软件设定的目标就是让软件尽可能的形同空气,让我们系统的运行效率尽可能的贴近底层硬件的原始效率。这就是我们工作的起点。

   

4. 言之有理,你有像其它那些传统大规模系统一样,尽量少的使用磁盘而将使用RAM作为常态吗?或者这样说,你是否认为RAM的访问速度非常重要?

通常来说,是的,访问RAM是比访问磁盘要快上好几个数量级。

有趣的是,News feed的信息大部分存在RAM中,我们花了很多时间来思考诸如页表、缓存条目,甚至NUMA架构——你们有些人可能对这些比较熟悉,所以News feed是个很特殊的情况,我们在尽力从RAM而不是磁盘中获取性能提升;但是,当你发生硬盘访问的时候,整个性能数字就变得很难看。所以到最后,我们唯一关心的事情就是压缩硬盘查找的次数。

   

5. 你认为给一百万个用户、一千万个用户或者十亿个用户构建系统,它们之间的难度是不是成指数增长的?或者,问题的属性是一样的,只不过规模更大?

当然不是成指数增长的。这个曲线是趋于平缓的。我的意思是,回顾2007年当我们设计News feed的首个版本时,当时我们有2500万用户,我们是按照一亿用户的规模进行系统设计的。我们当时就知道,以后肯定会需要扩展。

自从那年开始,查询量以每年三倍的速度增长。但是我们并没有多少的工程量投入其中。我们构建了一个从基础层面上可扩展性的系统,而且它已经成功的扩展过了,这是我觉得该系统了不起的地方。

所以就我看来,一旦你能够成功处理一亿的用户量,那么你后面遇到的困难就会越来越少,基本上大功告成了。

就像我所说的,当提高效率带来的金钱节省越多的时候,效率会变得越来越重要。同时,你会遇到越来越多的所谓“偶发性的问题”,比如服务器宕机,你必须要处理它,但是很有可能你从来都没有这方面的计划,因为你从没想过会发生这样的问题。当你有成千上万台服务器的时候,这种偶发性问题就会变成常见性问题:我们的服务器经常宕机,我们总是遇到网络问题,一些基础功能的模块也经常出现故障的情况。

由于它们成为了常见性的问题,当你日复一日面对这些问题的时候,你就能够更加明确的跟踪这些问题。

处理你所能够跟踪的常见性问题实际上要比处理偶发性问题容易的多,因为对于那些偶发性的问题,你并没有掌握多少相关的数据信息,一旦它们发生,你只能跟救火似的抓瞎。

所以在某种程度上,它实际上会随着你系统的扩展而变得越来越简单。如果你的核心部分可以扩展到一个很高的水平,那么它多半可以扩展到一个非常大的规模。

   

6. 你现在为那些常规故障做设计吗?或者说你会去设计一些正向反馈,把服务器宕机当做大规模集群服务器上的常规事件进行处理?

当然。我的意思是,在你需要考虑的事情当中,这大概占据了一半。首先,你要弄明白系统是怎么样运行的,该计划是否可以进行扩展和复制,这些操作是否可行;接下来,你再去考虑遇到故障之后该如何处理。

因此,故障场景不是仅仅考虑单台设备发生故障后该如何处理,或者在什么样的场景下哪种类型的请求会出错,而是还要考虑到在发生网络不稳定和重试的情况下,所有可能出现的衍生情况。随着问题的加剧,需要处理的单点会非常多。

你看到服务器本地行为的一些突发情况,同时你也知道这些情况会导致哪些衍生情况,那么你需要仔细考虑这些事情,你要想清楚你到底想要的是什么,以及如何从你写的代码中获得你想要的东西。

   

7. 看看你现在所构建的系统,你是否有想过可以回到两年前,去做一些完全不同的改变?或者说,你觉得现行的策略有哪些是很好的?

我觉得我们所做的最重要的选择就是第一条:我们把所有的数据都放在了内存中并提供实时查询;我觉得这就是一个很好的决策。

一路走来我们做了许多的创新工作,以便使我们的工作变得更简单;我等下会在我的演讲中谈到这些。总体的跳跃式改变并没有那么多。目前的代码量出人意料的少,我们做了不少次的修改,但现在的代码大体上还是基于之前的样子。所以我觉得我们做的相当不错。

   

8. 你刚刚谈论了很多关于内存的话题。你是否认为那些负载数十亿用户的服务器以后都是会只依靠RAM来运行系统,而不需要磁盘;为了支持这种庞大规模的系统,是不是在十年内这种情况就会发生根本性的改变?

肯定会的,我们现在甚至已经在消费市场中看到了这种趋势:固态硬盘在取代传统硬盘,它们在性能上需要解决的问题截然不同,而且它们的性能特性也截然不同;在服务器市场,同样也有这种趋势:Flash没有磁盘随机寻道的问题,它非常的快速,它的产量在不断扩大,而且价格在不断降低。我觉得这是非常振奋人心的。

你可能对事务的并行性需求越来越来大,所以并发性就越来越多的被人们所关注,不仅仅是在服务端有数十亿用户规模的时候,对并发性的关注也会一路延伸到更早的设计阶段。

出乎意料的是,我们现在最大的开销是在服务器的电力消耗上,哪怕我们什么都不做,只要机器开着就会消耗很多兆瓦的电量;所以我认为能效将成为另一大难题,不过我同样相信,这个领域在以后将会出现极多的、我们所无法预料的创新。

   

9. 那么你认为会是能效变得越来越高,而不是电费会越来越便宜,会出现更多的新能源,如核电站或其他类似的能源?

我希望是这样。我希望可以在我们的国家甚至全世界都解决能源问题。也许会是这样,也许能效会显得不那么重要;但实际上这是不对的:即使电力成本越来越低,但是冷却设备的消耗却是不会那么高效的,这是基本的热学定律,花再少的代价也是需要花代价的,为了提高能效也是会付出代价。但是,你可以减少这代价,你可以将这些节省下来的代价放在更多的事情上,因此我觉得这是一个不容忽视的趋势。

   

10. 你能给那些此时只有几百万用户的小型创业公司的开发经理和首席技术官们一些建议吗?

好的,我觉得我们所做的事情中有几点还是比较重要的。首先,我们有一系列的工具集,这个一个规模很小但还在不断丰富的工具集,通常我们都很信任这些工具集。我们应该使用它们,我们也清楚的知道它们的作用,我觉得我们可以依靠它们。

因此我们通常都对部署全新的技术存有怀疑态度,因为我们都有充足的理由相信它们多多少少都会有问题,这是第一点;第二点,即使在相对较小的规模下,如果你不能很轻松的画出一张查询延时的柱状图,如果你不能理解你的内存是用来干什么的,如果你不能得到缓存的命中率,那么你对你的服务是不了解的,因为这些都是最基本的问题,也是很重要的问题。

类似这些简单的度量标准,你不仅仅要了解,而且还要在心中能倒背如流;有时当你在那样的规模下进行运作时,这些往往会是揭示潜在问题的头号指标。你也知道,你需要对整个机制反复的试错,等等。

总而言之,这些要素是非常重要的:你要确保你有很好的监控体系,以及很好的图表呈现;一切都是实时的。这将有助于你的扩展,也有助于让你在目标方向上更加理性。

我要说的第三点经常在人们构建系统的时候被忽视:人们不仅仅要针对服务器的数量和开发的周期进行优化,同时也需要对开发者的经验进行优化。

如果你能构建一种系统,在该系统上,开发者可以取到你的代码进行修改,并且修改可以立即生效,那么MapReduce 的工作也就不那么必要了。这对整个公司非常好,要比我们扩展了多少台服务器更加重要。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT