对话伯昊、林轩：阿里 TAE 的发展故事

在 2013 年 7 月的阿里技术嘉年华上，来自阿里巴巴的刘昊旻（伯昊）和侯前明（林轩）介绍了为第三方代码提供托管平台的 TAE。TAE 是建立在淘宝私有云 T4 基础上的一个第三方代码托管平台。发端于店铺系统，现在应用于淘宝 U 站，淘宝 TMS，天猫品牌站等。TAE 为第三方代码提供了和淘宝内部服务直接交互的机制。未来将作为淘宝生态系统第三方代码引入的解决方案之一，支持更多类型的业务和应用。

InfoQ 编辑在现场跟伯昊与林轩沟通了有关 TAE 的更多细节。

嘉宾简介：

伯昊，2010 年加入阿里巴巴，做过 dubbo、TAE。对软件复用、应用可扩展性、DevOps 等话题感兴趣。也喜欢折腾各种开发板，做些自娱自乐的小东西。

林轩，2002 年毕业，2009 年加入淘宝。先后从事过 Java 中间件服务框架 HSF，分布式数据层 TDDL，消息中间件 Notify；2011 年开始专注于淘宝 TAE 代码托管平台。

InfoQ：通过你们的简介，我们知道 TAE 相当于是一个 PaaS 产品。先介绍一下 TAE 的发展历程吧。它是什么时候开始做的？经历过哪些发展阶段？

林轩：TAE 是从 11 年 7 月底发起的，原始的需求来自淘宝店铺的装修市场。装修市场是淘宝的店铺模板交易平台。在这里第三方设计师使用 PHP、HTML、CSS 等编写店铺模板, 为店铺提供美化和渲染；卖家订购某个模板后，淘宝的店铺系统就会按模板的代码来展现卖家的店铺。这些模板的代码存储在店铺系统内部的数据表中, 所以它的扩展性是有限的，只能做一些前端展现的功能。

随着装修市场的繁荣有一些更深入的需求提出来，比如说做个性化的展示，做一些数据存储等。当时的系统结构是无法满足的，所以就发起了 TAE 这个项目做代码托管。这样的话，一个是功能可以更丰富一些，可以有更多复杂的业务逻辑，代码可以有层次结构，可以有自己的设计模式。这是最初的一个需求的来源。

TAE 发起比较早，当时还没有 T4，也没有聚石塔。我们当时做的时候，相当于在阿里系内部没有任何参考和借鉴的东西，只有一个原始的需求。所以采用小步迭代的开发模式。开始只做 PHP 支持，沿用了装修市场的 PHP 引擎。因为店铺系统本身是 java 写的，装修市场的 php 也只是一些代码片段，所以装修市场没有使用 php 原生执行环境，而是使用 Quercus 引擎在 jvm 之上执行 php 代码。TAE 沿用了这个做法。一方面是便于和现有的 java 系统做交互，另一方面是方便做一些安全控制。

InfoQ：这个引擎是你们自己的吗？

林轩：Quercus 引擎是 Caucho 公司（该公司的另一著名产品是 Resin）一个开源的产品。TAE 在其基础之上做了很多封装和改造。在 JVM 之上用 Java 执行 PHP 有一个很大的好处，就是要比原生的 PHP 要安全很多。因为 PHP 代码和容器本身的代码——Java 代码是位于不同的层次上面。Java 代码作为 PHP 的执行引擎，对 PHP 是透明的，这是一个天然的安全屏障，不需要在系统层面做太多保护。而且项目发起时我们就那么几个，也没有资源去做系统层面的安全。

所以，第一个阶段就是 11 年，11 年主要解决的就是 PHP 的业务需求。到后期我们有 Java 的需求慢慢浮现出来的时候，就开始做 Java 这块系统层面的安全。因为对应 Java 代码托管，系统和容器本身都是 Java 的，这样容器的代码和第三方代码是同质的，它一旦通突破 Java 沙箱之后，就和系统代码具有完全相同的权限了。这个一定要通过系统层面来解决。

一直到 12 年末开始支持 Java 托管的时候，我们才开始深入到系统层面，然后也有其他内核组的专家来支持，后面 Java 才做起来。

