林仕鼎谈数据中心计算（三）：学术界与工业界，以及未来展望

在《林仕鼎谈数据中心计算》的第一部分，百度基础体系首席架构师林仕鼎先生提到要将数据中心当做逻辑上的一台机器来设计架构。在之后的对话中，林仕鼎具体介绍了对数据中心的存储资源做逻辑分层、物理映射的思路。

在接下来的对话中，林仕鼎会介绍他对于“为什么以前的系统做的并不是很好”的理解，以及“为什么会想要去做这个系统”的原因。此外，对话中也会涉及到他对12306 系统的部分解读，以及一些相关问题的看法。

InfoQ：像您提到的将数据中心看做一台 PC、逻辑分层这样的设计思路，为什么很少看到其他人来这样做呢？

林仕鼎：

设计一个好的系统架构，不仅仅是为了把系统做出来，更重要的是去考虑这个东西本质上应该是什么样的，怎样才会更优雅、更具有普遍性的推广意义。而且，数据中心里的系统涉及到应用、软件系统以及硬件架构等，需要多个团队配合，也需要产业链上合作伙伴的配合。我们可以提出思路并给出设计方案，但这些方案的实施需要业界的参与。这是一次产业的变革，我们很希望能在技术上起一些引领作用。

这同样也是现代 IT 技术演进的特点。创新，包括基础技术的创新，更多由工业界，特别是大型互联网公司来引导。因为，只有在大型互联网公司里才有需求有条件去做这些创新，真实的海量的数据和用户请求、实际运行的大规模平台，这些都是高校和研究机构所不具备的。

当然，也不是有需求有条件就必然带来创新，跟环境氛围、个人意愿和能力也有很大的关系。就我个人来说，我首先是一个工程师，一向 hands-on，一行一行代码写起，做过很多套系统；其次，我也有多年的系统研究背景，对这个领域的方法论、发展历史和现状比较熟悉。也就是说，我了解问题所在，有条件有能力去解决，并且也有意愿去定义一套完整的技术体系和理论框架。这个情况在业界是不太多的。

互联网公司里，多数工程师们在使用开源技术，这对于快速完成项目有很大帮助。在长期的实践过程中，大家也积累了很多经验，但这只是应用级开发经验，因为很多时候他们对这些技术的了解仅止于应用，缺乏对设计思路和实现细节的深究。在没有合适开源技术或者需要从头构建一个新的系统时，这些应用级开发能力就不足以胜任了。当然，深入了解这些开源技术也只是开始而已，说实话，大多数开源项目的设计和实现的水平并不太高。

学术界也有其固有的问题，从逻辑上的设计思路到物理上的系统架构和代码，还有很大的鸿沟存在。如我起先说的，一个复杂的系统在逻辑上有很多个层次，具体映射到模块、介质、机器、机群等物理结构上时，有诸多因素需要考虑，而这些因素有时候要到具体实施时才能被确定。另一方面，系统的实现难度也是很高的，怎么把硬件的并行度发挥出来，怎么让系统去异步地调度资源，这些都很复杂，需要大量的开发经验。

另外，系统研究产生的通常是原型系统，这跟实际的生产系统有两点根本性的不同。一个是规模，研究系统一般跑在几十台机器上，这已经很大了。把几十台机器当作一台机器来看，和把几千台机器当作一台机器来看，完全是不一样的。我经常开玩笑说，这会影响一个工程师的世界观，如果没有实际做过这样的大系统，根本体会不到其中的区别。比如刚才说的层次结构，在几十台机器的时候，根本就不明显。对于故障的处理方法，对于自动化工具和机制的重视程度也会完全不同。第二个不同在于，生产系统面临的压力是不一样的，用户请求的类型也完全不同。刚来百度的时候，我做了第一个存储系统，实现原型只用了半年，但是花了半年的时间才让它稳定运行，再花半年的时间才结束试运行，然后上线成为一个真正的生产系统。也就是说，从设计到实现的过程只是 1/3，把它变成真正可用的系统还要再花两倍的时间。

InfoQ：从原型到真正可用的系统，最大的难点在哪里？

林仕鼎：

