heiyeluren的blog（黑夜路人的开源世界）

[转][转]异步编程与响应式框架

heiyeshuwu — Mon, 21 May 2012 23:47:02 +0800

作者：老赵

来源：http://blog.zhaojie.me/2010/09/async-programming-and-reactive-framework.html

前言

异步操作是强大的，它是许多高伸缩性架构的基石。异步操作在许多情况下是必须的，例如在客户端保持用户界面的响应能力，以及在日益兴起的云计算场景中。但是，异步编程又是十分困难的，它让这让许多程序员敬而远之。因此，越来越多的编程语言都对异步编程提供了相当程度的支持，其中的典型代表便是F#中的异步工作流以及Scala的Actor模型。不过目前的一些主流编程语言，如C#或是JavaScript，它们在设计之时并没有在异步编程上考虑太多，我们便会根据它们的语言特性，提供合适的异步编程模型及其实现。而本文介绍的便是其中一例：响应式编程（Reactive Programming）模型及响应式框架（Reactive Framework，简称Rx）。

异步编程的难点

异步编程之所以困难，主要有三大难点。

首先是对于状态的维护。在普通编程中，我们已经习惯了根据各种状态采取不同做法的编程方式。在异步编程中，状态对于操作的影响则往往更为复杂。例如，我们在编写一个鼠标“拖动及绘图”的行为时，一般会采用这样的逻辑：

在MouseDown事件中将isDragging标记设为true，表示“拖动开始”，并记录当前鼠标位置prevPos。
在MouseUp事件中将isDragging标记设为false，表示“拖动结束”。
在MouseMove事件中检查isDragging标记，如果为true，根据鼠标当前位置currPos和之前记录的prevPos进行绘图，并将currPos的值写入prevPos。

仅在这样一个最基本的场景中，我们便需要编写三个事件处理器（Event Handler），控制isDragging，prevPos等外部状态，并根据这些状态决定事件触发时的效果。这样的例子数不胜数，尤其是在各式拖放操作中，几乎都会涉及大量状态的控制（例如，判断物体是否进入某个特定区域）。

异步编程的另一个难点，在于异步操作之间的组合及交互。例如在如上的简单拖放操作中，我们便涉及到了MouseDown，MouseUp及MouseMove三个事件。从某些角度来说，客户端的UI事件还是比较容易处理的，因为它们往往都是在单一线程上依次执行。但是在另外一些场景中，如云计算时，我们往往会同时发起多个异步操作，并根据这些操作的结果进行后续处理，甚至还会有一个额外的超时监控，这样便很有可能会出现并发操作的竞争（Race）情况，这将会成为程序复杂度的灾难。

此外，异步操作还会破坏“代码局部性（Code Locality）”，这可能也是异步操作中最为常见的阻碍。程序员早已习惯了“线性”地表达逻辑，但即便是多个顺序执行的异步操作，也会因为大量的回调函数而将算法拆得支离破碎，更何况还会出现各种循环及条件判断。同时，在线性的代码中，我们可以使用“局部变量”保存状态，而在编写异步代码时则需要手动地在多个函数中传递状态。此外，由于逻辑被拆分至多个方法，因此我们也无法使用传统的try/catch进行统一异常处理。

推模型与拉模型

平时我们使用最多的便是“交互式（Interactive）”的编程方式，采用的是组件之间的相互调用来表现逻辑。例如，对象A向对象B请求数据并等待返回，待对象B完成并返还数据之后A才继续进行后面的操作。交互式编程的一个典型应用便是GoF23中的迭代器（Iterator）模式，它在.NET中的实现为IEnumerable及IEnumerator接口，例如：

void Traverse(IEnumerable<int> source)
{
    var etor = source.GetEnumerator();
    while (etor.MoveNext())
    {
        Console.WriteLine(etor.Current);
    }
}

为了更好地说明问题，这里我们将标准的foreach操作展开为传统的迭代器使用形式，并省略了using语句。在使用时，我们先调用一个IEnumerable对象的GetEnumerator方法，获得一个迭代器，再根据MoveNext及Current进行遍历。在调用MoveNext时，迭代器会去“准备”下一个元素，并根据存在与否返回true或者false。试想，如果其中某个MoveNext的“准备”工作涉及到一个耗时较长的操作，则迭代器的使用者也必须眼巴巴地等待其返回。

这是一种“拉（Pull）”模型，数据由消费者（Consumer）从生产者（Producer）那里主动“拉”来。这是一种同步的交互方式，数据消费者会依赖于数据生产者的表现。这就好比我们去食堂吃饭时必须主动去取餐，此时则必须从队伍的最后排起，我们什么时候能结束等待并进行下一步操作（即“吃饭”），则要看食堂的生产速度如何。很显然，有些时候这种交互方式是不可接受的，例如我们在实现一个搜索引擎的“关键字提示”功能时，不可能让用户在输入一个字符后，必须等待远程的提示请求返回才能继续输入下一个字符。

而与交互式编程对应的便是“响应式（Reactive）”编程。响应式编程是一种基于“改变”的编程方式。例如在交互式编程中，A = B + C这样的表达式意味着将B与C之和赋给A，而此后B与C的改变都与A无关。而在响应式编程中，A会去“响应”B或C的变化，即一旦B或C改变之后，A的值也会随之变化。响应式编程的一个典型应用便是GoF23中的观察者（Observer）模式。与迭代器的IEnumerable/IEnumerator不同，在之前的.NET框架中并没有对这样一种编程模型指定“标准化（Formallized）”接口，不过在.NET 4.0的基础类库中增加了IObservable及IObserver接口，签名如下：

public interface IObservable<out T>
{
    IDisposable Subscribe(IObserver<T> observer);
}

public interface IObserver<in T>
{
    void OnCompleted();
    void OnError(Exception error);
    void OnNext(T value);
}

如果我们仔细比较“迭代器”与“观察者”的标准化接口，则会发现它们是完全“对偶（dual）”的：

IEnumerable.GetEnumerator方法“输出”一个IEnumerater对象；IObservable.Subscribe方法“输入”一个IObserver对象。
在遍历元素用尽时，IEnumerator.MoveNext方法返回false；在响应内容用尽时，IObserver.OnCompleted方法被调用。
在有新元素需要遍历时，IEnumerator.MoveNext方法返回true，并通过Current属性“输出”；在有新元素需要响应时，IObserver.OnNext方法被调用，并通过参数“输入”。
在出现错误时，IEnumerator.MoveNext方法会“抛出”一个异常；在出现错误时，IObserver.OnError方法会被调用，并通过参数“接受”异常信息。

至于IObservable.Subscribe方法返回的IDisposable对象，则用于“退定”操作，即让输入的IObserver对象再也不需要继续响应IObservable对象的新元素了。

从比较中可以看出，如果说IEnumerator对象是由数据消费者使用的话，那么IObserver对象则是由数据的生产者，即IObservable对象使用的。换句话说，数据是由数据的生产者“推”给数据消费者的，是一种“推（Push）”模型。在这种异步的交互方式中，数据消费者不必依赖于数据生产者的表现。这就好比我们去饭店吃饭，点菜后便可坐下和同伴聊聊天或是用手机上上网，而作为菜品的生产者，饭店，则会在产出之后主动端上桌来。这么做无疑解放了数据的消费者，例如用户可以在文本框里不断地输入字符，而只需等远程服务器将提示结果“推”给客户端后再显示即可。

许多模型都可以统一至标准的生产者接口IObservable上，如MouseMove事件便可以认做是“永不停止的MouseEventArgs对象的生产者”。而另一方面，单个异步操作则可以被视为“只产出单个数据便结束的生产者”。

LINQ to Observable

在许多人眼中，C# 3.0中新增的LINQ特性只是一种用于操作数据的DSL，它的主要作用也仅仅是针对IEnumerable或是IQueryable的数据操作。事实上，LINQ本身的能力远不止此。LINQ是一种非常简单的语言特性，编译器只是将LINQ查询语句转化为“字面等价”的“LINQ标准方法”调用（如Where，Select等等）和“和Lambda表达式”参数（如x => x > 0）而已。但是这里的关键便是“字面等价”四个字，LINQ本身并不规定“LINQ标准方法”是对象的实例方法还是扩展方法，“Lambda表达式”是构造出一个匿名函数还是表达式树，这一切都是由利用LINQ的类库来决定的。因此，微软能够基于LINQ实现了PLINQ这样的并行类库。直到最近的访谈中，LINQ的设计者Erik Meijer依旧认为LINQ还是被低估了，他们自己也还在继续挖掘LINQ的更多能力。

虽然LINQ本身在语法上只是一些方法调用，但是它在语义上是针对数据流的一系列操作，因此LINQ to Object，LINQ to SQL以及PLINQ可以认为是最自然，最符合LINQ语义的应用。如今，微软的“云编程能力团队（Cloud Programmability Team）”在其“响应式框架（Reactive Framework，简称Rx）”提供了LINQ to Observable，这又是另一个LINQ的经典使用案例。IObservable本身可以被认为是一股“推送数据”的数据流，因此也可以对其进行“过滤”或是“投影”等操作，这便是LINQ的应用场景，LINQ to Observable是对IObservable接口实现的一系列LINQ标准方法。因此，我们可以认为，LINQ to Observable是一套与LINQ to Object对偶的类库，事实上在响应式框架中，还有一套与LINQ to Queryable对偶的LINQ to Qbservable，请注意第一个字母是Q，我们可以把它看作是LINQ to Observable的“远程查询”版本。

利用LINQ to Object可以编写出声明式（表示“做什么”）的代码，其可读性往往远高于等价的命令式（表示“怎么做”）代码。LINQ to Observable也有类似的效果。假设现在有一个需求：利用ADWS键控制小球的位置。传统的写法可能是这样的：

void OnKeyPress(object sender, KeyPressEventArgs e)
{
    // 如果游戏已经开始
    if (isPlaying) 
    {
        // 向左且小球没有超出边界
        if (e.KeyChar == 'a' && ball.Left > 0)
        {
            ball.Left -= 5;
        }
        // 向上且小球没有超出边界
        else if (e.KeyChar == 'w' && ball.Top > 0)
        {
            ball.Top -= 5;
        }
        else ... 
    }
    else ...
}

由于KeyPress事件总是不断触发，因此我们只能它的事件处理器中进行判断各种状态，采取不同措施。而如果我们利用LINQ to Observable，则几乎是另外一种思维方式：

// 过滤出isPlaying时的keyPress事件
var keyPress = GetKeyPress().Where(_ => isPlaying);

// 过滤出向左移动的事件
var moveLeft = from ev in keyPress
               where ev.EventArgs.KeyChar == 'a'
               where ball.Left > 0
               select ev;
moveLeft.Subscribe(_ => ball.Left -= 5);

// 过滤出向上移动的事件
var moveTop = from ev in keyPress
              where ev.EventArgs.KeyChar == 'w'
              where ball.Top > 0
              select ev;
moveTop.Subscribe(_ => ball.Top -= 5);

我们可以将“KeyPress事件”视为“推送KeyPressEventArgs对象”这一数据流的数据源（由GetKeyPress方法返回），那么如今的代码便是使用LINQ过滤出“需要”的数据，并针对真正需要的那部分进行响应。这么做，便将“条件”与“操作”解耦，显著增强了代码的语义表达能力。事实上，只要补充一些辅助方法，可以利用LINQ表示更为完整复杂的逻辑。例如，微软咨询师Matthew Podwysocki便在博客中展示过一段代码，基于LINQ to Observable实现了创建一个WebRequest对象，设置属性，异步发送及下载数据的一系列操作。

响应式框架的JavaScript版本

响应式编程的重要使用场景之一便是与用户交互的GUI界面。例如，Silverlight禁止任何阻塞的IO操作，换言之Silverlight中的所有网络操作都是异步的，微软也正是出于简化异步开发的目的才设计了响应式框架（事实上响应式框架已经集成到Silverlight Toolkit中）。不过与Silverlight相比，基于浏览器的原生JavaScript应用程序无疑使用地更为广泛。对于这样的应用程序来说，动画是异步的，AJAX请求也是异步的，我们几乎可以断言，如果有一套面向JavaScirpt应用程序的响应式框架，一定会比面向Silverlight的框架更有意义得多。

微软也想到了这一点。之前我们讨论的“响应式框架”，其实只是响应式编程模型的一种实现。更确切地说，我们只是讨论了这套框架的.NET版本，微软还提供了JavaScript版本的响应式框架。JavaScript版本的API与.NET版本几乎完全一致，例如我们之前讨论的拖放操作，使用JavaScript即可写作：