InfoQ：TAE 的发展大致分为哪几个阶段？

林轩：大致可以分为这么两个阶段：一个前期的 PHP 容器阶段，后期的 Java 容器的阶段。

伯昊：我从另外一个侧面补充一下，就是从人的层面。这个项目开发发起的一个探索型项目，刚开始有 7、8 个人；后来因为业务方的调整，业务上的出路变得不太明朗了，资源投入相应减小了很多。

林轩：这个跟淘宝的业务有关系。在淘宝内部，很多项目的特点就是一定要有业务场景、有需求才会投资源去做。这个产品是从一个业务线发起，不是从平台部门发起的。如果是平台部门发起，可以先不理它的业务；但是从业务线发起，业务线是要有业务目标的，有业务压力。在业务需求不是很明朗、或者不是很急迫的时候，就没有更多的资源投入进来。

伯昊：从这个角度来讲，第一个阶段差不多是从 11 年初到大概 12 年年中的时候，这个阶段主要是打基础，做了很多重要的事情，包括 PHP 的代码支持引擎。这段时间主要是林轩和另外两个同学在里面。当时因为业务的投入比较少，所以纯粹是靠着技术人员的执着在钻研这些核心的问题，包括路由的问题，安全的问题，PHP 执行的问题，这些东西都是在那段时间搞定的。

然后就进入了第二个阶段，12 年下半年的时候，我们有一个业务终于进来了，是淘宝 UZ，uz.taobao.com，它的业务是把第三方的开发者引入进来，让他们在淘宝提供的环境上开发，提供商品不同的组织形式。就是导购型网站。这个业务进来之后，我们就有更多的人加入。这之后这段时间我们做了很多工作，第一个是产品化，第二个是把我们整个 PaaS 的运维、弹性这套东西给做起来。这是真正能够让 PaaS 运转起来的、底层的基础支撑系统。

整个 12 年下半年，我们花了很多时间把 TAE 从一个我们在实验室里边弄的、技术原型的一个东西，变成一个能够支撑 UZ 业务的一个正规产品。差不多到年底的时候，我们就可以正式支持 UZ 了。

林轩：那个时候就有了相对来说比较一个健全的一个产品化体系，包括外围的支撑，运维、监控、日志等。

伯昊：从第二个阶段回头来看，如果要去建这样一个 PaaS，肯定最开始要面对的问题，首先是你的代码怎么样去执行，你就会需要去解决我们第一个阶段做的一些东西；做完了之后，你会发现，第二阶段如果要把它产品化，也还是有那么多事情做，比如流量来的时候，你的弹性机制怎样能够去应对所有的这些突发的情况，你的监控体系是不是足够健全，让你能够非常早期的就发现一些系统的异常，比如说应用实例的资源的报警，还有系统本身的一些，前端的动态路由匹配性的经常性的检查，包括安全的一些检查，等等。如果你要正式运营，这些都是一定要做上去的。

InfoQ：U 站团队跟你们团队是什么关系？

林轩：一开始 UZ 属于另外一个产品线，后来并入店铺线了。TAE 原始的需求来自店铺，但是因为店铺改造当时还没有完成，一直无法应用于店铺。TAE 的第一个应用反而成了 U 站，后面才慢慢用到店铺的功能模块、功能模板这块。

伯昊：从业务上来讲，对店铺的接入反而是在后边。实际上从第二个阶段开始，我们逐渐发现了自己的一些特色。说实话，在阿里系内部，实际上有一个更有名气的 ACE，就是阿里云的 PaaS 系统。我们实际上比他们做得早，但当时做的时候确实也没考虑到那么多。后来我们发现，我们的定位实际上就是去支持淘宝的开放。

淘宝的开放有个特点：需要受控的开放。这些开放肯定都是插入到淘宝整个体系当中去的，比如说店铺里面有模块，U 站里边有别人写的网站，但是他们都是共同在淘宝或者天猫这样的域名之下。受控的开放有几个点，一个是要保护浏览淘宝网站的用户，保护他们的体验和安全；第二是要保护这些开发者们的数据和安全，不要因为他们经验不够导致他们的数据经常被干掉；第三是要确保淘宝自己系统的安全，不被恶意第三方代码侵害。

