本文最初发表于 2015年6月29日，最初分为七部分发表，2015年7月7日连载完成。
第二届OCP峰会过后不到一周，2011年11月1日，百度、阿里巴巴、腾讯（合称BAT）三巨头在英特尔（Intel）的支持下发起天蝎项目（Project Scorpio）。相隔只有半年的这两个项目因诸多共性而经常被放在一起比较，不过，天蝎项目最初的构想远没有开放计算项目（Open Compute Project，OCP）那么宏大，而BAT在IT基础设施建设上的成就也不止整机柜服务器那么简单。
在具有代表性的“自主”IT基础设施建设上，BAT各有侧重，可以不太严谨的说：阿里去IOE，腾讯TMDC，百度领舞天蝎。后两个看似均在OCP覆盖范围内，其实也是三家都在做的事情。
进一步展开前，先建立一个粗略的格局对照组：
- 百度对Google，搜索，最先确立的一个中美对应关系；
- 阿里对AWS，电商和公有云；
- 腾讯对Facebook，社交巨头。
微软与金山并非生于互联网，微软在社交尚未败阵之时，两者完全不是一个量级。如今，至少在中国市场上，金山系的小米手机可以秒杀Windows Phone，而金山云要想追近Windows Azure（全球已更名为Microsoft Azure），看来仍是遥遥无期。
从腾讯数据中心建设看中美差异
BAT都有自建数据中心，但是美国的互联网巨头们自建数据中心更为普遍，最关键的区别就是——我们百说不厌的“国情不同”。
同样是起家于社交服务，腾讯的资历比Facebook老，投身数据中心建设的时间也更早。腾讯2008年就开始建设位于天津滨海新区的数据中心，2010年1月封顶，12月建成。Facebook的第一个数据中心2010年1月才开始建设，却几乎在同时完工，建设进度不可同日而语。
腾讯天津滨海数据中心外景，图中左侧建筑主体为当时尚未启用的4号楼，中间露出一角的为3号楼（来源：张广彬拍摄）
腾讯的第一代数据中心从2006年起步，在深圳宝安租的一栋厂房进行改造。2007年启动的天津滨海数据中心发展为腾讯第二代和第三代（二期）数据中心，设计目标为可承载超过20万台服务器，是目前亚洲最大的数据中心之一；属于二期的3号楼，供电容量60MW（30×2），号称亚洲单体供电能力最强的数据中心，单机柜平均容量8KW，高可到10KW。3号楼能承载10万台服务器，差不多相当于8万个城市家庭的总用电量。
天津数据中心从开始拿地到最后交付，前后差不多用了三年时间。腾讯是第一次建设这么大规模的数据中心，有经验欠缺和天气的因素（2009年年底，天津遭遇暴雪），但Facebook也是第一次，却只用了不到一年的时间。
腾讯天津数据中心3号楼外景和内部大堂显示的运营参数，当时投入生产只有半年多（见安全运营天数），进驻服务器较少，实时负载才1.3MW左右，PUE也接近1.5。随着服务器数量的增加，这两个参数都会向设计值靠拢（来源：2014年9月11日拍摄）
百度在山西阳泉的数据中心，建设周期为四年，一期总建筑面积达12万平方米，从2012年8月19日奠基开工，到投入使用，也经历了两年左右的时间；美国Switch公司在拉斯维加斯的SuperNAP 9数据中心，由3个分段组成，面积47.1万平方英尺（近4.4万平方米），供电能力可达50MVA，预计建设工期一年，因为赌城允许24小时施工。
上面这组数字还算是接近的。总体而言，美国互联网巨头建设数据中心的进度更快，不得不提“中国特色”。相比美国，我国的数据中心建设主要受三大因素限制：土地、空气、产业环境——简而言之，就是“环境”。
首先，美国地广人稀，可以毫无负担的采用单层仓储式大开间的设计，如Facebook的数据中心，单体一层大开间容量就可达到十万台服务器量级。与楼房相比，框架简单，强度要求不高，不用考虑楼板承重问题，建设速度快，建好后直接进驻机柜、微模块、集装箱无压力，部署速度也快。
2013年8月底，夕阳下的Altoona数据中心建设工地，可以清晰的看到两层阁楼式结构，只在地面层放置服务器（一层大开间）。占地约194英亩（78.5万平方米），到2013年11月中旬，每天有超过200人工作，累计工时近10万小时（来源：Facebook官网）
其次，空气质量好，可以直接采用外部空气冷却（自然风冷），像Facebook就是上层阁楼进风和出风，外部空气进入后与适当比例的热通道（hot aisle）回风混合（必要时喷水雾降温），送入服务器机架前端所在的数据中心冷通道（cold aisle）。100%自然空气冷却，没有空调水冷那么复杂的管线，也降低了对数据中心建筑的要求，同时提高能效和建设速度，可谓一举两得。
最后，美国的运营商数量众多，互联网巨头在网络建设上有很大的自主权，Google甚至在多地推出了光纤接入服务。因此，在偏远地区建设数据中心，网络接入不会成为制约因素。
反观中国，由于全国网络建设的不均衡，BAT等互联网巨头，建设数据中心要首选靠近用户的地方，通常在人口密集的一二线城市附近（如百度M1数据中心在北京市酒仙桥区域），楼房必须是常态，不敢奢望单层仓储式大开间。即使是在相对偏远的地区，如融科智地建于大庆市东部的大庆联想科技城云计算数据中心，也因为政府对建设用地容积率的规定，必须建成三层楼房。受限于地块容积率、建筑覆盖率等硬性条件，盖两层、三层，甚至五层楼的结构，会带来很多制约。譬如，集装箱在美国单层仓库式数据中心可以很方便地进出，而在中国却上不了楼。
万国数据位于外高桥科技园区的上海自贸区数据中心，阿里与百度均为其客户。多层建筑，以及由此而来的层高、立柱等限制，都是在前几篇文章Google和Facebook的数据中心照片里很难体会到的（来源：GDS官网）
另一个有目共睹的问题就是空气质量，特别是京津地区，近几年的状况堪忧。腾讯在天津数据中心部分尝试过空气自然冷却，但是空气中的含硫量过高，腐蚀了许多硬盘的电路板，导致硬盘故障率上升很快，脱硫方案成本又非常高，后来只能关闭自然冷却，改回内部循环。因此，空调和水循环冷却系统仍不可少。典型的做法是一层接市电、装柴油发电机，以及制冷设备和复杂的水循环管路，二、三层布置服务器机柜等IT设备及电、冷支持系统（如腾讯天津数据中心3号楼）。这样的话，基建工作复杂、要求高，IT系统的部署则受限于电梯等中间环节，总体周期长，PUE（Power Usage Effectiveness，电源使用效率）也无法与Facebook相比。
浪潮为新风制冷数据中心设计的SmartRack高温耐腐蚀节点，主板、硬盘、内存、电源等部分都有涂覆，可在45度的高温环境中正常运行（来源：2015年2月拍摄）
考虑到中国数据中心市场的现状，BAT在加大自建数据中心力度的同时，仍与运营商或第三方数据中心服务提供商保持紧密的合作。百度有阳泉，阿里建张北，两者还在上海使用万国数据（GDS）的数据中心，阿里云与华通云数据（华数）的合作也由来已久。据说腾讯的服务器分布在全国13个城市的58个数据中心（这个数字应该在变化），可以确定的是，腾讯在天津、上海、深圳都有大型数据中心，天津滨海为自建，深圳坪山为联通按照腾讯的（数据中心及微模块相关）技术标准和规范建造，上海青浦则是腾讯与电信合建，建筑面积近5.8万平方米，由4栋数据中心楼、1栋业务楼和1座35KV变电站等主要建筑组成，全部建成后可容纳10万台服务器。
2015年6月，腾讯在重庆两江新区的数据中心正式开工建设。该项目于2013年年底签约，预计总投资金额为10亿美元，占地面积150亩（10万平方米），首期建成规模为10万台服务器，最终将建设为30万台服务器规模的大型云计算数据中心。重庆数据中心是腾讯在中西部地区建设的首个大型数据中心，也是其全国第四个大型云计算数据中心。这些数据中心都位于人口密集的一二线城市附近，好处是明显的，建设上不利的外部条件也难以规避，特别是除天津外，均处在炎热潮湿的南方，对数据中心的散热提出了很大的挑战。
腾讯TMDC与模块化潮流
前面已经提到，腾讯的数据中心至少发展了三代。据腾讯IDC平台部高级总监杨晓伟介绍：腾讯的第一代数据中心采用传统的电信解决方案，数据中心PUE（能效比，越小越好）差不多在1.6左右；第二代数据中心以天津滨海（一期）为代表，开启了腾讯超大规模数据中心的建设历程，采用水侧自然冷却技术，PUE降到1.4；2012年，腾讯进一步创新，自行研发了第三代的数据中心技术——TMDC。
TMDC即腾讯模块化数据中心（Tencent Modular Data Center），指完全按照模块化设计思路搭建的可快速部署的数据中心模型，数据中心内部由多个完全相同的微模块（Micro Module）组成；微模块则是以若干机柜为基本单位，包含制冷模块、供配电模块及网络、布线、监控在内的独立的运行单元，全部组件可在工厂预制，并可灵活拆卸，快速组装。
换句话说，微模块数据中心就是IT设施（服务器、网络、存储、机柜）加上部分基础设施，如高压直流UPS、末端精密空调、末端配电等，是一个对外部有部分依赖的微型数据中心。工信部2013年11月中对腾讯宝安数据中心的实测表明，TMDC 2.0内部（不含外部空调系统如水的损耗，市电+高压直流）的PUE达到1.066——要注意这不能代表整个数据中心的PUE水平。
微模块的关键是产品化、模块化，把数据中心里偏IT的部分打包成一个标准化的产品，从“风火水电”等数据中心基础设施中独立出来，主要组件如行间空调、直流电源、电池等，都是普通的标准化产品，商业化程度高，方便灵活配置，随时减配或增配，还支持在线扩容。如果说集装箱数据中心的应用场景优势在室外，那么微模块主要是解决数据中心内部的快速部署。微模块在结构上与集装箱数据中心最大的区别是可拆卸，能够适应国内大多数厂房的条件，对建筑基本没有特殊要求，而且方便拼装、改造、搬运。每一个微模块可以看作一个微型的数据中心，可以相对独立运行，具备自愈的能力。
产品化和模块化意味着去工程化，TMDC实际上把原来数据中心工程建设中机房精装修、高架地板、回风天花板、列头柜、配电柜、空调、消防、监控、现场测试验证等工作全部集成在微模块这样一个产品里，以前的大部分现场工程都可以在工厂预制完成，现场组装所需人力和时间都大为缩短。
腾讯天津数据中心3号楼一层和楼顶的管道，这是典型的工程，很难模块化。整个天津数据中心有上千个阀门，清楚的了解上千个阀门的具体位置，也成为天津运营团队的工作难点之一（来源：腾讯提供）
这样还实现了数据中心IT建设与土建的解耦，不用等待机房工艺条件明确再做建筑设计。因此，腾讯拿到一块地之后，可以先以最简单的厂房形式报建，把楼先盖起来，也不用考虑分割机房，可以是一个大开间。厂房盖起来，把一些基础的水电配套管路做好，再把柴发、冷机等基础设施装好，整个土建部分就完成了。IT部分完全根据需求去下单定制，即土建部分先行，虚位以待微模块，从而可以免受机房建设进度的影响。譬如前面提到的上海青浦数据中心，是腾讯首次对外采用与运营商合建数据中心的模式：腾讯负责土建建设、电信负责工艺建设，土建与工艺解耦、同步展开，将项目建设工期从30个月减少到24个月，节省了半年的时间。
微模块的灵活性和效率也是腾讯看重的优势。传统数据中心设计时不知道机器的布局，采取就高不就低的原则，每一个机柜都得按照高功耗的需求（供电、制冷）设计，可能造成数据中心设计容量远超实际使用的容量，造成很大的浪费；投产之后，可能会出现高功耗和低功耗的机柜混杂在一起的情况，也会产生一些局部的热点。TMDC把制冷系统从整个机房离散到微模块里，可以自行配制高低功耗类型，设计不同功耗等级的微模块；或者把所有微模块的功耗密度都设计成一样的，不用去区分高功耗模块和低功耗模块。微模块内部可以同时有高功耗和低功耗的服务器，因为微模块内部的制冷空间非常小，行间制冷的优势得以体现，可以在一个小空间里形成一个相对均衡的静压箱。
腾讯天津滨海数据中心的部分模块使用了整机柜（图中近处可见8个）。TMDC同样采用封闭冷通道的设计，便于发挥行间制冷的优势，对南方炎热潮湿的气候和非自建数据中心的适应性较好（来源：腾讯提供）
从数据中心运营的角度来看，微模块的颗粒度比数据中心小，又比服务器乃至机柜大，作为标准化的资源居于二者之间，便于全局调度。以微模块作为一个资源运作单位，可以整体上架、整体改造（如服务器机型发生变化）、整体退役，并且方便搬迁，不受服务器与数据中心生命周期不一致的影响；业务需要分布冗余的时候，可以微模块而不是服务器作为容灾的基本单位，同一个园区可以跨微模块分布，更灵活和节省投资。数据中心基础设施（风火水电）的运营与IT运营也分开了，可以大幅度简化管理。
下一步是数据中心监管控系统的南向和北向接口的标准化工作。南向接口是面向微模块内部的控制单元接口，北向接口是到运营管理平面的接口，腾讯希望把这两个软件接口标准化，这样就可以用运营管理系统把海量的数据中心智能、有效地运营管理起来，化解运营方面日益严峻的挑战。前两篇文章中我们已经粗略谈过Google和Facebook在这个方向上的努力，可见大势所趋。
在各种新业务层出不穷、快速发展的互联网时代，数据中心建设速度只有更快，没有够快。美国和中国的互联网巨头都将模块化数据中心作为发展方向，即数据中心建设尽量由传统的工程项目变成工厂生产、现场组装的方式，标准化、快速部署、降低成本。从这一点来说，腾讯的微模块数据中心与Facebook的RDDC（Rapid Deployment Data Center，快速部署数据中心）基于同样的思想，只是由于国情不同而在技术路线上各有侧重。
在大环境允许的情况下，像Facebook这样的公司，已经在尝试包括基础设施在内的整个数据中心的模块化。中国则不同，单凭水循环管道的存在，就很难实现数据中心基础设施的模块化。在这种情况下，围绕IT设施的模块化工作便成了BAT的重点。以机柜为单元的天蝎项目是一例，而将多个机柜连同冷/热通道组件等作为一个整体是更大范围上的模块化，如百度的预模块、腾讯的微模块，Facebook的RDDC也包括相应的部分。
浪潮宣称，微模块数据中心（MDC）的部署速度可以是整机柜的三倍
微模块数据中心不仅具有模块化数据中心标准化、部署灵活快速的优点，还方便迁移，对使用第三方数据中心格外有帮助。当然，百度和腾讯的业务情况不同，运用起来侧重点有所差异：腾讯的产品很多，一个业务上线初期很难估计其使用量，微模块颗粒度相对较细（又比整机柜粗，交付更快），小量部署也更具经济性；百度预模块的做法更像Facebook和Google，便于快速大规模部署——Facebook在瑞典实践RDDC，动因就是瑞典人工和物料贵，Facebook希望用模块化预制方式解决当地人手短缺的问题。
注：本部分参考了腾讯IDC平台部技术发展中心副总监朱华、腾讯数据中心架构师李典林的演讲和时任腾讯天津数据中心高级经理闫昆的介绍。
阿里“去IOE”的难与易
随着阿里云的兴起，阿里越来越多被拿来与亚马逊（Amazon）比较。不过，我们也知道，阿里巴巴集团当初分兵淘宝，是为了打败eBay（易趣）。正是这段经历和中国的国情，使阿里具备了一项亚马逊暂时还无法匹敌的技能——支付宝。
由于美国的信用卡普及程度高等原因，亚马逊在支付上布局很晚，进展也堪比百度的账号体系建设。而阿里在没有大上阿里云之前，淘宝更像eBay，支付宝对应PayPal。当然，淘宝与eBay、支付宝与PayPal在具体业务和实现手段上有太多的不同，这里只讨论他们的相似之处。
eBay/PayPal在业务类型和基础架构的风格上与Google、Facebook这些“典型”的互联网巨头有很大差别。PayPal和支付宝的核心都是支付业务，属于要求较强一致性的交易型应用，这意味着他们的技术路线更容易带有传统金融企业（如银行）的特征。eBay/PayPal是IBM XIV磁盘阵列的用户，我在SuperNAP数据中心里见过据称属于eBay的NetApp FAS家族全闪存（配置）阵列，还有前不久热炒的PayPal从VMware转向OpenStack……全是带有传统企业色彩的用例。
当然，最有说服力的是，PayPal（曾经）架构着世界上最大的Exadata OLTP（On-Line Transaction Processing，在线事务处理）系统，并使用Oracle在2010年推出的第三代数据库一体机Exadata X2-8。这表明PayPal将Oracle用于核心业务（关键业务数据库），而且不是很久远的事——这时候，阿里巴巴和淘宝的技术团队已经开始着手“去IOE”了。
顺带说一句，Exadata主要定位仍然是OLAP（On-Line Analytical Processing，在线分析处理）应用，据称其第一个生产上线系统在苹果（Apple）。2011年iCloud推出之前，还传出苹果向EMC旗下的Isilon订购了最多12PB存储设备（集群NAS）的消息。苹果的互联网基因是没有Google和亚马逊那么纯，而向其数据中心发起的下载请求与交易行为的关联度也很高。
回来说淘宝。淘宝是在2003年5月初上线的，为了快速上线，采用了LAMP（Linux+Apache+MySQL+PHP）的网站架构，完全符合现在的开源潮流，没有一点儿“IOE”的影子。但是，那时的MySQL还很不成熟，随着交易量的迅速上升，不到一年时间，MySQL就被替换为Oracle。
能替换为Oracle，离不开一支强大的DBA团队，当时淘宝有多名Oracle ACE（Ace即扑克牌中的A，Oracle ACE是Oracle公司官方推出的，旨在认可和奖励Oracle技术社区中技术娴熟、并愿意分享他们的知识和经验的成员为该社区所作的贡献）——前面提到的PayPal团队中也有。不过，彼时淘宝还缺乏熟悉硬件的人才，按照“淘宝技术大学校长”子柳所著《淘宝技术这十年》一书中的描述：在数据量变大，需要由本地存储转为共享存储时，淘宝选择了NetApp的NAS（Network Attached Storage，网络附加存储，文件协议）作为数据库的存储设备，配合Oracle RAC（Real Application Clusters，实时应用集群）实现负载均衡。
经历过那段岁月的人看到这里，不免会心一笑：2004年前后NetApp为了回应EMC等竞争对手的质疑，拉上Oracle为自己站台，证明Oracle数据库可以在NetApp的NAS设备上正常运行，一度声势颇大。但“能用”不代表效果好，至少以当时的情况来看，以NAS承载关键业务数据库应用，确实不是一个明智的决定。于是，淘宝又采购了Dell|EMC联合品牌的SAN（Storage Area Network，存储区域网，块协议）设备，才算解决问题。
Oracle RAC很快也不能满足应用需求了，2004年下半年，淘宝采购了IBM最新的Power5 590，大家争相与之合影。用原支付宝DBA冯大辉的话说，“本来淘宝应该最先上线，不过他们还想等等，看看稳定性，于是支付宝就先上去了。”Oracle运行在小型机上，存储从EMC中低端的CLARiiON CX系列升级为Sun OEM自日立（Hitachi，有子公司HDS）的高端存储，再到EMC Symmetrix DMX高端存储。
至此，IBM小型机、Oracle数据库、EMC高端存储的“IOE”组合正式成型。这三驾马车构成了一个从软件到硬件的完整商用数据库系统，甚至可以说是同类产品中的最佳组合，而其Scale-up架构+专有软件的特性与Scale-out架构+开源软件的“互联网Style”完全是两个方向，背道而驰。
所以狭义的“去IOE”，基本上只是阿里一家的事。从主营业务的需求看，国内的百度、腾讯，国外的Google、Facebook，从没有过IOE的必要，自然也不存在去IOE的经历。
技术架构是为业务应用服务的，需求与手段相匹配就是适用的。相比典型的互联网应用，支付宝的业务更接近银行，采用在金融行业中得到广泛验证的“IOE”本无可厚非。谷歌中国技术总监谷雪梅也曾明确表示，在严格要求一致性的Google广告系统中，（以Oracle为代表的）传统的交易型应用仍然是更好的解决方案。
不过，阿里巴巴集团还是在2010年前后走上了“去IOE”之路。
没有找到淘宝/支付宝团队欢迎小机的合影，这里是支付宝官方微博发布的2013年6月20日“欢送为支付宝用户服务了5年的最后一台小型机”的照片，图中有阿里巴巴“去IOE”运动的发起者王坚博士
其一是费用。以阿里巴巴集团的情况而言，Oracle数据库许可的开销不算很大，花费最多的是其运行平台——IBM小型机和EMC高端存储的购买及维保费用。互联网行业的公司发展迅速，集中式数据库系统会逐渐成为业务的瓶颈，投入重金升级硬件在资金和运维上的压力都很大。
其二是可控性。“IOE”组合在硬件上选择范围很窄，软件上难以根据自身的需求改造。在技术上对这几家大厂逐渐产生依赖感，会进一步推高成本，甚至不需要Oracle的业务也用，不需要用高端存储的数据也用。
两个因素存在相关性——不可控的话，费用问题就解决不了。但可控性是更重要的，开源+自研应该能够解决。
首当其冲是去“I”，因为小型机IBM一家独大，熟悉AIX的技术人员也远没有Linux多，在设备和人员上的选择余地很小。POWER+AIX的组合一大问题是因封闭而影响了生态系统的规模，IBM先后推出PowerLinux和OpenPOWER，大打开放牌也证明了这一点。
能够去“E”则要感谢闪存技术的成熟。以磁盘技术的IOPS和延迟，PC服务器集群运行Hadoop这样的离线分析型应用还行，无法满足Oracle或MySQL等在线交易（OLTP）型应用的需求。SSD（Solid State Drive，固态盘）则让几台PC服务器就可以拥有媲美高端存储的I/O性能，淘宝/支付宝更一度成为PCIe闪存卡供应商开拓国内市场的标志性客户。据称，阿里采购的SSD占全球总销量的1%（统计方法未知，从第四章定制SSD部分Google和Facebook的数字来看，并非没有可能）。
“去IE”相对容易且很有必要，已经为越来越多的“IOE”用户所认同，晚一些的如中国移动通信集团浙江有限公司王晓征所说：“去IE技术难度可控，设备标准化降低了对供应商的依赖度，最关键是真能省钱！”Oracle在阿里发动“去IOE”之前推出的Exadata数据库一体机原则上也是去“IE”（当然不会去“O”），只不过最初仅能用于OLAP（应用场景更接近Hadoop），正是从第二代产品装备SSD开始，Exadata才逐渐演化为“OLTP也行”的平台，以后关于融合系统的文章会有详细分析。
符合天蝎2.0规范的阿里整机柜服务器ALi Rack（左）及其冷存储节点（右）。阿里巴巴集团发力天蝎整机柜服务器即始于2.0，预计部署量将随着数据中心的建设而迎来明显增长（来源：2014年7月拍摄）
不论是为了可控还是降低成本，POWER迁移到x86，AIX换成Linux，设备和人才的选择范围大为扩展，在传统企业市场上，属于U2L（Unix to Linux）的范畴。不过，阿里的影响力加上时代背景，让“去IOE”更广为人知，而IBM反弹最强烈，也从侧面证明去“I”其实不是大问题，真正引发争议的是去“O”的必要性和难度。
去“O”是公认的最难。一则Oracle数据库与上层应用的关系更为紧密，二则在适用的场景里（如要求强一致性的在线交易），Oracle数据库仍然是最成熟的产品。PostgreSQL在中国的基础略欠，MySQL加上大量的工程师，综合投入与产出，效果未必够好。所以，支付宝去“O”的进度最慢，直到小机退了还有Oracle，并用“少量”EMC中端存储承载其Redo Log。
不想用Oracle，又对MySQL不满意，技术实力够的话，自研数据库是个好方法。Google在2009年第四季度提出名为Spanner的远景计划，三年后公布了F1数据库的底层存储组件Spanner。Spanner具有高扩展性、多版本、全球分布（globally-distributed）及同步复制（synchronously-replicated）等特性，F1则加入了SQL查询、Join、索引的事务一致性等能力。由于在一致性和存储等方面更为出色，F1逐渐在Google的Adwords关键词广告系统中取代了MySQL。
淘宝则一方面用MySQL和Hadoop逐步接替Oracle，一方面在2010年6月成立了OceanBase项目组，第一个版本0.1于2011年2月发布。2015年3月25日，淘宝顶级科学家阳振坤在微博上表示“从上周五开始，淘宝/天猫/聚划算在支付宝上的交易，100%都在OceanBase上了。”并宣称“目前OceanBase做到了商业数据库成本的一半以下，这得益于OceanBase不再需要昂贵的共享存储、高可靠的服务器、数据库软件的许可费。”——正好对应“IOE”模式。
“去IOE”的说法当然不够严谨，但如果作为一个宣传用语来看，并不比“大数据”更不严谨，也不比Oracle针对IBM、HP等竞争对手的一系列广告更过分。“去IOE”最引发争议的是其扩大化乃至运动式，对外是阿里的地位和特殊的时代因素相叠加，对内则在一定程度上绑架了自身的业务发展路线，譬如阿里云的RDS（关系数据库服务）迟迟未能支持Oracle数据库。
阿里云与华通云数据（华数）合作的杭州转塘数据中心，旁边是阿里云的“飞天5K”纪念碑。华数的千岛湖数据中心，阿里云也有合作（来源：张广彬，2013年10月拍摄）
阿里云催变阿里数据中心
淘宝飞速发展的这十多年间，互联网电商的格局也发生了很大变化。尽管业务类型有所区别，亚马逊的风头早已压过了eBay，不过在中国市场上，亚马逊电商仍不足以对淘宝系构成威胁，甚至在天猫开设了amazon官方旗舰店……正是阿里云的崛起，才令人们越来越多的将阿里与亚马逊相提并论。
阿里云也在很大程度上改变了阿里巴巴集团的IT基础设施布局。纯粹的电子商务，需要的服务器规模和产生的数据量，与云计算业务相比并不算大。据悉，大约到2012年，整个阿里集团保有的服务器数量还只有五六万台——单纯以数量计，相当于2010年Facebook的水平。当然，台与台之间不能简单的划等号，电商系统使用的服务器配置通常会比较高。然而，在阿里云兴起之后，一年的服务器采购量就达到这个数。
回顾一下2014年AWS的表述：“每天新增的服务器容量可以支持亚马逊作为一个年收入70亿美元企业时的全球基础设施”。亚马逊2015年第一季度的财报显示，销售收入增长15%，达到227.2亿美元；首次以独立方式公布了AWS的业绩，2014年营收约50亿美元，第一季度营收15.66亿美元，同比增长49%，运营收入2.65亿美元，也略有增长。
抛开利润状况不表，IaaS确实是一个重资产投入的行业，基础设施建设至关重要。阿里巴巴集团近两年来在包括天蝎项目在内的数据中心领域逐渐活跃，与阿里云的发展不无关系。
2014年，阿里采购了大约15万台服务器；不久前，浪潮（Inspur）与阿里签订了合作协议，从2015年下半年开始的三个季度内，交付5万台服务器，联想和华为也宣称拿下了类似规模的单子……英国互联网服务公司NetCraft在2015年6月初发布的调研数据分析指出：
“阿里云早在2012～13年就有过一次显著的增长，不过该轮涨势从2013年下半年开始逐渐趋于平缓并在2014年上半年基本处于停滞状态。然而自从2014年7月阿里云牵手浪潮集团，阿里云的Web服务器数量再次不断攀升，其中最大的一次增长出现在2015年4月到5月。”（图及注均来自NetCraft报告，2015年6月3日）
“从今年4月到5月仅一个月的时间，从阿里云直接连接到国际互联网的Web服务器数量就增长了8千多台。这样的迅猛增长已让其母公司阿里巴巴集团一跃成为世界第四大同时也是中国第一大服务器主机提供商。
在阿里巴巴集团所有直接连接到国际互联网的Web服务器当中，目前已有38%来自阿里云，有44%来自2009年收购的万网。如果阿里云近期的这种强劲涨势延续下去的话，在不久的将来，阿里巴巴集团一半以上的Web服务器都将来自于阿里云。
放眼全球，拥有将近3倍于阿里巴巴集团Web服务器数量的亚马逊仍然称霸着整个服务器主机行业，而DigitalOcean最近强势取代OVH坐上了第二把交椅……阿里云当前的增长速度是非常惊人的，几乎能和DigitalOcean的增速看齐（事实上，整个阿里巴巴集团的Web服务器数量在2015年5月的净增长已超越了DigitalOcean）。”
考虑到互联网公司的服务器更新周期多为三年而非五年，阿里这两年的服务器采购量不能视为净增量，有可靠来源表明，阿里巴巴集团现在使用的服务器数量尚未有50万台（基于同样的原因，Google的服务器存量也还不到200万台，尽管已很接近）。无论单台服务器的配置高低，服务器数量的增长，都将在对数据中心的需求上体现出来。
2015年3月25日上午，阿里云数据中心项目在接近自然冷却条件的张家口张北县开工，总投资约180亿元，占地630亩（42万平方米），建设规模为60万台服务器，拟建设为“一点三中心”，即：1个示范展示点（30亩），3个相互备份数据中心（600亩），项目计划分三期实施，每期占地200亩。
阿里巴巴技术保障部系统运营研究员曲海峰2015年6月8日在张北云计算项目工地发布的微博照片，蓝天白云似乎是相关新闻中所称“空气干净”的佐证。如照片所示，这是一幢两层建筑，底层机电，上层IT设备。由于张北缺水而空气条件较好，将采用水冷与风冷结合的方式
张北县位于河北省西北部、内蒙古高原南缘的坝上地区，平均海拔1400米，年平均气温3.2℃，接近自然冷却的气温条件；全县太阳能装机容量12万千瓦，风电装机185万千瓦，并网180万千瓦，用电量不足5亿度，电力资源丰富，是建设大规模数据中心的适宜场所。据称，该县“在2015年1月15日引进阿里云数据中心项目后，组织专人跟进服务，用短短两个月时间完成项目前期准备工作，进入具体实施阶段。”
百度“五艺”与天蝎诞生
虽然李彦宏几乎与Larry Page & Sergey Brin同期投身搜索行业，但是业内仍然公认Google是百度的模板。一如Google，百度在谈论自身的IT基础设施建设时也颇为谨慎。
有句形容BAT的老话：百度的技术，阿里的运营，腾讯的产品。近来百度热衷于披露其在大数据、机器学习（Machine Learning）上的探索，较为贴近上层应用，而底层基础设施方面的集中展示，当数2013年1月11日在南京数据中心公布的五大成果：
- 全球首个ARM服务器在数据中心的规模应用，服务于百度云存储；
- 国内首个大规模部署的定制化整机柜；
- 国内最大的万兆集群（5000台），主要用于HPC业务，支持超大规模机器学习和矩阵类算法。万兆ToR交换机全部由百度自主研发设计，接入成本对比同类商用方案下降83%；
- 百度自研SSD，硬件基于华为PCIe闪存卡，实践应用驱动、软件定义的理念，重新设计了SSD控制系统，取消写缓冲，对外暴露数据通路，把通路调度、读写平衡、擦除等操作都留给上层软件系统；
- 自建数据中心（百度M1，位于北京）年均PUE 1.37，最佳时段1.18，（水侧）自然冷却时间4200小时，接近半年。
百度的ARM服务器，每2U机箱容纳6个节点
不用与阿里飞天5K比先后，百度通过定制万兆交换机，以较低的成本普及万兆（10GbE）为业内同行所羡。这两年来曝光率颇高的ARM服务器和软件定义闪存其实已基本停止发展：ARM在服务器领域的进展未如人意，而百度早就借此达到了战略目的；软件定义闪存（Software Defined Flash，SDF）讲起来很美，实则增加了上层软件的复杂度，百度的应用类型又决定了对PCIe SSD暂时没有那么大的需求，投入产出比欠佳。目前，倒是腾讯对深度定制PCIe SSD有很大的兴趣。
每个ARM服务器带4个3.5英寸硬盘
唯一持续具有行业代表性的，就是整机柜（服务器），我们知道肯定与天蝎项目有关。
截至2014年，以整机柜服务器为主线的百度数据中心发展之路
根据时任百度大数据首席架构师的林仕鼎回忆，2009年，他申请了20万经费，请后来担任百度日本技术经理的张鑫极“去村里买民用配件来攒服务器。”2011年3月，百度启动整机柜服务器“北极”开发项目，合作的硬件供应商包括广达（Quanta）、富士康（Foxconn）、华为（Huawei）、英业达（Inventec）。
林仕鼎微博上的百度整机柜服务器照片
浪潮（Inspur）则在2010年春节期间立项，打造其首代整机柜服务器产品SmartRack V1.0，2011年发布V2.0——从不甚清晰的图片上看，两代产品结构类似，从上到下分为四个像刀片式服务器的区域，节点竖插，交换机布置在右侧，除了前端走线，都与后来（遵循天蝎标准）的SmartRack明显不同。
北极和Cloud Rack
百度Cloud Rack即“北极”项目的产品名称；
百度北极1.0和浪潮SmartRack 3.0对应天蝎1.0；
Cloud Rack 2.0和SmartRack 4.0对应天蝎2.0；
本文后面部分不再重复。
腾讯是浪潮最初开发整机柜产品的目标客户，但由于受供应商数量限制等原因，在相当长一段时间内腾讯采购的整机柜服务器都来自华为和戴尔，浪潮2015年才开始进入。不过，“失之东隅，收之桑榆”，浪潮也没有白忙，先是SmartRack 3.0获得百度采用，后有SmartRack 4.0批量交付阿里，到2015年2月初下线（节点）已达5万台。
第5万台（节点）下线仪式上的SmartRack 4.0（来源：张广彬拍摄）
2011年10月27日，第二届OCP峰会在纽约召开，宣布百度成为正式会员之一。大约半个月之前，腾讯IaaS研发团队的陈晓建和百度系统部的张家军曾应邀赴硅谷，参加讨论Open Rack的内部会议。那时，Open Rack的规范尚未发布（两个月之后），而百度和腾讯却已将整机柜服务器产品化，令Facebook甚感惊讶，但并未给予足够的重视。
部署“北极2.0”整机柜服务器的百度数据中心内部全景照（来源：2014年8月29日，百度张家军在开放数据中心2014峰会上的演讲材料）
那年早些时候，腾讯大约有接近10万台服务器，百度5万多台，阿里2万多台的样子。正如前一节所言，台与台之间不一样，阿里的服务器配置较高，腾讯的配置相对较低（还有不少单路服务器）。但是，除非单机构成相差过于悬殊，数据中心建设、部署和运维的压力，更多的与服务器数量规模而不是单机配置相关——由此也不难理解，腾讯和百度在自建数据中心上发力更早。据说，2014年360的服务器数量和构成与2011年的腾讯相仿，年运维费用5～6亿元人民币，并为带宽少而机柜多的业务，在洛阳等地自建数据中心。
不同来源提供的数字范围有出入，实属正常。可以确定的是，BAT三家的服务器采购高潮即将到来，基础架构部门的一线负责人倍感压力。
2011年11月1日，在深圳参加华为云计算大会期间，陈晓建和张家军遇到了阿里巴巴技术保障部的肖德芳，还有英特尔（Intel）公司的专员。三个人一聊，发现有多半数以上的挑战非常相似，于是一拍即合，分别代表BAT发起“天蝎项目”（Project Scorpio），英特尔担任项目顾问。项目描述如下：
天蝎项目是由阿里巴巴、百度、腾讯三方合作推动、众多服务器厂商参与的一整套整机柜服务器解决方案。英特尔担任本项目顾问。本项目将致力于推进数据中心基础架构的技术发展，和制定开放的行业规范。天蝎项目旨在共同推动行业合作、产业创新和新技术的应用，推动业界统一整机柜服务器规范、推动产业链配套和规模化生产、持续降低营运成本、提高服务器部署速度和运维效率。
由于发起者和目标的相似性，天蝎项目在问世之后，经常被拿来与OCP（Open Compute Project，开放计算项目）一起谈论。看过前一篇文章对OCP的介绍和上面这段描述，不难发现，OCP有包括数据中心、机柜（Open Rack）、服务器（节点）、网络等在内的一组规范，而天蝎项目主要对应其中的Open Rack。
Project的命名可随意可正式，主要取决于与其结合的词或词组能否直接关联项目的内容。随意如Facebook的Freedom project，不提供其他信息，无法联想到是一个服务器项目；正式如Open Compute Project，体现了组织者的“蓄谋已久”。天蝎项目得名于11月1日正属天蝎座，结合其成立的经过，自发和即兴的意味很强。不过，发起者们也明确不会止步于此——还有11个星座可以用呢……
在组织架构上与OCP最大的不同在于，天蝎项目是由三个体量相当的用户发起，创始人在各自公司的职位又不够高，协调的难度和挑战更大。OCP基金会最初的5位董事会成员，不是VP（副总裁）就是CxO，而天蝎项目的创始人中，职位最高的陈晓建是高级总监，与VP之间还隔着两个层级。在这种情况下，先利用BAT的影响力和业界资源把事情做起来，才能去争取更多的公司内部支持，考虑太多“名正言顺”也没什么用。
2011年11月11日，借英特尔在三亚召开第五届互联网数据中心（Internet Portal Data Center，IPDC）峰会之机，向业界公开了天蝎项目。
2011年11月16日，注册了opendatacenter.cn的域名，“开放数据中心”的愿景堪比“开放计算项目”……并设计了相应的Logo。
开放数据中心的标识（Logo），主体为字母e，代表互联网；有个尾巴代表天蝎，绿色代表节能
短短半个月的时间，没出天蝎座的周期，名义上的问题基本解决了，开始着手落地。
2011年12月22日，“在杭州集聚了Dell、HP、IBM、华为、联想、浪潮、 曙光等国内外主流服务器厂商，进行了一次全面而深入的技术研讨会”，讨论会前一天阿里巴巴、百度、腾讯和英特尔起草的“天蝎技术规格”。
经过几次“汇总和讨论所有厂商反馈意见后， 对多处规格与指标进行修订”，2012年4月6日，《天蝎项目整机柜服务器技术规格》Version 1.0正式定稿，即天蝎1.0，于11日在北京召开的IDF（Intel Developer Forum，英特尔信息技术峰会）2012上发布。
天蝎1.0到2.0的中国式标准之路
2012年5月2日，第三届OCP峰会在圣安东尼奥召开，宣布腾讯和阿里巴巴成为正式会员，并开始筹划Open Rack与天蝎项目的融合，期待能在2013年将两个规范合并：We've begun mapping out a convergence between Open Rack, the OCP's specification for an open-standard server rack design, and Project Scorpio, a similar spec under development by Tencent and Baidu. We expect to merge the two specs in 2013.
这反映了双方的共同意愿，不过，OCP方面似乎没有充分吸取半年前错过最佳时机的教训，特别是在天蝎项目已经启动的背景下。Open Rack与天蝎项目在设计理念上存在较大的分歧，而这又很大程度上是由不同的客观环境决定的。
1.0：整合度的权衡
中国服务器厂商的老朋友Supermicro，已在2010年9月中旬举行的秋季IDF上宣布推出SuperRack整机柜解决方案。Open Rack和天蝎整机柜服务器的定制性更强，不是直接把现有的机架式服务器装满机柜，而像是标准化程度更高、尺度更大的刀片式服务器，机柜好比刀片式服务器的机框（Blade Chassis），要整合供电、散热、管理等“基础设施”。
Open Rack只整合了供电单元（Power Supply Unit，PSU），而天蝎项目还集中了散热（风扇）和管理。
天蝎整机柜效果图，机柜中部的PSU和RMC（中图）、背面的风扇墙（右图）以及1U高的服务器节点（左图）是其主要特征
正如前面的文章所指出的，1999年Google的“软木板”机柜服务器就已集中了风扇。不过，Urs Hölzle等人当时那么做多少有不得已的成分，毕竟软木板服务器没有机箱可以用来固定风扇，既然机柜才是真正意义上的机箱，将风扇集中安装在机柜的后门上便是一个合乎实际情况的选择。后来Google步入正轨，有足够的时间规划，做法也不再那么“山寨”，遂回归到每个服务器节点自备风扇的常规设计。
浪潮SmartRack 3.0整机柜服务器符合天蝎1.0规范
Facebook的服务器设计与Google颇有渊源，也影响到了Open Rack。天蝎项目将风扇集中到机柜后部，形成风扇墙，至少有两大好处：
- 可以使用更大尺寸的风扇，具有更高的效率；
- 减少风扇的数量，有助于控制需维护的故障单元。
浪潮SmartRack整机柜服务器的介绍材料，提炼了天蝎项目集中供电、散热、管理的优势，数字仅供参考
既省电，又减少了活动部件的数量，为什么还不集中呢？因为也带来了管理上的挑战——不同的服务器节点发热量有区别，需要的风扇转速可能不同。特别是大直径的风扇会跨越多个服务器节点，即使把同样构造的节点放在一起，亦可能因为工作负载不同，而需要不同的风扇转速，考虑最坏情况，必须就高不就低，仍然难以避免能耗的浪费。
天蝎整机柜后部每排风扇的供电线缆及管理用网线（来源：张广彬拍摄）
利弊可以权衡，集中散热必须提供配套的管理——风扇墙是共享的，但要由RMC（Rack Management Controller，机柜管理控制器）或RBP（Rack Back Plane，机柜背板）实现独立风扇控制。天蝎1.0定义了机柜管理模块（RMC Module），阿里巴巴、百度、腾讯和英特尔构成的天蝎项目组2012年3月下旬起草初稿，经过几次修订，2012年5月16日，完成《整机柜服务器管理RMC CLI规范》Version1.0。RMC不仅监控节点（环境、CPU、内存）温度、电源和风扇状况，还有更新风扇控制板固件、识别插入节点是否属于本机柜、将位置信息刷入节点等管理功能。
百度北极1.0（上）和浪潮SmartRack 3.0（下）整机柜服务器中部的RMC（左侧）及集中PSU（来源：张广彬拍摄）
除了作为重要的发起者之一，百度在天蝎1.0时代是部署的绝对主力，并为天蝎项目贡献了大量工程实践和经验。譬如，供电系统中电源背板是单点，百度与供应商合作，成功实现管理与铜排（busbar）的拆分，铜排基本不会坏，管理部分可以单独更换，就不用冗余设计了，从而降低成本。从供电的角度来看，这种做法也可视为“控制与数据解耦”思路的一种体现。
2.0：内宽与标准化
对于Open Rack将机架内宽扩大到21英寸的做法，天蝎项目一开始是拒绝的。
理由很简单，一个几乎是全新的标准，初期注定没有规模。量上不去，成本下不来。据说，Open Rack刚开始时，仅仅一个机柜的价格就要1500美元。从整个公司的层面来看，BAT对基础设施还没有Google、亚马逊、Facebook那般重视，虽说多花钱是为了最终省钱，但何时能把多花的钱省回来？前瞻是好的，可超越权限太多的事，很难做成。
天蝎1.0基于流行的19英寸EIA 310-D标准机柜，规范中要求机柜承载能力不小于1200千克。机柜外宽不变，内宽拓展2英寸，“皮”更薄、“馅”更大，显然会对机柜的承重能力提出更高的挑战，这也是百度所担心的。Supermicro的SuperRack就同样遵循EIA 310-D标准，一直发展到现在。
尽管机柜标准不变，毕竟要增加供电框、风扇墙，相应的服务器节点也要减去PSU和风扇等部件，这些都是定制工作，初期还是会有采购成本上升的问题。经过内部的说服和协调工作，百度表示可以接受采购成本的小幅增长，接下来是浪潮、广达、富士康、华为、英业达等服务器OEM/ODM付出牺牲，用户和厂商共同培育天蝎生态系统。
腾讯与天蝎
腾讯部署整机柜服务器较早，但天蝎整机柜的比例不高。部分原因在于其两个主要供应商华为和戴尔，譬如华为的Tecal X8000在天蝎规范之前推出，戴尔DCS的G5具备部分天蝎2.0特性。倒是联想提供过天蝎1.0整机柜。
腾讯有5家服务器供应商的数量限制，2014年IBM (System x)合并到联想，浪潮才开始有机会。百度没有类似的限制，不过华为的整机柜只是送测和入围招标，也还没被采用过。
华为Tecal X8000高2100mm，纵向空间44U，内框宽度19英寸，支持1U高半宽服务器节点（左一）和4U高1/4宽服务器节点（左二）；戴尔DCS G5为52U，内框宽度21英寸，单机柜可支持多达120个（1U3）服务器节点（来源：华为X8000服务器硬件维护指南和EnterpriseTech网站）
2012年12月，以天蝎1.0为主体的百度“北极”1.0开发完成，并上线200个机架，部署地点包括我们在2013年1月11日参观的百度南京浦口电信机房；2013年8月，又向内蒙古机房交付数百套产品。在这些远离北京的区域（特别是内蒙古），把大部分组装工作转移到工厂预先完成、现场快速部署可以显著降低人力成本。与传统的机架式服务器相比，天蝎整机柜服务器除了节能，还具有约10倍的交付效率，日交付量从原来的几百台，提高到3000台（节点），乃至5000台（天蝎2.0），对需要快速大批量部署的百度很有价值。
百度“北极”2.0、阿里Ali Rack、浪潮SmartRack 4.0，天蝎2.0样机的正面与背面（来源：张广彬拍摄）
随着天蝎项目的发展，Open Rack的前瞻性与大胆探索也逐渐得到验证。
正如上一篇文章所提到的，Facebook认为EIA 310-D标准的一大问题是过于宽泛，把高度、深度、安装和布线方案以及连接器的规范都留给制造商去定义。类似的情况在“速成”的天蝎1.0上体现很明显，因为《天蝎项目整机柜服务器技术规格》V1.0只定义了框架设计，各厂商的结构实现、散热、供电、管理皆不统一，这使得运维效率、部件通用性、散热优化、供电与散热管理、可互换支持都成为新挑战，也影响了生态系统的正常发展。
腾讯天津滨海数据中心里的两款整机柜服务器，左边并排两个大尺寸风扇（172mm）的是华为Tecal X8000，右边并排三个较小尺寸风扇（140mm）的是戴尔DCS G5，可以直观的感受到风扇尺寸不同带来的显著差异（来源：张广彬拍摄）
仅举供电和散热的两个例子：供电方式和位置没有规定，风扇尺寸没有规定。服务器节点的供电方式可以是铜排或背板，都是铜排位置又可能不一样……如此种种，不一而足。作为一个整机柜规范，不能止于把供电单元和散热风扇集中起来，而应把它们也都视为机柜的组成部分，有统一的标准。这些都交给制造商去定义，那就要走上刀片式服务器的老路，与成立天蝎项目的初衷不合。
联想的天蝎工程样机，供电方面，1.0机型采用居中的背板，2.0机型采用靠左侧的铜排（来源：张广彬拍摄）
机柜本体仍是标准的，可还没装服务器节点就互不兼容了，每家各有一套，规模自然上不去，成本怎么下得来？
标准化不彻底，显然不是19英寸的问题。Facebook在第三届OCP峰会上宣布提交给孵化委员会（Incubation Committee，IC）代号“Knox”的存储项目——即后来的Open Vault，完整体现了Open Rack将内宽拓至21英寸的价值。
如果不考虑通用机架式服务器为两侧导轨留出的空间，21英寸只比19英寸多出11%左右。但是我们知道，对服务器主板和3.5英寸硬盘等大尺寸元件，可不是这么算的。譬如英特尔从至强E5开始大量提供的6.5英寸宽（20英寸长）主板，做成服务器的话，21英寸正好可以并排3个，而19英寸只能放2个，减少三分之一！
第六届OCP峰会戴尔展台上的DCS G5三大组件，内框宽度21英寸。上面是RMC（左侧）和集中的PSU，下面是1U3计算节点。隔壁是广达展台上的Yosemite（机箱）及Mono Lake（主板），这届峰会上OCP推出的提升计算密度利器，后面部分简要评述（来源：张广彬拍摄）
不过，BAT还不稀罕这个，因为天蝎项目的计算密度已经够高，由于整机柜架构的差异（后面会简要分析），短期内OCP服务器有Open Rack助力也赶不上。如果在21英寸机柜里进一步增加服务器数量，双路服务器从1U2变成1U3，整机柜对供电的需求可能超标：假设80个（40×1U2）到120个（40×1U3），每节点按200W计，总能耗就从16kW增至24kW，不放满或掺杂冷存储节点的话实用意义又不大……毕竟，天蝎1.0规定的7～12KVA供电容量，对中国的绝大多数数据中心而言，已然不低。
3.5英寸硬盘外宽4英寸，长度接近6英寸。横向放，要加上SAS/SATA接口和拔插的活动空间，19英寸实际排不下3个，21英寸就很轻松；纵向放，21英寸可以放5个，19英寸则只能放4个，意味着最少20%的差距。
Ali Rack内部节点供电的折线臂（Cable Arm，从前端抽出节点更换硬盘等部件时维持电力供应）特写，周边可见前面横排的3个3.5英寸（希捷SATA）硬盘、后面的铜排和3个140mm风扇、两侧承载节点的L型隔板，都体现了天蝎2.0规范的特征（来源：张广彬拍摄）
于是，从2012年12月30日汇总原始需求，中间经过一次修订，2013年10月完成了天蝎2.0规范Rev 0.5，相对天蝎1.0的主要改进包括：
- 定义了2100mm、2300mm两种高度的机柜，实际可用空间分别为42U和46U；
- 重新定义了机柜的内部尺寸，统一为538mm（21英寸） 内宽；
- 重新定义了每U的高度为46.5mm（Scorpio U，简称SU）；
- 增强了机柜背板功能，并可实现热插拔维护；
- 服务器节点与机柜系统解耦，可实现服务器节点混插互换；
- 明确定义了风扇的尺寸，统一为140×38(mm)规格（每行3个），风扇窗高度4U，能够以1U为单位固定或调整上下位置。
天蝎1.0（左，百度北极1.0）与天蝎2.0（右，浪潮SmartRack 4.0）整机柜对比，可以明显看出内框宽度的差异（来源：张广彬拍摄）
内框宽度从19英寸到21英寸是个重大转折，说明标准的延续性不好，但是该出手时又不能犹豫。经过机架和电源供应商如台达（Delta）与Facebook、Rackspace、Fidelity投资等客户的实践，21英寸内框机柜的成本已经降低到BAT可以接受的程度，除了曾借助Supermicro方案的曙光暂时没跟上节奏，联想（Lenovo）、中兴（ZTE）等国内服务器OEM纷纷活跃起来。
46U的中兴天蝎2.0工程样机顶部特写，注意右上方的U位编号（来源：张广彬拍摄）
在这个过程中，天蝎联盟的构成也逐渐发生了改变。
从天蝎联盟到ODCC
2012年9月，中国电信加入天蝎项目，中国移动于2014年正式加入。
2013年4月10日召开的IDF 2013期间，陈晓建作为天蝎项目轮值主席亮相主题演讲。在天蝎项目的创始人中，陈晓建业界资历最深，又代表腾讯加入了OCP的孵化委员会，虽然是轮值主席，但大家都很乐于他继续干下去。然而，没过太久，陈晓建被调去腾讯云任副总经理，2015年3月又加入UCloud任高级副总裁——巧合的是，同月加入平安科技(深圳)有限公司任基础架构首席总监的朱永忠，距2014年8月调任百度大数据部高级总监也没多久。此前，朱永忠在百度系统部历任高级经理、副总监、总监、高级总监，对魏伟、陈国峰等人负责的北极项目（百度版天蝎）给予了很大的支持。
人事变动非外人可以参透，起码新岗位应该会从中受益。不过，这样的结果，多少折射出即使在BAT，基础设施工作也很难得到足够的重视。
另一方面，进入2014年之后，随着天蝎2.0的成熟，阿里巴巴的积极性大幅提升。至少在推动天蝎项目发展的意愿上，BAT难分高下，再加上电信和移动，原来的协调机制很难继续发挥作用。于是，负责制定标准的工信部电信研究院（中国信息通信研究院）也加入进来，2014年8月29日在北京召开的开放数据中心2014峰会上，宣布成立开放数据中心委员会，英特尔仍担任技术顾问。
开放数据中心委员会的人员构成
天蝎联盟变身开放数据中心委员会，工作覆盖范围也终于如最初设想般扩展到数据中心。开放数据中心委员会（Open Data Center Committee，ODCC）下设服务器、数据中心、测试认证三大工作组，服务器工作组可以视为天蝎项目的自然延续：百度张家军出任服务器工作组组长，阿里巴巴肖德芳也是天蝎项目创始人，担任天蝎整机柜服务器项目经理；中国移动唐华斌担任弹性服务器项目经理，目前负责多节点服务器项目。
在开放数据中心2014峰会上，审批发布了天蝎2.0规范Rev 1.0，在前面版本的基础上，主要改进多了一项：
7. 增加了机柜顶部扩展功能，在交换机数量及节点数量无法满足要求时，可在机柜顶部安装固定交换机，总高度不超过2500mm。
规范的最后部分，还明确提出了对机房物理空间（包括电梯）的要求。
投身ODCC之时，回首天蝎项目之路
数据中心工作组的人数比服务器工作组多一倍，腾讯IDC平台部技术发展中心副总监朱华担任组长，加上张海涛、周洛，占据半壁江山；其他3人是阿里巴巴陈炎昌、百度李孝众、英特尔张敬。
测试认证工作组的5人分别来自腾讯以外的5家组织。
开放的楚河汉界：天蝎与Open Rack
Open Rack证明了自己路线的正确，天蝎2.0也基本从善如流。原计划2013年合并虽然没有实现，但天蝎2.0是2013年成型的，看起来2014年很有希望。不过，个人认为，两个组织为了自身的发展，在2014年各做了一件非技术考虑，甚至带有政治色彩的决定，使得合并基本成为泡影。
从整个框架的角度来看，Open Rack看得比较长远；而在具体的工程实现上，实践证明天蝎项目精于效率，至少在供电布局这一大共性上，值得Open Rack借鉴。
天蝎1.0（浪潮SmartRack 3.0）与2.0（SmartRack 4.0）整机柜对比
复习一下Open Rack V1的供电布局：
- 纵向上，分为3个供电区，每个供电区由3 OU（Open U，48mm）的供电框（Power Shelf）和10 OU的IT设备空间（Innovation Zone，创新区）组成；
- 横向上，机柜正后方有3根等距分布的铜排，严格说来，每根又被供电框分为三段。
3根铜排并不能提供冗余，因为规范不允许多根铜排给同一个设备供电，以免安装在同一供电区的机箱之间产生有害的直流电（DC）再循环。实际上，这么设计主要是为迁就第三代OCP服务器——2 OU的高度上并排3个，各自从所对应的铜排上取电。像Open Vault这种全宽度的设备，也只从正中间的铜排上取电，风扇的布置还得避开左右两根铜排。如此说来，多出的2根铜排便有浪费的嫌疑，不够“Vanity Free”。
第六届OCP峰会期间希捷（Seagate）展示基于其PCIe闪存卡和SMR硬盘的Ceph解决方案，使用了3台第三代OCP服务器（上）和1台Open Vault存储（下）。可以看到每台OCP服务器都从对应的铜排上取电，而Open Vault只从中间的铜排上取电，并不需要两边的铜排（如红色椭圆框中所示），其风扇也像天蝎整机柜的风扇模组一样从后端维护（来源：张广彬拍摄）
3个供电区可以提高机柜的供电能力，不过这种需求并不多见，反而限制了每个供电区（10 OU）和整机柜（30 OU）的IT设备载荷能力。天蝎1.0则将44U的纵向空间，由中间用于部署交换机、PSU和RMC的4U空间一分为二，其中PSU占3U空间，将铜排分为上下两段，各支持20U的服务器空间。
浪潮SmartRack 4.0整机柜服务器的RMC、PSU及交换机。天蝎2.0统一了定制PSU及RMC的规格，交换机仍可以像天蝎1.0规定的那样与它们一起占用4U空间（来源：张广彬拍摄）
在实际执行中，天蝎1.0整机柜的交换机也会被安装在机柜顶端（Top of Rack，ToR）。Open Rack阵营里，同样有Rackspace把供电框和交换机装在机柜中间、供电区分为上下两个，并且支持RMC（Remote Monitoring Controller，远程监控控制器）这样颇具天蝎风格的实现。
支持RMC且兼容Open Rack的供电框（来源：张广彬拍摄）
到了天蝎2.0，干脆规定RMC位于供电框左侧，与PSU共占机柜中部的3U空间，机柜下部空间（节点区1）固定为20U（此U非RU，后面再解释），上部空间（节点区2）为19U（42U规格）或23U（46U规格），交换机数量为1-4台，可部署在两个节点区的任意U位置。供电方式统一为1根铜排，位于机柜后方左侧（正面视角），以尽量减小对风扇墙的阻挡。
Open Rack V2的供电框仍是3 OU，但改为三上三下布局，即上面3个PSU为主（背面图中右侧），下面3个BBU为从（背面图中左侧），2+1冗余。供电框集成BBU（Battery Backup Unit，电池备份单元）消除了对单独电池柜（每6个Rack配1个）的需求，BBU使用因特斯拉而闻名的18650柱状锂离子电芯，性能也比电池柜的铅酸蓄电池更好，但要格外注重安全（来源：张广彬拍摄）
2014年1月底召开的第五届OCP峰会上，公布了Open Rack V2的进展，供电布局向天蝎靠拢：铜排可以减至中间1根（或保留全部3根），供电区也划为上下两个，但供电框仍有2个（共6 OU），有居中相邻和（后来Facebook采用的）相距16 OU两种方案。只有中间1根铜排对Open Vault当然没有影响，安装在左右两侧的（第三代）OCP服务器怎么办？Facebook提出名为Cubby的“子机箱”（Sub-chassis）方案来补救，即把2 OU的机架内部空间切分为左中右三份，统一由中间的铜排供电。
Facebook的Cubby项目示意和实物效果。如果一个机柜装满16个Cubby，成本应该高于保留3根铜排的方案，复杂度更是个问题（来源：张广彬拍摄&整理）
不过，OCP方面对天蝎2.0把每U高度由原来的Rack U（RU，44.45mm）增加到46.5mm非常不解：要么保持RU不变，要么统一到OU的48mm，弄个居中的46.5mm是什么意思？
一方面，21英寸内宽的跨度过大，受重力影响，时间长了，节点中间部位的纵向形变（下垂幅度）可能达2-3mm左右，如果还沿用19英寸内宽时的高度（RU），使用较久的节点可能会与下方的节点贴合在一起，难以拔出。因此，适当增加每U高度，可以加厚底板，对抗变形，Open Rack采用OU也有这方面的考虑。经过百度等方面的实践，认为在原有标准RU的基础上增加2mm就够了，遂命名为Scorpio U，简称SU。
百度Cloud Rack 2.0（天蝎2.0）整机柜服务器局部，注意中间的节点因缺乏厚底板支撑，中部已出现肉眼可见的下垂（来源：张广彬拍摄）
另一方面，天蝎2.0统一采用140×38mm规格风扇，加上风扇盒等构成风扇模组（Fan Tray）之后，高度与每U为46.5mm时的4U匹配很好，（48mm×4）再加6mm则略显勉强。
不同的散热设计似乎是决定性的。同样2100mm高的机柜，天蝎2.0为42 SU，Open Rack V1为41 OU，表面上看只损失1U。实际上，天蝎2.0把42U的空间从下到上划分为20U+3U+16U+3U，中间3U的PSU和顶上3U的交换机都自带风扇，另外36U正好安装9个（5+4）风扇模组，如果少掉1U，就要安装1个3U的背板，感觉不太划算。
联想天蝎2.0整机柜的风扇模组（来源：张广彬拍摄）
2100mm机柜面向租用或现有机房，供电基本不可能超过30A。2300mm机柜主要面向自建或合建机房（腾讯甚至希望50U以上，譬如52U的Dell DCS G5），46U划分为20U+3U+20U+3U，两个3U不解释，20U+20U形成对称的10个（5+5）散热区，“非常完美的布局”。不论天蝎U还是OpenU，2300mm都只能比2100mm多4U，如果2100mm是41(O)U，那么2300mm也会遇到同样的问题。
具体设计上的分歧，各有各的道理，见仁见智。在我看来，每U高度这样的技术问题，不是阻碍两个标准融合的首要因素。
先是，第五届OCP峰会上，微软携开放云服务器（Open Cloud Server，OCS）强势加盟，负责云和企业业务的副总裁Bill Laing直入OCP基金会董事会。从技术角度讲，正如我在上一篇文章中所指出的，OCS更像是做成12U的天蝎1.0整机柜，与Open Rack的差别比天蝎2.0实在大太多，却能立刻在OCP的服务器项目中占有显要位置，足见技术上的“血缘”差异并不妨碍公司与组织间的合作。
论采购量？2011年的BAT可能比不了，2014年的BAT加在一起，未必输给微软；
微软在传统企业市场的影响力更大？天蝎项目的核心人物中缺乏VP级别的代表？都是可以摆到台面上的理由，但也都不是技术因素……
然后，天蝎项目成为开放数据中心委员会（ODCC）的组成部分，这是一个基本与OCP基金会对等的组织，而且带有政府色彩。经此一变，如果没有重大转机出现，两个组织间的合作远比整机柜规范的合并更为现实。
殊途同归看未来
谈到技术上的合作，OCP方面曾经希望与天蝎项目至少在两点上能达成一致：首当其冲是每U的高度；其次是铜排的位置——在左边没问题，能不能与Open Rack左边的那根铜排重合？
天蝎2.0（左）与Open Rack（右）机柜等比例俯视图，中间是天蝎2.0铜排的特写。据说，有厂商曾考虑把铜排旁边的“空地”也用来装硬盘——Open Rack的最后方全都留给了铜排（来源：根据台达资料和Open Rack规范整理）
天蝎项目与Open Rack都志在机柜级别重新定义服务器，两大标准间尽可能的增强一致性肯定是好事。不过，之前一直保持沟通都没能达成一致，在天蝎2.0已经进入大批量生产阶段之后就更难了。OCP不愿意改，已经改过一次的天蝎项目自然也不愿意再改，反复折腾供应商可不行。
天蝎项目与Open Rack主要特征对比表
注：* 代表默认交换机占用3U空间，红色字体代表需要注意的参数或改变
不过，即使统一了每U高度和铜排位置，天蝎整机柜和Open Rack的差异仍然很大。天蝎整机柜的深度超出Open Rack达133mm（1200-1067），一是为了容纳风扇墙，二是加大IT设备的空间。Open Rack留给IT设备的深度为800mm，天蝎整机柜又多了50mm，加上设备内部没有风扇，这些空间至少可以多横置一排硬盘：Open Vault每U可以容纳15个硬盘，天蝎整机柜的（1U）冷存储节点则可以容纳18个硬盘，正好多3个。
2 OU的Open Vault分为上下两层，每层以5×3的方式布置15个3.5英寸硬盘；将Open Vault的SAS扩展器板（左下红色电路板）用基于Intel Atom处理器的Honey Badger轻量级计算模块（左上绿色电路板）替换之后，形成类似天蝎冷存储服务器（右）的产品。天蝎冷存储服务器也基于Intel Atom处理器，优势是在1U空间内容纳18个3.5英寸硬盘，如果改造成Open Vault式的JBOD，可以安置20个硬盘（来源：张广彬拍摄整理）
不同的散热布局，也是导致天蝎整机柜与Open Rack的节点形态不同的主因。由于内置风扇，Open Rack的节点尽量采用2(O)U设计，这样可以使用80mm风扇，比40mm（1U）或60mm（1.5U）等较小直径的风扇更有效率。典型的如Open Vault，基本上是把两层结构装在2 OU的机箱里面了。
天蝎2.0整机柜中的两个半宽计算节点（1U2），设计上完全可以把各自的2.5英寸盘位去掉，做成1U3。只是出于整机柜的供电能力考虑，没有这个需求而已（来源：张广彬拍摄）
天蝎项目就没有这个顾虑，风扇尺寸是机柜的事，节点可以自由采用1U、2U乃至4U（与Open Rack不同，不允许出现0.5U）的规格。1U通常可以达到更高的密度，已成为天蝎2.0节点的事实标准。
两种采用双路至强处理器的天蝎2.0计算存储均衡型节点，均可在不断电的情况下拉出维护硬盘。联想的节点（左）支持14个3.5英寸硬盘，需整体拉出；浪潮的节点（右）支持12个3.5英寸硬盘，硬盘托盘部分单独拉出维护。在宽度（21英寸）和高度（1U）既定的情况下，只能在深度上做文章，这又牵涉到强度……（来源：张广彬拍摄）
所以，基于双路至强的计算节点，天蝎整机柜每U可以容纳3个，2U即有6个，而Open Rack只能做到每2 OU容纳3个。2(O)U的优势是往垂直方向发展，可以放3.5英寸硬盘、PCIe SSD及更厚的GPGPU，具有更好的扩展性。2015年3月10日举行的第六届OCP峰会上，Facebook联合Intel宣布了名为Yosemite（优山美地）的项目，是在2 OU、三分之一宽度（7英寸）的第三代OCP服务器（Winterfell）基础上加以改造，拿掉原来的双路（2S）至强E5节点，换为4个代号Mono Lake（优山美地的一个湖）的单路至强D-1500 SoC节点。这样的话，在同样的空间里，CPU的数量可以翻一番——从2个到4个，计算密度就能追平天蝎的计算节点。当然，若论CPU的运算性能，至强D-1500与E5-2600 v3相比还是有较大差距的。
左为广达展出的四至强D节点服务器（Yosemite）及单个至强D-1500服务器（Mono Lake），右边可见Yosemite与第三代OCP服务器的渊源（来源：张广彬拍摄）
回顾OCP和天蝎项目的发展历史，不难发现：OCP是先有服务器，再发展到机柜；天蝎项目则是先有整机柜，天蝎1.0基本没有定义服务器节点，2.0也只是列出了一些建议和参考配置，具体设计和实现主要由客户和供应商决定。为了争取客户，供应商在节点的密度上下了很大的功夫，每家都维护着多个不尽相同的SKU，节点的标准化工作基本处于刚起步的状态。反观OCP，很早就着手计算与存储的解耦合，几乎与Open Rack同步发展了JBOD项目Open Vault。
与BAT发起的天蝎项目不同，OCP从成立之初就将传统企业市场作为目标之一，推出Open Rack之后则致力于与EIA机柜的转换，只整合供电也相对利于兼容传统机架式服务器，相比之下天蝎整机柜将散热一并整合，机柜架构层面的颠覆更为彻底。不过，从大的方向上来看，计算与存储解耦对在机柜层面重新定义服务器和争取传统企业客户都至关重要，毕竟不能指望传统企业客户像BAT一样按照自己的需求定制服务器节点，提供可自由组合的计算和存储单元是必须具备的手段。
据悉，预计于2015年9月召开的开放数据中心2015峰会上将发布天蝎2.5，以及天蝎3.0的愿景。早有传言说天蝎3.0会考虑计算与存储资源的解耦合及（机柜层面）再耦合，希望也能听到针对传统企业市场的发展计划。
