在提笔写这篇卷首语的时候，我们刚
刚为InfoQ中国过完八岁生日。回溯
到2007年的3月28日，InfoQ中文站正
式上线运营，从此中国的IT技术人有
了一个崭新的学习和成长的平台，
InfoQ中文站从一个不知名的翻译网
站逐渐成长为输出全方位优质内容、
对技术人有着深刻影响的媒体。几分
耕耘，几分收获。让我们感到欣慰的
是，InfoQ在中国IT发展的大潮中把握
住了自己的方向，踏踏实实地为技术
社区做了一些力所能及的事情。
很多时候，只有站在历史的峰峦之
上，才能更清晰地洞察时代风云，更
准确地把握前进方向。纵观过去八年
的发展，中国的IT技术圈发生了翻天
覆地的变化：
越来越多的技术领域开始引领世
界。由于IT是个相对新兴的行
业，特别是在一些垂直细分的领
域，中国的技术水平和国外大体
是在同一个起跑上线，在知识积
累和人才储备方面没有传统行业
差距那么大，中国没有历史包
袱，再加上开放的信息渠道，所
以顶尖的技术人能够在中国的技
术圈里做出影响世界的成果。
越来越多的技术人开始追逐梦
想。古语说，仓廪实而知礼节。
过去八年，中国的IT行业发展很
快，我们的技术人各方面有了显
著的改善，除了技能和经验方
面，还有软硬件的保障，越来越
多的技术人在物质方面有了保障
之后，开始追求兴趣，开始有了
更高的理想，想做一些更有价值
的事情，而这种基于兴趣和理想
的技术驱动力往往很产生惊人的
力量。
中国的技术圈越来越有吸引力。
中国的巨大市场给了IT企业发展
的能量，互联网、电商、社交网
络等领域，都产生了国际级的大
公司。中国人口多，消费能力
强，潜力大，随便做点什么，就
要面临海量数据的处理挑战，现
在中国的一些技术挑战是世界级
的，国外可能没有这样的先例和
经验。这些难题对于技术人来说
的吸引力是惊人的，也能获得巨
大的成就感。
道路决定命运，梦想引领现实。过去
八年，我们（InfoQ）把“促进软件开
发领域知识与创新的传播”作为努力
的目标，而未来八年，我们（极客
邦）将致力于“让技术人的学习和交
流更简单”。和中国的IT企业和技术
人一样，我们的梦想也更高了。梦想
是最令人心动的旋律，又是最引人奋
进的动力。目标已经明确，我们唯有
奋力前行，不负时代的使命。
《中国顶尖技术团队访谈录》是
InfoQ的一个内容品牌，第一季推出
之后收到了读者的热烈欢迎。这次精
选了过去一年InfoQ网站上的精彩访
谈内容，集结成第二季献给大家，作
为InfoQ八周年的礼物，向中国的技
术人致敬。
有梦想，有机会，有奋斗，一定会赢
得美好未来。
InfoQ中国总编辑 崔康
作者 郭蕾
Docker提供了一种在安全、可重复的
环境中自动部署软件的方式，拉开了
基于云计算平台发布产品方式的变革
序幕。腾讯内部对Docker有着广泛的
使用，其基于Yarn的代号为Gaia的调
度平台可以同时兼容Docker和非
Docker类型的应用，并提供高并发任
务调度和资源管理，它具有高度可伸
缩性和可靠性，能够支持MR等离线
业务。为了剖析Docker on Gaia背后
的实现细节，InfoQ专访了腾讯数据
平台部高级工程师罗韩梅。
InfoQ：能否介绍下目前Gaia平台的
状态？你们什么时候开始使用
Docker的？有多大的规模？
罗韩梅：Gaia平台是腾讯数据平
台部大数据平台的底层资源管理
和调度系统，其上层业务包括离
线、实时以及在线service服务，如
Hadoop MR、Spark、Storm、Hive
以及腾讯内部的Lhotse、Hermes、
广点通等业务。最大单集群规模
达8800台、并发资源池个数达
2500个，服务于腾讯所有事业
群。我们是2014年10月份正式上
线Docker，之所以选择Docker，一
方面是因为Gaia本来就一直在使用
cgroups类型的容器，深知其在共
享机器资源、灵活、轻量、易扩
展、隔离等方面的重要意义。另
一重要原因，是Gaia作为一个通用
的云操作系统，适合所有类型的
业务，但是各个业务的环境依赖
是一个比较困扰用户的问题，因
此我们引入Docker来解决，主要目
的还是通过Docker来将Gaia云平台
以更有效的方式呈献给各个业
务。
我们使用的OS是腾讯内部的tlinux
1.2版本，最新版本正在tlinux2.0上
测试，除了Docker，也使用了etcd
用来做服务注册和服务发现。我
们的集群都是同时兼容Docker应用
和非Docker类型的应用的，MR等
应用还是使用的cgroups类型的容
器，其它服务使用的Docker容器，
目前，大概有15000多常驻的
Docker容器，还有大量业务接入测
试中。由于我们原本就是使用的
cgroups容器，所以换成Docker
后，性能基本也无损耗，可以满
足线上需求。
InfoQ：腾讯是如何把Yarn与Docker
深度结合的？
罗韩梅：在腾讯的场景下，首先
一个特点就是，业务总类极大，
尤其是离线处理规模很大，因此
Yarn原生的调度器，效率远远跟不
上，因此我们开发了自研调度器
SFair，解决了调度器效率和扩展
性问题。另外，腾讯的业务特性
多样，因此我们引入了Docker，虽
然Yarn支持不同的应用类型可以实
现不同的AM（应用管理器），但
是对于绝大多数应用来说，他们
并不熟悉Yarn，实现一个支持容
灾、可扩展的完善AM，困难较
大，因此我们抽象了可以使用
Docker的业务，对其进行封装，实
现了统一的AM，并且对用户透
明，而对用户提供的是另一套全
新的基本的、易于理解的高级接
口。同时，我们为Docker业务实现
了统一的服务注册和发现机制，
并也将其封装在了新接口中。另
外，在资源管理方面，我们修改
了内存管理机制，引入了磁盘和
网络带宽管理。
除了Yarn之外，其实我们对Docker
本身也做了一定的修改和bug修
复，对于Registry等服务也做了优
化，保证了其服务的高可靠和性
能。
实现方面，我们并没有使用社区
提供的Docker调度器，我们研发
Gaia的时候社区还没有相应的调度
器，并且我们也有特殊要求，需
要同时支持同时支持Docker类型应
用和非Docker类型应用。
InfoQ：你们如何确定哪些业务适合
使用Docker ？
罗韩梅：我们认为，Docker提供
了一种在安全、可重复的环境中
自动部署软件的方式，拉开了基
于云计算平台发布产品方式的变
革序幕，因此，其实Docker对于
Gaia来讲，只是一个选择，我们并
不主动向业务推广Docker，而是
Docker on Gaia的整套方案，所
以，我们对于需要共享资源、降
低成本，需要支持快速的动态扩
容缩容、容灾容错，以及大规模
分布式系统尤为建议使用Docker
on Gaia 。
InfoQ：能否详细介绍下你们对
Docker以及Registry做了哪些优化？
罗韩梅：对于Docker，我们主要
做了三个方面的优化：首先是bug
修复，比如Docker非0退出时rm不
生效，对于bindmount为true时
config path无法清除等bug。其次是
优化Docker的资源管理策略，比如
内存的Hardlimit的管理策略，不但
使用户进程容易被kill，更加造成
了资源的浪费，对用户估计自己
业务的资源需求也非常高。Gaia引
入了EMC（Elastic Memor y
Control）的弹性内存管理机制。
最后一个方面是资源管理纬度，
Docker在资源管理纬度方面只有
CPU和内存两个维度，这对于共享
的云环境下需要完善，也是目前
相对于虚拟机不足的地方。Gaia引
入磁盘容量管理，网络出入带宽
控制以及磁盘IO的控制维护。其
实不仅仅在Docker层做控制，还将
会引进调度器，不但实现资源的
隔离，还要实现资源的保证。
对于Registry的优化，主要有下面
几个方面：
1. 容量问题。开源的Registry是单
机模式，其容量会受单个机器
的限制。我们修改存储driver，
取缔原有的mount方式，开发后
端存储driver，直接使用
HDFS，实现了存储的无限容
量。
2. 可靠性和可用性的问题。单机
版本的Docker Registry，其可靠
性和可用性都成了最大的问
题，我们引入数据平台部的tPG
系统，实现Registry server的无
状态化，便于实现服务的高可
用性。
3. 性能问题。将单机版的Registry
扩展成Registry集群，并实现在
Registry server pool中的负载均
衡，提升性能。
4. 网络问题。解决了全国不同
IDC的Gaia集群对Registry的访
问，采取就近访问的原则，不
产生跨IDC流量。
5. 自动同步官方镜像。Docker提
供的官方镜像中，有很多还是
非常有价值的，而官方的
Registry又在墙外，为此，我们
自动同步docker的官方镜像到
我们的私有仓库中。
InfoQ：能否介绍下目前的一个
workflow？
罗韩梅：目前使用Docker on Gaia
的方式有三种：1）通过Gaia
Portal；2）直接调用Gaia api；3）
通过上层各种PaaS平台透明间接
使用Gaia。比如在第一种方式中，
用户通过Gaia Portal提交应用，之
后Gaia调度器会自动分配资源，并
且部署、启动Docker容器，用户可
以在Portal上直接查看每个实例的
状态、日志、异常等，甚至可以
直接通过webshell登陆。同时，也
可以根据需求对应用进行扩容、
缩容、重启，以及灰度变更、停
止实例/应用等操作。
InfoQ：目前平台主要部署了哪些服
务？服务之间的调度是如何实现
的？
罗韩梅：目前平台上的服务有
Hermes、通用推荐、广点通、游
戏云等服务，很多服务都需要多
实例部署，因此跨主机部署非常
普遍，而不同服务直接也经常会
有调用的需求，主要是通过Gaia提
供的服务注册和服务发现机制。
具体地，NM（Yarn的一个组件）
在启动Docker容器时，会将该
Docker的真正地址，包括ip和所有
的端口映射，都会通过etcd做自动
的服务注册。对于Docker内部的服
务，我们通过修改Docker源码，扩
展了几个Gaia相关的环境变量，将
IP以及端口映射传入。服务的注册
和发现本质上一种名字服务，因
此不难理解为什么在创建应用的
时候，让用户填一个应用 name的
字段。而这种基于名字的服务是
贯穿这个Gaia的过程的：在提交作
业时，用户不需要指定Gaia master
的地址，而是通过指定Gaia 集群
的name即可；在获取应用的地址
时，也是通过应用的名字获取；
本质上port mappi ng也是一种名
字，只不过是将用户原来expose的
端口作为name，将实际端口作为
value。至此，不难理解为什么
name需要检查冲突。
InfoQ：万台规模的Docker容器，网
络问题是如何解决的？
罗韩梅：网卡及交换链路的带宽
资源是有限的。如果某个作业不
受限制产生过量的网络流量，必
然会挤占其它作业的网络带宽和
响应时延。因此Gaia将网络和
CPU、内存一样，作为一种资源维
度纳入统一管理。业务在提交应
用时指定自己的网络IO需求，我
们使用TC（Traffic Control）+
cgroups实现网络出带宽控制，通
过修改内核，增加网络入带宽的
控制。具体的控制目标有：
1. 在某个cgroup网络繁忙时，能
保证其设定配额不会被其他
cgroup挤占；
2. 在某个cgroup没有用满其配额
时，其他cgroup可以自动使用
其空闲的部分带宽；
3. 在多个cgroup分享其他cgroup的
空闲带宽时，优先级高的优
先； 优先级相同时，配额大的
占用多，配额小的占用少；
4. 尽量减少为了流控而主动丢
包。
受访者介绍
罗韩梅，腾讯数据平台部高级工程
师，任数据中心资源调度组副组长。
2009年加入腾讯，主要从事统一资源
管理调度平台的开发和运营，承担过
腾讯自研云平台“台风”中Torca资源调
度子系统的研发，目前主要专注于开
源技术、分布式数据仓库、分布式资
源调度平台、Docker等领域。
作者 臧秀涛
大数据时代，数据中心的异地容灾变
得非常重要。在去年双十一之前，阿
里巴巴上线了数据中心异地双活项
目。InfoQ就该项目采访了阿里巴巴
的林昊（花名毕玄）。
InfoQ：首先请介绍一下数据中心异
地多活这个项目。
毕玄：这个项目在我们内部的另
外一个名字叫做单元化，双活是
它的第二个阶段，多活是第三个
阶段。所以我们把这个项目分成
三年来实现。所谓异地多活，故
名思义，就是在不同地点的数据
中心起多个我们的交易，并且每
个地点的那个交易都是用来支撑
流量的。
InfoQ：当时为什么要做这件事呢？
毕玄：其实我们大概在2009还是
2010年左右的时候，就开始尝试
在异地去做一个数据中心，把我
们的业务放过去。更早之前，我
们做过同城，就是在同一个城市
建多个数据中心，应用部署在多
个数据中心里面。同城的好处就
是，如果同城的任何一个机房挂
掉了，另外一个机房都可以接
管。
做到这个以后，我们就在想，异
地是不是也能做到这样？
整个业界传统的做法，异地是用
来做一个冷备份的，等这边另外
一个城市全部挂掉了，才会切过
去。我们当时也是按照这个方式
去尝试的，尝试了一年左右，我
们觉得冷备的方向对我们来讲有
两个问题：第一个问题是成本太
高。我们需要备份全站，而整个
阿里巴巴网站，包括淘宝、天
猫、聚划算等等，所有加起来，
是一个非常大的量，备份成本非
常高。第二个问题是，冷备并不
是一直在跑流量的，所以有个问
题，一旦真的出问题了，未必敢
切过去。因为不知道切过去到底
能不能起来，而且整个冷备恢复
起来要花多长时间，也不敢保
证。因此在尝试之后，我们发现
这个方向对我们而言并不好。
那为什么我们最后下定决心去做
异地多活呢？
最关键的原因是，我们在2013年
左右碰到了几个问题。首先，阿
里巴巴的机房不仅仅给电商用，
我们有电商，有物流，有云，有
大数据，所有业务共用机房。随
着各种业务规模的不断增长，单
个城市可能很难容纳下我们，所
以我们面临的问题是，一定需要
去不同的城市建设我们的数据中
心。其次是我们的伸缩规模的问
题。整个淘宝的量，交易量不断
攀升，每年的双十一大家都看到
了，增长非常快。而我们的架构
更多还是在2009年以前确定的一
套架构，要不断的加机器，这套
架构会面临风险。
如果能够做到异地部署，就可以
把伸缩规模缩小。虽然原来就是
一套巨大的分布式应用，但是其
实可以认为是一个集群，然后不
断的加机器。但是在这种情况
下，随着不断加机器，最终在整
个分布式体系中，一定会有一个
点是会出现风险的，会再次到达
瓶颈，那时就无法解决了。
这两个问题让我们下定决心去做
异地多活这个项目。
为什么我们之前那么纠结呢？因
为整个业界还没有可供参考的异
地多活实现，这就意味着我们必
须完全靠自己摸索。而且相对来
讲，它的风险以及周期可能也是
比较大的。
InfoQ：这个项目具体是怎样部署
的？
毕玄：以去年双十一为例，当时
我们在杭州有一个数据中心，在
另外一个城市还有个数据中心，
一共是两个，分别承担50%用户的
流量。就是有50%的用户会进入杭
州，另外50%会进入到另外一个城
市。当用户进入以后，比如说在
淘宝上看商品，浏览商品，搜
索、下单、放进购物车等等操
作，还包括写数据库，就都是在
所进入的那个数据中心中完成
的，而不需要跨数据中心。
InfoQ：这样的优势是？
毕玄：异地部署，从整个业界的
做法上来讲，主要有几家公司，
比如Google、Facebook，这两家是
比较典型的，Google做到了全球多
个数据中心，都是多活的。但是
Google具体怎么做的，也没有多少
人了解。另外一家就是Facebook，
我们相对更了解一些，Facebook在
做多个数据中心时，比如说美国
和欧洲两个数据中心，确实都在
支撑流量。但是欧洲的用户有可
能需要访问美国的数据中心，当
出现这种状况时，整个用户体验
不是很好。
国内的情况，我们知道的像银
行，还有其他一些行业，倾向于
做异地灾备。银行一般都会有两
地，一个地方是热点，另一个地
方是冷备。当遇到故障时，就没
有办法做出决定，到底要不要切
到灾备数据中心，他们会碰到我
们以前摸索时所面对的问题，就
是不确定切换过程到底要多久，
灾备中心到底多久才能把流量接
管起来。而且接管以后，整个功
能是不是都正常，也可能无法确
定。
刚才也提到过，冷备的话，我们
要备份全站，成本是非常高的。
如果每个地点都是活的，这些数
据中心就可以实时承担流量，任
何一点出问题，都可以直接切
掉，由另外一点直接接管。相对
冷备而言，这是一套可以运行的
模式，而且风险非常低。
InfoQ：不过这样的话，平时要预留
出很多流量才能保证？
毕玄：没错。因为在异地或同城
建多个数据中心时，建设过程中
一定都会保有一定的冗余量。因
为要考虑其他数据中心出现故障
时加以接管。不过随着数据中心
建设的增多，这个成本是可以控
制的。如果有两个异地的数据中
心，冗余量可能是一倍，因为要
接管全量。但是如果有三个数据
中心，互为备份，就不需要冗余
两倍了。
InfoQ：这个项目挑战还是比较大
的。您可以介绍一下研发过程中遇
到的挑战吗？又是怎样克服的？
毕玄：对于我们来讲，异地项目
最大的挑战是延时。跨城市一定
会有延时的问题。在中国范围
内，延时可能在一百毫秒以内。
看起来单次好像没什么，但是像
淘宝是个很大的分布式系统，一
次页面的展现，背后的交互次数
可能在一两百次。如果这一两百
次全部是跨城市做的，整个响应
时间会增加很多，所以延时带来
的挑战非常大。
在解决挑战的过程中，我们会面
临更细节的一些问题。怎样降低
延时的影响，我们能想到的最简
单、最好的办法，就是让操作全
部在同一机房内完成，那就不存
在延时的挑战了。所以最关键的
问题，就是怎样让所有操作在一
个机房内完成。这就是单元化。
为什么叫单元化，而没有叫其他
名字呢？原因在于，要在异地部
署我们的网站，首先要做一个决
定。比如说，冷备是把整个站全
部备过去，这样可以确保可以全
部接管。但是多活的情况下，要
考虑成本，所以不能部署全站。
整个淘宝的业务非常丰富，其实
有很多非交易类型的应用，这些
功能可能大家平时用的不算很
多。但对我们来讲，又是不能缺
失的。这部分流量可能相对很
小。如果这些应用也全国到处部
署，冗余量就太大了。所以我们
需要在异地部署的是流量会爆发
式增长的，流量很大的那部分。
虽然有冗余，但是因为流量会爆
发式增长，成本比较好平衡。异
地部署，我们要在成本之间找到
一个平衡点。所以我们决定在异
地只部署跟买家交易相关的核心
业务，确保一个买家在淘宝上浏
览商品，一直到买完东西的全过
程都可以完成。
其他一些功能就会缺失，所以我
们在异地部署的并非全站，而是
一组业务，这组业务就成为单
元。比如说我们现在做的就是交
易单元。
这时淘宝会面临一个比Google、
Facebook等公司更大的一个挑战。
像Facebook目前做的全球化数据中
心，因为Facebook更多的是用户和
用户之间发消息，属于社交领
域。但淘宝是电商领域，对数据
的一致性要求非常高，延时要求
也非常高。
还有个更大的挑战，那就是淘宝
的数据。如果要把用户操作封闭
在一个单元内完成，最关键的是
数据。跟冷备相比，异地多活最
大的风险在于，它的数据会同时
在多个地方写，冷备则不存在数
据会写错的问题。如果多个地方
在写同一行数据，那就没有办法
判断哪条数据是正确的。在某个
点，必须确保单行的数据在一个
地方写，绝对不能在多个地方
写。
为了做到这一点，必须确定数据
的维度。如果数据只有一个维
度，就像Facebook的数据，可以认
为只有一个纬度，就是用户。但
是像淘宝，如果要在淘宝上买一
个东西，除了用户本身的信息以
外，还会看到所有商品的数据、
所有卖家的数据，面对的是买
家、卖家和商品三个维度。这时
就必须做出一个选择，到底用哪
个维度作为我们唯一的一个封闭
的维度。
单元化时，走向异地的就是买家
的核心链路，所以我们选择了买
家这个维度。但是这样自然会带
来一个问题，因为我们有三个维
度的数据，当操作卖家商品数据
时，就无法封闭了，因为这时一
定会出现需要集中到一个点去写
的现象。
从我们的角度看，目前实现整个
单元化项目最大的几个难点是：
第一个是路由的一致性。因为我
们是按买家维度来切分数据的，
就是数据会封闭在不同的单元
里。这时就要确保，这个买家相
关的数据在写的时候，一定是要
写在那个单元里，而不能在另外
一个单元，否则就会出现同一行
数据在两个地方写的现象。所以
这时一定要保证，一个用户进到
淘宝，要通过一个路由规则来决
定这个用户去哪里。这个用户进
来以后，到了前端的一组Web页
面，而Web页面背后还要访问很多
后端服务，服务又要访问数据
库，所以最关键的是要保障这个
用户从进来一直到访问服务，到
访问数据库，全链路的路由规则
都是完全一致的。如果说某个用
户本来应该进A城市的数据中心，
但是却因为路由错误，进入了B城
市，那看到的数据就是错的了。
造成的结果，可能是用户看到的
购买列表是空的，这是不能接受
的。所以如何保障路由的一致
性，非常关键。
第二个是挑战是数据的延时问
题。因为是异地部署，我们需要
同步卖家的数据、商品的数据。
如果同步的延时太长，就会影响
用户体验。我们能接受的范围是
有限的，如果是10秒、30秒，用
户就会感知到。比如说卖家改了
一个价格，改了一个库存，而用
户隔了很久才看到，这对买家和
卖家都是伤害。所以我们能接受
的延时必须要做到一秒内，即在
全国的范围内，都必须做到一秒
内把数据同步完。当时所有的开
源方案，或者公开的方案，包括
MySQL自己的主备等，其实都不
可能做到一秒内，所以数据延时
是我们当时面临的第二个挑战。
第三个挑战，在所有的异地项目
中，虽然冷备成本很高，多活可
以降低成本，但是为什么大家更
喜欢冷备，而不喜欢多活呢？因
为数据的正确性很难保证。数据
在多点同时写的时候，一定不能
写错。因为数据故障跟业务故障
还不一样，跟应用层故障不一
样。如果应用出故障了，可能就
是用户不能访问。但是如果数据
写错了，对用户来说，就彻底乱
了。而且这个故障是无法恢复
的，因为无法确定到底那里写的
才是对的。所以在所有的异地多
活项目中，最重要的是保障某个
点写进去的数据一定是正确的。
这是最大的挑战，也是我们在设
计整个方案中的第一原则。业务
这一层出故障我们都可以接受，
但是不能接受数据故障。
还有一个挑战是数据的一致性。
多个单元之间一定会有数据同
步。一方面，每个单元都需要卖
家的数据、商品的数据；另一方
面，我们的单元不是全量业务，
那一定会有业务需要这个单元，
比如说买家在这个单元下了一笔
定单，而其他业务有可能也是需
要这笔数据，否则可能操作不
了，所以需要同步该数据。所以
怎样确保每个单元之间的商品、
卖家的数据是一致的，然后买家
数据中心和单元是一致的，这是
非常关键的。
这几个挑战可能是整个异地多活
项目中最复杂的。另外还有一
点，淘宝目前还是一个高速发展
的业务，在这样的过程中，去做
一次比较纯技术的改造，怎样确
保对业务的影响最小，也是一个
挑战。
InfoQ：要将延时控制在1秒之内，
网络和硬件方面都有哪些工作？
毕玄：如果网络带宽质量不好，1
秒是不可能做到的。我们在每个
城市的数据中心之间，会以一个
点做成自己的骨干网，所以可以
保障不同城市之间的网络质量。
但是要保证到1秒，还必须自己再
去做东西来实现数据的同步，这
个很关键。这个东西现在也在阿
里云上有开放了。
InfoQ：异地多活其实也是实现高可
用。阿里技术保障的梁耀斌（花名
追源）老师会在4月23日~25日的
QCon北京2015大会上分享《你的网
站是高可用的吗？》，因为当时的
题目和内容也是您参与拟定的。您
可以先谈一下其中的一些标准吗？
毕玄：其实每家比较大的互联网
公司，每年可能都会对外公开
说，我们今年的可用性做到了多
少，比如4个9或者5个9。但是每
家公司对可用性的定义可能并不
一样。比如说，有的公司可能认
为业务响应时间超过多少才叫可
用性损失，而其他公司可能认为
业务受损多少就是可用性损失。
我们希望大家以后有一个统一的
定义，这样就比较好比较了。我
们发现，真正所有做到高可用的
网站，最重要的一点是故障恢复
时间的控制。因为出故障是不可
避免的，整个网站一定会出现各
种各样的故障，关键是在故障出
现以后，应对能力有多强，恢复
时间可以做到多短。追源会在
QCon上分享，我们在应对不同类
型的故障时，我们是怎样去恢复
的，恢复时间能控制到多短，为
什么能控制到那么短。在不同的
技术能力，以及不同的技术设施
的情况下，能做到的恢复时间可
能是不一样的，所以我们会定义
一个在不同的技术能力和不同的
技术设施的情况下，恢复时间的
标准。如果恢复时间能控制得非
常好，可能整个故障控制力就非
常强。举个例子，比如淘宝因为
能够做到异地多活，并且流量是
可以随时切换的，所以对于我们
来讲，如果一地出现故障，不管
是什么原因，最容易的解决方
案，就是把这一地的流量全部切
走。这样可以把故障控制在一分
钟以内，整个可用性是非常高
的。
关于系统的容灾能力，国家也有
一个标准，最重要的一点就是故
障的恢复时间。如果大家都以故
障恢复时间控制到哪个级别来衡
量，那所有网站就有了一套标
准。
InfoQ：好的，异地多活我们就聊到
这里。您现在在维护一个叫做
HelloJava的微信公共帐号，您在工
作中还是会去调优一些具体的Java
问题吗？
毕玄：没错。我在阿里巴巴这些
年来，很多问题有一些会流转到
我这里，或者有人会反馈到我这
里，所以我会介入到很多问题的
排查，现在也是一样，有些问题
我可能就会介入，直接去排查。
为什么有HelloJava那个微信公共
账号呢？最大的原因也是因为，
我们都知道很多人会排查故障，
有些人可能只是一眼扫过去就已
经知道原因是什么。为什么呢？
他可能已经排查过很多的故障，
积累出了经验，并不一定是这个
人的能力比你强，可能就是因为
他见的比你多，他对工具使用的
熟悉程度比你强。比如说我们看
到故障很多，排查故障很厉害的
人，他可能就是会善于用各种各
样的工具，而且用的非常熟练。
所以我做自己的HelloJava，就是
希望有更多的人看到，我们在面
对一个故障的时候是怎样处理
的。希望大家即使没有处理过这
个故障，至少也看过一篇文章，
也许在下次面对这个故障时，至
少有点思路，知道应该怎么去处
理。这个也是阿里巴巴分享给外
面的一些经验，很多时候就是经
验的积累。
InfoQ：您最近在HelloJava里提到
了一些期待的Java特性，您这边会
将它们反馈给Oracle，让他们加入
吗？
毕玄：我们跟Oracle官方有过一些
交流，谈到我们期望的J VM的一些
改进。但是说实话，因为我们看
到的很多J VM的问题，可能是因为
我们流量比较大，我们对Java的性
能、高并发有很高的期望。如果
能够突破一点，对于我们整个网
站来讲，提升可能就是巨大的。
但是对于Oracle来讲，因为
OpenJDK不仅仅是为大公司做的，
而是为所有不同的用户，比如中
小企业、大用户，所以他们必须
衡量需求的分布。所以有可能我
们的需求，对于Orcale的官方JVM
团队而言，只是小众需求，他们
不大会投入很大精力去做。
InfoQ：所以您这边的团队会做一些
定制？
毕玄：对。很多人知道，赵海平
加入了我们的团队，如果知道他
背景的话，知道他以前做过PHP运
行引擎的开放，不仅仅是HipHop
的翻译，还包括怎么运行整个PHP
应用程序。其实你可以认为也会
类似VM，因为我们已经看到在
Java、J VM的哪些点上如果有突
破，可以给我们带来巨大提升，
所以既然官方很难往前推进，那
我们就自己来推进。
受访者介绍
林昊（花名毕玄）于06年加入淘
宝，为阿里巴巴集团核心系统资深技
术专家。目前是阿里巴巴技术保障部
的研究员，负责性能容量架构。
作者 臧秀涛
去年的双十一过后，InfoQ曾经采访
过京东云平台首席架构师刘海锋。
巡展北京站的活动中，刘海锋分享了
《京东基础云服务技术演进》。
以服务的形式支撑其他业务单元。下
面我们分别来看一下。
存储系统面对的挑战与应
对之道
存储是互联网公司最基础的东西。这
也是开发团队花精力最多，持续迭代
的一个技术方向。
挑战1：非结构化存储
京东每天有千万级的商家上传图片，
用户浏览完图片后会产生交易订单，
需要很多文本来描述这些订单。另外
京东有自己的库房，任何一份订单经
过拆分，经过库房的流转，每一分订
单又会产生几十份非结构化的数据，
涉及商品的入库、出库、调拨等。商
品送到客户手中之后，还有签单信
息、银行小票，未来这些信息的电子
化、和银行对账，又是很多非结构化
的数据。
非结构化的数据越来越多，如何存储
这些数据？商家的图片、交易的订
单、库房的记录、电子签收的信息，
这些数据都是非常关键的，而且这些
数据有一个特点，量比较大，但每份
数据一般都比较小。
JFS:Jingdong Filesystem
版本，可以统一管理小的对象、大的
文件以及私有云中可持久化的块设
备。
的集成方面，目前也有不错的进展和
落地的应用。
目前该系统已经在支撑京东商城的如
下服务：
图片服务
订单履约
物流数据交换
电子签收
内部云存储服务
虚拟机与容器卷存储
挑战2：越来越多的缓存
等，但当到了很大规模的时候，技术
也会发生质变。
Jimdb：分布式缓存与高速
NoSQL
相比，它有如下特性：
精确故障检测与自动切换
混合存储
在线横向扩容
异步、同步、局部复制
全自动化接入与管理
这一点是最近半年的主要工作，目的
是降低维护成本。
固态硬盘的，支撑了京东的商品详情
页、搜索、推荐、广告点击等很核心
数据的快速访问。
下一代新存储平台
刘海锋的团队最近在做的事情是，更
多考虑多数据中心的复制，让数据更
加可靠，并且希望做统一的存储服
务，实现One Jingdong One Stroage，
用一个系统抽象出文件、对象、表甚
至缓存，能够在分布式的多个数据中
心实现统一的复制存储底层的数据，
在主IDC做缓存，甚至全量内存加
速；向上支持在线服务、Hadoop，支
持私有云内部的容器卷的管理等。
中间件：消息队列与SOA
底层存储的上面就是各种中间件。
挑战：越来越多的消息传
递
京东跟很多互联网公司不一样的地方
是，除了北京和江苏的核心机房，在
全国各地还有很多商品的库房，每个
库房会有几十台服务器，相当于一个
小型的数据中心，消息队列不仅要串
联核心机房里的业务，还要驱动库房
里的订单生产环节，跟业务存在很强
的依赖关系。从订单管道，到核心机
房，再到仓储库房，普遍是用消息队
列驱动业务流程的。日均消息数超过
百亿。
JMQ：Jingdong Message
Queues
面对业务挑战，京东的消息队列系统
经过了三代演进，于去年双十一之前
上线了JMQ并完成切换。
JMQ有如下特点：
机房断电不丢消息
因为库房的网络环境是不稳定的，所
以必须保证不丢消息。
组提交技术
引入了数据库中经典的group commi t
技术，提高同步刷磁盘的写的性能。
透明压缩
灵活复制
挑战：越来越多的在线服
务
电商系统内有很多服务。这些服务内
部会互相调用，对外也要开放一些接
口，供商家或者合作伙伴使用。
JSF：Jingdong Service
Frame work
JSF。可以做到运行时服务质量分
析，提供了完善的服务治理功能。目
前在京东已经接入了几万台服务器，
更好地支持了内部的SOA化以及对外
的服务开放。
弹性计算
弹性计算云是目前的主要工作。
挑战：越来越多的机器
任何一个高速发展的互联网公司，机
器数量都是在成倍增加的。随着业务
规模的增长，机器的数量也在不断增
加。现在就要面对这样的场景：有很
多数据中心，而每个数据中心内的机
器又会被划分给不同的业务，比如有
的机器处理交易，有的处理订单履
约，有的处理搜索，有的处理图片等
等，面对这么多机器，应该怎样管
理，让研发团队的效率更高呢？
弹性计算云
该项目的愿景是在IDC的资源和业务
系统之间建立一个桥梁，让业务与机
器完全解耦，做到真正自动化维护，
缩短产品开发到上线的流程，让工程
师的精力更多放在产品的设计和研发
上，而不必关注如何申请资源、如何
上线；提高资源利用率和服务质量，
让研发团队的生活更美好。
从公司整体来看，希望能够提高资源
的利用率。因为很多机器是分散的，
由各个业务团队使用，必然有很多机
器是空闲的，统一管理必然能提高资
源的利用率。
弹性计算云的整体架构如下图所示，
分拆两层服务。底层是基础服务，实
现软件定义数据中心。通过
OpenStack和Docker的结合，实现容器
化。JFS实现可靠的存储。上层是平
台服务，希望通过集成部署，实现资
源的统一分配，业务不用关注自己到
底部署到哪台机器上，并由平台根据
业务量实现自动伸缩。
现在这个系统已经在部分业务中落
地，大规模落地会在今年年完成。具
体而言，像商品详情页、图片系统，
就是弹性计算云支撑的，用户的每一
次浏览，都有这个系统在做贡献，能
够按访问流量自动调度资源。在流量
高峰的时候，这两个服务会自动扩
容。
做为总结，刘海锋总结了两点：
1. 业务发展推动基础架构的演进；
2. 技术的关键是团队。
在演讲之后，InfoQ采访了刘海锋。
InfoQ：最近两年，容器技术，特别
是Docker在业界非常火，可以介绍
一下京东在这方面的实践经验吗？
刘海锋：刚才我在演讲中提到，
我们希望在IDC的资源和业务系统
之间建立一个桥梁，让业务与机
器完全解耦，这是一个很复杂的
工程，不是一个容器或者Docker就
能解决的。弹性计算云分为两个
层面，底层的基础服务更多是把
机器做一个统一的虚拟化、容器
化，上层的平台服务更多地要考
虑怎么样去配合京东的业务，跟
应用能够更顺畅地融合在一起。
举个例子，从最简单的部署角度
来说。以前部署是这样的，一打
好包了，在部署界面上选，选了
三个机器，三个机器的IP分别是多
少，然后部署。部署完成检查一
遍就成功了。而接下来整个系统
会做成这样，一个程序要上线
了，要部署，点部署，系统给部
署完成之后告诉开发者成功了，
然后再说部署在哪里。不需要关
心之前的那些环节，不需要层层
的领导审批和运营部门审批。而
是直接部署，部署位置由平台来
统一控制。一开始分配很少的机
器，随着流量的增大自动扩容。
需要的量小的话，再自动缩容，
节省出的机器再统一调度。这样
可以提高公司的资源利用率，数
据中心中都是公司的机器，而不
再分你的我的。
我们用Docker，更多的是考虑它比
较适合公司内部的私有云环境，
而且比较轻量。我们底层的平
台，简单的理解是Docker和
OpenStack的嫁接。我们用
OpenStack去管理Docker，比如给
它分配一个独立的IP等。但是除了
两个第三方平台，我们的底层平
台要做到简单、可控、稳定，所
以上面还有一个很强大的完全自
研的一套平台和服务，能够统一
的调度和控制，实现管理、监控
和部署。
Docker在这里面发挥了很重要的作
用。另外我们也稍微做了一些改
造，去掉了很多用不到的特性，
让它稳定简单。
网络方面，用Open vSwitch给每个
Docker容器分配一个IP，这样每个
容器看上去跟虚拟机或者物理机
没什么区别，迁移业务的时候大
家更容易接受，过渡更为平滑。
InfoQ：刚才您提到了Ope nStack和
Docker的嫁接，可以具体介绍一下
其结构吗？
刘海锋：基础服务层面，核心有
三点：OpenStack、Docker和自研
的JFS存储。OpenStack和Docker在
这里都是非常重要的组件。在这
里都是非常重要的组件。
先说OpenStack。因为OpenStack变
化比较快，我们没有那么多精力
一直跟随。我们从OpenStack拆出
了一个分支，经过定制，做了一
个内部的分支，叫做Jingdong Data
Center OS。这方面的工作有两
点。一方面是让它能跟Docker更好
地配合；另一方面，我们加入了
很多故障处理功能，应对物理机
故障和容器故障。物理机故障的
时候快速检测出来，快速报警，
快速迁移上面的容器。
再说Docker。网络和存储上都有些
改造，比如可以支持JFS mount过
来的目录。我们会把故障当成常
态，物理机的硬件故障，像磁
盘、内存和硬件方面的问题，所
以对OpenStack做的改造主要是更
好地应对故障，快速响应。
InfoQ：Docker或者Ope nStack方面
的工作，会向开源社区反馈吗？
刘海锋：其实我们也有考虑。我
们在今年年底或者明年年初
的时候有些动作，目前还是希望
把当前的工作做好。
InfoQ：社区的版本更新比较快，这
方面如何me rge自己的特性和新版
本的特性呢？
刘海锋：外面比较好的我们也会
吸收。实际上OpenStack更多是面
向公有云设计的，从我们的需求
来看，它比较臃肿，不是很好控
制。所以我们做了裁剪，砍掉了
很多公有云的功能。
InfoQ：这个会不会像你们的文件系
统那样，在定制的过程中走向自研
了？
刘海锋：这是有可能的。像
Docker这样的项目，设计的时候考
虑的是更为通用的目标，功能非
常多，这会引入过多的复杂性，
也引入一些问题，所以要做减
法。而且就互联网公司的开发团
队而言，基础架构是在业务的推
动下不断演进的，而不是满足某
种通用的需求。
InfoQ：现在弹性计算云的落地情况
如何呢？
刘海锋：现在弹性计算云已经在
支撑很多业务，像图片服务。很
多边缘系统也在用。根据研发战
略，我们希望今年大规模落地。
InfoQ：可以介绍一下公司其他业务
在向私有云迁移的过程中都有哪些
挑战吗？
刘海锋：挑战很多，我们很多精
力也放在这上面。我们做了一个
基础设施，会面对两类用户，像
新的用户和新的产品，直接选择
它就可以了；但像老的服务，可
能占用的是物理机，资源利用率
很低。迁移其实不仅是技术层面
的问题。所以我们会有专门的项
目经理团队去推动。另外我们有
一些工具，方便旧业务的迁移。
此外，我们还需要在保证业务稳
定的前提下追求规模，因为规模
大了才有资源管理方面的优势，
所以我们希望做到万台规模。我
们每天都很谨慎，很小心，但是
还是希望量上来。
受访者介绍
刘海锋，2013年加入京东，担任云平
台首席架构师、系统技术部负责人，
主持建设存储、中间件、弹性计算等
私有云技术体系。
作者 杨赛
云计算无疑是IT界近几年最火的话题
之一。很多互联网公司，传统IT公
司，甚至是初创公司，都将视角投到
了云计算上。
在即将于10月16日-18日举行的QCon
上海技术大会上，华三通信研发副总
裁王飓将做题为《SDN控制器集群中
的分布式技术实践》的主题演讲。在
大会召开前，InfoQ中文站就传统通
信技术与云计算的关系对他进行了采
访。
InfoQ：在云计算时代，通信技术历
史的积累您感觉有多少是有用的？
新的技术又是主要来自哪里？
王飓：通信技术历史的积累其实
大部分都是有用的。云计算核心
关注的是虚拟化，并没有破坏
TCP/IP的通讯层次模型，也没有彻
底改变网络上需要的各种网络设
备的种类（比如依然需要交换机/
路由器/防火墙）。只是这些设备
的控制管理方式（SDN是改为了集
中式管控）和形态（产生了虚拟
形态如VNF）发生了变化。当然个
别协议在新的SDN架构上可能没用
了，或者需要进化，这就是很自
然的事情了，任何协议都有生命
周期。
InfoQ：基于已有的体系改造，要比
新建设一套体系更加困难。无论如
何，过去有很多积累要放弃，给新
的技术腾地儿。您目前跟通信领域
的同行们沟通，感觉行内整体目前
的心态是偏激进的（主动引入新技
术革自己的命），还是偏保守的
（用各种手段拦着新技术发展，给
原来的积累多争取一些时间）？偏
激进的那批人主要在哪儿？
王飓：我感觉业内大部分人的心
态是比较积极的。现在谈革命可
能还不够准确，就像我上面说
的，云计算时代，并不是完全颠
覆已有的东西，那些过去的积累
并不会一下子失去价值。
其实，大概在6、7年以前，我也
迷茫过：数据通讯网络发展到当
前的状况，是否就差不多了，剩
下的只是提高一下带宽，提高一
下芯片的容量就可以了？这就好
像19世纪末一些物理学家认为经
典物理学大厦已经建成，后人只
有拾遗补阙的份了。所幸，这个
世界的精彩总是超过我们的想
象。云计算/SDN等技术的发展，
无疑为我们的未来又重新增添了
无穷的魅力。
当然，新技术是否就一定是好
的？这个有待时间来验证。即使
方向是对的，但具体的技术路线
可能还是需要不断探索。所以，
如果单纯是技术手段，则不存在
什么保守或者激进的说法，任何
技术行为都可以看成是一种尝
试。在通信产业界，各种通信协
议的竞争一直都有，而胜利从来
不是单纯的看技术先进与否，适
合的才是最好的。（当然，如果
利用自己的垄断地位采用非正常
的竞争手段是例外。）
我和我们公司都是这种变革的积
极拥护者，这种变化，无论如
何，最终都是让我们的技术更贴
近我们的用户，让网络世界变的
更美好。
InfoQ：有观点认为互联网是IT的消
费者，并不是主要的IT贡献者，而
主要的IT贡献者其实还是IBM、思
科、华为这些传统IT公司。现在IT
越来越便宜，互联网公司获益最
大，IT公司、通信公司则很惨。但
其实我们也看到像是Google、
Amaz on这样的互联网公司也在越来
越多的往基础IT做投入。您如何评
估现在互联网公司对于整体IT的贡
献度？
王飓：如果IT这个词代表网络基
础设施的话，可以认为互联网公
司是IT的消费者，但别忘了最终的
消费者是广大的用户，所有的评
价应该以最终用户得到了什么作
为评价。
技术本身是没有边界的，无论是
互联网公司，还是所谓的传统IT公
司，最终的目标都是满足和提升
广大用户的使用体验。如果互联
网公司认为现在的网络基础设施
阻碍了他们提升用户体验，现有
的传统IT公司无法给出他们满意的
解决方案，则他们在这个方向投
入就是很自然的事情。
至于说IT公司和通信公司，很惨应
该还不准确，应该说是其利用技
术和市场垄断来谋取高利润的时
代结束了。
我们或许可以这样理解，互联网
公司就是第三产业，是服务业，IT
公司就是第二产业，是制造业，
完成了工业革命以后，第三产业
的比重越来越大，附加值高，这
是历史大趋势。这也是为什么十
多年前思科、微软这样的公司市
值最高，而现在的新贵是Google、
Facebook和阿里巴巴。而当第三产
业高度发展以后，肯定会反哺第
二产业，这也就是为什么互联网
公司开始向基础IT投入的原因。
想精确评价互联网公司对于整体IT
的贡献度恐怕是很难的，但毫无
疑问，他们的影响是正面的，推
动了IT的发展，最终用户得到了个
更优质、更方便、更便宜的服
务。
InfoQ：互联网公司作为用户，在网
络方面倾向于O pe nFlow这种完全由
Controller掌控的网络结构，比如
Google和Face book都是O pe nFlow的
主要推手。但是这似乎是早期的一
个观点，发展到现在，他们理想中
的Controller还是没有实现，而且现
在越来越多的声音也认为将所有控
制逻辑放在Controller里面也未必合
理。您对此是什么观点？您认为哪
些节点应该使用Controller，而转发
层面应该保留哪些逻辑？
王飓：说这个问题，先看看我们
的世界：今天的人类社会，是由
一个个国家组成的，所有国家构
成了一个松散的组织——联合
国。每个国家都是一个自治的区
域，有各种各样的政体，有的是
松散的联盟，有的中央集权。看
看互联网发展史，是否也是这样
呢？我一直认为，网络虚拟空
间，就是现实的折射。
所以，在一些封闭的空间里，比
如一个数据中心，一个小的运营
商网络，是比较适合使用
Controller集中控制的。而在一些
开放空间，边界不是很清晰的地
方，还是需要传统的网络，这也
是互联网诞生之初的设计思想：
在一个无比广阔的空间里，网络
自由互联、互通、自治，没有一
个集中的控制点，任何对网络的
攻击都只能影响局部，不会导致
整个网络的崩溃。
至于转发层面需要保留哪些逻
辑，现在大家争论还是很热烈
的，但显然完全没有逻辑已经被
证明不是最理想的，因为今天的
设备，即使是冰箱和洗衣机都可
以变的很聪明。这样看，完全把
转发层面当成无逻辑的节点显然
也是一种浪费。目前看，一些需
要高速检测、本地链路快速切换
等可能放到转发节点上更合适。
InfoQ：现在互联网公司做云计算，
传统IT公司也做云计算，运营商和
通信公司也做云计算，初创企业也
做云计算——这里说的云计算仅限
于IT基础设施层面。就您的观察，
你觉得他们要做的东西有什么不
同？想要达到的目的有什么不同？
对技术的需求又有什么不同？
王飓：云计算这个概念很大，大
到不同的人可以有不同的理解。
云计算的世界很广阔，广阔到可
以容纳这些不同的力量一起来建
设。
从方案上看，大体可以分为公有
云，私有云和混合云三种；从内
容上看有的偏重计算，有的偏重
网络。
从技术本质上看，他们做的东西
是类似的，但从需求角度看，又
有明显的区别，各自的侧重点也
不同。
互联网公司和运营商本身都是提
供服务的，都是要解决自己的网
络所面临的问题，相当于私有
云，然后是建立公有云，提供公
有云服务。
而通信公司则是希望借此机会进
行转型，由卖设备变成卖服务，
因为大家看到了，随着这个趋势
（硬件标准化/软件开源化），设
备的毛利率越来越低，价值链条
中服务的部分会逐渐成为主体。
这些通信公司即做公有云，也做
私有云，甚至是混合云。这个服
务和前面讲的互联网公司的服务
不同，是指提供完整解决方案服
务，自己并不运营。当然也不排
除某些企业借此转型，变成了互
联网公司。
初创企业就不说了，这个领域肯
定是拿VC的热门，为什么不搏一
下？而且初创企业没有历史包
袱，显然在技术上是最有冲劲
的，因为传统领域的蛋糕已经分
完了，后来者要么重新做一个大
蛋糕，要么就是打破原来壁垒，
而推动一次技术革命显然是一个
不错的选择。
InfoQ：感谢您接受我们的采访。
受访者介绍
王飓，华三研发副总裁。从事数据通
讯设备软件开发长达14年，作为资深
的网络协议专家和软件系统架构师，
熟悉多个层面的数据通讯协议，擅长
做通信协议设计以及实现，对嵌入式
系统和复杂软件系统设计，以及对实
时系统的性能优化有着十分丰富的经
验。此外，对网络安全有着比较深入
的研究，对各种网络攻击和防护有着
丰富的经验。 近年来开始关注并投
入SDN相关领域的研究和开发。对
OpenStack、OpenDaylight、
OpenVswitch、NFV等都有一定的研
究，对云计算时代的网络通信有着深
刻的理解。
作者 刘羽飞
明略数据是一家聚集了国内顶尖大数
据人才的技术型大数据整体解决方案
供应商，其从创立之初就秉承着将技
术研究落地转化为科技生产力的基本
理念，至今已经为银联、中央电视
台、中国联通、国美在线、苏宁云商
等公司部署了大数据处理平台，并带
来了大量的业务创新机会。那么，明
略数据是怎样做到这些的？明略数据
在技术层面上又具有怎样的过人之处
呢？为此，我们请到了明略数据CTO
冯是聪博士进行了采访，以便更加深
入的了解明略数据的技术特点。
InfoQ：明略推出的大数据平台
BDP，对于这个平台我理解的就是
很多传统企业比如说银行、政府，
这种大型的机构当中，会有很多的
分支部门，而部门之间的数据可能
会由于种种的历史原因无法进行打
通。这些数据，可能它的字段跟描
述方式以及存储的格式也是不一样
的。那么该如何把这些不同格式、
不同表达方式的数据进行打通？是
不是BDP这个产品可以实现这样的
功能呢？
冯是聪：从技术上讲，对于一些
企业、政府机构来说，一定会存
在这样的情况，它有不同的数据
来源的，不同的数据格式。那么
这些数据必然面临着一个问题，
就是如何把它们融合在一起，怎
么实现数据之间的交互。
这一问题从技术的角度上来看确
实具有一定挑战，但明略恰恰就
善于解决这种问题。明略BDP中有
两个核心模块——Data ONE与SQL
ONE。Data ONE采用的是All-In-
One模式，无论数据来源是什么，
无论是来源于关系型数据，还是
来源于非关系型数据库，是
NoSQL，还是来源于NewSQL，或
是文件系统，这都没有关系。明
略会以统一的方式将这些数据放
到BDP平台内，通过Data ONE把
所有数据统一管理起来。
那么接下来怎么实现数据之间的
交互呢？这就需要用到另一个核
心模块SQL ONE了。SQL ONE是
一个标准的SQL查询引擎。传统的
新客户一般对于关系型数据库都
非常熟悉，对SQL语句也会非常熟
悉。那么当我们提供了SQL ONE
这种语言之后，如果客户会操作
传统的关系型数据库的话，就可
以操作我们所有的文件系统、
NoSQL,甚至是NewSQL。SQL ONE
可以智能地识别这些数据被物理
地存放在Data ONE的哪个子系统
中，确定数据是放在关系型数据
库，还是放在非关系型数据库，
或是放在文件系统中。客户只需
要输入一个SQL语句，系统就能自
动完成所有的事情，这也是BDP的
一个特点之一。
InfoQ：从数据安全问题上来说，不
同的行业，不同的企业，对数据安
全的审计、审核的标准也不一样，
尤其像一些涉及到国计民生的政府
机构，他们的数据对安全的要求是
非常高的。明略的产品是部署在客
户的数据中心当中的，这样从物理
上就可以规避一部分安全隐患。那
么除此之外，明略还有在安全方面
还有哪些不一样的地方？
冯是聪：从目前来讲，在大数据
安全这一领域中很多技术都是不
太成熟的。从大数据的特点来
看，首先数据规模比较庞大，数
据内容也比较复杂，再加上各种
数据来源，各种数据格式，还要
要求统一在大数据平台上进行管
理，这些因素导致其对安全技术
的要求变得非常高。
明略针对这些问题开发了自己的
核心安全组件Acre，在Hadoop平
台上首次实现了行列级别的数据
安全访问管理。它的核心思想
是，可以把任何人操作该数据的
历史、权限，包括他的授权认
证，全部统一管理起来。
另外在隐私保护方面，明略实现
了多种数据脱敏与加密算法，智
能地实现了敏感数据的自动脱敏
和保护。
InfoQ：您刚才也提到，明略还会在
数据价值挖掘上有一些自己的动
作，这就可能涉及到机器学习、深
度学习，这些现在比较流行的新技
术。那么，能否介绍一下明略在这
方面的一些研究实践？
冯是聪：机器学习还有数据挖掘
是大数据最核心的技术之一。明
略的3大核心产品之一的DataInsight
就是数据挖掘和机器学习的一个
典型的平台。数据挖掘和机器学
习在明略实施的几乎每一个项目
中都得到了充分地应用，基本上
每个项目都会进行一些预测、分
类，这些都会用到机器学习里面
去，另外像以前机器学习有进度
学习、无进度学习、深度学习，
这些也都会用到明略的项目里面
去。
InfoQ：展望2015年，您认为哪些类
型的企业会成为大数据领域的明星
企业，或者说哪些企业会有高速的
增长空间？能根据您的研究，分享
一下您的观点吗？
冯是聪：因为大数据现在已经慢
慢被大部分企业或者是政府接受
了，它会在很多的领域都得到广
泛的应用。从我个人看来，我觉
得有两个领域是值得关注的，第
一个是金融领域。现在的个人
贷、余额宝等金融产品越来越
多，因此为了更有效的进行反欺
诈，征信系统将会利用更加密切
的、彻底的应用大数据技术。
第二个领域是安全领域。安全永
远都是一个话题，几乎每一家企
业、每一个政府机构都会关心安
全问题。数据安全技术没有得到
突破的情况下，很多企业和政府
是不会轻易的把自己的数据放在
云端的。另外现在有的公安机
关，甚至军方机构，都开始将大
数据安全技术用于追捕或是反
恐，这都说明了安全领域将更多
的应用大数据技术。
InfoQ：明略的商业模式是很清晰。
那么在未来，您更看好是像明略这
样的面向企业的On-Pre mise的商业
模式，还是同时还看好别的一些大
数据创业公司的商业模式？
冯是聪：对于我自己来讲，我肯
定是看好明略的商业模式的。一
方面这种模式能够更好的基于客
户的不同需求进行定制化开发，
另一方面在安全上也更有保障。
那些能够跟客户共同成长，能把
客户当成伙伴，能够把客户的问
题当成自己的问题的那种公司，
才能够得到比较迅猛的发展。
大数据的核心在于从数据中挖掘
价值。2015年是大数据应用元
年，企业将更加关注大数据技术
的落地和应用。因此我比较看好
那些能够根植于客户业务，能够
帮助客户解决业务痛点，真正能
够给客户带来价值的大数据公
司。那些在不同细分领域，能够
提供整体解决方案的大数据公司
的前景将更好。
InfoQ：也就是不仅仅要做技术，而
且还要熟悉、了解客户的业务模
式，从而能更好提供有针对性的大
数据服务。
冯是聪：明略始终认为大数据仅
仅靠技术是不行的，它必须要能
解决业务问题。厂商的数据科学
家通常需要三方面的知识，一方
面是需要懂得计算机知识，第二
方面他要懂得数据挖掘知识，第
三方面他要懂得数学，这是综合
能力的体现。而只有当把客户的
业务本质了解比较透彻，才能给
客户带来实际的价值。
InfoQ：您能否谈谈有哪些技术会对
大数据行业的未来产生巨大影响或
者说带来巨大推动力？
冯是聪：我认为有四类技术比较
重要。第一类技术是大数据安全
技术，无论是金融业的反欺诈，
还是警方的反恐与安保，都需要
有大数据安全技术的帮助。
第二类技术是机器学习领域，从
各种报道来看，无论是在云识
别，还是图像识别，甚至视频的
处理，已经基于机器学习以及深
度学习而得到广泛的应用，我相
信随着深度学习的发展，将会带
来巨大的变革。
第三类技术是量子通讯，据我了
解中国量子通讯的研究还是非常
的具前沿的，基本上处于国际领
先地位。像中国科大，他们现在
在量子通讯上，能够在超过一百
公里上午距离上进行传输。所以
我相信随着量子通讯技术和量子
计算机的发展，最后我们的通讯
技术，还有计算机技术、语言都
会发生翻天覆地的变化。
第四类是智能设备。我们身边生
活中的几乎每一样设备，每一样
东西实际上都可能会智能化。而
一旦设备智能化了，这就需要想
办法将数据收回来，当这些数据
达到一定规模的时候，就一定会
需要大数据技术来进行处理这些
数据。我相信随着智能设备的发
展，无论是中国还是外国，人们
的生活方式以及工作方式都将得
到改革。
受访者介绍
冯是聪，北京大学计算机系博士毕
业，北京明略软件系统有限公司联合
创始人兼CTO。
作者 崔康
本次受访嘉宾是UnitedStack创始人程
辉，就云计算市场的现状、发展趋
势，以及UnitedStack在业务方面的战
略调整给出了自己的解读。
InfoQ**：为什么UOS1.0是做发行
版，而从2.0开始做公有云和托管云
了？**
程辉：公司2013年成立，在当年
10月份的时候发布UOS1.0，当时
的想法很简单，很多厂商都推出
高度产品化、定制化或者优化过
的OpenStack发行版，然后通过外
围的一些服务挣钱。我们也想解
决OpenStack的一些痛点，比如自
动化部署、运维等，并针对国内
用户的使用习惯进行了改进，最
终发布了UOS1.0。产品本身是比
较酷的，把U盘做成了一个产品，
交付给任何一家IT公司或者个人用
户，在服务器上插上U盘，过一会
就搭建出一个云环境。
但我一直在反思。用户拿到了
UOS1.0之后，整个安装过程非常
快捷，但是用户拿UOS 1.0来提供
7x24小时持续的云服务还是很遥
远。我们只是解决了从无到有的
问题，而这只是万里长征第一
步，接下来还需要提供对外服
务，保证产品不宕机可扩展，而
当时我们并没有解决这个问题。
所以，公司做了重大的业务转
型。把UOS 1.0中的的核心技术包
括分布式存储、高性能网络、优
化的主机调度等，应用到自己的
公有云上，开放给公众使用。当
时还没有考虑商业模式的事情，
只是觉得我们应当把这些有价值
的技术和产品开放出去，让别人
受益，公司就自然就有价值了。
说做就做，我们拿出了公司剩余
的大部分钱在北京租了机房，买
了一批设备，从核心技术到计费
平台、说明文档、注册系统、自
动化运维等，花了近半年的时候
做公有云。
InfoQ**：公有云发布之后遇到了哪
些挑战？**
程辉：主要有三个挑战：
第一，如何在坚持OpenStack开放
标准的同时满足国内客户定制化
的需求。UnitedStack云服务完全基
于OpenStack开放API构建，但是
OpenStack开放API并不能完全满足
客户需求，因此这里需要与社区
做足够的沟通工作，将这些差异
化的需求提交给社区，同时我们
还在保证100%兼容的目标的情况
下对OpenStack API进行扩展。这
对于团队对于OpenStack开发能力
有足够的自信才能做到。
第二，平衡OpenStack社区开发与
生产运营的差异。社区开发时，
我们只需要完成功能开发和测
试，但当我们要生产运营一个
OpenStack云平台时，这时需要考
虑平台运营过程中可能出现的各
种事件，比如物理服务器宕机，
存储扩容、缩容，磁盘故障，网
络抖动和攻击等，需要为每一种
异常或者失效准备预案，及自动
化运维措施，并及时响应。
第三，获得客户信任。作为一个
新兴公有云平台，获得客户信任
是一个漫长的过程，任何一次异
常或者故障都会导致客户信心的
丢失，客户几乎不能容忍一次故
障，这是最大的挑战。平台每天
都会有更新和升级，也不能中断
客户业务。
InfoQ**：UnitedStack为什么提供托
管云业务，出于什么考虑？**
程辉：有句话说“出来混总是要还
的”，刚开始创业的时候，我们没
想商业模式，从发行版到公有
云，都没想好怎么赚钱。我们知
道现在很多公有云都是巨头在
做，几十亿的资本投进去才可以
做好。作为一个小的创业公司做
公有云，你确实有机会，但是相
比资本的力量，这是上百倍的差
距，你在市场上可能有竞争力，
但是很难做的比他们更好。
我开始思考如何进一步商品化整
个公司的品牌和技术，在国内，
有一批大客户，对云的需求量更
大，而且没有哪一家公有云可以
服务好他们。大到什么程度呢？
大到用公有云已经很不划算了。
比如对弹性计算要求极高的新兴
的移动互联网公司、公司，
还有对云扩展性和安全性要求高
的银行和互联网金融公司等，他
们的业务量规模大且比较需求量
比较固定，而且对于安全性、数
据主权等要求极高，因此这些客
户不太放心将这些业务放到公有
云上。
所以，我们推出了托管私有云
(Managed Private Cloud)，可以理
解成独享的公有云。我们的核心
价值在哪里？我经常把云建设的
投入分为三个部分，一是IDC资
源，包括电力、带宽、机位等，
这是一个高度市场化的领域，比
较成熟，这块交给客户去解决，
因为价格已经市场化了；二是服
务器设备，更加市场化的领域，
发展了几十年，我们没有必要
做；三是独立的技术平台和运
维，这才是我们应该做的事情，
帮客户做好管理、维护以及后续
的升级，甚至新功能的研发、监
控等。
事实上，如果把托管云三部分的
投入成本和同样资源的公有云费
用做比较，就会发现，托管云的
整体成本只有公有云的1/3-1/5，看
起来不可思议，但事实如此。目
前，已经有10个托管云的大客户
上线，机房12个，分布在北京、
广东、上海和东北地区。
我可以随口算一下，做一个云计
算环境，需要的人包括虚拟化工
程师、存储工程师、网络工程
师、监控工程师、UI设计师、运维
工程师等等，每一个岗位都需要
花很大价钱。托管云可以让客户
节省大量的钱，关注自己的业
务。在UnitedStack平台，托管云的
系统平台和公有云是一样的，有
什么更新，都会同步升级。
InfoQ**：既然托管云商业模式比较
好，为什么还要做公有云，据我所知
国内的其他公有云市场盈利艰难。**
程辉：这是个好问题，很多人都
不理解。在没有公有云之前，我
们去向客户推销技术平台时，客
户经常会觉得你说的这个好东西
没有经过验证，没有看到实际的
生产案例，没有看到实际的用
户，后来，我们上线了公有云，
让大家看到我们的高性能、用户
体验、运维、持续更新等能力，
通过这些方式，客户才开始接受
我们的托管云。另外，不同企
业，在不同的阶段，对云的需求
是不一样的，比如，互联网创业
公司，肯定初期倾向于公有云，
待业务规模足够大而且稳定的时
候，这时采用第三方服务的私有
云可能是一个更好的解决方案，
他们需要不同的云服务模式去支
撑他们当前的业务。因此，总结
一下，公有云一方面满足部分客
户的需求，另一方面，方便客户
构建其混合云体系。因此，这里
公有云也是我们商业模式的一部
分。
InfoQ**：关于托管云服务，用户自
己找机房和数据中心，那么在搭建和
维护云服务过程中，是不是偶尔需要
你们派工程师去现场？**
程辉：我们现在落地了10个大规
模的托管云，几乎没有上门服务
过！前期，我们会和客户商量
好，需要采购哪些设备，如果配
置，发给他们一个表单，购买之
后，我们的工程师会告诉他们如
何关联这些设备，还是一个清单
搞定。最后是打通VPN隧道，一旦
完成，我们就可以通过远程方式
部署第一台种子机器，剩下的其
他机器就会逐渐配置完毕。我们
最快的客户案例是从确定合同到
托管云正式上线用了不到一个月
的时间。我认为，以云计算为中
心的上下产业链配合的很好，IDC
提供电力、机柜和带宽服务，硬
件厂商提供基础设施，我们提供
云平台技术，上面的PaaS或者
SaaS厂商提供相应服务，云生态
和谐共存。
InfoQ**：如果部署在客户那里的托
管云平台系统需要升级，对客户的服
务是透明的吗？**
程辉：保证部署在客户数据中心
的托管私有云无中断地平滑升级
是我们的核心能力之一。面向大
规模业务的互联网分布式IT基础架
构一个最重要的特点是不允许中
断。以微信为例，用户基数很
大，几乎每分每秒都有人用，微
信从上线到现在，几乎每天都有
很多变更，但不能中断服务。云
计算也是这个道理，客户把服务
交给我来管理，我需要既保持稳
定又要不断的改进、变更和升
级。为了保障无中断升级，我们
推出了很多举措，比如，我们在
升级的时候，会给客户的业务做
热迁移，保障业务连续性，用户
几乎感觉不到服务中断。通过这
些手段，每次OpenStack推出新版
本时，我们都能及时跟进，现在
我们公有云和所有的托管云客户
都是运行在最新的OpenStack Juno
版本上的，我们为客户提供托管
的OpenStack有一年多了，都是从
早期的G版本一路升级过来的。既
然我们做托管云，也需要按照最
严格的公有云标准来要求自己。
InfoQ**：分享下你在开源方面的心
得吧。**
程辉：这需要从我在新浪工作时
说起，当时我没有做开源，接手
的任务是把公司的云平台尽快上
线。我招了一批在校实习生，让
他们两个月之内不参与任何公司
的内部工作，只在社区中做，找
bug，然后尝试修补。如果提交的
补丁不规范，就会被社区退回
来，有人曾经被打回20多次，通
过这个过程，社区帮我很好的培
养了这些人。在新人成熟之后，
云平台只用了一个月时间就上线
了。 后来，我们被邀请去国外分
享经验，我也有了创业的原始动
力。后来就成立了UnitedStack，即
使在资本很紧缺的情况下，我也
会安排工程师全职在社区当中
做。正因为如此，我们的系统稳
定性才会很高。
另外，社区的架构设计和文档对
我们很有借鉴意义。比如，某一
个开源的账号体系，开始我们觉
得特别复杂，设计了几十个新的
概念，不可思议。但是，后来我
们在设计云平台的账号系统时，
才发现人家的设计是多么好。如
果没有社区经验，是很难设计出
来的。 通过社区让我们知道了这
些东西，让云服务产品更加有竞
争力。
InfoQ**：你认为UnitedStack的核心
竞争力是什么？**
程辉：刚才我已经说了一些。第
一个是开源，目前在中国市场主
流的云当中，我们算是唯一一个
完全基于开源来构建的商业的生
产的云，我们目前云系统采用的
两大开源平台，OpenStack和
Ceph，不仅开源平台为我们提供
了源源不断的动力，我们还有一
批非常懂开源的工程师，保证我
们团队在开源业界的领先水平。
第二个是互联网精神，既要变又
要稳。公司核心团队基本上来自
于互联网公司，因此我们有能力
将互联网的基础设施和运维管理
经验带到客户的数据中心。第三
个优势，商业模式的创新，我们
是国内第一家旗帜鲜明地提出托
管云理念。如果对明年或者后年
的云市场做一个预测的话，托管
云会成为一个不可小觑的云计算
细分市场。
InfoQ**：你对目前云计算的发展现
状有什么样的看法？**
程辉： 中国云计算市场现在还没
有清晰的市场区分，总体发展还
处于初创和混沌期。具体表现
在，目前主流的云服务产商均采
用的是自研的私有技术、私有
API，云平台之间没有统一的互通
接口，缺少统一标准，无法通过
标准参数来衡量一个云服务的优
劣。
基础设施云计算技术，不论是
IaaS还是PaaS，大约未来3～5年左
右时间会成为高度商品化的技
术，商品化意味着花钱就可以买
来，有市场有技术，而且市场和
技术可以交易和转换，到那个时
间，云计算市场竞争将从技术竞
争真正转变为资源和服务的竞
争。
比如，我们提出的托管云服务其
实对应国外的是Managed Private
Cloud，这在国外是一种主流的私
有云交付方式，不论厂商、企业
用户还是媒体都非常清楚。
InfoQ**：云计算市场有哪些细分领
域和玩家？他们分别有何特点？**
程辉：我就按大家最常见的理解
分为公有云和私有云两大体系。
公有云市场按平台技术类型来看
有两大类：
第一大类是基于自研的私有技
术的公有云，比如阿里、腾讯
等互联网巨头提供的云平台、
外资的云（如AWS，Azure）、
Ucl oud，青云为代表的创业公
司的云 ；
第二大类：基于开源技术构建
的公有云：如京东云、金山
云，UnitedStack、还有电信、
联通等运营商的云平台，都是
基于开源的OpenStack平台构
建；
云计算和其他行业一样，顺应从
闭源技术到开源技术的发展趋
势， 我们看到，2014年之后新成
立的云平台，基本上都属于大二
大类，基于开源构建。
云计算是可以OEM的，透露一
下，到目前为止，国内已经有接
近10家IDC、互联网公司公有云厂
商的底层是Powered By UnitedStack
的，即我们团队为其提供完整的
公有云平台、技术还有运维服
务，初步实现了IaaS云平台的商品
化。
私有云有目前非常明显两大体
系：
一类是商业VMw are生态，目前
私有云市场占有率非常高，尤
其是在传统行业，但是目前大
量只解决了虚拟化的问题，分
布式存储、SDN网络等云计算
核心技术还很难应用起来。
第二类还是OpenStack开源私有
云生态，目前OpenStack开源私
有云模式已经被广泛接受，在
VMw are最稳定的、市场占用率
最高的金融和政企行业也可以
看到越来越多的应用案例。
UnitedStack的OpenStack私有云
方案已经帮若干家金融和银行
公司替换掉了VMw are解决方
案。
InfoQ:**按照以前的IT规模，可能是
市场成熟之后，有两三个比较大的卖
家。你觉得云计算这个市场，会遇到
这个问题吗？**
程辉：不会例外，也会是这样
的，大者恒大，因此，我们在未
来两年必须变得强大起来，否则
就会被淘汰出局。
InfoQ**：UnitedStack在未来几年的
路线图是什么？**
程辉：技术路线上，我们会坚持
开源，投入更多资源将开源项目
产品化。在基础设施服务层面，
高性能SDN网络和高性能统一存储
将持续是我们的重点。SDN网络在
开源界也是最近两三年才开始逐
渐被关注和被应用起来，目前已
经初步实现了SDN网络的构想，但
其性能和稳定性还有进一步提升
空间，在我们的中，未来1
年，SDN网络的性能还有3到5倍的
提升，并且会新增更多企业级安
全特性，进一步满足严肃的企业
级应用。
高性能统一存储的目标很简单，
不仅要完美的替代传统的SAN企业
级块存储，还能够为大数据、对
象存储等业务提供底层支撑。性
能优化方面，目前我们的分布式
存储读写IO延迟已经突破了1毫
秒，几乎接近分布式块存储的极
限。在提供极高性能的同时，我
们还在数据安全性方面下了很大
努力。今年会继续在存储多样化
上下努力，比如，刚刚上线的NAS
存储服务和虚拟SAN功能，在行业
内也是独一无二的。
基于扎实的基础设施架构，我们
还将在PaaS层构建更多服务。
首先是容器技术的大规模商用。
UnitedStack是国内第一家提供容器
服务的云服务厂商，今年将在
Docker存储和网络方面做一些功能
优化，解决目前阻碍Docker容器服
务商用的问题；
其次，将大数据与统一存储做整
合，将OpenStack云平台和Hadoop
大数据平台两大开源体系全二为
一，真正实现我们内部早年提出
的“一个底层，多个平台”的构想；
第三，将持续引入更多的开源的
和商用的PaaS层服务，比如
MySQL,Mongodb，Oracle数据库服
务，Redis, Memcache等缓存服
务，让开发和运维变得更简单。
受访者介绍
程辉，UnitedStack公司创始人兼
CEO，曾任OpenStack基金会董事，
是中国OpenStack领域最活跃的布道
师和实践者。
他致力于打造OpenStack全球生态圈
中最成功的开放云平台：他创立
UnitedStack是中国最专业的OpenStack
开源云计算公司，拥有中国最强大的
OpenStack开发团队，第一次真正将
OpenStack开放平台的精髓注入了中
国云计算领域。在他的带领下，
UnitedStack革命性地将“托管云”服务
落地中国，是中国市场上第一个提供
类似标准化服务的云公司。目前，
UnitedStack基于自主开发的全球最好
用高性能OpenStack云服务平台UOS，
已经成为中国最具代表性的高性能、
可信赖云服务平台。
作者 崔康
对陈本峰的采访，源于技术圈内的一
个饭局，虽然大家对他的云适配创业
经历很感兴趣，但是他却在自我介绍
中反复提到了“开源”和“Amaze UI”，
言谈举止中透露着对国内开源社区发
展的关注和热情参与，特别是他领导
的Amaze UI开源项目在正式上线2个
月之后，在Github上就取得了1000多
个star的关注度，这样的成绩在国内
屈指可数。于是，便有了对陈本峰的
采访和下面的内容。
Amaz e UI 的前世今生
在中关村创业大街旁边的办公室中，
Amaze UI项目的领导者、云适配CEO
陈本峰欣然接受了InfoQ中国总编辑
崔康和高级编辑郭蕾的专访。陈本峰
首先谈起了Amaze UI开源的背景，云
适配是专注前端技术的公司，在把网
站从电脑版转到手机版的时候，需要
一个手机的前端框架。从创业初期开
始积累，Amaze UI逐渐发展起来。
早期的时候，对这种移动端的We b
界面框架比较少。国外的这块移
动版做得相当的好，我觉得他们
兼容性做得不错，但是速度非常
慢，打开非常慢，所以无法忍
受。于是我们当时决定自己做，
所以就有了这套框架（Amaze
UI），一直以来都是给云适配整套
体系用的，后来我们觉得这套东
西可以剥离出来，让别人也能
用。所有人开发移动网站的时
候，都应该需要这么一个框架，
因为这样可以大幅度提高开发效
率，不需要重新发明，这是一个
基本的思想。
在开源之前，陈本峰的团队主要做了
3件事情，这些看似微不足道的步骤
为开源项目打下了良好的基础 ：
代码精进化
文档规范化
启动内测
国内开源项目尚处萌芽期
随着国内技术社区的发展，国产开源
项目越来越多，但真正运营成功并取
得广泛关注的例子并不多。在笔者抛
出这个问题之后，陈本峰显然已经早
有答案。他指出，从国外的开源经验
来看，一个项目要想成功，必须有一
个专职的研发团队来做。虽然我们谈
开源，经常说靠社区的力量，但是最
核心的推动力还需要是专职团队，并
且这个专职团队是真的为社区服务
的。
国内很多开源项目，大多是开发者自
己的兴趣爱好，并不是公司层面来支
持项目的，经过一段时间之后，开发
者工作调动或者公司业务重心转移，
就会导致项目夭折了。陈本峰分析过
Github上的一些开源项目，刚启动的
时候，更新频率很高，一个月有几十
次，但是到后来，基本两年都没有更
新一次了。这种状况无法给潜在的开
发者信心。
对于开发者来说，评估开源项目可用
性主要有两点，一是社区支持度，二
是活跃度。这两项不达标，就没人敢
用。陈本峰认为，如果开源是一个公
司行为，而不是个人兴趣爱好，那么
活跃度可以有保障。
如何成功做好开源项目
即使公司提供支持，开源项目就可以
成功了吗？显然不是！ 陈本峰强
调，开源要用一种服务社区的心态去
做，而不只是服务自己公司内部。
虽然Amaze UI是云适配整个大产品
体系的一部分，但是开源之后，
Amaze UI团队就只需要去考虑外面
社区的开发者的需求，把我们自
己的内部团队也当成跟外面社区
等同的客户去对待，不因为是内
部的团队就优先处理，而是看这
个需求到底是大家普遍认为一个
比较需要的高的需求，还是它就
是我们的一个特殊行为。如果是
我们的一个特殊行为，就应该慎
重。让我们内部的团队基于开源
基础上自己去改，改完以后由开
源项目团队判断是接受还是拒绝
掉，完全独立地由两套团队去运
行，他们的目标也就非常明确。
云适配跟Amaze UI开源的目标是各
自明确的，互相独立的。我们在
做的过程中，也发现外面社区有
很多比较强烈的需求，比如我们
在做Amaze UI里面发现最大的一个
需求就是除了Amaze UI本身提供的
一些功能，客户需要一些第三方
的英文插件。其实这个需求本身
在云适配这块是没那么强的，因
为云适配这块主要还是针对移动
端，而客户需要的英文插件是开
发者在做一个横跨手机、平板、
PC三屏的网页时会需要的。并不
是云适配的强烈需求，但是在我
们的2.0阶段最重要的工作就是做
这件事情，这就是个非常典型的
例子，说明我们是优先考虑外面
开发者的，然后才是考虑内部开
发者，或者就等同对待。
这并不是纸上谈兵，Amaze UI项目如
今由两位全职的开发者在推动和维
护，都是云适配的员工。
用产品的标准做开源，解决移动化
难题
对于开源项目的定位问题，Amaze UI
虽然提供英文的相关介绍，但是它更
是为国内开发者优化的，陈本峰分析
了几个原因：
本土化的支持，Bootstrap没有做
专门针对中文的支持。字体是网
页里面非常重要的一块，直接决
定了网页展示出来的体验的好
坏。Bootstrap里面是没有定义中
文字体的，这就会导致每个浏览
器都会根据默认设置去选一个字
体。比如说IE在XP和Window s 8下
字体就是不一样的，在苹果下面
字体又不一样了，然后在各种手
机浏览器上面字体都不一样。最
后导致做出来的网页可能在各种
浏览器、各种操作系统下面看起
来效果都不一样，是完全不可控
的。而且可能会导致排版格式变
掉。Amaze UI里面很严格的定义
了中文字体，做到在各种设备、
操作系统、浏览器下看到的效果
基本上是一样的，比如说中文字
体，我们用的是雅黑。在Window s
底下是雅黑，但是在苹果底下是
没有雅黑这个字体的，那我们就
用最接近的黑体去做。Bootstrap
基本上是用13号字，我们是用14
号字，字号的大小也会导致排版
不一样。Bootstrap不太可能去加
中文字体，因为如果一旦加中文
字体，就还要加日文字体、韩文
字体、法文字体， Bootstrap就会
变得巨大无比了，这肯定也不是
产品设计的初衷。还有对本土浏
览器的支持，当时做Amaze UI的
另外一个想法源于浏览器的兼容
性，对于多数前端开发者来说，
或者都是一个梦魇。可能开发一
个网页用一个月的时间，但是做
浏览器的兼容可能要花两个月的
时间，甚至都做不完，面向的浏
览器太多了。这些工作没有必要
让开发者一遍又一遍的重复。所
以当时我们想做一个开源产品，
大家基于这个产品，把浏览器兼
容性都调整一下，以后使用这个
产品就行了，节省了大量的工
作。国内浏览器和国外浏览器也
是很不一样的，像360、搜狗等，
而且国内有双核浏览器，这也是
国外不存在的。针对这些中国特
色，我们会做一些调整和一些特
别的优化，这也是我们跟
Bootstrap一个比较大的区别。
移动优先，Amaze UI一开始为移
动端开发的，所以非常考虑在移
动端的表现，要让整个代码体积
尽量小。另外尽量的采用CSS3的
动画，动画效果以前在PC端，都
是用JS版做，一方面要下载JS代
码。另外一方面是它对机器的要
求比较高。因为JS需要大量的
CPU运算。移动端的浏览器，相
对来说都比较现代，都是支持
Html 5的，使用CSS3动画就会节省
代码，因为一行CSS3代码可以解
决一个动画的问题，代码体积会
小很多。第二，因为CSS动画是浏
览器原生支持的，所以会有硬件
加速。硬件的运算能力是要比用
JS软件上的能力要强很多的，所
以整个移动端的体验会好。
组件化，Amaze UI非常强调组件
这个概念，近两年有一个非常热
的技术叫做Web component，它的
意思是说，网页的每一个构件，
都可以封装成一个组件，这种技
术在后端已经非常成熟了。比如
说Node.js里面的NPM，可以用来
管理各种各样的包。Ruby的
Ge m，Python也有，但是前端是没
有的。在前端大家的做法是非常
原始的，比如要做轮播图，就是
拷贝大段的Html 5、CSS和JS，这
个很大的问题就是，只要拷错一
行，就不工作了。另外一个是更
新的问题，来源的组件更新了，
本地的代码也需要更新，可能一
个修改就直接导致更新不了。所
以前端整个开发的技术还是相对
比较原始的状态的，所以Google
在2012年的时候提出了Web
component的概念，这个概念发展
的非常快，W3C已经把它列入标
准的开发范围了，现在已经在推
进这个Web标准，我们设想未来的
Web前端开发，应该是基于这种组
件式的，所以我们也做了很多组
件。Bootstrap并没有朝这个方向
去走，它更多的是强调它这种框
架的底层架构，而我们强调组
件。而且这种组件是非常具有本
土化特质的，比如说我们上面有
百度地图的组件，国外用
Google。我们的客服的组件，都
是第三方部分提供商，或者一些
视频播放的组件，视频播放组件
可能会播放土豆优酷的视频，在
国外会用Youtube。未来我们希望
做成类似于Node.js的NPM的包管
理的系统，程序开发者需要什么
组件，一个命令行直接就下载下
来了。
说到Amaze UI对待开源的认真态度，
版本路线图的规划也是一个例子。陈
本峰介绍说：
我们是比较严格的按照国外比较
先进的开源项目的运营方式，比
如说我们会找Bug，去分级，分成
P0、P1、P2、P3、P4。PO是前面
要解决的，P1会在下一个发布版
本会解决， P2我们会在下一个版
本有时间的条件下去做，没有时
间会往后推。P3属于这种未来可
以讨论头脑风暴的，用户提交上
来一个Bug，一个issue，我们马上
就会做一个级别的判定，这样子
提这个Bug的开发者会知道，他的
这个问题大概是会在什么时间阶
段会被解决，而不是说就是大家
提上来了，我们把所有的Bug拢在
一起，而是清清楚楚去把问题分
类，确定会在哪个版本解决。版
本规划也是，每一个版本的工作
重点都分的很清楚，有很清晰的
规划图，清晰的Bug管理系统，让
开发者觉得这个项目比较靠谱，
认真对待的每一个版本，很认真
对待用户提出来的每一个问题
的，而不是含含糊糊的，让用户
根本没有期待。
开源亦能双赢
目前国内很多企业做开源都是抱着试
试看的态度，那么开源仅仅是做活雷
锋吗？ 陈本峰认为从商业角度，
Amaze UI和云适配也是受益的：
本身云适配业务是让用户把网站
转到手机端，所以我们对兼容
性、适配性是非常关注的。但是
单凭一己之力，是没法做到兼容
性非常完善的。我们开源出去，
如果这个产品有别人用，那别人
也来贡献代码，这样也能够返过
来帮助云适配这个产品，能够做
到更好的兼容性、适配性，对我
们产品的提升是有直接帮助的，
所以我们愿意去做这件事情，也
值得投入做这件事情。
做招聘， Amaze UI的开发者全部
是前端的开发者。我们去招人的
时候，就在Amaze UI上打广告，
大家会觉得Amaze UI这家公司前
端工程师，是一个不错的选择，
就会愿意来，成本跟猎头费的成
本也差不太多。从这点来说，对
我们就是招人肯定是有帮助的。
目前Amaze UI在招募技术爱好
者，也欢迎大家参与。
对于公司这个品牌来说，如果我
们做了一个全中国最流行的一个
前端框架，那么云适配以后做跟
网站相关的一些业务，肯定会得
到别人的认可，这也是一个品牌
上的关注。所以我们会去做这件
事情。对于另外一家公司，他可
能就没有这么大动力了，比如说
如果是一家做电商的公司，他可
能不会有那么直接的帮助，那招
人直接花猎头费了，他也不做网
站相关的业务。可能跟云适配自
己本身这个特定的业务是非常相
关的。
开源的未来出路
开源项目有哪些出路？陈本峰分析了
国外的例子：
开源项目参与模式现在在国外是
比较成熟的，基本上国外2B（To
Business，面向企业，以下简称
2B）产品的公司基本都是做开源
的，我觉得他们的这个商业模式
有几种，一个就是做收费技术支
持，然后就是做培训，我们在做
的过程中已经有这种参与，已经
有人找过我们去给客户做收费培
训。技术支持也可以做，这是比
较容易看到的。还有就是去做一
些系统集成的解决方案的，像
IBM，IBM做了这种大量的开源，
像Java、Eclipse，基本上做这种解
决方案，当然解决方案里面利用
最高的还是它的硬件。当IBM的软
件不是主要收入来源的时候，他
就愿意去做开源的软件，加上自
己的硬件卖出去。像Google做开源
的目的是通过开源这种方式促进
各种人去使用互联网，越来越多
的人使用移动互联网，他的移动
搜索就赚钱了，为什么Google会去
做一个开源的浏览器Chr ome？
Google的商业模式在于流量变现，
只要世界上有越来越多的人上
网，就有越来越多的流量，那他
就能够变现，这是Google的一个商
业逻辑，那这些都是跟他支撑业
务是有关系的，如果纯支撑业务
没关系，那就是培训，还有技术
支持，Redhead就是这种模式。
谈到对未来国内的这种开源发展趋势
的看法，陈本峰对2B市场的开源报以
比较大的期望：
我觉得开源在国内市场里比以前
是要好很多了，市场繁荣多了，
今天的Github上面有越来越多的中
国开发者出现了，随着这个行业
的发展，未来开源这个事情会在
国内会越来越流行。当然我觉得
可能主力应该还是那些大的互联
网公司，因为国外主力也都是像
Google、Facebook和雅虎这些公
司。现在还处在一个萌芽期，哪
一天它真的能爆发，就是看这些
大佬们在这块开始发力的时候。
可能也是因为在中国做2B的大公
司是非常少的，国外这种2B的大
的上市公司是非常多的。在中国
整个2B的企业还没有完全起来，
这个也限制它开源时期的发展，
为什么呢？因为首先这个企业有
很多内部系统的集成的需求，如
果不是开源，他没法知道这个产
品是不是跟他内部的现有的这些
产品能够很好的融合在一起。那
你开源之后，他自己先拿过来研
究一下，是不是结合的好，所以
这个时候，把产品开源，其实是
一种变相的推广手段。第二个考
虑到一些安全性的问题，开源之
后客户也可以消除对安全性的隐
忧，像我们云适配也是，它也是
针对企业，是个2B的产品，我们
基本上也还是按这条路来走的，
所以我觉得国内开源能够飞速发
展，就是有两个条件，一个就是
BAT一些大公司开始介入、开始投
入，第二个就是国内2B的公司开
始参与进来。
受访者介绍
陈本峰，云适配创始人CEO，Amaze
UI项目的领导者，国际互联网标准联
盟W3C中国区HTML5布道官，专注
互联网标准以及浏览器相关技术研究
超过10年。曾任职于微软美国总部IE
浏览器核心团队，师从浏览器行业泰
斗Christian，参与IE的HTML5引擎设
计开发以及下一代互联网标准
HTML5国际标准制定。
作者 郭蕾
3月10日，豌豆荚的张铎成为中国第5
位HBase Commi tter。现在越来越多的
公司和开发者都开始关注开源，开源
正在经历前所未有的繁荣时期，但这
只是开始。从整体比例来看，国内参
与开源项目的人并不多，很多人都不
知道如何参与开源项目。在这个背景
下，InfoQ采访了张铎，希望能深入
挖掘HBase项目组织架构、运营、流
程等方面的细节。
第一次提交代码
作为一个历史悠久的开源项目，
HBase非常复杂，据统计，HBase差
不多有34万行代码，主要使用Java语
言编写，部分模块可能会使用C语
言。我在2008年底的时候就开始接触
HBase，但是提交第一个Patch是在去
年的9月份，当时在工作过程中发
现，HBase有时候会丢失数据，确认
自己的代码没问题后，我开始怀疑是
HBase的bug，定位问题后就立即对该
问题进行了修复。而小米的冯宏华已
经是HBase的Commi tter，也正好是我
的学长，在冯的鼓励下，我把自己发
现的问题提交给了官方。
提交后不到10分钟的时间，就有一位
Commi tter联系我让改代码的说明格式
（有些地方不符合规范），简单修改
后，这位commi tter立即@了负责这块
代码的其他Commi tter。整个提交过程
非常快，HBase方的反馈也很好，和
我之前想的根本不一样。
如果要总结下第一次贡献代码的经
验，我觉得应该胆子大点，不要害
怕。不要怀疑自己的能力，发现问题
就提交。不要担心自己的英文不好，
只要发现问题就往上提，这对自己的
成长也有好处。很多国外的程序员写
的代码很烂，但是他们却敢于提交。
而提交后又有很多牛人来帮你修改，
这相当于免费请大牛当私人教练。
如何成为HBase的Committe r？
并不是第一次提交代码后就能成为
Commi tter，只要提交过代码的都是
Contributor的角色。Contributor要成为
Commi tter，需要持续不断的贡献代
码，并且开发过新的feature（猜
测）。当代码贡献到一定程度时，项
目管理者会主动与你沟通是否愿意成
为Commi tter，并不需要自己申请。
成为Commi tter之前，我一共提交过30
次左右的代码，从官方的邀请信中可
以看到，PMC（项目管理者）比较看
重我为HBase 1.1提交的几个大的
feature，以及对HBase整个项目的单
元测试流程的改进贡献。
目前HBase共有41个Commi tter，但真
正活跃的不到一半，目前也没有相应
的退出机制。Commi tter之间主要是通
过邮件沟通，没有固定的在线沟通时
间。
代码提交后的流程
Contributor不能直接push代码到仓
库，他的代码需要经过Commi tter审
核。如果是一个简单的改动，那一个
Commi tter就可以直接做主。如果是一
个比较大的改动，那就需要多个
Commi tter一起讨论才能决定。如果是
可能影响兼容性的改动，那需要与该
版本的负责人讨论后才能确定。
HBase的代码并没有使用GitHub进行
管理，GitHub上的代码只是一个镜
像。Apache基金会中一些比较老的项
目使用的都是官方自建的Git仓库，
缺陷管理工具用的是JIRA，提交代码
后，JIRA中相关issue的状态会变为
Patch Available。同时，项目机器人
会定时扫描是否有Patch Available状
态的issue，如果有，它会下载相应的
附件，并通过脚本检查格式是否正
确、单元测试能否通过，并把结果发
回到JIRA。当Patch要合并到某个版
本之前，该版本的负责人会重点进行
测试，包括功能和性能上的。
HBase的项目架构
HBase的项目直接负责人称为VP，VP
全职负责这个项目。VP下面是几个
PMC，每个版本的release manager一
般是某个 PMC。PMC下面就是
Commi tter了。一般情况下，一个
Commi tter会对HBase的固定负责某个
版本的某几个块功能模块特别熟悉，
所以当Contributor提交代码时，项目
组是有审核该代码的第一负责人。
HBase项目组会优先让对该模块比较
熟悉的Commi tter来审核，这个
Commi tter的意见也是最重要的。
HBase主要的代码贡献者都
是Cloudera和Hortonworks的员工，他
们都是全职负责HBase，甚至HBase
中写文档的人都是Cloudera的员工。
Cloudera和Hortonworks都是基于
HBase的商业公司，他们同时维护开
源的HBase，但同时也都有自己的商
业版本。
社区分歧
每个开源项目都会遇到技术方案分歧
的情况，同样HBase也有。HBase在
这方面并没有好的解决方案，每次讨
论这样的问题时都会分为两派，大家
都在说自己的解决方案以及优势，但
是永远也没有结论。目前也没有相关
的投票机制，比如谁的得票多就听谁
的，因为投票很容易导致产生更大的
分歧。
其它开源项目也没有好的解决方案。
如果社区比较融合，大家都抱着解决
问题的心态来看待这样的分歧，那还
好办。但如果大家都比较偏执，一派
人坚持要这样做，另外一派人坚持要
那样做，那这样下去稍有不慎社区就
可能分裂，这已经有先例了。再或者
就像HBase一样先挂起这问题，但也
不是长久之计。其实分歧问题和社区
文化直接挂钩。
开源谈
如果只靠个人无私奉献，开源项目很
难发展起来，更不用说建立生态圈。
如同公司一样，开源社区需要有人来
推动、管理和运营，开源不仅仅是代
码本身。比如前面提到的开源文化，
这完全是需要有人来引导的。
豌豆荚一直比较崇尚互联网「开放」
「平等」的价值观，也很支持重视开
源技术。公司决策层领导层也非常重
视员工在技术方面的长期积累，所以
也允许我有一些比较自由的时间来研
究HBase，做一些贡献，也不要求这
个研究马上得在多少天内就贡献多少
代码或者做出多少新feature。我觉得
豌豆荚对于基础技术的长期积累还是
很看重的，而且很有耐心。纵观一些
好的公司，一定会多给员工一些属于
自己的时间探索新的东西。如果每天
都很忙，不停的在加班，那什么时候
去进步了？员工的成长甚至跟不上公
司的成长，长期来看反而会拖累公
司。
受访者介绍
张铎，豌豆荚基础技术负责人，目前
主要关注存储相关的技术。2010年研
究生毕业，来豌豆荚之前一直在网易
有道工作，从事的也是基础技术相关
的工作。2014年底带领团队开发了名
为Codis 的分布式存储解决方案，并
于2014年11月7在GitHub上开源。
作者 臧秀涛
2015年3月，赵海平回到中国，加入
阿里巴巴技术保障部，任职研究员，
将重点攻克阿里巴巴在软件性能以及
Java使用过程中遇到的技术问题。
InfoQ已经邀请他在4月23日~25日举
行的QCon北京2015大会上做主题演
讲，分享《异步处理在分布式系统中
的优化作用》。是什么吸引他加入了
一家中国的互联网公司呢？InfoQ对
他进行了专访。
InfoQ**：首先欢迎您回到中国。可
以介绍一下您加入阿里巴巴的初衷
吗，阿里巴巴最吸引您的地方在哪
里？ **
赵海平：去年机缘巧合，我和阿
里巴巴的同事有了交流的机会。
当时我们聊了很多技术细节，发
现阿里巴巴的规模非常之大，很
多技术上的难题是美国公司都没
有的。比如说双十一这个问题，
没有哪家美国公司单天有这么大
的交易量，这是很特殊的一个问
题。这个技术问题对我特别有吸
引力。
当规模大到一定程度，简单的问
题也会变得复杂。有的时候软件
就是这个样子，在一台或者几台
机器上执行是一个情况，当机器
多到一定程度时，对软件的要求
就特别高了。在多台机器上，怎
么才能保持很快的速度，并且节
省机器，又不出问题，这是一个
很难的技术问题。
单天的资源需求是平时的好多
倍，怎么机器，让峰值最高
的那天不出现问题，平时又要做
到很好的利用，这是很不容易
的。我特别希望自己能够有这么
一个经历，去阿里巴巴解决这个
问题，这是在其他公司找不到的
技术问题，而且跟我很对口，我
一直在做的都是怎么提高大规模
系统的性能、稳定性，所以这正
是我的兴趣所在。
InfoQ**：您在阿里巴巴的新角色就
是解决这些基础设施的性能问题？**
赵海平：基本上是几个方面，性
能、稳定性、容量、架构，还有
运维，恰恰就是我现在这个团队
——技术保障部——的工作。性
能提升上去，容量就增加了，随
着我们监控系统的改进，系统的
稳定性也会提高，运维也会更方
便。如果发现架构上的问题，我
们也会做些调整。
InfoQ**：谈到性能问题，定位是很
关键的一点。像这种规模的分布式系
统，如何实现全系统的监控，准确定
位问题就非常重要，您会在这方面发
力吗？**
赵海平：Profiling特别重要。如果
能有一个特别强大的Profiling系
统，就知道整个系统在哪个地
方，哪台机器上，花了多少CPU、
内存、磁盘IO或者网络带宽等资
源，才能知道优化什么地方效益
最大。
所以我的第一步工作就是帮助完
善阿里巴巴的监控和Profiling系
统，希望能够很清楚地把软件的
整个性能展现给大家，做到实时
监控，同时让研发人员看到自己
的代码在线上的运行情况，了解
这些代码花掉了多少资源，这样
有问题的话他们可以自己解决。
InfoQ**：大家对您的最初印象多是
来自HipHop for PHP这个项目。像淘
宝之前就从PHP切换到了Java，而
Facebook选择了自己改进PHP。可以
谈一下这个项目吗，当时的出发点是
什么样的？**
赵海平：HipHop也是一步步慢慢
建立起来的。最初是我遇到了一
个PHP的函数，在C++里也想用。
当时想，重写一下就可以。不过
那个PHP函数不断在变，我就想写
一个简单的工具，把这个函数转
换成C++，这样就可以跟上PHP代
码的变化。那时正好机器开始吃
紧，大家意识到PHP的速度问题，
CPU消耗很大。大家就开始讨论如
何提高PHP的性能。当时想法很
多，有人想改变PHP本身，有人想
干脆用Python或Java重写网站。
当时也重写过，有三四个人在做
这件事情，但这些人改的速度远
远赶不上另外二三十人写新PHP业
务代码的速度。所以我们就想到
写一个工具，来转换这些新写的
代码，既不干扰既有的开发节
奏，又能大幅优化性能，跟上变
化。
当时我也读了下Zend Engine的代
码，研究PHP为什么会慢。发现
PHP速度之所以慢，是因为有很多
的函数调用是动态的，而像C和
C++里，很多函数是静态调用，不
需要在执行的过程中去查询函数
指针在什么地方，所以速度才
快。
所以我们做了很大的调整，一定
要改变这种方式，争取让所有的
函数调用都能尽快实现，在编译
的时候静态处理，执行的过程中
就不需要再查询，指针已经在那
儿了，这是最主要的加速思路。
那时候就萌芽了一个想法，如果
能够把PHP直接转换成C++，也许
这个性能问题就解决了。然后就
花了很多时间去做原型。我们做
了很多工作，把底层的PHP实现都
改变了，有一个自己的Runtime
Library，再就是一个PHP的扩展
库，这个实际上是很大的一块代
码。在这个上面，我们又写了一
个把PHP转换成C++的一个编译
器。先将PHP编译成C++，然后靠
底下的这个库实现功能。这是最
早期的工作。
不过这在当时只是一个副业，因
为不知道这个东西到底有没有意
义，是不是能提高性能。大概能
拿出30%~40%的时间做这个。做
完之后发现效果很好，就加入了
其他同事一起做。后来速度不断
提高，第一年提高了2倍，第二年
又提高了2倍，后来提高到5~6倍
的样子。
现在回头看，如果当时雇很多人
把网站改成Java的，也是可以做到
的，但Facebook的发展可能要停半
年到一年时间，甚至更久，就有
可能对Facebook的发展带来不可预
期的影响。这件事情主要还是业
务推动的。
InfoQ**：后来HipHop发展成
HHVM，从原来的静态编译变成了动
态的JIT机制，您也参与了这方面的
工作吗？**
赵海平：引入HipHop之后，我们
也有自己本身的一些问题，比如
产品环境和开发环境就是不一样
的，这样多多少少会存在一些问
题，也就容易出现bug。再就是
Facebook的代码量非常庞大，编译
时间非常长，另外生成的二进制
文件也非常大（超过1G），发布
也很困难。
这时就出现了HHVM。HHVM不再
是把PHP转换成C++，而是采用了
一种新方法，把PHP转换成一个中
间码，这个中间码在执行过程中
再转换成机器码，不过调用的还
是我们原来为HipHop写的底层
库，它取代的主要是把PHP编译为
C++的过程。
我并没有参与HHVM的编写，当时
我已经离开这个小组了，另外一
件事情吸引了我，这就是异步处
理在分布式系统中的优化作用。
之所以离开这个小组，原因大概
有几个方面：一个是，个人认为
HHVM不再能把性能提高更多了，
后来也确实如此，两三年之后
HHVM出来，速度并没有更大的提
高，最高只比原来静态编译机制
快10%~15%，而且是因为静态编
译这一块不再开发了。再就是新
的课题特别有意思，具体我会在
QCon北京上分享。
这就是为什么去GitHub上看，
HHVM里面会有我的代码，主要是
底层的代码还是基于HipHop的。
HHVM的头两个字母就是来自
HipHop，引擎还是原来的，不过
上面做了很多工作，把PHP转换成
中间代码，这个有点像Java的
J VM。这样的好处就是研发过程和
产品过程其实是一样的，而且不
会有原来说的那种超大二进制文
件的问题。中间代码很小，PHP可
以直接发布到线上系统上。
InfoQ**：国外一些著名的互联网公
司，在性能调整和优化的过程中，慢
慢都发展出了自己的编程语言，像
Facebook设计了Hack语言，Google有
Go和Dart等语言，Apple有Swift等。
这方面您有什么感想吗，Facebook的
Hack语言您是不是参与设计了？**
赵海平：Google的Go语言挺有意
思的，写得非常好。Hack语言我
没有太多的参与。
PHP是弱类型的，这是性能提高的
一个瓶颈，而强类型的话就可以
做很多优化。最初我们是想增强
PHP的类型系统。强化数据类型，
这是引入Hack的一个主要因素。
InfoQ**：PHP7最近也有很多改变，
性能提高也比较大。**
赵海平：这也是我临来之前刚刚
听到的。PHP核心开发组的力量是
很强的。我也跟他们的人员交流
过，他们对整个PHP的优化有自己
的思路和想法，也做了很多工
作。这是件好事。其实重要的并
不是说哪个团队或小组把PHP优化
到什么样的地步，有几个小组都
在做这个事情，彼此竞争，会促
进整个PHP生态系统的发展。这种
竞争也恰恰说明了PHP的重要，所
以会有很多人关注它的性能优
化。
InfoQ**：您对公司发明创造自己的
编程语言怎么看？**
赵海平：编程语言这个问题，我
说两点。第一，不能把语言当成
一个特别神圣、至高无上的东
西。语言也是整个软件系统的一
部分，只是它分割的很好，独立
出来了，可以执行更多的功能，
我们可以用它实现我们的功能，
可是在整体架构上看，语言也只
不过是软件系统的一部分，而这
一部分我们完全可以做一些调
整，使其更适合我们的系统。而
设计语言时一般考虑的是比较通
用的目标，我们拿来用，只是因
为它的绝大部分特性都是我们想
用的。比如我们用C和C++写程序
的时候，每次都要思考内存的模
式是什么，是不是用share
pointer，是不是用自己写的
Object，内存的
allocation/deallocation怎么做，一
个语言帮我们把这些事情都做好
了，这就是它的好处。它提供了
一个很大的库，提供了一个软件
执行的环境和范围，而这正是我
们选择语言的初衷。
第二，作为一个公司来讲，不能
说为了研发一个语言而去研发一
个语言。这是没有意义的。一定
要根据自己想要做的事情，在现
有的软件架构当中，我们发现当
前所用的语言提供的环境和范围
不太适合，或者说这个语言的很
多假设和假想，和我们所期待的
东西并不一样，只有在这个时
候，我们怎么也找不到一个合适
语言的时候，我们才会创造一个
新的语言，让这个语言更适合公
司的事情。如果可以通用化，提
炼出来，那就是语言，否则设计
成软件库就可以了。
这是水到渠成的，不要强求。像
Google开发Go语言，我认为它有
自己的考量，可能在开发很多分
布式系统的时候，现在的语言写
法上不太直观，或者速度不够
快，所以才创造了这么一个东
西。Go应该能解决公司内部的很
多问题，否则是很难存活的。
InfoQ:**您可以结合自己这些年的经
验，给中国开发者的成长一些建议
吗？**
赵海平：在美国的时候，我跟
Facebook的中国员工聊的很多。我
给他们最多的建议就几条。
第一，一定要提高交流能力。咱
们中国人，尤其是中国搞计算机
的人，很多人有个不该有的特
点，就是喜欢把自己锁在黑屋子
里埋头干活，跟机器交流特别擅
长，跟人的交流一窍不通。这样
不行，我相信在中国也是这样
的，你不但要把自己的工作，技
术活要做得特别好，而且要擅长
表达自己的想法，擅长在工作当
中讲述做的是什么，怎么样能够
说服别人，怎么样能够跟别人在
不伤和气的情况下，把问题解决
好，这是很强的一个能力，而这
个能力不是在学校里能学会的，
是我们走向社会之后慢慢学到的
东西，这个我恰恰认为中国的员
工，尤其是在美国那样的环境，
因为不是母语，可能处理得就不
是特别好，有时说出来的话比较
生硬，给对方的感觉不是特别
好。
第二，中国人比较谦虚、内敛，
讲究内涵，自己心里有的东西不
表达出来。但是在工作中，可以
适度强势一点，勇敢表达自己的
想法。当然这个建议是基于美国
多元文化的背景，在国内大家的
文化背景一致，也许可以探讨最
合适的沟通方式。
第三，掌握好英语，开拓眼界。
我觉得在计算机这个技术里边能
够非常了解英语，把英语的这个
隔阂给去掉还是非常重要的。
我回来的时间还不长，等和大家
接触多了，可能会有新的想法，
目前就这几点吧。
InfoQ**：好，感谢您接受我们的采
访。期待您在QCon上的分享。**
受访者介绍
赵海平，2007年加入只有不到50个软
件工程师的Facebook，致力于软件性
能和架构分析，在此期间创建了
HipHop项目，重新编写和实现PHP语
言，使其速度提高5到6倍，为公司节
约数十亿美元。HipHop项目之后，
致力于“用异步处理来优化分布式系
统”的设计理念中，并为此做了多项
分布式数据库的优化研究，在PHP语
言中加入了yield和generator的新功
能，来帮助日趋复杂的Facebook 网页
设计。