我之前也说过一些，在讨论 12306 的时候。一个系统最复杂的地方不在于取得高性能，而是实现大压力下的稳定性。比如说，一个系统在运行时，有人有 scan 的需求，有人要写，有人要读。Scan、写和读，这些操作的资源消耗量的差异很大。而且这些操作是并发产生的，读写需要并行，随机读写和 scan 需要并行，scan 和 scan 也需要并行。在最糟糕的时候，比如几十个大的 scan 请求同时进来，你不能让资源被它消耗光，需要留一些出来去响应写和读。

同样是 scan，也有其他的问题要考虑。为了使 scan 更快，需要为每个 scan 准备更多的缓冲。在有很多 scan 请求的情况下，系统资源不足，只能大家共享这些缓冲块。这时候有两个问题，第一，如何在大量请求的情况下共享资源。很多系统的处理方案是限制请求数量，比如只允许 10 个并发请求，其他请求在队列里等待着。为了保险起见，要根据每个请求可能的最大资源消耗量来限制并发请求数量，通常这会导致资源的浪费。第二，每个 scan 接收方的能力或者带宽都不同，如果多数 scan 接收方很慢，它们占着系统资源，这很可能导致快的接收方也被拖慢。

比如某系统每秒只能发 100MB 的数据，有两个请求进来，请求 A 每秒只能接收 1MB，而 B 每秒能接收 200MB。有时候可能会出现这种情况，系统把 100MB 全给了 B，而 A 这边一点都拿不到。还有另一种情况是，A 收 1MB，B 也只能收 1MB，也就是说，最慢的那个出口拖慢了整个系统。这些输出情况已经算是不错的了，有很多系统在这种负载下甚至都不能正常工作。

好的处理方式应该是这样的，在有两个请求的时候，系统资源先分成一半一半进行输出。A 这边其实资源有富余，他只能收 1MB，50MB 的输出他是接收不了的，我们可以把多出来的 49MB 分给 B。也就是说，先平均分配资源，然后对消耗不了的多余资源进行再次分配，这是一个兼顾公平和效率的分配策略——所有的请求都能得到响应，如果资源有富余，可以分配给有更强能力的接收方。当然，要实现这一点，需要有很多机制的支持。比如需要反馈机制，这样才能知道 A 的接收能力不足。也需要有细粒度的资源分配方式，这样才能把多余的预分配资源回收。

刚才说的这个情况比较简单，请求量大了之后要实现这个规则就复杂了。而且，不同类型的请求对资源的消耗量是完全不一样的。比如 scan 消耗的资源可能是一次随机查询的几万倍，持续的时间也更长。假如有 100 个随机请求进来，然后又有 100 个 scan 请求进来，这时候我要怎样分配资源，让大家都觉得可以接受？这就是类似 12306 的系统遇到的最根本的问题。有些操作的资源消耗是其他操作的几十倍或者几百倍，而并发操作的总的资源消耗量是超过极限的。这种情况下，需要合理的资源调度策略来保证系统的稳定输出，而简单的排队和并发数限制策略的效果并不够好，因为一个请求的资源消耗量并不是事先能够确定，并发数少了导致资源浪费，而多了又将带来资源消耗过多导致系统崩溃的风险。

顺便提一下高性能系统，这个一直没有过合适的定义，我的看法是一个能够按硬件所能提供的最大能力持续稳定输出的系统才是高性能系统。

InfoQ：那么，即使百度、淘宝来做 12306，也会遇到这个问题么？

林仕鼎：

12306 所遇到的问题，说实话，要完美高效地解决还是不容易的。淘宝交易系统的压力其实并不高，系统的压力主要在搜索和图片上。12306 也是如此，交易量不大，但查询量很大，而它的服务器规模也不可能有百度淘宝这么大。另外，它有一个更大的问题，就是后台要跟铁路内部的 ERP 类系统连接，那个系统的部件是很慢的。如果给这个很慢的部件太大压力，很可能拖慢整个系统并使其崩溃。