var target = $("#dragTarget");
var mouseMove = target.toObservable("mousemove");
var mouseDiff = mouseMove.Zip(mouseMove.Skip(1), 
    function(prev, curr) {
        return {
            PrevPos: { x: prev.clientX, y: prev.clientY },
            CurrPos: { x: curr.clientX, y: curr.clientY }
        };
    });

var mouseDown = target.toObservable("mousedown");
var mouseUp = target.toObservable("mouseup");
var mouseDrag = mouseDown.SelectMany(function() {
    mouseDiff.TakeUntil(mouseUp);
});

mouseDrag.Subscribe(...);

由于没有C#中的LINQ查询语言，我们只能直接使用展开后的方法，如SelectMany来编写逻辑。JavaScript版本的响应式框架还提供了一系列的“胶合”层，能够与jQuery，Dojo，MooTools，Prototype等流行框架同时使用。例如，上一段代码中的toObservable便是在jQuery根对象上扩展的方法。

总结

异步编程在用户交互式界面及一些云计算场景中尤其重要。微软的云编程能力团队针对.NET平台和JavaScirpt分别提供了一套响应式框架，希望以此简化异步程序的开发。不过，这套响应式框架所表现出的理念是通用的。而且，事实上只要是拥有匿名函数及闭包的语言，例如Scala，Python，Ruby等等，实现这样一套框架其实都不是十分困难的事情。

作者：heiyeshuwu 发表于2012-5-21 23:47:02 原文链接

阅读：92 评论：1 查看评论

[转][转] 淘宝技术发展

heiyeshuwu — Thu, 10 May 2012 16:36:26 +0800

作者: 赵超

来源：http://blog.sina.com.cn/s/blog_633219970100x9cc.html

　　一、引言

　　二、个人网站

　　三、Oracle/支付宝/旺旺

　　四、淘宝技术发展（Java时代：脱胎换骨）

　　五、淘宝技术发展（Java时代：坚若磐石）

　　六、淘宝技术发展（Java时代：创造技术-TFS）

　　作者：赵超

　　一、引言

　　光棍节的狂欢

　　“时间到，开抢！”坐在电脑前早已等待多时的小美一看时间已到2011年11月11日零时，便迫不及待地投身于淘宝商城一年一度的大型网购促销活动——“淘宝双11购物狂欢节”。小美打开早已收藏好的宝贝——某品牌的雪地靴，飞快的点击购买，付款，一回头发现3000双靴子已被抢购一空。

　　小美跳起来，大叫一声“欧耶！”

　　小美不知道，就在11日零点过后的这一分钟内，全国有342万人和她一起涌入淘宝商城。当然，她更不知道，此时此刻，在淘宝杭州的一间办公室里，灯火通明，这里是“战时指挥部”，淘宝技术部的一群工程师，正在紧盯着网站的流量和交易数据。白板上是他们刚刚下的注，赌谁能最准确地猜中流量峰值和全天的交易总额。他们的手边放着充足的食物和各类提神的饮料。

　　一阵急促的电话声响起来，是前线部门询问数据的，工程师大声报着：“第1分钟，进入淘宝商城的会员有342万”。过一会工程师主动拿起电话：“交易额超过1亿了，现在是第8分钟。”接下来，“第21分钟，刚突破2亿”。“第32分钟，3亿了”。“第1个小时，4.39亿”。这些数据随后出现在微博上，引起一片惊呼。

　　“完蛋了！”突然有人大喝一声，所有的眼睛都紧张的盯着他，只见他挠挠头，嘿嘿的笑道“我赌的少了，20亿轻松就能过了，我再加5亿”，他跑去白板边上把自己的赌注擦去，写上25，接下来有人写上28，有人写上30，有人跑到微博上开下盘口，同事们纷纷转载下注。接下来的这24个小时，战时指挥部的工程师们都不能休息，他们盯着网站的各种监控指标，适时的调整机器和增减功能。顶住第一波高峰之后，这些人开始忙里偷闲的给自己买东西，大家互相交流着哪家买的移动硬盘靠谱，哪家衣服适合自己的女朋友，不时的有人哀嚎宝贝被人抢了、信用卡额度不够了。同时，旁边白板上的赌注越下越大。

　　11月11日，这个棍子最多的日子被网民自我调侃的变成了一个节日——“光棍节”。而淘宝网又用疯狂的折扣促销给它赋予了另外一个意义——“购物狂欢节”。2011年11月11日这一天，淘宝商城与淘宝网交易额之和突破52亿，这个数字是“购物天堂”香港一天零售总额8.5亿的6倍。

　　网民感受到的是疯抢的喜悦，而网站的技术人员感受到的却是“压力山大”。就如同你家办酒席，宴请左邻右舍，这个办起来容易。倘若宴请十里八乡所有的人，吃饭的人自然开心，但却不是一般人家能够办得起来的。能办得起来如此盛宴者，需要强大的财力物力、组织能力、技术实力（例如做这么多菜，你的炒锅一定要是“分布式的”、“可复制的”、“可扩展的”，洗菜切菜要有“工作流引擎”，上菜的路径要用图论来计算出来，甚至连厨房的下水道都要重新设计）。

　　淘宝能够举办如此盛宴，网站的技术实力可见一斑。淘宝网拥有全国最大的Hadoop分布式计算集群之一，日新增数据50TB，有40PB海量数据存储。分布在全国各地80多个节点的CDN网络，支持的流量超过800Gbps。淘宝的搜索引擎能够对数十亿的商品数据进行实时搜索，另外还拥有自主研发的文件存储系统和缓存系统，以及Java中间件和消息中间件系统，这一切组成了一个庞大的电子商务操作系统。另外从商业数据上来看，Amazon的财报显示2011年完成了大约480亿美金的交易额，eBay 2011年财报全年完成了大约600亿美金的交易额（不包括其独立的汽车交易平台）。不管从交易额、商品数量、同比增速等指标上看，淘宝网均远超于此，是目前全球最大的电子商务平台。（由于淘宝非上市公司，未公布2011年业绩，以上内容来自淘宝网技术副总裁@_行癫的微博）

　　以上这些技术数据可能已经让一些同学产生不适的感觉，为了让更多的人读懂这本书，我们从技术的角度来看，小美访问淘宝网的时候，网站上发生了什么事情。参考资料：《技术普及帖：你刚才在淘宝上买了一件东西》，来自南京邮电大学孙放同学。

　　为了有个更直观的对比，我们说一个同行，他在2011年光棍节之前做促销，流量上去之后，达到12Gbps（他们有这么大的流量，老板很高兴，在微博上面说了这个数据），这时候流量达到了极限，网站几乎挂掉，用户无法下订单。而淘宝网光棍节当天网络的流量最高达到800多Gbps，带给各家银行和快递公司的流量也让他们压力山大，如临大敌（后来，他们以能够撑住淘宝带来的流量为荣而到处宣传）。另外如果你在网上购买过火车票的话，更能体会到网站能支持多大的流量有多重要。但这不是一朝一夕做出来的，也不是有钱就能办到的。

　　以上对比的这些网站，也许读者很容易就猜到是哪一家，这里拿出来作对比，绝对没有嘲笑人家的意思，采用通常的网站技术方案，能做到这种程度已经不错了。任何网站的发展都不是一蹴而就的，在什么样的阶段采用什么样的技术。在发展的过程中网站会遇到各种各样的问题和业务带来的压力，正是这些原因才推动着技术的进步和发展，而技术的发展又会反过来促进业务的更大提升。二者互为因果，相互促进。如今淘宝网的流量已经是全球排名第12、国内排名第3（美国的eBay全球排名23，国内前两名是百度和腾讯）。淘宝网的系统也从使用一台服务器，到采用万台以上的服务器。本书就为大家描述淘宝网在整个发展过程中，所有的主动和被动的技术变革的前因后果，这由很多有趣的故事组成。

　　正如同很多人或组织成功了以后，就会为自己的出身编造一个美丽的传说。淘宝网的出身，网上也有非常多的传说，下面我们就从它的出生开始讲起。

　　二、个人网站

　　2003年4月7日，马云，在杭州，成立了一个神秘的组织。他叫来十位员工，要他们签了一份协议，这份协议要求他们立刻离开阿里巴巴，去做一个神秘的项目。这个项目要求绝对保密，老马戏称“连说梦话被老婆听到都不行，谁要是透漏出去，我将追杀到天涯海角”。这份协议是英文版的，匆忙之间，大多数人根本来不及看懂，但出于对老马的信任，都卷起铺盖离开了阿里巴巴。

　　他们去了一个神秘的据点——湖畔花园小区的一套未装修的房子里，房子的主人是马云。这伙人刚进去的时候，马云给他们布置了一个任务，就是在最短的时间内做出一个个人对个人（C2C）的商品交易的网站。现在出一个问题考考读者，看你适不适合做淘宝的创业团队。亲，要是让你来做，你怎么做？

　　在说出这个答案之前，容我先卖个关子，介绍一下这个创业团队的成员：三个开发工程师（虚竹、三丰、多隆）、一个UED（二当家）、三个运营（小宝、阿珂、破天）、一个经理（财神）、还有就是马云和他的秘书。当时对整个项目组来说压力最大的就是时间，怎么在最短的时间内把一个从来就没有的网站从零开始建立起来？了解淘宝历史的人知道淘宝是在2003年5月10日上线的，这之间只有一个月。要是你在这个团队里，你怎么做？我们的答案就是：买一个来。

　　买一个网站显然比做一个网站要省事一些，但是他们的梦想可不是做一个小网站而已，要做大，就不是随便买个就行的，要有比较低的维护成本，要能够方便的扩展和二次开发。那接下来就是第二个问题：买一个什么样的网站？答案是：轻量一点的，简单一点的，于是买了这样一个架构的网站：LAMP(Linux+Apache+MySQL+PHP)。这个直到现在还是一个很常用的网站架构模型。这种架构的优点是：无需编译，发布快速，PHP功能强大，能做从页面渲染到数据访问所有的事情，而且用到的技术都是开源的，免费。

　　当时我们是从一个美国人那里买来的一个网站系统，这个系统的名字叫做PHPAuction（他们的官方网站 http://www.phpauction.net，这个名字很直白，一眼就看出来这个系统是用什么语言做的、是干什么用的），PHPAuction有好几个版本，我们买的是最高版的，功能比较多，而且最重要的是对方提供了源代码。最高版比较贵，花了我们2000美金（貌似现在降价了，只要946美元）。买来之后不是直接就能用的，需要很多本地化的修改，例如页面模板改的漂亮一点，页头页脚加上自己的站点简介等，其中最有技术含量的是对数据库进行了一个修改。原来是从一个数据库进行所有的读写操作，拿过来之后多隆把它给拆分成一个主库、两个从库，读写分离。这么做的好处有几点：存储容量增加了，有了备份，使得安全性增加了，读写分离使得读写效率提升了。这样整个系统的架构就如下图所示：

　　其中Pear DB是一个PHP模块，负责数据访问层。另外也用开源的论坛系统PHPBB（http://www.phpbbchina.com ）搭建了一个小的论坛社区，虚竹负责机器采购、配置、架设等，三丰和多隆负责编码，他们把交易系统和论坛系统的用户信息打通，给运营人员开发出后台管理（admin系统）的功能，把交易类型从只有拍卖这一种增加为拍卖、一口价、求购商品、海报商品（意思是还没推出的商品，先挂个海报出来）这四种。（PHPAuction只有拍卖的交易，Auction即拍卖的意思。@_行癫在微博中提到：今天eBay所有交易中拍卖交易仍然占了40%，而在中国，此种模式在淘宝几乎从一开始就未能占据优势，如今在主流的交易中几乎可以忽略不计。背后的原因一直令人费解。我大致可以给出其中一种解释，eBay基本在发达国家展开业务，制造业外包后，电子商务的基本群体大多只能表现为零散的个体间交易。）

　　在经历了另外一些有趣的事情之后（这些有趣的事情包括“淘宝”这个名字的由来，员工花名的由来等等，由于本书主要描述技术方面的故事，对这些有兴趣的可以去网上找），网站开始上线运行了。

