林昊：用淘宝T4保障系统稳定性 降低运维成本

阿里巴巴高级技术专家林昊（腾讯科技配图）

腾讯科技讯 10月27日消息，2012全球软件开发大会（杭州站）进入第三天议程，阿里巴巴高级技术专家林昊在会上发表主题演讲，分享“T4：淘宝私有云”。

林昊介绍，淘宝在2011年开始引入虚拟化，引入以后，淘宝整个运维成本下降许多。他指出，许多企业运维成本不够低的主要原因包括：单台物理机上跑的应用不够多；分给应用的机型以及机器数是静态的；集群的资源利用率不均衡。

所谓淘宝T4，林昊表示，淘宝架构都以主题的功能系统来命名，到目前为止，淘宝都处于3.X的时代。如果他们做了一个产品来改变整个运行体系，整个产品将会改变整个淘宝运行体系，因此他骂们命名为淘宝4.0，缩写为淘宝T4。他还指出，T4目标其实比较简单，保障系统稳定性最为重要，在保障整体系统稳定性的情况下，降低整体的运维成本，这才是重要目标。

今年有来自于腾讯、阿里巴巴、淘宝、盛大、天翼、百度、陌陌、支付宝等公司的一线技术专家，以及国外的Facebook、Tumblr、PayPal、RightScale的讲师等国内外技术专家出席了本次大会。

腾讯科技作为大会战略合作伙伴、官方指定微博平台，全程图文、微博直击大会盛况。

以下是阿里巴巴高级技术专家林昊演讲实录：

林昊：这应该是三天上午场中最轻松的一场，因为唯一一场中文。会给大家介绍一下，很多人以前在内部分享的时候，很多人都都会问我调查念T4还是TFOUR，原来是T4不是很吉祥。我给大家介绍一下T4的起源，在整个阿里的使用状况以及我们后续的计划。

淘宝到大概在2011年开始引入虚拟化，那个时候我们的方案在一台物理机上虚拟成三个虚拟机，引入以后，淘宝整个运维成本下降了不少。随着我们几年以来机器规模增长非常快，所以也面临一些新的问题。去年年终的时候我们统计了一下，我们看到其中有三分之一的虚拟机风值漏的只有0.5。愈是在去年年终的时候，我们计划做一个产品，来提升整体的机器的利用率。多人为什么叫T4？淘宝对外讲我们技术发展体系的时候，比如说在前几年，淘宝对外讲淘宝的整个架构演变的时候，大家都会看到淘宝对整个架构有版本的命名，我们已经经历过的版本有淘宝PHP，第二个是集中式Jave，3.0是一个大规模的分布式Jave应用。一般来讲，淘宝架构都已主题的功能系统来命名，所以我们在目前为止，我们都处于3.X的时代。我们认为如果我们做了一个产品来改变整个运行体系的话，整个产品将会改变整个淘宝运行体系，所以我们命名为淘宝4.0，缩写就是淘宝T4。

我们做这个产品的时候，T4目标百其实比较简单，保障系统稳定性最为重要，在保障整体系统稳定性的情况下，降低整体的运维成本，这是我们的重要目标。然后一点是这个产品在推出的时候，我们必须能够实现平滑的迁移。比如说淘宝到现在为止已经九年了，有很多历史因素摆在那里。假如我做一个新的T4，原来所有体系要推翻，这个东西是非常难以运用起来的。所以对T4来讲，实现平滑迁移非常重要。我们可以看一下运维成本不够低的主要原因，从我们角度去看，主要有三个原因：第一，单台机上跑的应用不多，我们是一虚三的方案，所以需要跑更多；第二分解应用机型以及机器数是静态的，我们是一个固定分配方案，一会说一台机器上分配出来有不同类型的机器，一定是同种类型。机器数也是大问题，上线的时候一定会开始做一个简单的预估。所以很多时候会出现一个状况，就是你申请那些机器，其实非常富于，要么就是根据不够用，有两种状况。这个可以借助容量规划等等技术提供一定帮助，但是不足以让整个机器利用率做的很好；第三，集群资源利用率不均衡。比如说一虚三，在给应用分配机器的时候，到底这个应用要分配到哪台机器上，这是很大的问题。因为应用是会动态变化，即使上线的时候估计这个应用是CPU型，但是后面很可能会变成另外的类型。这个时候，整个集群利用率会变的非常不均衡，这个问题会导致整个运会成本只能处于一个比较高的水平。