一个系统里面通常由很多部件组成，每一个部件都在输入输出，也具有不同的服务能力。有些部件每秒可以支持 100 个并发，而有些部件每秒可能只能支持 1 个并发，你给他 10 个并发，它就崩溃并拖垮全系统。要达到高性能，需要让每个部件都有足够的并发量；而要稳定输出，则需要让每个部件都工作在它的能力范围之内。所以，在每对上下游的部件之间，都需要有队列来控制压力。但这个控制机制不能基于固定的数量，要根据现有的空闲资源量进行动态反馈调节。同时，对于资源，预分配可以提高效率，但会带来 live-lock，需要有一套细粒度的分配机制，在效率和可回收之间取得平衡。

InfoQ：不过话说回来，2013 年的 12306 事实上可用性已经比之前一年提高很多了，虽然买到票仍然很难，但至少不会总出现页面刷不出来的问题。

林仕鼎：

我猜测今年他们做了一个事情，把 transaction 和 query 分开了。transaction 的压力其实不大，毕竟票量也就那么多。Query 不需要保证严格的一致性，再多用一些 cache，性能就提升了。

（InfoQ 编辑注：林仕鼎在自己的博客上写过三篇文章，专门评论火车票系统架构的设计。具体请见：简单讨论火车票系统后面的架构设计，​再谈谈火车票系统，三谈火车票系统）

InfoQ：我注意到，您一直在用存储系统的例子在讨论 12306，其实这跟火车票本身的业务逻辑没有关系。我感觉这是一个通用的系统架构的设计问题，对于工程师来说，要怎么学习才能对这些系统架构设计有了解呢？

林仕鼎：

是这样的，不同系统有业务逻辑带来的固有差异，但却具有更多的作为系统的共同点。还是以存储系统为例，在我看来，做一个存储系统有三部分工作：第一是存储系统本身对数据的组织，第二它是个分布式系统，第三它是个操作系统。

第一部分就是存储系统自身的业务逻辑，数据的组织就是怎么去做文件系统，怎么去做对象系统，怎么去做数据库。这些涉及到的问题是，数据在介质上怎么排列，索引该怎么建，修改的逻辑应该是什么样子——比如是原地修改，还是在后面追加然后合并等等。

分布式系统要解决的就是数据怎么分布，如何容错的问题，简而言之就是 partition 和 replication。而操作系统要解决的问题实际上就是如何在面临压力的时候合理的调度资源，如何去实现硬件所能提供的最大资源输出，同时保持稳定。 现在很多存储系统的设计或实现，其实那只是在第一个层面的工作，在其他两个层面并没有深入。真正做一个完整的存储系统是非常难的，这也是很多项目仿照存储系统论文的设计，依葫芦画瓢，却没有取得很好效果的原因。

火车票系统也是如此，卖票的业务逻辑只是其中的一部分，它同样也有需要分布式系统和操作系统的支持。

说到学习，我个人的看法是要不断设计并搭建实际系统，同时注意方法论和设计理念的学习和提炼。这好比一个武林高手，内力、招式和实战经验缺一不可。编程能力就是内力，需要勤加修炼，不断对代码进行重构。实战经验通过战斗获得，也就是需要实际搭建系统。而招式呢，则通常是前人积累下来的，来自于拳谱或剑法，也就是所谓的武功秘笈。我总结过一篇学习材料，可作为入门功法。

内力、招式和实战经验，这三者通常不是单独成长的，只有在一次次的迭代过程中才能得到提升，即在实战中锻炼内力并加深对招式的理解，而后两者可以带来更多实战的机会和成功概率。

InfoQ：百度用 ARM 做存储服务器，您对冷数据和热数据的存储有什么建议？比如说网盘（共享居多）服务，需要定制什么样的存储服务器好？在线备份（写多读少）服务怎样定制比较好？又比如对 IOPS 要求高的数据库存储服务怎样定制比较好？

林仕鼎：

我们希望硬件比较统一，而不是有很多种的硬件。对于不同的需求，尽可能通过软件来处理这种不同。我做 CCDB 的出发点也是希望能用一套统一的存储技术体系来适配不同的存储需求。之前提到了存储系统逻辑上的三个层次，可以按不同情况映射到不同的硬件介质上。比如说你的场景是写多读少，那就不引入 Flash 这层，直接使用硬盘。具体实现是在部署的时候，你会有个配置，配置上你定义它没有 Flash 只有硬盘，或者调节 Flash 和硬盘的比例。