　　在接下来的大半年时间里，这个网站迅速显示出了它的生机。这里有必要提一下当时的市场环境，非典（SARS）的肆虐使得大家都不敢出门，尤其是去商场之类人多的地方。另外在神州大地上最早出现的C2C网站易趣也正忙的不亦乐乎，2002年3月，eBay以3000万美元收购了易趣公司33%的股份，2003年6月以1.5亿美元收购了易趣公司剩余67%的股份。当时淘宝网允许买卖双方留下联系方式，允许同城交易，整个操作过程简单轻松。而eBay为了收取交易佣金，是禁止这么做的，这必然增加了交易过程的难度。而且eBay为了全球统一，把易趣原来的系统替换成了美国eBay的系统，用户体验一下子全变了，操作起来非常麻烦，这等于是把积累的用户拱手送给了淘宝。为了不引起eBay的注意，淘宝网在2003年里一直声称自己是一个“个人网站”。由于这个创业团队强大的市场开拓和运营能力，淘宝网发展的非常迅猛，2003年底就吸引了注册用户XXX，最高每日31万PV，从5月到年底成交额4000万。这没有引起eBay的注意，却引起了阿里巴巴内部很多员工的注意，他们觉得这个网站以后会成为阿里巴巴强劲的对手。甚至有人在内网发帖，忠告管理层要警惕这个刚刚起步的网站，但管理层似乎无动于衷。（这个团队的保密工作做的真好）

　　在市场和运营的后方，淘宝网的技术团队也在快速的做着系统的改进和创新。这里还有个有趣的故事，eBay和易趣早期都有员工在论坛上响应用户的需求，eBay的论坛用粉红色背景来区分员工的发言，易趣的员工在论坛上昵称都选各种豆豆，例如黄豆豆、蚕豆豆等。淘宝在讨论运营策略的时候提到这个问题，要求所有的员工都去论坛上回答用户的问题。最早回答问题的任务落在小宝头上，那我们用什么名字好呢？“淘淘”？“宝宝”？小宝都不满意，太女性化了。讨论了很久之后，小宝灵光乍现，干脆取个名字叫“小宝”吧，小宝带七个老婆来开店，迎接各位客官，很有故事性。于是很多武侠小说中的人物开始在论坛中行侠仗义，这些昵称下面标志着“淘宝店小二”，他们回答着各种各样的问题，快速响应着用户的各种需求。如果是技术上能解决的，几个人商量一下，马上就开发、测试、发布上线。反过来对比一下，易趣被eBay收购之后，系统更换成了全球通用的版本，响应用户的一个需求需要层层审批，反应速度自然慢了下来。

　　当时淘宝第一个版本的系统里面已经包含了商品发布、管理、搜索、商品详情、出价购买、评价投诉、我的淘宝这些功能（现在主流程中也是这些模块。在2003年10月增加了一个功能节点：“安全交易”，这个是支付宝的雏形）。随着用户需求和流量的不断增长，系统上面做了很多的日常改进，服务器由最初的一台变成了三台，一台负责发送email、一台负责运行数据库、一台负责运行Web App。过一段时间之后，商品搜索的功能占用数据库资源太大了（用like搜索的，很慢），又从阿里巴巴中文站搬过来他们的搜索引擎iSearch，起初iSearch索引的文件放在硬盘上，随着数据量的增长，又采购了NetApp服务器放置iSearch。

　　如此快节奏的工作，其实大家都累得不行，有人就提议大家随时随地的锻炼身体，可是外面SARS横行，在一个一百多方的房子里，怎么锻炼呢？高挑美女阿珂提议大家练习提臀操，这个建议遭到男士的一致反对，后来虚竹就教大家练习倒立，这个大家都能接受。于是这个倒立的传统一直延续至今，和花名文化、武侠文化一并传承了下来。

　　随着访问量和数据量的飞速上涨，问题很快就出来了，第一个问题出现在数据库上。MySQL当时是第4版的，我们用的是默认的存储引擎MyISAM，这种类型读数据的时候会把表锁住（我们知道Oracle在写数据的时候会有行锁，读数据的时候是没有的），尤其是主库往从库上面写数据的时候，会对主库产生大量的读操作，使得主库性能急剧下降。这样在高访问量的时候，数据库撑不住了。另外，当年的MySQL不比如今的MySQL，在数据的容量和安全性方面也有很多先天的不足（和Oracle相比）。

　　三、Oracle/支付宝/旺旺

　　淘宝网作为个人网站发展的时间其实并不长，由于它太引人注目了，马云在 2003 年 7 月就宣布了这个是阿里巴巴旗下的网站，随后在市场上展开了很成功的运作。最著名的就是利用中小网站来做广告，突围 eBay 在门户网站上对淘宝的广告封锁。上网比较早的人应该还记得那些在右下角的弹窗和网站腰封上一闪一闪的广告。市场部那位到处花钱买广告的家伙，太能花钱了，一出手就是几百万，他被我们称为“大少爷”。

　　“大少爷”们做的广告，带来的就是迅速上涨的流量和交易量。在 2003 年底，MySQL 已经撑不住了，技术的替代方案非常简单，就是换成 Oracle。换 Oracle 的原因除了它容量大、稳定、安全、性能高之外，还有人才方面的原因。在 2003 年的时候，阿里巴巴已经有一支很强大的 DBA 团队了，有冯春培、汪海（七公）这样的人物，后来还有冯大辉（@fenng）、陈吉平（拖雷）。这样的人物牛到什么程度呢？Oracle 给全球的技术专家颁发一些头衔，其中最高级别的叫 ACE（就是扑克牌的“尖儿”，够大的吧），被授予这个头衔的人目前全球也只有 300 多名（名单在这里： http://apex.oracle.com/pls/otn/f?p=19297:3 ），当年全球只有十几名。有如此强大的技术后盾，把 MySQL 换成 Oracle 是顺理成章的事情。

　　但更换数据库不是只换个库就可以的，访问方式，SQL 语法都要跟着变，最重要的一点是，Oracle 并发访问能力之所以如此强大，有一个关键性的设计——连接池。但对于 PHP 语言来说它是放在 Apache 上的，每一个请求都会对数据库产生一个连接，它没有连接池这种功能（Java 语言有 Servlet 容器，可以存放连接池）。那如何是好呢？这帮人打探到 eBay 在 PHP 下面用了一个连接池的工具，是 BEA 卖给他们的。我们知道 BEA 的东西都很贵，我们买不起，于是多隆在网上寻寻觅觅，找到一个开源的连接池代理服务 SQLRelay（ http://sourceforge.jp/projects/freshmeat_sqlrelay ），这个东西能够提供连接池的功能，多隆对它进行了一些功能改进之后就拿来用了。这样系统的架构就变成了如下的样子：

　　数据一开始是放在本地的，DBA 们对 Oracle 做调优的工作，也对 SQL 进行调优。后来数据量变大了，本地存储不行了。买了 NAS（NetworkAttached Storage：网络附属存储），NetApp 的 NAS 存储作为了数据库的存储设备，加上 Oracle RAC（Real Application Clusters，实时应用集群）来实现负载均衡。七公说这实际上是走了一段弯路，NAS 的 NFS（Network File System）协议传输的延迟很严重，但那时侯不懂。后来采购了 Dell 和 EMC 合作的 SAN 低端存储，性能一下子提升了 10 几倍，这才比较稳定了。再往后来数据量更大了，存储的节点一拆二、二拆四，RAC 又出问题了。这才踏上了购买小型机的道路。在那段不稳定的时间里，七公曾经在机房住了 5 天 5 夜。

　　替换完数据库，时间到了 2004 年春天，俗话说“春宵一刻值千金”，但这些人的春宵却不太好过了。他们在把数据的连接放在 SQLRelay 之后就噩梦不断，这个代理服务经常会死锁，如同之前的 MySQL 死锁一样。虽然多隆做了很多修改，但当时那个版本内部处理的逻辑不对，问题很多，唯一解决的办法就是“重启”它的服务。这在白天还好，连接上机房的服务器，把进程杀掉，然后开启就可以了，但是最痛苦的是它在晚上也要死掉，于是工程师们不得不 24 小时开着手机，一旦收到“SQLRelay 进程挂起”的短信，就从春梦中醒来，打开电脑，连上机房，重启服务。后来干脆每天睡觉之前先重启一下。做这事最多的据说是三丰，他现在是淘宝网的总裁。现在我们知道，任何牛B的人物，都有一段苦B的经历。

　　微博上有人说“好的架构是进化来的，不是设计来的”。的确如此，其实还可以再加上一句“好的功能也是进化来的，不是设计来的”。在架构的进化过程中，业务的进化也非常迅猛。最早的时候，买家打钱给卖家都是通过银行转账汇款，有些骗子收了钱却不发货，这是一个很严重的问题。然后这伙人研究了 PayPal 的支付方式，发现也不能解决问题。后来这几个聪明的脑袋又想到了“担保交易”这种第三方托管资金的办法。于是在 2003 年 10 月，淘宝网上面上线了一个功能，叫做“安全交易”，卖家选择支持这种功能的话，买家会把钱交给淘宝网，等他收到货之后，淘宝网再把钱给卖家。这就是现在的支付宝，在前两天（2012.2.21）年会上，支付宝公布 2011 年的交易笔数已经是 PayPal 的两倍。这个划时代的创新，其实就是在不断的思索过程中的一个灵光乍现。

　　当时开发“安全交易”功能的是茅十八和他的徒弟苗人凤（茅十八开发到一半去上海读 MBA 去了，苗人凤现在是支付宝的首席业务架构师），开发跟银行网关对接的功能的是多隆。当时多数银行的网站已经支持在线支付了，但多隆告诉我，他们的网关五花八门，用什么技术的都有，必须一家一家去接。而且他们不保证用户付钱了就一定扣款成功、不保证扣款成功了就一定通知淘宝、不保证通知淘宝了就一定能通知到、不保证通知到了就不重复通知。这害苦了苗人凤，他必须每天手工核对账单，对不齐的话就一定是有人的钱找不到地方了，少一分钱都睡不着觉。另外他为了测试这些功能，去杭州所有的银行都办理了一张银行卡。一堆银行卡摆在桌子上，不知道的人还以为这个家伙一定很有钱，其实里面都只是十块八块的。现在我们再一次知道，任何牛B的人物，都必须有一段苦B的经历。

　　有人说淘宝打败易趣（eBay 中国）是靠免费，其实这只是原因之一。如果说和易趣过招第一招是免费的话，这让用户没有门槛就愿意来，那第二招就是“安全支付”，这让用户放心付款，不必担心被骗。在武侠小说中真正的高手飞花摘叶即可伤人，他们不会局限于一招两招，一旦出手，连绵不绝。而淘宝的第三招就是“旺旺”，让用户在线沟通。其实淘宝旺旺也不是自己生出来的，是从阿里巴巴的“贸易通”复制过来的。从 2004 年 3 月开始，“叮咚、叮咚”这个经典的声音就回荡在所有淘宝买家和卖家的耳边，“亲，包邮不？”，“亲，把零头去掉行不？”，这亲切的砍价声造就了后来的“淘宝体”。有人说中国人就是爱砍价，虽然笔者体会不到砍价成功后有多少成就感，但每次我去菜市场，看到大妈们砍价砍得天昏地暗，那满足的劲头堪比捡到了钱，我就深刻的理解了淘宝旺旺在交易过程中的价值。我猜 eBay 也体会不到砍价的乐趣，他们一直不允许买卖双方在线聊天，收购了 skype 之后也没有用到电子商务中去。

　　旺旺在推出来没多久，就惹了一个法律方面的麻烦。有个做雪饼的厂家找上门来，说我们侵权了，他们家的雪饼很好吃，牛奶也做得不错，我们都很喜欢。然后我们就在旺旺的前面加了两个字，叫做“淘宝旺旺”。在那个野蛮生长的阶段，其实很多产品都是想到什么就做什么，例如我们还搭建过一个聊天室，但似乎淘宝网不是一个闲聊的地方，这个聊天室门可罗雀，一段时间后就关闭掉了。

　　SQLRelay 的问题搞得三丰他们很难睡个囫囵觉，那一年开半年会的时候，公司特地给三丰颁了一个奖项，对他表示深切的安慰。但不能总这样啊，于是，2004年的上半年开始，整个网站就开始了一个脱胎换骨的手术。

　　淘宝技术发展（Java时代：脱胎换骨）

　　我的师父黄裳@岳旭强曾经说过，“好的架构图充满美感”，一个架构好不好，从审美的角度就能看得出来。后来我看了很多系统的架构，发现这个言论基本成立。那么反观淘宝前面的两个版本的架构，你看哪个比较美？

　　显然第一个比较好看，后面那个显得头重脚轻，这也注定了它不是一个稳定的版本，只存活了不到半年的时间。2004年初，SQL Relay 的问题解决不了，数据库必须要用 Oracle，那从哪里动刀？只有换开发语言了。换什么语言好呢？Java。Java 是当时最成熟的网站开发语言，它有比较良好的企业开发框架，被世界上主流的大规模网站普遍采用，另外有 Java 开发经验的人才也比较多，后续维护成本会比较低。　　