根据这个状况，我们在考虑方案的时候，会围绕这几点来做。比如说如果让单台物理机上跑更多应用，很简单。比如说大家看到外部各种各样的云在卖各种各样的机器的时候，其实这太极旗不一定是完成给你用的，可能一台机器上跑的资源超过分配资源的数，所以必须支持超配。因为要保持稳定性，所以超配一定要支持资源可共享。要支持共享资源动态调整，这是从稳定角度高度考虑。必须有一个动态调整方案，能够让他现在给你的是1号，运行的时候，根据整个运行状况，可能会调整到2号，3号，所以要支持共享资源到能动态调整。部署的应用要做合理搭配。比如说这个很多人都会想，我们资消耗多的和少的搭配在一起是很好的，我可以让资源消耗少的CPU奉献出来资源消耗多的去用，然后消耗资源要不同互补。从静态角度，其实都不是很好做的，必须是一个动态方案。

分配应用的机型和机器数是静态，也会造成运维成本比较高。再分配的时候，这点要做成动态。动态的方案肯定是根据应用资源消耗状况来做动态调整，比如说你上线以后，发现你的CPU利用率不高。加入上线给了你4个CPU，随着上线运行状状况，可能会从4个降到两个。所以这点就爱国机型本身是支持动态调整的。机器数如果要动态变化，对应用来讲要求主要是这个应用的上线和下线的过程必须是全自动化。像淘宝做双十一活动，很也可能我们双十一是平时N倍量，如果不是全自动的话，必须人工不断介入，这个成本是非常高的，因为维护应用非常多，机器数也非常多。集群资源利用率要做到均衡，运行师能够动态迁移的话，就会保证集群资源利用率是一个均衡状况。

根据这样分析，我们决定在集群方案上有两个点需要做到。第一，这个方案要具备动态性：第二，要具备弹性。动态是指单机资源的搭配以及数量可以动态调整，因为虚拟化方案需要引入，如果不做隔离的话，应用的稳定性会很受影响，所以虚拟化方案仍然需要。我们需要做动态的迁移，如果你想在运行时动态去迁移，首先一个前提是要有一个比较好的监控系统。比如说你的监控系统是10分钟延时，或者半小时延时是没有任何意义的。然后需要做一套资源管理系统，应用上下线一定是全自动化。弹性在T4里面，是指能够根据资源消耗状况，来做动态调整。亚马逊上线以后，他们不用做容量规划，原因是有动态的，它本身具备弹性能力。

同样压做到这点也需要强大监控系统，监控系统是其中最基础的东西。

看一下我们选择的虚拟化方案，我们虚拟化方案必须支持动态的搭配还有数量，这里面数量的定义不知道用什么词比较好。动态搭配，假设一个虚拟家分配两个CPU，开始分配是0、1号，动态是指要不调整，可能会调整到2、3。数量是指我开始给你分配一个CPU物，但是运行的时候需要调整到两个、三个、要不断的变化，虚拟化方案要很好的做支持。因为T4主要做淘宝内部应用，不用于对外提供服务，所以内部应用的特征在淘宝，我们特征主要是不做任何共享，是一个很集群化的，这点很重要。这点就意味者其实在集群中，当机任何一台是没有任何关系的。基本都是统一的OS，不会有其他的OS在里面。相对来讲，内部安全级别没有那么高，内部应用不会有人在上面做恶意动作。

我们经过一些预言之后，我们选择LXC。我们自己尝试去做一个轻量级虚拟化方案，我们发现太痛苦，后面还是选择LXC。LXC有两个部分对我们来说很重要，一个是namepace，有了这个之后，可以让我创造出来的每个容器可以享用不同的IP。比如说N个应用部署在一起，像淘宝的应用出现的第一个问题是端口会冲突，淘宝很多应用端口是写死，所以IP首先要隔离。然后是用户需要隔离。如果大家用外部AE的话，其实它的用户是很容易做的，每个应用都可以让你跑在不同用户下，像内部应用这点没有办法做。如果虚拟化方案中，必须支持我每个创建出来的容器上都可以有相同的用户，这种在LXC里面都是很容易支持的。所以namepace对我们来讲是很满足我们需求。然后是cgroup，它作CPU和内存上比较成熟，假设我给一个容器分配两个CPU，我可以做到的是让它在两个CPU上最多占用百分之多少的资源。比如说可以让1号CPU上最多占用50%，而且这个是一个比较智能的。如果1号CPU没有人抢用的话，这个应用是可以直接抢到100%的，用cgroup，资源控制会做到非常细。我们选择LXC以后，在T4里面创建的每个LXC容器我们叫Instance。