林轩：从淘宝开放目前可以说有了 3 种形态。做得最早的是 TOP，只开放接口。后来我们有了聚石塔，把第三方的程序拿到淘宝的机房去运行，提供了一个可靠的 IT 环境。TAE 可以说是第三种，通过开放 PaaS 产品，希望能够把第三方应用程序的生命周期都接管过来。接管过来之后，第一是为他们提供更多的服务，第二个是可以做更多的控制。

所以说到 TAE 分几个阶段，我觉得我们现在属于第三个阶段：这个阶段我们调整了自己的定位，突出我们能够安全和受控接入第三方代码的机制。

林轩：因为淘宝开放是一个大的方向，所以很多业务线、产品线做到后来都会有一个接入第三方的需求。现在在淘宝内部，有接入第三方的需求后，首先想到的是 TAE。在这一年多来，TAE 首要的目标是保护淘宝集团内部和淘宝域名下的安全性，它的安全性要求要比一般的 PaaS 高，因为淘宝是涉及交易的。我们一开始就是冲着第三方代码不能影响淘宝主站的核心系统这个目标来设计的，所以我们对前后端安全和数据安全都有规划，也做了一定的沉淀。所以，现在淘系下面的子业务有第三方代码、第三方开发者接入的需求，很多都会找上门来的。

伯昊：目前我们有一些需求是来自无线端的，比如说天猫，一淘，他们都有无线的主客户端，主客户端里边希望第三方创建一些内容，甚至代码片段和一些逻辑。这也是一个方向，我们可能也会去支撑无线端的后端 hosting。

再好比交易这块，他们也想做一些事情，比如在交易里边，我直接填一个车牌号，系统就直接到第三方写的程序里、直接到公安部的系统里边去查，如果查到你有违规，商家就直接帮你把罚金交掉。包括更准确的算物流，卖家可以自己去写代码片段。

简单来说，交易现在遇到一个问题，就是它要支持的交易类型非常丰富，可能要和很多外部的系统进行连接，比如刚才说的公安部的系统，但是它不想把这东西做到自己的系统里面，而且它自己都不想写这个代码，希望第三方来做这个事情。但是他在做的时候，因为交易系统这么核心的一个系统，它一定会遇到开放和安全之间的一个权衡和拿捏。这块正好是我们之前纠结的最多的问题。不知不觉的，我们发现我们在淘宝内部，已经算是这方面经验最丰富的团队了。

我们还有一个可能的业务方向是聚石塔。它以前更多的是做主机的托管和售卖，可能卖虚拟机，卖 MySQL 的服务，而未来它也需要一个 PaaS 的方案，让它能够去做更多，包括刚才我说的那三个受控。所以我们这边也在跟聚石塔谈一些合作，包括跟 ACE 在谈合作。和 ACE 团队一起为聚石塔提供一个受控开放的 PaaS 环境，聚石塔这个 AE 产品估计在年底就能够和大家见面了。

所以，TAE 现在是属于第三阶段。第一阶段是实验室，通过一些非常重要的实验对重要基础点进行验证和突破；第二阶段是产品化。第三阶段，应该说是发展期。

InfoQ：这样听起来，好像跟淘宝开放平台的定位有重合？

林轩：TOP 只提供 API，他不关心第三方的代码写在哪里，跑在哪里。聚石塔是关心他跑在哪里，但是不关心他怎么写。我们是重点关心他代码怎么写的。

伯昊：所以我们跟 TOP 是正交的。TOP 提供了一个接口，一个调用的设施。在 TAE 里边我们也是一定要开放 TOP 的。你可以说，我们是淘宝的开放体系的一块砖头。

InfoQ：所以总体来说，TAE 是给哪些人用的？

林轩：就现在最新的这个阶段，应该是分两方面：一方面是淘系内部，一方面是聚石塔的用户，即非淘系下面的第三方应用。这两部分安全性的要求是不一样的，淘系方面安全性要求更高，聚石塔相对来说没有那么高，因为他本身就是在一个完全隔离的环境中。