　　到 2004 年上半年，淘宝网已经运行了一年的时间，这一年积累了大量的用户，也快速的开发了很多功能，当时这个网站已经很庞大了，而且新的需求还在源源不断的过来。把一个庞大的网站的开发语言换掉，无异于脱胎换骨，在换的过程中还不能拖慢业务的发展，这无异于边换边跑，对时间和技术能力的要求都非常高。做这样的手术，需要请第一流的专家来主刀。现在再考一下读者，如果你在这个创业团队里面，请什么样的人来做这事？我们的答案是请 Sun 的人。没错，就是创造 Java 语言的那家公司，世界上没有比他们更懂 Java 的了。除此之外，还有一个不为人知的原因，……（此处和谐掉 200 字，完整版见 aliway）

　　这帮 Sun 的工程师的确很强大，在笔者 2004 年底来淘宝的时候，他们还在，有幸跟他们共事了几个月。现在摆在他们面前的问题是用什么办法把一个庞大的网站从 PHP 语言迁移到 Java？而且要求在迁移的过程中，不停止服务，原来系统的 bugfix 和功能改进不受影响。亲，你要是架构师，你怎么做？有人的答案是写一个翻译器，如同把中文翻译成英文一样，自动翻译。我只能说你这个想法太超前了，换个说法就是“too simple, sometimes naive”。当时没有，现在也没有人能做到。他们的大致方案是给业务分模块，一个模块一个模块的替换。如用户模块，老的 member.taobao.com 继续维护，不添加新功能，新的功能先在新的模块上开发，跟老的共用一个数据库，开发完毕之后放到不同的应用集群上，另开个域名 member1.taobao.com，同时替换老的功能，替换一个把老的模块上的功能关闭一个，逐渐的把用户引导到 member1.taobao.com，等所有功能都替换完毕之后，关闭 member.taobao.com。后来很长时间里面都是在用 member1 这样奇怪的域名，两年后有另外一家互联网公司开始做电子商务了，我们发现他们的域名也叫 member1.xx.com、auction1.xx.com……　　

　　说了开发模式，再说说用到的 Java MVC 框架，当时的 struts1.x 是用的比较多的框架，但是用过 webwork 和 struts2 的同学可能知道，struts1.x 在多人协作方面有很多致命的弱点，由于没有一个轻量框架作为基础，因此很难扩展，这样架构师对于基础功能和全局功能的控制就很难做到。而阿里巴巴的 18 个创始人之中，有个架构师，在 Jakarta Turbine 的基础上，做了很多扩展，打造了一个阿里巴巴自己用的 MVC 框架 WebX （http://www.openwebx.org/docs/Webx3_Guide_Book.html），这个框架易于扩展，方便组件化开发，它的页面模板支持 JSP 和 velocity 等、持久层支持 ibatis 和 hibernate 等、控制层可以用 EJB 和 Spring（Spring 是后来才有的）。项目组选择了这个强大的框架，这个框架如果当时开源了，也许就没有 webwork 和 struts2 什么事了。另外，当时 Sun 在全世界大力推广他们的 EJB，虽然淘宝的架构师认为这个东东用不到，但他们还是极力坚持。在经历了很多次的技术讨论、争论和争吵之后，这个系统的架构就变成了下图的样子：

　　Java 应用服务器是 Weblogic，MVC 框架是 WebX、控制层用了 EJB、持久层是 iBATIS，另外为了缓解数据库的压力，商品查询和店铺查询放在搜索引擎上面。这个架构图是不是好看了一点了，亲？　　

　　这帮 Sun 的工程师开发完淘宝的网站之后，又做了一个很牛的网站，叫“支付宝”。　　

　　其实在任何时候，开发语言本身都不是系统的瓶颈，业务带来的压力更多的是压到了数据和存储上。上面一篇也说到，MySQL 撑不住了之后换 Oracle，Oracle 的存储一开始在本机上，后来在 NAS 上，NAS 撑不住了用 EMC 的 SAN 存储，再然后 Oracle 的 RAC 撑不住了，数据的存储方面就不得不考虑使用小型机了。在 2004 年的夏天，DBA 七公、测试工程师郭芙和架构师行癫，踏上了去北京测试小型机的道路。他们带着小型机回来的时候，我们像欢迎领袖一样的欢迎他们，因为那个是我们最值钱的设备了，价格表上的数字吓死人。小型机买回来之后我们争相合影，然后 Oracle 就跑在了小型机上，存储方面从 EMC 低端 cx 存储到 Sun oem hds 高端存储，再到 EMC dmx 高端存储，一级一级的往上跳。　　

　　到现在为止，我们已经用上了 IBM 的小型机、Oracle 的数据库、EMC 的存储，这些东西都是很贵的，那些年可以说是花钱如流水啊。有人说过“钱能解决的问题，就不是问题”，但随着淘宝网的发展，在不久以后，钱已经解决不了我们的问题了。花钱买豪华的配置，也许能支持 1 亿 PV 的网站，但淘宝网的发展实在是太快了，到了 10 亿怎么办？到了百亿怎么办？在N年以后，我们不得不创造技术，解决这些只有世界顶尖的网站才会遇到的问题。后来我们在开源软件的基础上进行自主研发，一步一步的把 IOE（IBM 小型机、Oracle、EMC 存储）这几个“神器”都去掉了。这就如同在《西游记》里面，妖怪们拿到神仙的兵器会非常厉害，连猴子都能够打败，但最牛的神仙是不用这些神器的，他们挥一挥衣袖、翻一下手掌就威力无比。去 IOE 这一部分会在最后一个章节里面讲，这里先埋个千里伏笔。　　

　　欲知后事如何，且听下回分解。

　　淘宝技术发展（Java时代：坚若磐石）

　　已经有读者在迫不及待的问怎么去掉了 IOE，别急，在去掉 IOE 之前还有很长的路要走。行癫他们买回来小型机之后，我们用上了 Oracle，七公带着一帮 DBA 在优化 SQL 和存储，行癫带着几个架构师在研究数据库的扩展性。Oracle 本身是一个封闭的系统，用 Oracle 怎么做扩展？用现在一个时髦的说法就是做“分库分表”。

　　我们知道一台 Oracle 的处理能力是有上限的，它的连接池有数量限制，查询速度跟容量成反比。简单的说，在数据量上亿、查询量上亿的时候，就到它的极限了。要突破这种极限，最简单的方式就是多用几个 Oracle 数据库。但一个封闭的系统做扩展，不像分布式系统那样轻松。我们把用户的信息按照 ID 来放到两个数据库里面（DB1/DB2），把商品的信息跟着卖家放在两个对应的数据库里面，把商品类目等通用信息放在第三个库里面(DBcommon)。这么做的目的除了增加了数据库的容量之外，还有一个就是做容灾，万一一个数据库挂了，整个网站上还有一半的数据能操作。　　

　　数据库这么分了之后，应用程序有麻烦了，如果我是一个买家，买的商品有 DB1 的也有 DB2 的，要查看“我已买到的宝贝”的时候，应用程序怎么办？必须到两个数据库里面分别查询出来对应的商品。要按时间排序怎么办？两个库里面“我已买到的宝贝”全部查出来在应用程序里面做合并。还有分页怎么处理？关键字查询怎么处理？这些东西交给程序员来做的话会很悲催，于是行癫在淘宝的第一个架构上的作品就来解决了这个问题，他写了一个数据库路由的框架 DBRoute，这个框架在淘宝的 Oracle 时代一直在使用。后来随着业务的发展，这种分库的第二个目的 —— 容灾的效果就没有达到。像评价、投诉、举报、收藏、我的淘宝等很多地方，都必须同时连接 DB1 和 DB2，哪个库挂了都会导致整个网站挂掉。　　

　　上一篇说过，采用 EJB 其实是和 Sun 的工程师妥协的结果，在他们走了之后，EJB 也逐渐被冷落了下来。在 05、06年的时候，Spring 大放异彩，正好利用 Spring 的反射（IoC）模式替代了 EJB 的工厂模式，给整个系统精简了很多代码。　　

　　上一篇还说过，为了减少数据库的压力，提高搜索的效率，我们引入了搜索引擎。随着数据量的继续增长，到了 2005 年，商品数有 1663 万，PV 有 8931 万，注册会员有 1390 万，这给数据和存储带来的压力依然山大，数据量大，性能就慢。亲，还有什么办法能提升系统的性能？一定还有招数可以用，这就是缓存和 CDN（内容分发网络）。　　

　　你可以想象，九千万的访问量，有多少是在商品详情页面？访问这个页面的时候，数据全都是只读的（全部从数据库里面读出来，不写入数据库），如果把这些读操作从数据库里面移到内存里，数据库将会多么的感激涕零。在那个时候我们的架构师多隆大神，找到了一个基于 Berkeley DB 的开源的缓存系统，把很多不太变动的只读信息放了进去。其实最初这个缓存系统还比较弱，我们并没有把整个商品详情都放在里面，一开始把卖家的信息放里面，然后把商品属性放里面，商品详情这个字段太大，放进去受不了。说到商品详情，这个字段比较恐怖，有人统计过，淘宝商品详情打印出来平均有 5 米长，在系统里面其实放在哪里都不招人待见。笔者清楚的记得，我来淘宝之后担任项目经理做的第一个项目就是把商品详情从商品表里面给移出来。这个字段太大了，查询商品信息的时候很多都不需要查看详情，它跟商品的价格、运费这些放在一个表里面，拖慢了整个表的查询速度。在 05 年的时候，我把商品详情放在数据库的另外一张表里面，再往后这个大字段被从数据库里面请了出来，这也让数据库再一次感激涕零。　　

　　到现在为止，整个商品详情的页面都在缓存里面了，眼尖的读者可能会发现现在的商品详情不全是“只读”的信息了，这个页面上有个信息叫“浏览量”，这个数字每刷新一次页面就要“写入”数据库一次，这种高频度实时更新的数据能用缓存吗？如果不用缓存，一天几十亿的写入，数据库会怎么样？一定会挂掉。那怎么办？亲……先不回答你（下图不是广告，让你看看浏览量这个数据在哪里）

　　CDN 这个工作相对比较独立，跟别的系统一样，一开始我们也是采用的商用系统。后来随着流量的增加，商用的系统已经撑不住了，LVS 的创始人章文嵩博士带人搭建了淘宝自己的 CDN 网络。在本文的引言中我说过淘宝的 CDN 系统支撑了 800Gbps 以上的流量，作为对比我们可以看一下国内专业做 CDN 的上市公司 ChinaCache 的介绍 —— “ChinaCache……是中国第一的专业 CDN 服务提供商，向客户提供全方位网络内容快速分布解决方案。作为首家获信产部许可的 CDN 服务提供商，目前 ChinaCache 在全国 50 多个大中城市拥有近 300 个节点，全网处理能力超过 500Gbps，其 CDN 网络覆盖中国电信、中国网通、中国移动、中国联通、中国铁通和中国教育科研网等各大运营商。” —— 这样你可以看得出淘宝在 CDN 上面的实力，这在全世界都是数一数二的。另外因为 CDN 需要大量的服务器，要消耗很多能源（消耗多少？在前两年我们算过一笔帐，淘宝上产生一个交易，消耗的电足以煮熟 4 个鸡蛋）。这两年章文嵩的团队又在研究低功耗的服务器，在绿色计算领域也做了很多开创性的工作。淘宝 CDN 的发展需要专门一个章节来讲，想先睹为快的可以看一下笔者对章文嵩的专访。　　

　　回想起刚用缓存那段时间，笔者还是个小菜鸟，有一个经典的错误常常犯，就是数据库的内容更新的时候，忘记通知缓存系统，结果在测试的时候就发现我改过的数据怎么在页面上没变化呢。后来做了一些页面上的代码，修改 CSS 和 JS 的时候，用户本地缓存的信息没有更新，页面上也会乱掉，在论坛上被人说的时候，我告诉他用 Ctrl+F5 刷新页面，然后赶紧修改脚本文件的名称，重新发布页面。学会用 Ctrl+F5 的会员对我佩服的五体投地，我却惭愧的无地自容。　　

　　有些技术的发展是顺其自然的，有些却是突如其来的。到 2007 年的时候，我们已经有几百台应用服务器了，这上面的 Java 应用服务器是 WebLogic，而 WebLogic 是非常贵的，比这些服务器本身都贵。有一段时间多隆研究了一下 JBoss，说我们换掉 WebLogic 吧，于是又省下了不少银两。那一年，老马举办了第一届的“网侠大会”，会上来的大侠中有一位是上文提到的章文嵩，还有一位曾经在 JBoss 团队工作，我们也把这位大侠留下了，这样我们用起 JBoss 更加有底气了。　　