选择了LXC以后，因为他支持动态调整，但是你需要有更方便的方式。CPU搭配的动态调整，LXC自己是不会做的。我们在上面做了一定的封装，比如说在T4里面，大家可以看到，如果选中一台T4机器，在上面可以做一系列操作。在这张截图上，有调整CPO的个数，调整内存的限额，调整硬盘的容量。像这些东西调完，都是立刻生效的。在淘宝应用里，我们看到这几个功能可以起到很大作用。比如说某个应用会作某个时间点突然做活动，在传统情况下，几乎是没有方案的，一种方案是立刻加机器，但是加机器的功能不是那么简单。如果碰到高峰的话，多数用限制流量来做。有些应用上了T4以后，我们的方案是当它做活动的时候，比如说我之前给你分的是四核，随着你流量上涨，我给你加CPU，有可能会动态给你加到8核。你可以非常容易去支撑突增的高峰，相当于给你加了一倍的机器。因为应用不需要重启所以这个有很大的好处。

监控对于我们来说是有好处的，因为淘宝是一个已经运行九年的网站，本来有一套县城的监控系统，所以我们什么都不用做，我们唯一需要做的是T4的应用是它是完全无缝集成的。另外是应用上下线全自动化，淘宝在去年，在T4以前，我们应用的上下线不是全自动化的，整个过程需要有很多人工参与。对于T4来讲，如果上下线不是全自动化的话，是不可能做动态迁移的。虽然我们没有自动化上下线系统，但是我们有很多套负责各种运维的系统，让你从原来的虚拟化迁移到T4，是完全无缝的。对于我们来讲，在这点上，我们也做了很多的工作。

资源管理系统。资源管理系统在T4里面有一个演变过程，这个管理系统主要是用来负责资源的分配以及调度。比如说现在一个应用要上线，需要分配10台机器，它会在这套系统里面分配10台机器。我们最早的时候的做法是资源池的方式，比如说我们拿到一台物理机，我们在这太物理机上创建出固定个数虚拟机。我们上线以后碰到一个问题，创造出来的Instance配制是一样的，很多应用都满足不了。比如说这个应用需要另外一种机型，应用跑不起来，所有必须提供各种各样的机型。这样时候就很痛苦，因为资源池是一个固定方式，后来我们改成了按需分配的方式。但是其实机型太灵活也会带来一些问题，比如我我们的机器是很灵活的，你可以创造各种各样的机型，这种机型来灵活的状况会带来碎片化的问题。所以共有云为什么是等倍的机型，这样是不会有碎片化的。

结合监控调度整个应用资源。其实T4认为只有做了这个，才能算一个真正走入云的阶段。T4还没做这一步，所以有点标题党。可以看一下T4的结构，其实T4的结构是比较简单的，不是一套很复杂的系统。T4主要由两大块组成，一个是web界面，这套系统是用Jave写的。这套系统的背后是整个阿里众多的运维系统，完全不会有重新的现象，因为我们是对接现有的所有运维系统，所以整个过程都是很平滑。最下面是一台T4的物理机，T4的物理机我们内核是我们改造过的，然后会有LXC，我们也稍微做了一些改造。因为LXC的官方版本有一些BAG。每台物理机上有一些Instance的控制脚本，所以运维人员非常容易维护，会有一个CPU调度程序，每个Instance里面会有一些控制脚本，所以看到T4的整体是由各种各样的东西组成的。有Jaee部分、内核部分、虚拟机部分和整个控制的脚本部分。

我们碰到过的一些问题，可能对于有些想做这块的有一些帮助。比如说的一个问题，是我们刚上线的时候很明显的问题，如果你用LXC的话，你用LXC创建一个容器，创建一个容器之后，某个应用的人会看一下状况，看的是物理机的状况，你根本不知道自己利用率是怎么样。所有状态都是这样，LXC是没有做这一块的，所以它也不是一个很完整的方案。我们的方法是直改掉内核，可以让你做到，当你进入Instance的时候，第一个看到是我给你的。其实看到是比较诡异的，如果我给你一个Instance机器，你看到的是很连续的，其实整个利用率计算是均衡的。

然后一个问题是目前用LXC方案中遇到比较大的问题。做托管的话，一定会碰到每个托管的Instance里面会有多个相同的帐号，比如说这个Instance里面有user1，另外一个也有。在LXC并不支持user，所以会互相影响。我们现在临时解决方案是会让你每个Instance创造的用户都有不同的UID，即使帐号是一样的。但是也有一些问题，假设我要挂一个设备，很有可能我UID不会改，这个时候大家权限就会乱掉。这是一个不完整的方案。还有LXC是不支持磁盘空间做限额，Img面临的方式是不能缩小，缩小也可以，需要停机做维护，不是一个动态调整方案。对于我们来讲，这个方案也是非常痛苦，我们当时上线以后，在这点上就碰到很多问题，不得不做了一次很大规模的停机，来切换到用quota来做。每个Instance里面用户UID是一样，而quota用UID做限制，你一定会面临一个问题。如果用UID来简，我会把所有Instance都限掉。现在我们在内核层面做新的方案，新的方案是会做目录级的quota，比如说这个Instance给你的是APP1的目录，我对APP1做quota，会让你做到每个Instance磁盘空间限额都是全体的。