伯昊：我觉得你刚才说的那两个应该都算是淘系的第三方开放的一部分。我的看法是这样：如果是分为淘宝的小二和第三方开发者，那 TAE 的用户至少会分为这两种；对于淘宝内部的技术小二和业务小二来说，TAE 给他们提供的是一个受控的第三方开放的方案，如果他的业务想要去引入第三方来为他的这个体系增加活力，同时又要考虑他整个的安全性，那么他就可以去考虑使用我们了。这是对内部。

对外部来说，这些业务小二所开放出来的业务是谁来使用呢？就是那些第三方的开发者，就是刚才林轩说的这两部分。有一部分的安全级别要求是很高的，即顶着淘宝天猫的域名的这种应用的开发者。对他们来说，可能会感到很辛酸。为什么？因为我们安全上实在控制的太严了，所以他们用起来会真的很不爽。

比如说 JS，你是不能用 jQuery 的，你只能用我们的 Kissy。因为，你的 JS 写出来之后，我们会全部用 Caja 这个解释容器再把它编译一遍。所以，你写的 JS 和执行的 JS 完全是两码事，重新编译过的 JS，估计你在浏览器里去看，你自己都看不懂。

JS 的限制太多是目前开发者抱怨的焦点，目前我们也在尝试另外的办法，提升易用性。希望我们以后能够尽量不用 JS 白名单这样的方式去限制 JS 使用。目前这些探索还处于实验室阶段，希望尽快能够和各位开发者见面。

目前，TAE 的用户主要还是 PHP，因为相关的业务用 PHP 写比较方便。现在我们 Java 也处于试用阶段。

InfoQ：现在外部用 Java 的还不太多？

伯昊：你我们目前的业务，无论是店铺的装修，还是 UZ 这些，都是偏展示型的。他有简单的逻辑，用 PHP 写是最合适不过的。

支持 Java，是我们想去支持像聚石塔这样后端的业务，可能有 CRM、进销存这样的业务，这种业务更多是用 Java 来写的。支持 Java 运行环境，把我们的触角伸到偏向后台的应用，是我们接下来的工作重点。

InfoQ：作为 PaaS，TAE 现在提供的服务都有些什么？

伯昊：PaaS 类型的基础服务都有的，像 fetchurl，定时程序，数据库，文件，缓存这些都有。正常的 Web 应用程序想用的东西基本上都有。在这个基础之外，我们还提供一些偏淘宝业务的一些独特的特性，比如说 Session。

林轩：比如你是一个 UZ 的第三方开发者，你会通过程序里面获得一个用户的标识。这个标识当然和我们淘宝内部用的标识不一样，但是有了这个标识，你就能识别出一个用户，知道当前用户是哪个人，他下次来访问的时候知道他上次做了什么事情。你通过这个可以做很多个性化的功能。

伯昊：我们和业务靠得很近，他们在业务上需要用到什么东西的时候，我们就会研究一下，给他注入到他的执行环境里边，他就可以自己去用了。

林轩：其实每一条业务线都有很多内部的服务，他们接入第三方开发者的时候，会统计第三方开发者需要调用哪些内部服务作为接口。我们现在可以很方便的通过动态配置的方式直接注入到他的应用执行环境里面，他就可以直接用了。

InfoQ：TAE 的安全设计能详细介绍一下么？

伯昊：我们安全体系是分层的：网络层，系统层，JVM 层——即容器层，然后是应用层。大概是这么四层。

我们所关心的领域，我刚才说了，第一个是淘宝网络环境的安全，我们不希望恶意的第三方开发者通过突破沙箱的方式，突破到淘宝托管环境里边来干一些事情。第二个是 ISV 自身的安全，我们不希望某一些恶意的攻击者，或者恶意的 ISV，通过一些方式拿到别的 ISV 的代码、数据，甚至于有些 ISV 的安全意识比较弱，下意识的写出很多有漏洞的代码，比如 SQL 注入什么的，这个是我们不希望看到的。第三个是淘宝的数据安全，就是 TOP 有些重要的接口暴露出去的数据，其实淘宝是希望控制的，我们希望大家通过贡献自己的程序为淘宝的整个体系注入活力，提升整个淘宝体系的用户黏性，在这个基础之上，ISV 得到他自己的利益；但是我们不希望这个过程当中有很多淘宝重要的数据泄露到外边去。数据对我们来说是非常重要的。