　　这些杂七杂八的修改，我们对数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss，看起来没有章法可循，其实都是围绕着提高容量、提高性能、节约成本来做的，由于这些不算大的版本变迁，我们姑且叫它2.1版吧，这个版本从构图上来看有 3 只脚，是不是稳定了很多？

　　架构图如下：

　　淘宝技术发展

　　在讲淘宝文件系统TFS之前，先回顾一下上面几个版本。1.0版的PHP系统运行了将近一年的时间（2003.05~2004.01）；后来数据库变成Oracle之后（2004.01~2004.05，叫1.1版本吧），不到半年就把开发语言转换为Java系统了（2004.02~2005.03，叫2.0版本）；进行分库、加入缓存、CDN之后我们叫它2.1版本（2004.10~2007.01）。这中间有些时间的重合，因为很多架构的演化并没有明显的时间点，它是逐步进化而来的。

　　在描述2.1版本的时候我写的副标题是“坚若磐石”，这个“坚若磐石”是因为这个版本终于稳定下来了，在这个版本的系统上，淘宝网运行了两年多的时间。这期间有很多优秀的人才加入，也开发了很多优秀的产品，例如支付宝认证系统、招财进宝项目、淘宝旅行、淘宝彩票、淘宝论坛等等。甚至在团购网站风起云涌之前，淘宝网在2006年就推出了团购的功能，只是淘宝网最初的团购功能是买家发起的，达到卖家指定的数量之后，享受比一口价更低的价格，这个功能看起来是结合了淘宝一口价和荷兰拍的另一种交易模式，但不幸没有支撑下去。

　　在这些产品和功能的最底层，其实还是商品的管理和交易的管理这两大功能。这两大功能在2.1版本里面都有很大的变化。商品的管理起初是要求卖家选择7天到期还是14天到期，到期之后就要下架，必须重新发布才能上架，上架之后就变成了新的商品信息（ID变过了）。另外如果这个期间内成交了，之后再有新货，必须发布一个新的商品信息。这么做有几个原因，一是参照拍卖商品的时间设置，要在某日期前结束挂牌；二是搜索引擎不知道同样的商品哪个排前面，那就把挂牌时间长的排前面，这样就必须在某个时间把老的商品下架掉，不然它老排在前面；第三是成交信息和商品ID关联，这个商品如果多次编辑还是同一个ID的话，成交记录里面的商品信息会变来变去；还有一个不为人知的原因，我们的存储有限，不能让所有的商品老存放在主库里面。这种处理方式简单粗暴，但还算是公平。不过这样很多需求都无法满足，例如同样的商品，我上一次销售的时候很多好评都没法在下一个商品上体现出来；再例如我买过的商品结束后只看到交易的信息，不知道卖家还有没有再卖了。后来基于这些需求，我们在2006年下半年把商品和交易拆开。一个商家的一种商品有个唯一的ID，上下架都是同一个商品。那么如果卖家改价格、库存什么的话，已成交的信息怎么处理？那就在买家每交易一次的时候，都记录下商品的快照信息，有多少次交易就有多少个快照。这样买卖双方比较爽了，给系统带来了什么？存储的成本大幅度上升了！

　　存储的成本高到什么程度呢？数据库方面提到过用了IOE，一套下来就是千万级别的，那几套下来就是⋯⋯。另外淘宝网还有很多文件需要存储，我们有哪些文件呢？最主要的就是图片、商品描述、交易快照，一个商品要包含几张图片和一长串的描述信息，而每一张图片都要生成几张规格不同的缩略图。在2010年，淘宝网的后端系统上保存着286亿个图片文件。图片在交易系统中非常重要，俗话说“一张好图胜千言”、“无图无真相”，淘宝网的商品照片，尤其是热门商品，图片的访问流量是非常大的。淘宝网整体流量中，图片的访问流量要占到90%以上。且这些图片平均大小为17.45KB，小于8K的图片占整体图片数量61%，占整体系统容量的11%。这么多的图片数据、这么大的访问流量，给淘宝网的系统带来了巨大的挑战。众所周知，对于大多数系统来说，最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁的寻道和换道，因此在读取上容易带来较长的延时。在大量高并发访问量的情况下，简直就是系统的噩梦。我们该怎么办？

　　同样的套路，在某个规模以下，采用现有的商业解决方案，达到某种规模之后，商业的解决方案无法满足，只有自己创造解决方案了。对于淘宝的图片存储来说，转折点在2007年。这之前，一直采用的商用存储系统，应用NetApp公司的文件存储系统。随着淘宝网的图片文件数量以每年2倍(即原来3倍)的速度增长，淘宝网后端NetApp公司的存储系统也从低端到高端不断迁移，直至2006年，即使是NetApp公司最高端的产品也不能满足淘宝网存储的要求。从2006年开始，淘宝网决定自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题。这标志着淘宝网从使用技术到了创造技术的阶段。

　　2007年之前的图片存储架构如下图：

　　章文嵩博士总结了几点商用存储系统的局限和不足:

　　首先是商用的存储系统没有对小文件存储和读取的环境进行有针对性的优化；其次，文件数量大，网络存储设备无法支撑；另外，整个系统所连接的服务器也越来越多，网络连接数已经到达了网络存储设备的极限。此外，商用存储系统扩容成本高，10T的存储容量需要几百万，而且存在单点故障，容灾和安全性无法得到很好的保证。

　　谈到在商用系统和自主研发之间的经济效益对比，章文嵩博士列举了以下几点经验：

　　1. 商用软件很难满足大规模系统的应用需求，无论存储还是CDN还是负载均衡，因为在厂商实验室端，很难实现如此大的数据规模测试。

　　2. 研发过程中，将开源和自主开发相结合，会有更好的可控性，系统出问题了，完全可以从底层解决问题，系统扩展性也更高。

　　3. 在一定规模效应基础上，研发的投入都是值得的。上图是一个自主研发和购买商用系统的投入产出比对比，实际上，在上图的交叉点左边，购买商用系统都是更加实际和经济性更好的选择，只有在规模超过交叉点的情况下，自主研发才能收到较好的经济效果。实际上，规模化达到如此程度的公司其实并不多，不过淘宝网已经远远超过了交叉点。

　　4. 自主研发的系统可在软件和硬件多个层次不断的优化。

　　历史总是惊人的巧合，在我们准备研发文件存储系统的时候，Google走在了前面，2007年他们公布了GFS（ Google File System ）的设计论文，这给我们带来了很多借鉴的思路。随后我们开发出了适合淘宝使用的图片存储系统TFS（Taobao File System）。3年之后，我们发现历史的巧合比我们想象中还要神奇，几乎跟我们同时，中国的另外一家互联网公司也开发了他们的文件存储系统，甚至取的名字都一样——TFS，太神奇了！（猜猜是哪家？）

　　2007年6月，TFS正式上线运营。在生产环境中应用的集群规模达到了200台PC Server(146G*6 SAS 15K Raid5)，文件数量达到上亿级别；系统部署存储容量：140TB；实际使用存储容量： 50TB；单台支持随机IOPS200+，流量3MBps。

　　要讲TFS的系统架构，首先要描述清楚业务需求，淘宝对图片存储的需求大概可以描述如下：

　　文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾能备份。应对这种需求，显然要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；并发量高，读写随机性强，需要更少的IO操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。

　　参照GFS并做了适度的优化之后，TFS1.0版的架构图如下：

　　从上面架构图上看：集群由一对Name Server和多台Data Server构成，Name Server的两台服务器互为双机，就是集群文件系统中管理节点的概念。

　　在这个架构中：
　　• 每个Data Server运行在一台普通的Linux主机上
　　• 以block文件的形式存放数据文件(一般64M一个block)
　　• block存多份保证数据安全
　　• 利用ext3文件系统存放数据文件
　　• 磁盘raid5做数据冗余
　　• 文件名内置元数据信息，用户自己保存TFS文件名与实际文件的对照关系–使得元数据量特别小。

　　淘宝TFS文件系统在核心设计上最大的取巧的地方就在，传统的集群系统里面元数据只有1份，通常由管理节点来管理，因而很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存实际上用户并不关心，因此TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如图片的大小、时间、访问频次等等信息，包括所在的逻辑块号。而在元数据上，实际上保存的信息很少，因此元数据结构非常简单。仅仅只需要一个fileID，能够准确定位文件在什么地方。

　　由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性极大提高。实际上，这一设计理念和目前业界的“对象存储”较为类似，淘宝网TFS文件系统已经更新到1.3版本，在生产系统的性能已经得到验证，且不断得到了完善和优化，淘宝网目前在对象存储领域的研究已经走在前列。

　　在TFS上线之前，淘宝网每个商品只允许上传一张图片，大小限定在120K之内，在商品详情里面的图片必须使用外站的服务。那时侯发布一件商品确实非常麻烦，笔者曾经想卖一台二手电脑，先把照片上传到Google相册，在发布到淘宝网之后发现Google相册被墙了，我的图片别人看不到，当时郁闷的不行。TFS上线后，商品展示图片开放到5张，商品描述里面的图片也可以使用淘宝的图片服务，到现在为止，淘宝网给每个用户提供了1G的图片空间，这下大家都满足了。技术和业务就是这么互相用力的推动着，业务满足不了的时候，技术必须创新，技术创新之后，业务有了更大的发展空间。

　　1.3版本的架构见阿里味（阿里巴巴内网）⋯⋯　　

　　作者的另一篇：从P1到P7——我在淘宝这7年

作者：heiyeshuwu 发表于2012-5-10 16:36:26 原文链接

阅读：411 评论：0 查看评论

[转][转]Instagram 架构分析笔记

heiyeshuwu — Sat, 21 Apr 2012 11:47:14 +0800

作者: Fenng

来源：http://www.dbanotes.net/arch/instagram.html

Updated: 2012 年4月10日凌晨消息，Instagram 被 Facebook 以10亿美金收购。团队规模：13 人。

Instagram 团队上个月才迎来第 7 名员工，是的，7个人的团队。作为 iPhone 上最火爆的图片类工具，instagram 用户数量已经超过 1400 万，图片数量超过 1.5 亿张。不得不说，这真他妈是个业界奇迹。

几天前，只有三个人的 Instagram 工程师团队发布了一篇文章：What Powers Instagram: Hundreds of Instances, Dozens of Technologies，披露了 Instagram 架构的一些信息，足够勾起大多数人的好奇心。读罢做点笔记，各种线索还是有一定参考价值的。能打开原文的建议直接读原文。

Instagram 开发团队奉行的三个核心原则：

Keep it very simple (极简主义)
Don't re-invent the wheel (不重复发明轮子)
Go with proven and solid technologies when you can(能用就用靠谱的技术)

OS/主机

操作系统的选择，在Amazon EC2上跑 Ubuntu Linux 11.04 (Natty Narwhal) ，这个版本经过验证在 EC2 上够稳定。因为只有三名工程师，只有三名工程师，所以自己部署机器到 IDC 是不靠谱的事情。幸好有亚马逊。

负载均衡

此前曾用过两台 Nginx 做 DNS 轮询承载前端请求，这样做会有副作用，现在已经迁移到Amazon的ELB(Elastic Load Balancer)，起了三个 Nginx 实例，在 ELB 层停掉了 SSL , 以缓解 CPU 压力。DNS 服务使用 Amazon Route53 服务。

应用服务器

启用了 25 个 Django 实例，运行在 High-CPU Extra-Large 类型的服务器实例上，之所以用 High-CPU Extra-Large 实例是因为应用请求是 CPU 密集型而非 IO 密集型。

使用 Gunicorn 作为 WSGI 服务器。过去曾用过 Apache 下的 mod_wsgi 模块，不过发现 Gunicorn 更容易配置并且节省 CPU 资源。使用 Fabric 加速部署。

数据存储

用户信息、图片元数据、标签等大部分数据存储在 PostgreSQL 中。主要的 Shard 数据库集群有 12个节点。

实践中发现 Amazon 的网络磁盘系统单位时间内寻道能力不行，所以有必要将数据尽量放到内存中。创建了软 RAID 以提升 IO 能力，使用的 Mdadm 工具进行 RAID 管理。

管理内存中的数据，vmtouch 这个小工具值得推荐。

PostgreSQL 设置为 Master-Replica 方式，流复制模式。利用 EBS 的快照进行数据库备份。使用 XFS 文件系统，以便和快照服务充分配合。使用 repmgr 这个小工具做 PostgreSQL 复制管理器器。

连接池管理，用了 Pgbouncer。Christophe Pettus 的文章包含了不少 PostgreSQL 数据库的信息。

TB 级别的海量图片存储在 Amazon S3 上，CDN 采用的也是 Amazon 的服务，CloudFront。