Cgroup里面有一个死锁和活锁的问题。大家感兴趣的话，可以去看一下连接。这是我们内核团队的人做的。因为我们的机器里面一定会有各种各样机型，我们碰到的一个问题是在某些网卡情况下，如果直接执行一下network restart，就会直接导致网络挂掉。LXC还有运维上面的问题，比如说如果是虚拟机的话，运维人员进去之后，我改了一个东西，我需要重启这个东西才会有效，就要执行Reboot，所以LXC是一个不完整的方案，我们现在暂时的方法是直接屏蔽掉，LXC容器本身是支持容器，但是需要在物理机上做，在虚拟机上没有办法做。

我们还碰到一个问题，如果在后端挂载一个NFS设备，在某些情况下会导致load的暴涨，这也是内核层面的BAG，现在只有到最新的版本才会有修复。像2.6.3的所有版本都没有修复这个BAG，在连接里面有BAG的详细描述。因为现在T4不支持机型弹性，一个应用上线的时候必须选择一个机型，这个时候是很痛苦的，运维会很纠结给这个应用什么样的机型合适的，这是一件很难选择的事情。所以我们在这里碰到过很多问题，假设上线的时候选了一个两核3G的机器，上线以后发现内存不够用，这只有上线的时候才会暴露。随着T4后续版本的改进，应该是有一些帮助的。

大家可以看到，问题主要是集中虚拟化，弹性是因为功能原则。目前使用状况，覆盖淘宝、天猫、一淘，覆盖有部分Jave应用，T4是跟语言无关的方案，只是我们选择以jave为突破口。我们也会碰到很多问题，比如说我们虚拟机本身是支持CPU动态调整，可以从两个CPU加到4个，但是很不幸，Jave很多东西不支持CPU动态调整，也会带来一系列问题。Instance的数量在上个月的时候突破了1000台，这个规模在阿里不算大了，是一个比较小的规模，但是有1000台规模情况下，可以验证整个方案是比较稳定的。我们是在一个蛮负荷的状态下跑的，事实上，如果真的大规模使用的话，比如说在线应用一定是有余量的，我们现在Instance平均配制是三核5G，因为我们多数都是Jave应用，Jave比较耗内存。

我们物理机有一种机型是16核48G机器，我们平行会运行12个虚拟机。这个跟公有云没有什么可比的，淘宝上每个Instance跑的应用都在几百万以上，其实资源消耗是比较大的。大家可以看到平均每台上跑了16个，看上面的配制就可以知道，其实我们超配比较眼中，简单算一下，我们物理机漏的不是很高。我们现在不会用过于激进的方案，从目前运营状态来看，我们认为将来在一台机器上跑更多，是不会有太大风险。

性能介绍一下。我们这些数据全部是在线上生产环境中的数据，我们一个应用同等QPS的情况下，Instance和RT基本一致。第二个应用可以看到Instance响应时间比xen响应时间低一倍。Load也是一样，有一个应用在压极限的情况系，XEN能撑五倍，Instance能撑8倍以上。这跟应用类型会有一定的关系。

T4现在还在发展过程中，将来我们需要做的重点第一个是动态，我们需要做集群利用率均衡，然后是弹性，第三个是我们会尝试在这个结构上优化整体部署结构。大家知道，比如说我们淘宝在3.0版本中是一个大规模的分布式Jave应用，意味着内部有很多交互状况，这种现象很正常。在这种状况下，有可能我们会尝试优化整体部署结构，让最重要的调用者和最重要的提供者部署在同一台机器上。所以我们觉得如果做这种优化的话，对整体的性能是也提升的，对稳定性有一定帮助。

最后我们会和不同类型的应用一起运行。比如说整个公司有各种类型的运用，有CPU型、IO型、存储类型，各种各样应用。像谷歌(微博)在今年一个PPT里面，有一张图就是讲谷歌共享运行环境。大家看那长图会看到，谷歌在一台机器上会运行各种各样的Jave应用，Maprudece等等，这对公司来讲，对大规模网站来讲，就意味这我整个公司只需要一种机型就可以了，如果只需要一种机型的话，整个IDC规划会变得非常简单。现在我们不得不面临N种机型的选择，这个是我们后一步的目标。