于是，在合理地定义软件系统架构之后，我们把需求的不同转化成了配置问题。在硬件模型上，趋向于归一化到一个标准架构，通过调节硬件参数，配合软件系统满足应用的不同需求。

（InfoQ 编辑注：目前阿里、腾讯、新浪等，也都在进行硬件机型标准化的工作，需求类似的服务器硬件机型很多都在进行合并。虽然可能会造成闲置资源的浪费，但由于批量采购统一的机型更加便宜，整体成本还是有所降低的。）

InfoQ：百度目前在 SDN 这方面采用的什么方案，定制的交换机么？有哪些进一步的打算？

林仕鼎：

在很多材料中我都提到，我们对数据中心系统的设计思路是，application-driven 和 software-defined。网络是数据中心的一部分，我们同样希望它越简单越好，通过应用和软件系统的合理设计，可以使其变得更简单。

以前有人问我，我们的一个数据中心有多大。我的理念是，一个紧耦合的逻辑数据中心应该尽量限制在万台以内，这里的收敛比最好是 1:1，而数据中心之间的互联带宽和延迟可以低一个等级。上层应用如果需要超过万台的规模，则自己按照数据中心去切分，把无需紧密相连的模块部署到不同的数据中心上。在这个前提假设下，我们数据中心的内部互联和相互连接都可以做得比较简单。

我个人的看法是，SDN 更适合于拓扑结构需要经常变化的复杂路由情况，比如广域网。我们现在也在做一些 SDN 的研究，比如通过公网搭建 overlay 降低数据中心互联的成本并提高可靠性。

InfoQ：之前听说百度的负载均衡系统也是自主研发的，基于 64 核处理器，可为业务提供最大 320G 的负载均衡。另外之前听杜熙介绍过，BAE 这块的路由算法也是带智能的随机路由，会跳过繁忙或故障的后端节点。能简单介绍一下百度负载均衡系统的设计思路吗？

林仕鼎：

百度外网接入的负载均衡系统是我们自主研发的。BAE 的路由算法相对来说简单一些，更多考虑故障处理的问题。负载均衡算法其实很简单，把请求轮流分配到某几台机子上面去，在出问题时跳过故障机器。只要能知道目标机器的状态，这个实现并不难。

InfoQ：通过软件定义硬件后，将会出现很多一体机，是否会出现各家做各家的，结果出现标准不统一，对软硬件发展不利呢？或者会出现另外新标准？百度是否会出新标准呢，像以前提的 ARM 存储服务器一样。

林仕鼎：

我倒不觉得会在大型数据中心里出现很多一体机，一体机可能更多按终端的方式销售到企业里。在软件定义数据中心之后，整个数据中心成为一台机器，原先的节点成为一个部件。软件需根据整个数据中心的架构来开发，如果有一体机，那也是整个数据中心的系统。

我们对硬件的要求很简单，硬件的设计原则最好是简单、傻（dummy），同时对外暴露所有可编程的接口（programmable），复杂的控制逻辑由软件实现，而且在全系统规模进行考虑。

新标准我们也在考虑，不仅仅是 ARM 服务器，还有机架。我们说可编程，不只是服务器可编程，服务器周边的东西也需要可编程，这包括机架位置，包括主板温度、风扇转速等等，这些都需要可编程，也需要可以收集数据。

InfoQ：去年，Frank Frankovsky 在 Open Compute 的网站上提到他们的 Open Rack 和百度、腾讯设计的 Project Scorpio 这两个规范计划在 2013 年合并。这个合并的计划进展是否顺利？

林仕鼎：

合并的计划我不是很清楚。

如起先的介绍，其实我们内部做的事情比起 Open Rack 会更多一些。未来我们也希望能够将这些思路和实现方案分享出去，多做一些开源方案，包括软硬件架构，让大家了解我们在做些什么，也帮助业界共同进步。

在 4 月 25 日 QCon 北京的主题演讲上，林仕鼎将会带来主题为《架构设计与架构师》的分享，就系统领域中基本的存储、计算、分布式技术以及服务模型进行分析，从另一种视角看待这些领域问题。敬请期待！