Instagram 也是 Redis 的重度用户，Feed 以及 Session 信息都用 Redis 处理，Redis 也是以 Master-Replica 方式部署。在 Replica 节点上进行数据备份。

使用了 Apache Solr 承担 Geo-search API 的工作，Solr 简单的 JSON 接口也不错。

缓存使用了 6 个 Memcached 实例，库使用 pylibmc 和 libmemcached。亚马逊也提供缓存服务－Elastic Cache service ，Instagram 也有尝试，不过不便宜。

任务队列/发布通知

队列服务使用 Gearman ，通知系统则使用 pyapns 来实现。

监控

前面提及的服务器实例数量加起来，的确有100多个，有效的监控是相当有必要的。使用 Munin 作为主要监控工具 , 也写了不少定制插件，外部监控用 Pingdom 的服务。通知服务使用PagerDuty。

对于 Python 的错误报告，使用 Disqus 团队开源的 Sentry 来处理。

几个感想

0）轻装上阵说起来容易，做起来非常难。这也是 Instagram 团队目前最令人着迷的地方；

1）Python 社区已经足够成熟，各个环节上都已经有不错的解决方案了。

2）如果要问我最大的一个感慨，我要说：Amazon 真是一家伟大的公司，甚至比 Google 还伟大。

--EOF--

作者：heiyeshuwu 发表于2012-4-21 11:47:14 原文链接

阅读：551 评论：1 查看评论

[转][转]Redis消息通知系统的实现

heiyeshuwu — Sat, 17 Mar 2012 21:49:01 +0800

作者：老王
链接：http://huoding.com/2012/02/29/146

最近忙着用Redis实现一个消息通知系统，今天大概总结了一下技术细节，其中演示代码如果没有特殊说明，使用的都是PhpRedis扩展来实现的。

内存

比如要推送一条全局消息，如果真的给所有用户都推送一遍的话，那么会占用很大的内存，实际上不管粘性有多高的产品，活跃用户同全部用户比起来，都会小很多，所以如果只处理登录用户的话，那么至少在内存消耗上是相当划算的，至于未登录用户，可以推迟到用户下次登录时再处理，如果用户一直不登录，就一了百了了。

队列

当大量用户同时登录的时候，如果全部都即时处理，那么很容易就崩溃了，此时可以使用一个队列来保存待处理的登录用户，如此一来顶多是反应慢点，但不会崩溃。

Redis的LIST数据类型可以很自然的创建一个队列，代码如下：

<?php

$redis = new Redis;
$redis->connect('/tmp/redis.sock');

$redis->lPush('usr', <USRID>);

while ($usr = $redis->rPop('usr')) {
    var_dump($usr);
}

?>

出于类似的原因，我们还需要一个队列来保存待处理的消息。当然也可以使用LIST来实现，但LIST只能按照插入的先后顺序实现类似FIFO或LIFO形式的队列，然而消息实际上是有优先级的：比如说个人消息优先级高，全局消息优先级低。此时可以使用ZSET来实现，它里面分数的概念很自然的实现了优先级。

不过ZSET没有原生的POP操作，所以我们需要模拟实现，代码如下：

<?php

class RedisClient extends Redis
{
    const POSITION_FIRST = 0;
    const POSITION_LAST = -1;

    public function zPop($zset)
    {
        return $this->zsetPop($zset, self::POSITION_FIRST);
    }

    public function zRevPop($zset)
    {
        return $this->zsetPop($zset, self::POSITION_LAST);
    }

    private function zsetPop($zset, $position)
    {
        $this->watch($zset);

        $element = $this->zRange($zset, $position, $position);

        if (!isset($element[0])) {
            return false;
        }

        if ($this->multi()->zRem($zset, $element[0])->exec()) {
            return $element[0];
        }

        return $this->zsetPop($zset, $position);
    }
}

?>

模拟实现了POP操作后，我们就可以使用ZSET实现队列了，代码如下：

<?php

$redis = new RedisClient;
$redis->connect('/tmp/redis.sock');

$redis->zAdd('msg', <PRIORITY>, <MSGID>);

while ($msg = $redis->zRevPop('msg')) {
    var_dump($msg);
}

?>

推拉

以前微博架构中推拉选择的问题已经被大家讨论过很多次了。实际上消息通知系统和微博差不多，也存在推拉选择的问题，同样答案也是类似的，那就是应该推拉结合。具体点说：在登陆用户获取消息的时候，就是一个拉消息的过程；在把消息发送给登陆用户的时候，就是一个推消息的过程。

速度

假设要推送一百万条消息的话，那么最直白的实现就是不断的插入，代码如下：

<?php

for ($msgid = 1; $msgid <= 1000000; $msgid++) {
    $redis->sAdd('usr:<USRID>:msg', $msgid);
}

?>

Redis的速度是很快的，但是借助PIPELINE，会更快，代码如下：

<?php

for ($i = 1; $i <= 100; $i++) {
    $redis->multi(Redis::PIPELINE);
    for ($j = 1; $j <= 10000; $j++) {
        $msgid = ($i - 1) * 10000 + $j;
        $redis->sAdd('usr:<USRID>:msg', $msgid);
    }
    $redis->exec();
}

?>

说明：所谓PIPELINE，就是省略了无谓的折返跑，把命令打包给服务端统一处理。

前后两段代码在我的测试里，使用PIPELINE的速度大概是不使用PIPELINE的十倍。

查询

我们用Redis命令行来演示一下用户是如何查询消息的。

先插入三条消息，其<MSGID>分别是1，2，3：

redis> HMSET msg:1 title title1 content content1
redis> HMSET msg:2 title title2 content content2
redis> HMSET msg:3 title title3 content content3

再把这三条消息发送给某个用户，其<USRID>是123：

redis> SADD usr:123:msg 1
redis> SADD usr:123:msg 2
redis> SADD usr:123:msg 3

此时如果简单查询用户有哪些消息的话，无疑只能查到一些<MSGID>：

redis> SMEMBERS usr:123:msg
1) "1"
2) "2"
3) "3"

如果还需要用程序根据<MSGID>再来一次查询无疑有点低效，好在Redis内置的SORT命令可以达到事半功倍的效果，实际上它类似于SQL中的JOIN：

redis> SORT usr:123:msg GET msg:*->title
1) "title1"
2) "title2"
3) "title3"
redis> SORT usr:123:msg GET msg:*->content
1) "content1"
2) "content2"
3) "content3"

SORT的缺点是它只能GET出字符串类型的数据，如果你想要多个数据，就要多次GET：

redis> SORT usr:123:msg GET msg:*->title GET msg:*->content
1) "title1"
2) "content1"
3) "title2"
4) "content2"
5) "title3"
6) "content3"

很多情况下这显得不够灵活，好在我们可以采用其他一些方法平衡一下利弊，比如说新加一个字段，冗余保存完整消息的序列化，接着只GET这个字段就OK了。

实际暴露查询接口的时候，不会使用PHP等程序来封装，因为那会成倍降低RPS，推荐使用Webdis，它是一个Redis的Web代理，效率没得说。

…

最近Tumblr发表了一篇类似的文章：Staircar: Redis-powered notifications，介绍了他们使用Redis实现消息通知系统的一些情况，有兴趣的不妨一起看看。

作者：heiyeshuwu 发表于2012-3-17 21:49:01 原文链接

阅读：678 评论：0 查看评论

[转][转]Tumblr架构 – 页面浏览量150亿/月并且比Twitter更难拓展

heiyeshuwu — Sat, 17 Mar 2012 20:48:29 +0800

作者：longhao
来源：http://www.longtask.com/blog/?p=736

注：一些内容不熟悉，所以没有翻译。原文地址在这里

Tumblr每个月增长30% , 一天5亿网页浏览，40K/sec , 每天3TB的数据存储在1000+的服务器上。最开始只有4名工程师来处理所有事情，当有20多个工程师的时候，才有实力出一些有趣的解决方案。

Tumblr最开始是典型的大型LAMP应用，现在的分布式服务模型使用了Scala, HBase, Redis,Kafka , Finagle等，现在在处理PHP应用的问题，开始走向面向服务的设计。

分布式系统工程师 Blank Matheny讲述Tumblr的架构

现状

每天5亿PV
~20 工程师
平均每秒4W请求
每天1+ TB 数据写入到Hadoop集群
每天更多TB的数据写入到 MySQL/HBase/Redis/Memcache
每月增长超过30%
~1000 硬件服务器
每个工程师每天分摊的PV将近10亿
每天提交 50GB . Follower列表更新每天产生2.7TB 的数据。
Dashboard 每秒百万的读取和每秒5万的写入, 并且还在增长.

软件

开发使用OS X , 服务器使用Linux (CentOS, Scientific)
Apache
PHP, Scala, Ruby
Redis, HBase, MySQL
Varnish, HA-Proxy, nginx,
Memcache, Gearman, Kafka, Kestrel, Finagle
Thrift, HTTP
Func – a secure, scriptable remote control framework and API
Git, Capistrano, Puppet, Jenkins

硬件

500 web servers
200 database servers (许多服务器是容灾的需要)
- 47 pools
- 30 shards
30 memcache servers
22 redis servers
15 varnish servers
25 haproxy nodes
8 nginx
14 job queue servers (kestrel + gearman)

架构设计

Tumblr 相对其他社会网络有不同的使用模式
- 网状的分发结构，每天超过5000万的提交需要分发到用户的Follower , 很多用户都有数百个Follower ，百万Follower的用户也不是一两个。所以Tumblr的规模极具挑战性。
- 由于存在图片和视频，让用户停留时间比较长。
- 返回给用户的内容和用户的联系人有关，不是简单的数据流。
- 需要做大量的数据分析（用户数量，用户平均活动范围，用户提交的高质量的内容等）
Tumblr 运行在托管服务器上 . 设计上需要考虑未来的地理分布。
Tumblr作为一个平台有2部分组成: 公共Tumblr日志和面板
- 公共Tumblr日志是一个博客平台 . 容易缓存
- 控制面板类似 Twitter 时间表 . 需要实时更新用户follower的内容.
  - cache不管用，尤其对活跃的用户
  - 需要实时和一致，不应该显示陈旧数据，所以会有每天提交50GB，Follower列表更新需要2.7TB。（多媒体存储在S3上）
- 多数用户把Tumblr作为内容消费工具, 70%浏览来自面板.
- 面板的可用性非常好了，Tumblr日志因为遗留的架构问题导致可用性不好。

老的Tumblr

Tumblr公司开始托管在Rackspace ，他们给每个自定义域blog一个A记录（域名管理方面的内容），当迁出Rackspace的时候需要迁移大量用户，2007年前，使用 HAProxy and Varnish来负责均衡。许多像这样的遗留问题
一个传统的 LAMP 演进.
- 历史原因，每个工程师都用PHP。
- 最开始阶段一台web服务器，一台数据库服务器，一台PHP应用服务器。
- To scale they started using memcache, then put in front-end caching, then HAProxy in front of the caches, then MySQL sharding. MySQL sharding has been hugely helpful.
- 最开始使用memcache ，然后转到前端缓存，使用HAProxy 在缓存前，然后使用Mysql水平分区，Mysql水平分区非常有用。
- 最开始中心化，过去的几年中采用了2台用C语言写的后端服务器来做2件事情：生成ID 和 Staircar ，使用Redis来处理面板通知
面板采用了 scatter-gather 的方式，当用户访问他们面板的时候采用事件驱动的方式，由于采用事件顺序，分片方案不是工作的很好。

新的Tumblr