网络层，我们主要照顾的是淘宝自身网络环境的安全。中间的容器层可以做很多事情：容器层以下的系统层和网络层往往都是在 JVM 层被突破的。这一层主要是防范恶意代码。

林轩：常规防护都是在容器层做的。再上面是前端安全。ISV 产生的页面在某些业务场景下会嵌入到一个店铺页面里面，或者嵌入到淘宝子域名下面的某一个页面里面去，如果不做控制，它可能会改变一些父页面的元素，最典型就是装修污染。比如说有的店铺装修引入一个第三方模块，第三方模块有一些恶意的脚本或者 CSS，可以去修改店铺的信誉评价，或者类似这种会影响用户行为的内容，这是一种欺骗。我们会有一个沙箱防止这个事情，就是刚才说到的 Caja。

常规的安全主要是这两方面，一个容器，一个前端，也包括 JS，CSS。

伯昊：容器和前端这块，我们主要是在解决刚才说的 ISV 自身的安全。数据安全这方面，整个体系都会照顾。

容器层的安全，我觉得比较常规，就是 JVM 的安全。系统这层，我们有一个基本的假设：攻击者即便突破了我们的沙箱，他进来以后，我们也希望攻击者什么事情都做不了。就是他可能很幸运的在我们机器上看看有什么文件，甚至他可以看到我们的容器代码，但是其他的什么事都干不了。

假设你拿到了本地的脚本执行权限，你可以 ls，你能看到你的容器代码，但是容器代码我们很好的 Review 过了，我们觉得没有什么不能给你看的。这块是跟 GAE 学的，即使沙箱被突破了，也干不了什么事情。这是我们在系统层以及网络层的一个设计目标。

InfoQ：TAE 的技术组成这块，还有哪些值得介绍的么？

伯昊：可以罗列一下。我们现在虚拟化方案已经做成可插拔了，我们可以换虚拟化方案的。当前是 T4，就是淘宝内部私有云的解决方案，我们现在也在做基于阿里云的方案。

林轩：容器也可以说一下。PHP 容器里做了一些防范，比如说他不断的写一些代码去耗费内存，像死循环，一次返回过多记录，这些都有防范。

伯昊：不过，我觉得如果在虚拟化层做更彻底的隔离，就没有必要去做这样的防范。

林轩：我们目前的 PHP 容器是没有做彻底隔离的，我们的一个 VM 可以有多个 PHP 应用，多个 ISV 代码，所以需要做这个事情。虚拟化不仅解决机器调用、资源分配的问题，也解决了安全隔离问题，跟安全也有关系——安全跟哪个方面都有关系。然后还有各个应用耗费系统资源的监控等等。

伯昊：监控运维日志是蛮有趣的一块，因为日志的量是很大的，你整个集群拖过来多少应用，上面承载了多大的访问量，就意味着下边会产生大量的日志。这些日志对于开发者来说是至关重要的。作为一个 PaaS 环境，他要看到日志，就必须通过我们给他提供的界面去看日志，那么我们就得把他的日志很好的组织、存储、展现，并提供搜索。

林轩：这个我们用了淘宝现有的一些大数据的技术。

伯昊：用了 HBase。也用了 Storm，主要是做业务的处理和日志的结构化，然后把它扔到 HBase，在上面做一些离线处理，比如搜索的全量索引等。另外我们的日志系统这块，你可以把它看成一个管道，你在里边也可以产生很多监控报表. 就是说，你可以把很多监控的数据写在日志里边，特别是系统的一些东西，然后我们去通过后边这样的一些系统来分析，比如说每个应用的 PV、UV，甚至于一些业务数据，都可以在这样一个日志系统里边去采集、统计、分析。

InfoQ：你们团队自己也负责这块的运维么？

林轩：目前运维还是我们自己在做，以后希望把它移交给运维部门的同学。

伯昊：刚说到第一阶段和第二个阶段里，我们团队没有 PD，甚至也没有专职的 PE。大部分都是我们自己在搞。第三阶段，我们是准备把这些东西移交给更专业的团队来做。

InfoQ：PaaS 的前提就是底层的资源隔离。资源隔离这方面，能否再具体说一些？