因招聘和开发速度的原因，转向JVM。
目标是移除PHP的所有应用，采用服务的方式。所有应用是很薄的一层，通过访问服务来鉴权和呈现。
Scala and Finagle 的选择
- 内部人员很多回Ruby和PHP，所以Scala语言比较容易接受
- Finagle 是Scala写的，解决了大部分的分布式问题，同时它是免费的。
- Finagle 提供了初始阶段所有想要的东西 (Thrift, ZooKeeper, etc).
- Finagle 被 Foursquare和Twitter使用 . Meetup在使用Scala
- 喜欢Thrift的应用接口，主要是高性能方面。
- 喜欢Netty, 但是不喜欢Java , Scala是个不错选择
- 选择 Finagle 可以通过更少的代码解决分布问题。
- Node.js不被选择是因为JVM平台更有优势，Node.js没有开发标准和好的开发策略，没有通过大型系统的代码验证。Scala 可以使用java代码，可拓展性好，5毫秒的响应速度，有许多大型java应用可以参考。
内部服务从基于C/libevent转向基于 Scala/Finagle
使用非关系型数据库HBase和Redis , 但是大半数据存储在Mysql集群，没有使用HBase替代MySQL。
HBase 被用来备份数十亿的短网址和历史数据分析，被用来解决高并发写的问题，例如：每秒百万写级别的面板重置。HBase 没有替代Mysql是因为项目经验少，不能打赌。
MySQL和shard(分片数据库）在时序数据上的问题是，一个分片总是热点块，并且由于在slave端的平行插入而导致读端的复制总是落后。
Created a common services framework.
- Spent a lot of time upfront solving operations problem of how to manage a distributed system.
- Built a kind of Rails scaffolding, but for services. A template is used to bootstrap services internally.
- All services look identical from an operations perspective. Checking statistics, monitoring, starting and stopping all work the same way for all services.
- Tooling is put around the build process in SBT (a Scala build tool) using plugins and helpers to take care of common activities like tagging things in git, publishing to the repository, etc. Most developers don’t have to get in the guts of the build system.
前置层使用 HAProxy. Varnish ， 40台机器.
500 台web服务器上跑着Apache和PHP应用.
200台数据库服务器，部分服务器是容灾需要；成本考虑，硬件使用MTBF。
6种后端服务支撑PHP应用。有一个小组专门来开发这种服务，每2,3周都会推出一种新的服务。包括： Includes dashboard notifications, dashboard secondary index, URL shortener, and a memcache proxy to handle transparent sharding.
MySQL足够了，所以没有用MongoDB.
Gearman , 一个工作队列系统。用来跑长时间运行的或者无需人工干预的工作。
Availability is measured in terms of reach. Can a user reach custom domains or the dashboard? Also in terms of error rate.
历史最高需求已经被搞定。现在，如果一部分需求不能满足要求，我们会从用户角度和应用角度对错误的模型进行分析和系统的处理来达到成功的目的。
最初使用了Finagle的Actor模型，后来去掉了。使用了twitter的utility library的Futures接口来处理异步的需求。
Scala鼓励不适用共享状态。Finagle 在twitter的产品中得到了很好的测试验证，在机器上无状态运行，保证了开发人员不用去担心线程和锁。
22 Redis servers. Each server has 8 – 32 instances so 100s of Redis instances are used in production.
- Used for backend storage for dashboard notifications.
- A notification is something like a user liked your post. Notifications show up in a user’s dashboard to indicate actions other users have taken on their content.
- High write ratio made MySQL a poor fit.
- Notifications are ephemeral so it wouldn’t be horrible if they were dropped, so Redis was an acceptable choice for this function.
- Gave them a chance to learn about Redis and get familiar with how it works.
- Redis has been completely problem free and the community is great.
- A Scala futures based interface for Redis was created. This functionality is now moving into their Cell Architecture.
- URL shortener uses Redis as the first level cache and HBase as permanent storage.
- Dashboard’s secondary index is built around Redis.
- Redis is used as Gearman’s persistence layer using a memcache proxy built using Finagle.
- Slowly moving from memcache to Redis. Would like to eventually settle on just one caching service. Performance is on par with memcache.

内部的Firehose(通信管道)

Internally applications need access to the activity stream. An activity steam is information about users creating/deleting posts, liking/unliking posts, etc. A challenge is to distribute so much data in real-time. Wanted something that would scale internally and that an application ecosystem could reliably grow around. A central point of distribution was needed.
Previously this information was distributed using Scribe/Hadoop. Services would log into Scribe and begin tailing and then pipe that data into an app. This model stopped scaling almost immediately, especially at peak where people are creating 1000s of posts a second. Didn’t want people tailing files and piping to grep.
An internal firehose was created as a message bus. Services and applications talk to the firehose via Thrift.
LinkedIn’s Kafka is used to store messages. Internally consumers use an HTTP stream to read from the firehose. MySQL wasn’t used because the sharding implementation is changing frequently so hitting it with a huge data stream is not a good idea.
The firehose model is very flexible, not like Twitter’s firehose in which data is assumed to be lost.
- The firehose stream can be rewound in time. It retains a week of data. On connection it’s possible to specify the point in time to start reading.
- Multiple clients can connect and each client won’t see duplicate data. Each client has a client ID. Kafka supports a consumer group idea. Each consumer in a consumer group gets its own messages and won’t see duplicates. Multiple clients can be created using the same consumer ID and clients won’t see duplicate data. This allows data to be processed independently and in parallel. Kafka uses ZooKeeper to periodically checkpoint how far a consumer has read.

Cell Design for Dashboard Inbox(业务方面的实现，未翻译)

The current scatter-gather model for providing Dashboard functionality has very limited runway. It won’t last much longer.
- The solution is to move to an inbox model implemented using a Cell Based Architecture that is similar to Facebook Messages.
- An inbox is the opposite of scatter-gather. A user’s dashboard, which is made up posts from followed users and actions taken by other users, is logically stored together in time order.
- Solves the scatter gather problem because it’s an inbox. You just ask what is in the inbox so it’s less expensive then going to each user a user follows. This will scale for a very long time.
Rewriting the Dashboard is difficult. The data has a distributed nature, but it has a transactional quality, it’s not OK for users to get partial updates.
- The amount of data is incredible. Messages must be delivered to hundreds of different users on average which is a very different problem than Facebook faces. Large date + high distribution rate + multiple datacenters.
- Spec’ed at a million writes a second and 50K reads a second. The data set size is 2.7TB of data growth with no replication or compression turned on. The million writes a second is from the 24 byte row key that indicates what content is in the inbox.
- Doing this on an already popular application that has to be kept running.
Cells
- A cell is a self-contained installation that has all the data for a range of users. All the data necessary to render a user’s Dashboard is in the cell.
- Users are mapped into cells. Many cells exist per data center.
- Each cell has an HBase cluster, service cluster, and Redis caching cluster.
- Users are homed to a cell and all cells consume all posts via firehose updates.
- Each cell is Finagle based and populates HBase via the firehose and service requests over Thrift.
- A user comes into the Dashboard, users home to a particular cell, a service node reads their dashboard via HBase, and passes the data back.
- Background tasks consume from the firehose to populate tables and process requests.
- A Redis caching layer is used for posts inside a cell.
Request flow: a user publishes a post, the post is written to the firehose, all of the cells consume the posts and write that post content to post database, the cells lookup to see if any of the followers of the post creator are in the cell, if so the follower inboxes are updated with the post ID.
Advantages of cell design:
- Massive scale requires parallelization and parallelization requires components be isolated from each other so there is no interaction. Cells provide a unit of parallelization that can be adjusted to any size as the user base grows.
- Cells isolate failures. One cell failure does not impact other cells.
- Cells enable nice things like the ability to test upgrades, implement rolling upgrades, and test different versions of software.
The key idea that is easy to miss is: all posts are replicated to all cells.
- Each cell stores a single copy of all posts. Each cell can completely satisfy a Dashboard rendering request. Applications don’t ask for all the post IDs and then ask for the posts for those IDs. It can return the dashboard content for the user. Every cell has all the data needed to fulfill a Dashboard request without doing any cross cell communication.
- Two HBase tables are used: one that stores a copy of each post. That data is small compared to the other table which stores every post ID for every user within that cell. The second table tells what the user’s dashboard looks like which means they don’t have to go fetch all the users a user is following. It also means across clients they’ll know if you read a post and viewing a post on a different device won’t mean you read the same content twice. With the inbox model state can be kept on what you’ve read.
- Posts are not put directly in the inbox because the size is too great. So the ID is put in the inbox and the post content is put in the cell just once. This model greatly reduces the storage needed while making it simple to return a time ordered view of an users inbox. The downside is each cell contains a complete copy of call posts. Surprisingly posts are smaller than the inbox mappings. Post growth per day is 50GB per cell, inbox grows at 2.7TB a day. Users consume more than they produce.
- A user’s dashboard doesn’t contain the text of a post, just post IDs, and the majority of the growth is in the IDs.
- As followers change the design is safe because all posts are already in the cell. If only follower posts were stored in a cell then cell would be out of date as the followers changed and some sort of back fill process would be needed.
- An alternative design is to use a separate post cluster to store post text. The downside of this design is that if the cluster goes down it impacts the entire site. Using the cell design and post replication to all cells creates a very robust architecture.
A user having millions of followers who are really active is handled by selectively materializing user feeds by their access model (see Feeding Frenzy).
- Different users have different access models and distribution models that are appropriate. Two different distribution modes: one for popular users and one for everyone else.
- Data is handled differently depending on the user type. Posts from active users wouldn’t actually be published, posts would selectively materialized.
- Users who follow millions of users are treated similarly to users who have millions of followers.
Cell size is hard to determine. The size of cell is the impact site of a failure. The number of users homed to a cell is the impact. There’s a tradeoff to make in what they are willing to accept for the user experience and how much it will cost.
Reading from the firehose is the biggest network issue. Within a cell the network traffic is manageable.
As more cells are added cells can be placed into a cell group that reads from the firehose and then replicates to all cells within the group. A hierarchical replication scheme. This will also aid in moving to multiple datacenters.

团队结构

Teams: 技术设施, 平台开发，架构, SRE （侧重可靠性和可拓展性方面的问题解决）, 产品, 测试, services（趋向于战略研究）.

软件部署

开发一套rsync脚本来部署PHP，当机器超过200台的时候出现各种状态问题。
接下来，使用Capistrano（一个开源工具，可以在多台服务器上运行脚本）在服务堆栈中构建部署进程（开发、分期、生产）。在几十台机器上部署可以正常工作，但当通过SSH部署到数百台服务器时，再次失败。
现在，所有的机器上运行一个协调软件。基于Redhat Func（一个安全的、脚本化的远程控制框架和接口）功能，一个轻量级的API用于向主机发送命令，以构建扩展性。
建立部署是在Func的基础上向主机发送命令，避免了使用SSH。比如，想在组A上部署软件，控制主机就可以找出隶属于组A的节点，并运行部署命令。
部署命令使用Capistrano来实现。使用http的方式从git从库上来检出和上传。
Func API用于返回状态报告，报告机器上的软件版本号
安全重启任何服务，因为他们先关闭连接，然后重启。
所有功能在激活前都运行dark mode下

开发

从哲学上将，任何人都可以使用自己想要的任意工具。但随着团队的发展壮大，这些工具出现了问题。新员工想要更好地融入团队，快速地解决问题，必须以他们为中心，建立操作的标准化。
过程类似于Scrum（一种敏捷管理框架），非常敏捷。
每个开发人员都有一台预配置的开发机器，并按照控制更新。
开发机会出现变化，测试，分期，乃至用于生产。
开发者使用VIM和TextMate。
测试是对PHP程序进行代码审核。
在服务方面，他们已经实现了一个与提交相挂钩的测试基础架构，接下来将继承并内建通知机制。

招聘流程

面试通常避免数学、猜谜、脑筋急转弯等问题，看重实际工作技能。
编程能力是重中之重。
找到合适的人，不是比较人
挑战在于找到具有可用性、扩展性经验的人才，以应对Tumblr面临的网络拥塞。
- Example, for a new ID generator they needed A JVM process to generate service responses in less the 1ms at a rate at 10K requests per second with a 500 MB RAM limit with High Availability. They found the serial collector gave the lowest latency for this particular work load. Spent a lot of time on JVM tuning.

Lessons learned

无处不在的自动化。
MySQL 添加水平分区, 应用则不需要。
Redis是惊人的（是不是提醒大家用一下）。
Scala应用程序执行效率和出色。
取消不能工作的项目。
雇佣的人不要因为他们有对团队无用的技能，雇佣的人应该适应团队和工作。
找到帮你找到合适人的stack
围绕团队技能开展工作
阅读论文和博客
多与同行交流
技术追求需要循序渐进。在正式投入使用前，Tumblr用心研究HBase和Redis ，这样可以降低线上服务风险。

作者：heiyeshuwu 发表于2012-3-17 20:48:29 原文链接

阅读：394 评论：0 查看评论

[转][转]使用Go语言一段时间的感受

heiyeshuwu — Sat, 17 Mar 2012 20:04:54 +0800

作者：Windstorm

来源：http://www.kunli.info/2012/03/03/golang-feeling/

有一段时间没更新了。最近在忙一个Server+Client的项目，Client是Android手机，大概也就是几十的规模。Server是纯Golang实现，没有apache或者ngix这种web server，也没有数据库，自己写了个文件管理module，handle这种小规模的服务没问题。算下来接触Golang也有四个多月了，断断续续写了一些东西，这里纪录一下心得吧

先大概说下为什么用Golang。我是一个对语言有洁癖的人，曾经是一个c+Python的坚定呐喊者，最常说的一句话就是，只要熟练这两种，什么情况都能应付，根本不用Java和C++(纯指我所在的领域）。核心代码用c，速度快，需要记的语言细节少；外围用Python glue，灵活，简洁，任何模块都容易上手，绝配。Java的繁琐，C++的无数无用的特性，都让我只在不得不用的时候才去用。Objective-C是另一个我欣赏的语言，问题是不跨平台，过于封闭。

可惜的是，在这个节奏极快的时代，不是所有情况下都适合上c。之前有一个项目也是类似的架构和规模，为了节省时间，当初几乎没有服务器平台编程经验的我，在服务器端选择用Django+Apache+MySQL做，成熟，社区活跃，又是python作为主要开发语言，这些都是这个选择的原因。说实话，几个月过去后，回首看，这不是一个愉快的经历。Django是一个好架构，大而全，而大而全有时也就意味着臃肿，五花八门的配置，过紧的模块耦合对引入第三方工具限制颇多，自带的ORM又不好用。之前从来没有搞过服务器配置的我，对Apache的配置和效率所带来的琐碎的东西也头疼。总的来说这个部分花了我很多时间，有新手学习服务器编程的必经过程，也有折腾Django和Apache没必要的时间浪费，很大部分上抵消了Python带来的快速开发的灵活性。而一旦服务器上线，动态语言带来的一些bug又会让人头疼。对于普通高校实验室这种没有完善的服务器调试的条件，基本就是改了就上线用，有些隐蔽bug到某些条件分支才会触发，一旦在运行中途出问题，改起来也麻烦。

从那时起，我就特别想，要是有一种语言能把c和Python的优点结合起来，也就是说

速度快，高性能
简洁明了，需要记的语言细节少，开发迅速(c)
灵活，开发快速，类Python的list，map等常用数据结构支持(Python)
完善的模块支持，模块也容易上手(Python)
对程序员友好的并行架构(Erlang)
安全，绝大部分问题能消灭在compile time中(C minus pointer)

那基本就是系统级和网络级编程最对我胃口的语言了。然后我就找到了Go。

Golang是一个新语言，截至目前为止，第一版正式版还没有发布。Golang的设计者是Robert Griesemer, Rob Pike和Ken Thompson，当年设计C和Unix，后来的Plan9团队中的人。Golang的设计理念很明确，就是将动态类型语言的编程容易度和静态类型语言的安全效率结合起来。如果你想更深入了解Golang的发展历史以及完整的目标，请参考Golang FAQ。

当然，Golang吸引我的地方，不是因为其是Google出品，也不是因为其设计者皆为大牛，而是因为，Golang真的做到了它所宣称的目标。Golang就如同C和Python中间的完美结合，如果你是Python爱好者，又追求代码的速度和并行化，那么简单说，Golang就是为你设计的。Golang有很浓厚的C的遗风，尽量屏蔽C++和Java的影响，比如没有独立的OO体系（并不是说不能OO），一切以struct为中心，没有exceptions(Oh yes!)，仍然有指针，等等。但是，Golang又吸取了很多新语言的精华，并带有自己独特的设计。比如

1. 保留但大幅度简化指针

Golang保留着C中值和指针的区别，但是对于指针繁琐用法进行了大量的简化，引入引用的概念。所以在Golang中，你几乎不用担心会因为直接操作内寸而引起各式各样的错误。

2. 多参数返回

还记得在C里面为了回馈多个参数，不得不开辟几段指针传到目标函数中让其操作么？在Go里面这是完全不必要的。而且多参数的支持让Go无需使用繁琐的exceptions体系，一个函数可以返回期待的返回值加上error，调用函数后立刻处理错误信息，清晰明了。

3. Array，slice，map等内置基本数据结构

如果你习惯了Python中简洁的list和dict操作，在Golang中，你不会感到孤单。一切都是那么熟悉，而且更加高效。如果你是C++程序员，你会发现你又找到了STL的vector 和 map这对朋友。

4. Interface

Golang最让人赞叹不易的特性，就是interface的设计。任何数据结构，只要实现了interface所定义的函数，自动就implement了这个interface，没有像Java那样冗长的class申明，提供了灵活太多的设计度和OO抽象度，让你的代码也非常干净。千万不要以为你习惯了Java那种一条一条加implements的方式，感觉还行，等接口的设计越来越复杂的时候，无数Bug正在后面等着你。

同时，正因为如此，Golang的interface可以用来表示任何generic的东西，比如一个空的interface，可以是string可以是int，可以是任何数据类型，因为这些数据类型都不需要实现任何函数，自然就满足空interface的定义了。加上Golang的type assertion，可以提供一般动态语言才有的duck typing特性，而仍然能在compile中捕捉明显的错误。

5. OO

Golang本质上不是面向对象语言，它还是过程化的。但是，在Golang中，你可以很轻易的做大部分你在别的OO语言中能做的事，用更简单清晰的逻辑。是的，在这里，不需要class，仍然可以继承，仍然可以多态，但是速度却快得多。因为本质上，OO在Golang中，就是普通的struct操作。

6. Goroutine

这个几乎算是Golang的招牌特性之一了，我也不想多提。如果你完全不了解Goroutine，那么你只需要知道，这玩意是超级轻量级的类似线程的东西，但通过它，你不需要复杂的线程操作锁操作，不需要care调度，就能玩转基本的并行程序。在Golang里，触发一个routine和erlang spawn一样简单。基本上要掌握Golang，以Goroutine和channel为核心的内存模型是必须要懂的。不过请放心，真的非常简单。

7. 更多现代的特性

和C比较，Golang完全就是一门现代化语言，原生支持的Unicode, garbage collection, Closures(是的，和functional programming language类似), function是first class object，等等等等。

看到这里，你可能会发现，我用了很多轻易，简单，快速之类的形容词来形容Golang的特点。我想说的是，一点都不夸张，连Golang的入门学习到提高，都比别的语言门槛低太多太多。在大部分人都有C的背景的时代，对于Golang，从入门到能够上手做项目，最多不过半个月。Golang给人的感觉就是太直接了，什么都直接，读源代码直接，写自己的代码也直接。

有朋友要抗议了，你把Golang吹的这么好，难道它就没有缺点？有，当然有，不过和它的优点比，我觉得很多缺点都是因为整个语言太新，不成熟，随着时间的推移都能得到解决，相比之下都能忍了。如果你希望进一步了解Golang的优缺点，可以参考以下yufeng写的这篇文章，系统编程语言明日之星—Go（http://blog.yufeng.info/Go.pdf。

还有朋友要说，Golang这么好，为什么没人用？我想说，眼界放开点，这个世界精彩的东西比你想象的多。Golang被Google用于Youtube的数据库，被越来越多的国外公司(大部分创业公司)用于后端开发，甚至在天朝，也有完全用Golang做服务开发的云应用公司了。可以说，随着Go 1即将到来的正式推出，Golang的使用范围，应该会越来越广。

好，总结时间

如果你是Python和动态语言狂热爱好者，Go不一定能给你带来很大的惊喜，这纯粹取决于你得项目性质，考虑到Python目前在很多地方都用C做核心运算，速度在大部分情况下都不是大问题。scalability是一个问题，但并不是人人都会遇到的。

如果你是C爱好者，强烈建议你学习和使用Go。Go可以调用C/C++程序，又提供了太多的便利，速度上稍有牺牲，但并不大。在绝大部分场景下Go能给你带来媲美C的性能，而对于某些确实性能过于关键的场合，也可以通过cgo让Go和C搭配。

如果你是Java爱好者，除非你是做Android这种不得不用Java的平台，否则也建议你尝试学习Go，这个开发上感觉的差异如同比较开载着1吨石头的拖拉机和开保时捷911那么明显，而Java能给你的，Go能给得更好。

如果你是C++爱好者，!@#$%^&*，恭喜你，至少你的智商应该是没问题的。人生苦短，赶紧脱离C++这个苦海吧。你用来学89个C++高级特性的时间，估计已经用Go写了64个开源项目了。

如果你是像我一样的C和Python的爱好者，对动态语言又没有特殊的热爱……我还需要说什么呢？

让我们荡起双桨，去遨游Golang的海洋吧。

作者：heiyeshuwu 发表于2012-3-17 20:04:54 原文链接

阅读：486 评论：0 查看评论

[转][转]使用 PHP 直接在共享内存中存储数据集

heiyeshuwu — Sat, 17 Mar 2012 11:59:17 +0800

来源：http://www.ibm.com/developerworks/cn/opensource/os-php-shared-memory/

概述

共享内存是一种在相同机器中的应用程序之间交换数据的有效方式。一个进程可创建一个可供其他进程访问的内存段，只要它分配了正确的权限。每个内存段拥有一个惟一的 ID（称为 shmid），这个 ID 指向一个物理内存区域，其他进程可在该区域操作它。创建并提供了合适的权限之后，同一台机器中的其他进程就可以操作这些内存段：读取、写入和删除。

这表明使用 C 语言编写的应用程序可与使用其他语言（比如 Java™ 或 PHP）编写的应用程序共享信息。它们都可以共享信息，只要它们可访问和理解该信息。共享内存在针对大部分语言的实现中得到了广泛使用，所以访问应该不是问题。要理解信息，我们可以使用一种标准格式，比如 XML 或 JSON。

共享内存的使用是一种在进程之间交换数据的快速方法，主要因为在创建内存段之后传递数据，不会涉及内核。这种方法常常称为进程间通信 (IPC)。其他 IPC 方法包括管道、消息队列、RPC 和套接字。当使用需要彼此通信的应用程序的生态系统时，这种在应用程序之间快速、可靠地交换数据的能力非常有用。取决于生态系统的大小，使用数据库在应用程序之间交换信息的常用方法常常会导致查询缓慢，甚至 I/O 阻塞。使用共享内存，没有 I/O 会减缓开发人员的进度。

本文的提议非常简单，学习如何使用 PHP 创建和操作共享内存段，使用它们存储可供其他应用程序使用的数据集。即使没有使用共享内存交换数据的计划，它本身也在许多好处，因为它使应用程序能够远离 I/O 问题。将数据集直接存储在内存中具有诸多优势，从 Web 服务数据缓存到会话共享。它是一个非常有用的概念，每个 PHP 开发人员都应该知道。

共享内存和 PHP

PHP 拥有丰富的可用扩展，共享内存也一样。使用一些共享的函数，无需安装任何扩展，开发人员就能够轻松操作内存段。

方法	用途
`$.mobile.changePage`	以编程方式从一个页面切换到另一个页面。例如，要使用一个幻灯片过渡切换到页面 weblog.php，使用`$.mobile.changePage("weblog.php", "slide")`。
`$.mobile.pageLoading`	显示或隐藏页面加载消息。例如，要隐藏消息，使用 `$.mobile.pageLoading(true)`。
`$.mobile.silentScroll`	滚动到一个特殊的 Y 位置，不生成滚动事件。例如，要滚动到 Y 位置 100，使用 `$.mobile.silentScroll(100)`。
`$.mobile.addResolutionBreakpoints`	jQuery Mobile 已经为 `min/max` 类定义了一些断点。调用这个方法来增加断点。例如，要为 800 像素宽度添加 `min/max` 类，使用`$.mobile.addResolutionBreakpoints(800)`。
`$.mobile.activePage`	引用当前活动页面。

元素	HTML5 data-* 属性
页眉、页脚工具栏	<div data-role="header"> <div data-role="footer">
主体内容	<div data-role="content">
按钮	<a href="index.html" data-role="button" data-icon="info">Button</a>
已编组按钮	<div data-role="controlgroup"> <a href="index.html" data-role="button">Yes</a> <a href="index.html" data-role="button">No</a> <a href="index.html" data-role="button">Hell Yeah</a> </div>
内联按钮	<div data-inline="true"> <a href="index.html" data-role="button">Foo</a> <a href="index.html" data-role="button" data-theme="b">Bar</a> </div>
表单元素（选择菜单）	<div data-role="fieldcontain"> <label for="select-options" class="select">Choose an option:</label> <select name="select-options" id="select-options"> <option value="option1">Option 1</option> <option value="option2">Option 2</option> <option value="option2">Option 3</option> </select> </div>
基本列表视图	<ul data-role="listview"> <li><a href="index.html">One</a></li> <li><a href="index.html">Two</a></li> <li><a href="index.html">Three</a></li> </ul>
对话框	<a href="foo.html" data-rel="dialog">Open dialog</a> <a href="dialog.html" data-role="button" data-inline="true" data-rel="dialog" data-transition="pop">Open dialog</a>
过渡	<a href="index.html" data-transition="pop" data-back="true">

I/O	CPU Cycle
L1-cache	3
L2-cache	14
RAM	250
Disk	41000000
Network	240000000