伯昊：我们现在的方案主要还是基于 Linux container，就是 T4 用的隔离机制。阿里云下面用的是 Xen，但我们最终去在上面用的时候，还是会用 Linux container 做隔离。因为 Xen 的问题在于，一个物理机不能虚很多 VM 出来，好像也就 30 多个的量级，这个数目在往上走 overhead 会变得很大。那么，我们在这个之上再去用 Linux container 隔离一下，就可以隔的更细。比如一般的应用，我们给他分 0.25 个 CPU，甚至更低，这样刚才我们说到的 PHP 死循环这种问题，就没有必要在容器层面去防范，而是在下边隔离资源就直接搞定。我每一个隔离出来的资源单元，里面只放一个应用实例就可以了。

InfoQ：现在是用 LXC 那套方案吗？还是有自己做一些改动？

伯昊：做了一些改动，但是不能直接说有哪些改动，因为这些改动涉及到安全。安全就是，说得越多越不安全了。

InfoQ：好的。最后想问问，TAE 开发过程中遇到过什么难点？不一定是技术方面的，也可以包括一些业务调度方面的。

林轩：安全肯定是最难的。业务上线推广的一个瓶颈就是 JS 安全，后来通过引入 Caja 来解决的。在这之前，店铺装修污染的问题已经存在了一两年了。

伯昊：最近都还一直在奋斗。

林轩：因为控制了 JS，但 CSS 也非常灵活，通过 CSS 他也可以进行店铺装修污染。比如他拿个图片，显示自己卖出去了一万件，实际他就卖出去五件。这个问题看起来好像不是一个很要紧的问题，但实际上真的它就能阻碍你的发展。

伯昊：这个实际上是业务层面的应用安全，你如果不搞定，业务就跑不起来；只有把这个解决了之后，你才有机会能够担心你的业务系统安全问题。

还有一个点就是 PHP 的执行引擎，当时还是花了很多精力的。因为我们用的开源的 Quercus 执行引擎，它有两个版本，一个是 Pro 版，一个是开源版。开源版首先很多 Bug，然后性能比较差。

林轩：因为它虽然很多地方用，但是应用规模没有淘宝这么大。我们修了很多 Bug，修的过程中又发现各种各样的问题，这个过程中我们发觉淘宝是第一个大规模商用 Quercus 的。

伯昊：听说 Quercus 好像是一个写 C 的开发者，用 Java 写了一个库，很多地方都用得很不地道，这导致很多性能问题。我们这方面的经验积累了很多，改了很多代码。我们现在正准备把所有改的这些 Bug 和改进给整理一下，放出来。

林轩：最近正在做这个事情，就是在最新版上把之前的所有 bugfix 再应用一遍，再整理一下，提交给 Resin 公司。

伯昊：不过，像有些性能上的东西就没办法提交给他，那些可能在他的 Pro 版本里面。

林轩：Pro 版还是不一样的，他只是解决了执行抽象语法树到执行 Java 类的一个优化，把执行语法树编译成 Java 类，然后动态去执行。这样的性能提升会有，但是从其他方面来看，包括字符的处理，它的 Pro 版和开源版有一样的问题。这块改造也比较大，我们可能也会提给他，但是他接不接受是个问题了。

伯昊：他说不接受，我们也可以把这个东西开源出来。因为 Quercus 作为一个 Java 的 PHP 执行引擎，它主要就两部分：一部分是做语法解析，解析成抽象的语法树；另一部分就是执行，通过 Java 代码执行语法树。主要就这两个部分。

其实前边一部分，业界有比较标准的参考。因为前边抽象语法树、解析这个事情完全是标准的，其实可以把第二部分的改动拆出来，发布为一个开源的项目。

非技术上的难点，就是在推广。

林轩：从业务线做平台性的产品，有优势也有劣势。优势是，做出来如果有合适的业务产品马上可以落地，推广，快速成熟, 成长会很快。但是劣势也是这个：如果没有业务，就没有资源投入。

伯昊：没有资源投入，就很难进行快速的技术积累。这个是比较矛盾的，有时候就是鸡生蛋，蛋生鸡的问题，这个很痛苦。所以，就看你能不能坚持了。