“我的孩子总喜欢缠着我，问我离圣诞节还有几天。通常这并没有那么容易能算出来，但现在你所要做的仅仅是询问你的手机。”

四个月多前，在位于加州库比蒂诺（Cupertino）的苹果公司（Apple Inc.）总部，公司的高级副总裁 Scott Forstall 兴致勃勃地向全世界展示着他们引以为傲的智能助手 Siri。他长按手中 iPhone 4S 的 HOME 键，对着那个泛着紫色神秘光晕的话筒问道：

“现在离圣诞节还有几天？”

“让我查查……稍等……我为你找到了答案。”

一阵紧张的云计算过后，Scott 得到了他想要的答案：“82 天，也就是 2 个月又 21 天，也就是 11 周零 5 天，也就是 58 个工作日，也就是 0.22 年。”

就是从那一刻起，才让许多人听说了 Wolfram Alpha 这款智能搜索引擎的大名。

事实上，Wolfram Alpha 同苹果公司并没有太大的关系。它的创始人 Stephen Wolfram 将其定义为一款“专业的知识搜索引擎”。今年 52 岁的 Stephen Wolfram 是一名具有传奇色彩的科学家、软件设计师和创业者——他 15 岁时发表了自己的第一篇物理学论文，20 岁时获得加州理工学院（California Institute of Technology）的博士学位，22 岁时则被授予了美国跨领域最高奖项之一的麦克阿瑟奖（MacArthur prize）。

Stephen Wolfram 在 2009 年宣布了 Wolfram Alpha 的计划，它的第一版是用约五百万行的 Mathematica 代码编写的，并且在 10000 个中央处理器上运行。2010 年，在加州的长滩市（Long Beach）的 TED 大会上，Stephen Wolfram 向众人揭示了 Wolfram Alpha 计划的缘由。

（手机用户点此）

好了，其实你根本不需要知道这些的。你所要做的，就是将一连串的问题输入 Wolfram Alpha 的对话框，等着它以最人性化的方式将简洁规范的答案呈现给你。下面是几个例子。

• 你是 NFL（美国橄榄球联盟）的忠实拥趸？想查查今年超级碗交战双方的历史战绩？

• 你是天文爱好者？想知道国际空间站此刻运行到了哪里？

• 还在用纸和笔进行数学计算吗？Wolfram Alpha 的数学、物理学运算能力足以让学生抛弃任何一款 TI 计算器。

  

• 身处异国他乡，急于了解眼前的这件商品若换成是本国的货币则价值几何？Wolfram Alpha 非但会告诉你货币换算结果，甚至还会显示出这两种货币的兑换汇率的历史走势图。

• 又或者，当你望着窗外，犹豫着今天出门到底要不要擦防晒霜的时候，Wolfram Alpha 已经自动根据你的 IP 地址抓取到了你所在区域的实时 UV 指数。

• 当你问：“什么是生命、宇宙与万事万物的终极解答”的时候，没错，Wolfram Alpha 也会告诉你这个出自道格拉斯·亚当斯的小说《银河系漫游指南》的经典答案：“42。”

事实证明，选择与苹果公司合作并为 Siri 提供搜索支持，属于 Wolfram Alpha 非常明智的一项决定——《纽约时报》最近的一项报道指出，目前 Wolfram Alpha 处理的数据流量中有 25% 都是由 Siri 带来的。此前，Wolfram Alpha 早已与微软公司（Microsoft Corporation）建立合作关系，为搜索引擎 Bing 提供运算支持。

三年前当 Wolfram Alpha 面世的时候，因其“直接提供最佳解决方案而非链接”的设计初衷而被许多评论家称为“Google 杀手”并寄予厚望。为此，科技媒体 CNET 曾特地对它进行了一次测评，将同样的关键词分别键入 Wolfram Alpha 和 Google 的搜索栏，由反馈出来的搜索结果比较二者的优劣。结果显示，尽管在涉及到科学领域的搜索时 Wolfram Alpha 提供的计算结果更为精确和直观，而一旦转到诸如“今日影讯”之类的生活资讯类搜索范畴时，Wolfram Alpha 立刻败下阵来。

Wolfram Alpha 的计算概念固然让人浮想联翩，人们透过它也仿佛是看到了未来智能搜索引擎的雏形。但 Wolfram Alpha 未来将走哪一条路？是继续在小众的科学研究领域施展拳脚，还是飞入寻常百姓家去造福众生？这是关乎 Wolfram Alpha 使命和价值观的两难抉择，也是摆在 Stephen Wolfram 面前的一大难题。

不过，我们似乎还是能从一些事态发展上看出些许端倪。不久前，Wolfram Alpha 推出了重大更新，支持了图片导入分析功能和文档导入分析功能。同时，Wolfram Alpha 在其官方博客中给出的诸如“超级碗数据统计”、“瘦身数据分析”等实际案例也在向人们传达一个信息：Wolfram Alpha 正越来越贴近生活。

想想你现在是如何向 Google 提问的：打开 Google.com，键入一个问题或者若干关键词，习以为常地在搜索结果的第一项发现问答网站 Quora 的链接，点击链接浏览网友的历史提问和最佳解答。渐渐地你也开始意识到，这不是对于这些问题最好的解决方案。而我们现在所能期许的，就是终有一天，能见到一个真正脱胎换骨的 Wolfram Alpha——它将不再是 Frankenstein（科学怪人）手中的玩物，而是我们每个普通人坐言起行的生活伴侣。

本文题图来自 Wolfram Alpha 的官方博客

周 宗珉 (John Chow)

在汽车出现以前，你去问消费者需要什么，他们都会告诉你：“一匹更快的马。”——福特

所在地 邮箱 Twitter Facebook 新浪微博 知乎 Google+

爱范儿 · Beats of Bits | 原文链接 · 3 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

在个人应用领域将软件变为服务，将重新定义已经沿用二十多年的软件分发流程：由制造 – 授权分发 – 使用变为制造 – 使用；而盗版软件滋生的土壤，就是传统的“授权分发”过程。当我们不需要经过这个过程就可以直接使用软件（或者服务）的时候，盗版也将不复存在。

盗版在中国

在中国，盗版猖獗是众所周知的事实。虽然近些年有些好转，但我国仍然是世界范围内的盗版重灾区。

我的前一篇文章，引起了很大的争议。不过让人觉得有趣的是，在其他科技网站或论坛，我们其实很少看到关于盗版的争论。在论坛里发一个破解版的 ipa 包，却往往能收获几百楼的“楼主好人一生平安”。

华尔街日报说，2010 年中国市场上销售的所有软件中约有 78% 属于盗版。这一数字与 2006 年的 82% 相比有所下滑，但考虑到中国 PC 市场的快速膨胀，盗版软件在中国的绝对安装数量仍然是上升趋势。2011 年的数据还没有出炉，希望我们能看到让人不那么绝望的数字。

盗版在中国仍然是一个老大难的问题。自然而然，我们会问——

如何解决盗版问题？

正如李楠所说，“利益面前，任何人的自律都不太可靠”。“免费”二字带来的诱惑，是道德无法控制的；这种情况下，法律的介入必不可少。正因如此，在法制相对健全的欧美国家，打击盗版的重手屡见不鲜。

现代人类出自同源，即使有肤色语言的差别，但人与人的基本心理活动总是相差不大的。 前段时间，法国总统府都曝出了下载盗版 FLAC 无损唱片的丑闻。而像 MegaUpload 这样血淋淋的案例，无疑可以压制住许多人偷鸡摸狗的心思。

有时我们会觉得打击盗版的法规似乎太过严酷。Twitter 上前阵子流传的漫画道出了很多人的疑惑：为盗版内容提供存储空间要判 50 年，奸杀少女才判 20 年？MegaUpload 的重判，很难说不是因为版权方的重重压力。

不仅如此，关注科技新闻的朋友应该看到过很多因为下载盗版内容而遭受牢狱之灾的案例。只是下载，并没有分享，也要被严刑峻法制裁。

在法国，对非法下载影视、音乐、游戏作品的网络用户，在经过电子邮件或挂号信件两次警告后，仍不听劝阻的，第三次警告时，将可能被强制断网最长一年，还可能被重罚30万欧元或入狱两年。

尽管有种种疑虑，对于难以抵御免费诱惑的潜在侵权人而言，严刑峻法似乎仍然要比精神文明建设有用得多。可是这样的法律，虽说确实保护了版权所有者获取合法收入的基本权利，但很明显少了点人情味，不和谐。

还有更糟的问题：在欧洲以盗版率高而臭名远扬的法国，2010 年正式施行“断网法令”之后，盗版软件比率仍然高达 45%，仅比前一年降低了 2%。尽管比起我们这块神奇的土地来说要好得太多，但是与欧盟 36% 的平均水平相比，还是相当丢脸。

靠吃牢饭来治盗版，管得了一时，管不了一世。何况不同的法律之间也有相互冲突的地方，只靠法律强制力，怎么看都不像是万全之策。既然从用户的角度而言，法律和道德都难以真正形成有效的约束，那么为何不换个角度想想呢？

上帝爱你，我们也是

怒鸟公司的 CEO Mikael Hed 前段时间发表了一段很有意思的声明：

盗版可能并不是那么糟糕，最终能够给我们带来更多业务。不要把消费者视作用户，而是将他们视作粉丝。我们正在这样做，我们总是关注我们已有多少粉丝。如果我们失去粉丝基础，我们的业务也将走到尽头。而如果我们扩大粉丝基础，我们的业务将会增长。

这就是问题的关键。盗版软件使用者们追求蝇头小利，冒着遭遇电脑病毒、木马的风险，违反一切保护版权的法律，只是为了从你那儿偷走你应得的一星半点的利润。他们偷得越多，你死得越惨；更糟的是，按照目前的情况来看，序列号、硬件锁、法律、道德乃至整个人类都已经无法阻止他们了。

但是正如 Hed 所说，他们是你的粉丝；或者说得更骚一点：他们爱你！

是的，他们爱你，就好像上帝爱你一样。他们如同圣经里描述的一般，为你设下各种各样的考验，有时让你求生不得、求死不能，甚至偶尔还会让你下地狱——但不可思议的是，他们仍然爱你，因为他们爱你的产品。

Hed 或许是第一个说出这个道理的人，但是在聪明人集聚的 IT 行业，早就已经有大无畏的小白鼠作出了尝试；被盗版弄得欲仙欲死的 Adobe，就是先行者之一。

这么多年来，Adobe 在平面设计、印刷出版行业的专业软件一直处于一流水平。但让它苦恼的是，互联网上，Adobe 系列软件的盗版下载链接简直就是浩如烟海——这让人怎么活呢？

不过，茫茫多的盗版用户也给 Adobe 带来了至少一样好处：无限扩散的影响力。现在流行一句话，叫做“影响力变现”；Adobe 于是幡然醒悟，开始利用自己在用户中的好印象，从事起服务提供商这份更有前途的职业。

iPad 面世之后，电子杂志再一次火了起来，于是 Adobe 在 2010 年底借机推出了数字出版服务（Digital Publishing Suite），跻身出版商的行列。购买一份数字出版套件，官网价格需要 $395。这份软件仍然没有 DRM 的限制，可以肆意地非法传播；但是如果想要用 Adobe 成熟的出版服务在 iPad 上发行电子杂志，那就必须每月再乖乖缴纳至少 $495 的月费。除此以外，依照预计的下载数量多寡，Adobe 还会收取每年至少 $5500 的下载费用，超额多收，上不封顶。

黑吗？黑！为什么还用？我们相信 Adobe 的实力！况且盗版用了那么多年，早就习惯了……

Photoshop 可以被盗版，Illustrator 可以被盗版，InDesign 可以被盗版，但是服务无法被盗版。多年来积累的良好口碑，让 Adobe 藉着 Pad 版电子杂志发行的一条龙服务，在电子出版行业继续一骑绝尘。只过了一年多的时间，Adobe 的官方网志上已经罗列出了 863 份以 DPS 系统创作的电子杂志 app。这意味着多少收入？真的没法算。

Adobe 已经尝到了爱情的甜蜜。盗版造成的损失？就当作是初夜的阵痛吧。

云，云，云。

云这个概念已经被说得够烂的了，可惜目前绝大多数所谓“云服务”都还停留在乔布斯所说的“a hard disk in the sky”的层面。只具有存储功能的服务并不能被称为“云”，“云”除了存储，更重要的是进行数据处理、分析、计算，以节省本地的资源。

当用户不需要再“安装”软件的时候，“盗版”也就不复存在了。我所需要的只是一套 I/O 设备和网络连接。所有的软件都将以“服务”的形式存在：想砸猪了？在 App Store 点一下怒鸟的图标，在第一次点击的时候确认付费，然后就可以无限制地直接运行云端的游戏程序。要给观众播放幻灯片了吗？打开在线的办公软件，让 keynote 直接在云端播放就行啦。

这个构想，说白了其实和近年来在企业中普遍应用的 SaaS 相差无几。但是在个人应用领域将软件变为服务，起到的作用将不仅仅是削减开支这么简单。它将重新定义已经沿用二十多年的软件分发流程：由制造 – 授权分发 – 使用变为制造 – 使用；而盗版软件滋生的土壤，就是传统的“授权分发”过程。

一般来说，软件的盗版就是指在未经版权所有人同意的情况下，对其享有版权的软件进行复制、再分发的行为；无论是用 U 盘拷贝，还是从网上下载，本质上都是一种未经授权的复制与再分发。当我们不需要经过这个过程就可以直接使用软件（或者服务）的时候，盗版也将不复存在。

现在正在流行的 Web App，以及 Google 正在完善的 WebGL，都是这个方向上的尝试；这些设想成真的日子其实并不遥远。

当然，即使这一天真的到来，世界也不会就此和平。但这篇文章只能说到这里——童话里讲到王子公主快乐地生活在一起之后，一般也就该收尾了。

关 小羽

新媒体从业者，喜欢独立思考。a.k.a. nervouna

所在地 邮箱 Twitter 知乎 Google+

爱范儿 · Beats of Bits | 原文链接 · 38 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

首先，打开你的手机摄像头。

然后，拍下手中百事可乐的照片。

最后，发送到 pepsi@pongr.com 这个邮件地址。

你就能看到所有跟“百事”有关的照片都汇集到了这个地址：http://www.pongr.com/brand/pepsi ，每个参与者都可以获得一笔虚拟金币，用金币可以兑换一些奖品。当 Pongr.com 网站上出现了各种品牌页面时，这就变成一门实实在在的生意。

从本质上说 Pongr 就是一个图片社区，它跟 Instagram ，PicPlz 最大的区别在于：

• Pongr 不需要客户端，只要你的手机拥有摄像头和邮件功能，就可以参与；
• Pongr 具有清晰的商业模式，促使品牌之间的竞争；
• Pongr 给予拍摄者以“金钱”回报。

最近 fastcompany 采访了 Pongr 的创始人 Jamie Thompson ，谈到了他的一些点子和做法。

Pongr 的客户是谁？

很明显，最终掏钱的是品牌商（或广告主）。Pongr 的第一批客户有英特尔，百事，激浪，X Factor ，他们都是舍得掏钱做广告的主儿。

拿百事来说，它的页面里汇集了 112890 张照片，有 91061 位粉丝，他们的照片还利用 Facebook 和 Twitter 来传播，等于是拥有了近十万名“广告专员”。

用到了图片识别技术吗？

是的，识别品牌和 LOGO 带来了庞大的工作量，这不可能用人工来完成。Pongr 的后台有一套识别程序，只有当照片展示出全部商标（或特定商品）时，才会被汇集到品牌页面。

这也避免一些色情照片的烦恼。

除了品牌，还是什么花样？

Pongr 最近在搞“配对”活动，就是把百事可乐和薯片拍在同一张照片里，然后发送到 match@pongr.com 邮箱，服务器程序会自动识别出有效的照片，然后展示在活动页面。

不用说，这就是百事可乐的一个营销方案，刺激用户们去购买百事。（顺便买乐事薯片）

什么是好的营销？

摆出一个丑陋的 QR 码让用户来拍摄，这绝对不是一个好的营销方式。而只有让用户真正拍摄到商品和品牌，才是最直接最有效的。

这也是商家愿意看到的局面，不知这种模式在美国之外能否流行起来。

张恒

先后在华为技术和炬力集成做码农和 PM，并在华强北摆弄过手机档口。致力移动互联网，LBS，垂直社区，新媒体观察，致力于 iSeed 访谈的推动和建设。

邮箱 Flickr 知乎 Google+

爱范儿 · Beats of Bits | 原文链接 · 3 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

每到春运，买火车票就成为头痛的事情。今年铁道部开设了网上购票，本来是件惠民的好事儿，但是由于订票网站 http://www.12306.cn，没能快速地处理用户的查询和订单，引起网友的冷嘲热讽。

@王津THU 在微博上替 12306 辩解了几句 [1]，立刻成为众矢之的。王津有点冤，首先 12306 系统的确有技术难度，初次亮相，出点洋相，在所难免。其次，王津似乎没有参与 12306 项目，大家骂错了人。

即便王津是项目负责人，大家开骂也不解决问题。今年骂完了，明年是不是接着骂？不如讨论一些有建设性的设计方案，但愿明年春运时，大家能够轻松买到车票。

有评论说，“你们这些建议都是YY，铁道部不会听你的”。

你说了，铁道部不一定会听。但是你不说，它想听也听不到。为自己，为亲友，为老百姓，说总比不说好。

又有评论说，你们这些设计，“都是大路货，没技术含量”。

12306 网站不是研究项目，而是旨在解决实际问题。此类系统的设计原则，实效是首要目标，创新是次要目标。

@简悦云风 提了个建议，分时出票，均摊流量。“卖票这种事情，整个需求量（总出票数）摆在那里在。把峰值请求压下来在时间轴上（前后要卖几百小时呢）平摊，业务量就那么点。网站被峰值请求冲挂了，只能是因为简单的问题都没处理好”[2]。

这个办法的确没有什么技术含量，但是很明快很实用，所以是值得推崇的好办法好思路。

说实话，像 12306 这样受众广大的系统，能不创新，尽量别创新。因为创新是有风险的，在 12306 网站玩创新，你是不是把上亿着急回家过年的老百姓，当成实验小白鼠了？

创新主要是学界的活儿。学界强调另辟蹊径，即便新路不如老路好走，但是或许在某某情况下，新路的办法有一定优势。如果是这样，新路仍然有存在的价值。

务虚完毕，下面务实。

一。找到核心问题。

1月12日，拙作“建设一个靠谱的火车票网上订购系统”发表后[3]，收到不少同行的反馈。归纳一下，主要有两类评论，

1. “真正的瓶颈，一般会出在数据库上，怎么解决数据的问题，才是核心”。
2.“如果大量的黄牛阻塞队列或者被DDOS攻击的情况下，普通用户会等到崩溃”。

也就是说，支付与登录是 12306 系统的两大短板。

@FireCoder 著文分析 12306 的用户体验和系统瓶颈，印证了上述两个问题。

“最难的两关是登陆和支付，这也是用户体验最糟糕的两步。登陆是最难闯的一关，验证码验证码验证码…，每次尝试等待若干时间，然后总是一个系统繁忙。这是令人着急和上火的一步。支付则是悲催的一步，订单到手，接着在 45 分钟内超时自动取消” [4]。

官方新闻报导，也证实了这两个问题很突出。

“今年购买火车票最大亮点是，可以登录 www.12306.cn 中国铁路客户服务中心，在网上订票。最新统计显示，7天内，12306网站访问用户已占全球互联网用户的 0.902%，每天点击量高达 10 亿人次。12306 网站的带宽已经从最初的400兆扩充到了1.5G，但是每天 10 亿次的点击量，仍然弥补不了网上登录和支付的短版。据了解，12306 网站正在进行后台调试，争取让订票和网上支付系统分开运行，互不交叉，避免拥堵，让整个订票支付流程更加顺畅” [5]。

二。单机与分布式。

有人问，12306 订票系统，为什么不用现成的 IBM z/TPF?

@周洪波-TSP 老师回复，“z/TPF目前仍然是集中式交易处理量最大的，不过如果每张票都要经过 TPF 做唯一性 TP 确认，z/TPF 也是远远不能达到中国铁路处理量要求，需要分布式处理和缓存（队列）技术来分散压力” [6]。

赞同周老师的观点。好汉难敌四虎，再彪悍的武士，也抵挡不住千军万马的围攻。对于中国春运这样的流量冲击，再牛的单机终归会有容量上限，所以单机基本不靠谱。

靠谱的办法，是分布式。分布式需要解决的问题，是如何切割。切割流程，切割数据。

三。横向切割流程。

拙文 [3] 讨论了把 12306 系统，按登录、查询、订票三类业务，切割成三种流程。其中查询业务，又可以再切割成三种，查询车次时间表、查询某车次余票、查询某用户订购了哪些车票。

为什么要不厌其烦地切割流程？因为不同流程的环节构成不同，不同流程用到的数据也不一样，有些是静态数据，例如车次时间表，有些是动态数据，例如余票和乘客订购的车次座位。分而治之，有利于优化效率，也有利于让系统更皮实，更容易维护。

静态数据，更新少，尽可能存放在缓存（Cache）里，读起来快，而且不给数据库添麻烦。例如车次路线和时间表查询，就应该这样处理。

只有动态数据，才必须存放在数据库中。动态数据在数据库中，存放的方式是表。例如，查询余票与订票，就必须这样处理。

四。切割数据。

在 12306 系统中，最关键的数据，是各个车次各个座位的订购状态。存放这些数据的数据格式，是订票表。

最简单的订票的表设计，或许是设置若干列（车次，日期，座位，路段1,…路段N）。例如高铁 G19，从北京始发，途径济南和南京，终点是上海，共三个路段。乘客甲，订购某日G19某座位，从北京始发，途径济南，到南京下车。乘客乙也订购了同日同车次同座位，但是从南京上车，到上海下车。那么这张表中，就会有一行，（G19，X日，Y座位，乘客甲ID，乘客甲ID，乘客乙ID）。

如果把全国所有日期的所有车次，全部集中在一个数据库实例的同一张表中，那么势必造成数据库的拥塞。所以，必须对表做切割。

@李思Samuel 建议横向切，也就是按行切，“假定现在有100张北京到上海的车票可售，如果有 10 个卫星数据库，那么在未来1秒内，每个卫星数据库各有 10 张票可售。1 秒以后，各卫星数据库向中心数据库提交本地余票量，并由中心数据库重新分配”[7]。

这个办法的确可以达到减少中心数据库负载的目的。但是顾虑是卫星数据库，必须频繁地与中心数据库同步（李思建议每一秒同步一次）。同步不仅导致内网中的数据流量加大，另外，同步需要上锁。分布式锁机制相当复杂，也容易出故障。实际运行中，搞不好会出乱子。

我的办法是纵向切，根据不同车次，以及同一个车次的不同日期，切成若干表，放进多个数据库中去。这样，每张表只有（座位，经停站1, … 经停站N）几列。假如每趟火车的载客人数不超过 5000 人，那么每张表的行数也不会超过 5000 行。

同一个车次，不同日期，分别有一张表。这样做的好处是，可以方便地实现分时出票。假如提前十天出票，今天是1月16日，那么在G19车次的数据库中，存放着1月16日到1月26日的 10 张表，今晚打烊期间，数据库清除今天的表，并转移到备份数据库中，作为历史记录。同时增添1月27日的表。明天一早开门营业时，乘客就可以预定1月27日的车票了。

把不同车次的表，分别存放在不同的数据库中去，可以有效降低在每个数据库外面，用户排队等待的时间，同时也避免了同步和上锁的麻烦。

另外，假如每趟火车的座位不超过 5000 个，每趟火车沿线停靠的车站不超过 50 个，那么每个车次数据库外面，排队订票的队列长度，不必超过 50 x 5000 = 250,000。理由是，火车上每个座位，最多被 50 位乘客轮流坐，这种极端情况，出现在每位乘客只坐一站。

五。订票流程。

图一。订票流程的异步的事件驱动的服务协作模式。
Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/12306-2.png

图一描述了订票的内部流程。例如有乘客想订两张联票，G11从北京到南京，然后D3068从南京到合肥。他从查询页面看到这两趟列车有余票，于是他点击订票。

“订票拆解”服务收到他的订票请求后，先通知“下单调度”服务，跟踪和处理该订单的后续工作，参见图中1.1和1.2。然后“订票拆解”服务分别向G11和D3068两个车次的预订队列，插入请求，分别预订两个座位，参见1.3。

G11和D3068两个车次的订票请求，在各自的预订队列中排队等待。排队结束后，G11和D3068的“预订队列”服务，分别查询各自的数据库，是否还剩余两个座位，参见2.1。

G11车次数据库收到指令后，查询订票表中，是否有两行（对应两个座位），从北京到南京途经的各个路段，对应的列的值，是否都是空。如果有，把这些值改写为订单中的乘客ID。

如果预订成功，G11车次“预订队列”服务，把订单号以及预订的座位号等等，发送给“下单调度”服务。如果没有余票，预订的座位号为空。参见2.2。

“下单调度”服务，会先后收到G11和D3068两个“预订队列”服务，发来的预订信息。只有G11和D3068都预订成功，“下单调度”服务才会指挥网站前端，显示网银下单网页，参见3.1和3.2。

弹出网银下单网页后，如果在 45 分钟内，“下单调度”服务收到网银的回执，汇款到账，那么“下单调度”服务就通知用户，订票成功，以及座位号，参见4.1。如果没有及时收到汇款，“下单调度”服务就给车次数据库发指令，让它们把预订座位相应的数据，逐一清零，参见4.2。

六。纵向切割流程。

前文中谈到流程切割，主要是按照业务类型切割，是横向切割。对于某一个业务流程，例如订票流程，还可以根据不同环节，做纵向切割。

图一描述了几个服务，分别是“订票拆解”、“下单调度”、“预订队列”、和“网银下单”。之所以是“服务”，而不是模块，是因为这些业务逻辑，各自运行在相互独立的线程上，甚至不同机器上。

在没有任务时，这些服务的线程处于等待状态。一旦接收到任务，线程被激活。所以，订票系统是异步的（Asynchronous）事件驱动的（Event-driven）的系统架构[8]。这种系统架构，在当下被称作，面向服务的系统架构（Service-Oriented Architecture，SOA）。

之所以采用面向服务的系统架构，最主要的动机是方便扩展吞吐量。

例如在图一中，“下单调度”是一个枢纽，如果流量压力太大，单个机器承受不住怎么办？采用了上述设计，只要加机器就行了，方便，有效，皮实。

七。登录流程。

除了支付是短板以外，登录也是突出问题，尤其是大量用户不断刷屏，导致登录请求虚高。

应对登录洪峰的办法，说来简单，可以放置一大排 Web Servers。每个 Web Server 只做非常简单的工作，读用户请求的前几个 Bytes，根据请求的业务类型，迅速把用户请求扔给下家，例如查询队列。

Web Server 不甄别用户是否在刷屏，它来者不拒，把用户请求（也许是刷屏的重复请求），扔给业务排队队列。队列先查询用户ID是否已经出现在队列中，如果是，那么就是刷屏，不予理睬。只有当用户ID是新鲜的，队列才把用户请求，插入队尾。

这个办法不难，但是经受住了实践考验。

例如2009年1月20日，奥巴马就任美国总统，并发表演说。奥巴马就职典礼期间，Twitter 网站每秒钟收到 350 条新短信，这个流量洪峰维持了大约 5 分钟。根据统计，平均每个 Twitter 用户被其他 120 人关注，也就是说，每秒 350 条短信，平均每条都要发送 120 次。这意味着，在这持续 5 分钟的洪峰时刻，Twitter 网站每秒钟需要发送 350 x 120 = 42,000 条短信。

Twitter 应对洪峰流量的办法，与我们的设计相似，参见拙作“解剖 Twitter，4”[9]。

有观点质疑，“Twitter 业务没有交易, 2 Phase Commit, Rollback 等概念”，所以 Twitter 的做法，未必能沿用到 12306 网站中来 [6]。

这个问题问得好，但是交易、二次确认、回放等等环节，都出现在 12306 系统的后续业务流程中，尤其是订票流程中，而登录发生在前端。

我们设计的出发点，是前端迅速接纳，但是后端推迟服务，一言以蔽之，通过增加前端 Web Servers 机器数量来蓄洪。

又有观点质疑，通过蓄洪的办法，Twitter 每秒能处理 42,000 条短信，但是 12306 面对的洪峰流量远远高过这个数量。增加更多前端 Web Servers 机器，是否能如愿地抵抗更大的洪峰呢？

每逢“超级碗 SuperBowl”橄榄球赛，Twitter 的流量就大涨。根据统计，在 SuperBowl 比赛时段内，每分钟 Twitter 的流量，与当日平均流量相比，平均高出40%。在比赛最激烈时，更高达150%以上。

面对排山倒海的洪峰流量，Twitter 还是以不变应万变，通过增加服务器的办法来蓄洪抗洪。更确切地说，Twitter 临时借用第三方的服务器来蓄洪，而且根据实时流量，动态地调整借用服务器的数量 [10]。

值得注意的是，Twitter 把借来的服务器，主要用于前端，增加 Apache Web Servers 的数量。而不是扩充后端，以便加快推送等等业务的处理速度。

这一细节，进一步证实 Twitter 的抗洪措施，与我们的相似。强化蓄洪能力，而不必过份担心泄洪能力。

Reference，

[1] “海量事务高速处理系统”是一种非常特别的系统，恳请大家不臆测不轻视类似 12306 系统的难度。

http://weibo.com/2484714107/y0i3b53dd

[2] @简悦云风 的微博

http://weibo.com/deepcold

[3] 建设一个靠谱的火车票网上订购系统

http://blog.sina.com.cn/s/blog_46d0a3930100yc6x.html

[4] 12306 的问题

http://blog.csdn.net/firecoder/article/details/7197959

[5] 铁道部订票网站或分开运行订票与支付系统

http://news.qq.com/a/20120116/000024.htm

[6] @周洪波-TSP 的微博

http://weibo.com/iotcloud

[7] @李思Samuel 的微博

http://weibo.com/u/1400321871

[8] SEDA: An Architecture for Well-Conditioned,Scalable Internet Services

http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf

[9] 解剖 Twitter，4 抗洪需要隔离

http://blog.sina.com.cn/s/blog_46d0a3930100fd5c.html

[10] 解剖 Twitter，6 流量洪峰与云计算

http://blog.sina.com.cn/s/blog_46d0a3930100fgin.html

爱范儿 · Beats of Bits | 原文链接 · 23 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

昨天，2012年1月11日，网友 @fenng 写了一篇文章，批评铁道部火车票网上订购系统，http://www.12306.cn ^[1]。同时在新浪发了一条言辞激烈的微博，“去你妈的‘海量事务高速处理系统’”，引起热议 ^[2]。

春节将到，大家买不着车票，赶不上大年三十与家人团聚，急切心情可以理解。但是拍桌子开骂，只能宣泄情绪，解决不了实际问题。

开发一套订票系统并不难，难在应对春运期间，日均 10 亿级别的洪峰流量。日均 10 亿级别的洪峰请求，在中国这个人口全球第一大国，不算稀罕，不仅火车票订票系统会遇到，而且电子商务在促销时，也会遇到，社交网站遇到新闻热点时，也会遇到。

所以，能够在中国成功运行的云计算系统，推广到全球，一定也能成功。但是在美国成功运行的云计算系统，移植到中国，却不一定成功。

如果我们能够设计建造一套，稳定而高效的铁路订票系统，不仅解决了中国老百姓的实际问题，而且在全球高科技业界，也是一大亮点，而且是贴着中国标签的前沿科技的亮点。

于是软件工程师们献计献策，讨论如何改进 12306 网上购票系统 ^[3]。其中比较有代表性的，有两篇 ^[4,5]。

网友的评论中，有观点认为，[4] 利用“虚拟排队”的手段，将过程拉长负载降低，是网游的设计思路。而 [5] 利用缓存技术，一层层地降低系统负荷, 是互联网的设计思路。

个人认为，[4] 和 [5] 并不是相互排斥的两种路线，两者着重解决的问题不同，不妨结合起来使用，取长补短。下面介绍一下我们的设计草案，追求实用，摈弃花哨。抛砖引玉，欢迎拍砖。

图一。12306.cn 网站系统架构设想图。

Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/12306.png

图一是系统架构图，典型的“展现层”/ “业务层”/ “数据层”的三段论。

用户接入有两类，一个是运行在电脑里的浏览器，例如 IE，另一个是手机。

无论用户用电脑浏览器，还是手机访问 http://www.12306.cn 网站，用户请求首先被网站的负载均衡器接收。负载均衡器连接着一群门户服务器，根据各个门户服务器的负载轻重，负载均衡器把用户请求，转发到某一相对清闲的门户服务器。

门户服务器的任务类似于收发室老头儿，它只读每个用户请求的前几个 bytes，目的是确定用户请求的类型，然后把请求投放到相应类型的队列中去。门户服务器的处理逻辑非常简单，这样做的好处，是让它能够快速处理大批量用户请求。

根据 [5] 的分析，12306 处理的用户请求，大致分为三类，

1. 查询。用户订票前，查询车次以及余票。用户下订单后，查询是否已经订上票。
2. 订票，包括确定车次和票数，然后付款。用户付款时，需要在网银等网站上操作。
3. 第一次访问的用户，需要登记，包括姓名和信用卡等信息。

三类请求的业务处理过程，被分为两个阶段，

1. 运行于缓存中的任务队列。设置队列的目的，是防止处理过程耗时太长，导致大量用户请求拥塞于门户服务器，导致系统瘫痪。

2. 业务处理处理器，对于每一类业务，分别有一群业务服务器。不同业务的处理流程，各不相同。

图二。12306.cn 网站查询和订票业务流程设想图。
Courtesy http://i879.photobucket.com/albums/ab351/kan_deng/12306-1.png

图二描述了查询和订票，两个业务的处理流程。登记业务流程从略。

查询的业务流程，参见图二上半部，分五步。这里有两个问题需要注意，

1. 用户发出请求后，经过短暂的等待时间，能够迅速看到结果。平均等待时间不能超过 1 秒。

2. 影响整个查询速度的关键，是“查询服务器”的设计。

查询任务可以进一步细化，大致分成三种。

1. 查询车次和时间表，这是静态内容，很少与数据库交互，数据量也不大，可以缓存在内存中。

车次和时间表的数据结构，不妨采用 Key-Value 的方式，开发简单，使用效率高。Key-Value 的具体实现有很多产品，[5] 建议使用 Redis。

这些是技术细节，不妨通过对比实验，针对火车票订票系统的实际流量，以及峰值波动，确定哪一个产品最合适。

2. 查询某一班次的剩余车票，这需要调用数据库中不断更新的数据。

[5] 建议把剩余车票只分为两种，“有”或“无”，这样减少调用访问数据库的次数，降低数据库的压力。但是这样做，不一定能够满足用户的需求，说不定会招致网友的批评讥讽。

[4] 建议在订票队列中，增加测算订票队列长度的功能，根据订票队列长度以及队列中每个请求的购票数量，可以计算出每个车次的剩余座位。如果 12306.cn 网站只有一个后台系统，这个办法行之有效。

但是假如 12306.cn 网站采用分布式结构，每个铁路分局设有子系统，分别管理各个铁路分局辖区内的各个车次。在分布式系统下，这个办法面临任务转发的麻烦。不仅开发工作量大，而且会延长查询流程处理时间，导致用户长久等待。

3. 已经下单的用户，查询是否已经成功地订上票。

每个用户通常只关心自己订的票。如果把每个用户订购的车票的所有内容，都缓存在内存里，不仅非常耗用内存空间，内存空间使用效率低下，更严重的问题是，访问数据库过于频繁，数据量大，增大数据库的压力。

解决上述分布式同步，以及数据库压力的两个问题，不妨从订票的流程设计和数据结构设计入手。

假如有个北京用户在网上订购了一套联票，途经北京铁路局和郑州铁路局辖区的两个车次。用户从北京上网，由北京铁路局的子系统，处理他的请求。北京铁路局的订票服务器把他的请求一分为二，北京铁路局的车次的订票，在北京子系统完成，郑州铁路局的车次在郑州子系统完成。

每个子系统处理四种 Key-Value 数据组。

1. 用户ID：多个 (订单ID)s。
2. 订单ID：多个 (订票结果ID)s。
3. 订票结果ID:  一个 (用户ID，车次ID)。
4. 车次ID：一个(日期)，多个 (座位，用户ID)。

北京订票服务器完成订票后，把上述四个数据组，写入北京子系统的数据库，同时缓存进北京的查询服务器，参见图二下半部第6步和第7步。

郑州订票服务器完成订票后，把上述四个数据组，写入郑州子系统的数据库，同时缓存进北京的查询服务器，而不是郑州的服务器。

让订票服务器把订票数据，同时写入数据库和查询服务器的缓存，目的是让数据库永久保留订票记录，而让大多数查询，只访问缓存，降低数据库的压力。

北京用户的订票数据，只缓存在北京的查询服务器，不跨域缓存，从而降低缓存空间的占用，和同步的麻烦。这样做，有个前提假设，查询用户与订票用户，基本上是同一个人，而且从同一个城市上网。

但是这里有个缺陷，某用户在北京上网订了票。过了几天，他在北京上网，输入用户ID和密码后，就会看到他订购的所有车票。可是又过了几天，他去了郑州，从郑州上网，同样输入用户ID和密码，却看不到他订购的所有车票。

解决这个缺陷的办法并不麻烦，在用户查询订票信息时，需要注明订票地点，系统根据订票地点，把查询请求转发到相应区域的子系统。

另外，每次订票的时候，网站会给他的手机发送短信，提供订票信息，参见图二下半部第8步和第9步。

以上是一个初步设计，还有不少细节需要完善，例如防火墙如何布置等等。这个设计不仅适用于单一的集中式部署，而且也适合分布式部署。

或许有读者会问，为什么没有用到云计算？其实上述架构设计，为将来向云计算演变，留下了伏笔。

在上述架构设计中，我们假定每个环节需要用多少服务器，需要多大容量的数据库，预先都已经规划好。但是假如事先的规划，低于实际承受的流量和数据量，那么系统就会崩溃。所以，事先的规划，只能以峰值为基准设立。

但是峰值将会是多少？事先难以确定。即便能够确定峰值，然后以峰值为基准，规划系统的能力，那么春运过后，就会有大量资源冗余，造成资源浪费？

如何既能抗洪，又不造成资源浪费？解决方案是云计算，而且目前看来，除了云计算，没有别的办法。

Reference，

[1] 海量事务高速处理系统。

http://www.douban.com/note/195179318/

[2] 去你妈的‘海量事务高速处理系统’。

http://weibo.com/1577826897/y0jGYcZfW

[3] 火车订票系统的设想。

http://weibo.com/1570303725/y0l9Y2mwE

[4] 铁路订票系统的简单设计。

http://blog.codingnow.com/2012/01/ticket_queue.html

[5] 铁路订票网站个人的设计浅见。

http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html

题图来自 Designyoutrust

爱范儿 · Beats of Bits | 原文链接 · 95 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

阳光穿过玻璃窗，照进室内，照在人身上，暖洋洋的，甚至有点痒，说不出的舒服。我双手捧着茶杯，前倾着身子，聆听坐在对面的前辈，讲解什么是格局。

我们的话题是互联网产业的竞争格局，这个话题太大，所以首先谈的是网络的竞争格局。

前辈说，什么叫格局？举个例子。

例如辽沈战役那会儿，锦州拿下后，四野腾出手来，全力以赴对付廖耀湘兵团。但是廖兵团是东退沈阳，还是南逃营口，谁也说不准。

黄永胜麾下四野六纵，负责阻击，林彪给黄的命令是，不惜一切代价，坚决堵住廖耀湘兵团的退路，等待攻锦主力赶到后，围歼廖耀湘。于是，黄永胜命令部队急行军，迅速抢占一切可以阻击敌人的制高点，坚决挡住廖兵团。

这种漫天撒网的布局，有个缺陷，就是处处设防，但是处处薄弱。果然，最激烈的厉家窝棚一战，126师有9个连，撤出战斗时，只剩10来个人。

黄永胜部队急行军的时候，关闭了电台，与东总司令部联系中断。六纵行踪不明，如果没有堵住廖耀湘兵团怎么办？四野参谋长刘亚楼拍着桌子说，“这个黄永胜搞的什么名堂，误了事非杀他头不可！”

廖兵团被黄永胜截住了，刘亚楼不拍桌子了，改拍手，“这个黄永胜，真有一手！”^[1]

说完这个故事，前辈说，“知彼知己，百战不殆。黄永胜堵截廖耀湘的时候，一定非常想知道廖兵团的兵力分布和运动方向。我们今天谈网络格局，首先需要做的功课是，中国网络的参与各方，各自分布在哪些区域”。

中国网络格局，目前只有一些大致的描述，但是似乎还没有详尽的全景图。

但是绘制这张全景图, 办法还是有的。

1998 年 12 月美国“连线”杂志，刊登了一幅图片，如图一所示 ^[2]。杂志解释说，这是贝尔实验室的研究员和CMU毕业生，绘制的网络全景图。所谓网络全景图，实际上是网络中所有公开的路由器，与相互之间的网络连线，所构成的地图。图中点（路由器）和线（网络连线）的颜色，代表这个路由器和这段网络，属于哪一家运营商。

图一。网络全景图，1998 年 9 月^[2]。
Courtesy http://imgur.com/rF7Lz

当我们仔细端详这张地图的时候，有几个疑问。

1. 全景图上的每一个点，实际上代表一个网络路由器。每个路由器都有明确的地理位置，但是全景图上却没有标注。而且从这张全景图，完全看不出地球的地缘和地貌，看不出哪里是美国，哪里是中国。这是为什么？

2. 这张全景图，真的绘制了全球所有的路由器，以及路由器与路由器相互之间的所有连线了吗？

3. 如何知道每个路由器，各自属于哪一家运营商？

关于这种全景图是如何绘制出来的，贝尔实验室的研究员写过一段简短的说明 ^[3]。

“网络绘图程序，陆续发送一些 UDP 数据包，或者 ICMP Ping 数据包，给随机的高位端口。每个数据包的生存时间（Time-to-Live，TTL），数据包没经过一个路由器，TTL 就缩短一段。当 TTL 的值为零的时候，数据包死亡的消息，就按原路，通知发送的人，（即我们的网络绘图程序）。我们并不指望这些数据包，能够到达运行中的网站，更不指望他们能够到达 UDP 服务站点。

对于最初发出的数据包，我们给它们设置的 TTL 较短，而给后继的数据包的 TTL，缓慢地但是逐渐延长。如果一个数据包无声无息地消失了，而我们没有收到它死亡的通知，这个数据包多半是被路由器弄丢了，或者被防火墙截断了。如果遇到这种情况，我们就再试几次，然后放弃，并且把收到的信息，通通记录下来”。

贝尔实验室的研究员，对于读者的电脑和网络知识，似乎有过高期待。下面我们把这段文字，剖开了揉碎了，逐句讲解。

Reference,

[1] 一将难求 第七章（3）

http://vip.book.sina.com.cn/book/chapter_182825_131484.html

[2] The Scenic Route.

http://www.wired.com/wired/archive/6.12/scenic.html

[3] Internet Mapping Project, Mapping Details.

http://www.cheswick.com/ches/map/

爱范儿 · Beats of Bits | 原文链接 · 10 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

通过社交网络推销图书并不新鲜，你在 Facebook、Twitter、豆瓣或者新浪微博都能看到各种书籍介绍和购买链接。不过几家出版社支持的 anobii 打算走得更远一些——直接将 Facebook 改造成自己的电子书销售渠道。

anobii 成立于 2006 年，名字源自拉丁语中的“书虫”。它的目标一开始只是成为针对阅读爱好者的社交网站。它提供的功能和豆瓣读书差不多——添加作品、打分、写评论、搭讪等等。anobii 的发展一直不温不火，多数用户来自欧洲。

今年 3 月，三大出版巨头哈珀•柯林斯、企鹅、兰登书屋以及英国娱乐零售公司 HMV 决定向 anobii 投资并将它改造成一个社交网络化的电子书销售平台。新的测试版网站最近也已上线，能够直接购买电子书。

anobii CEO Matteo Berlucchi 在接受 PaidContent 采访时提供了很多有趣的信息。他解释说 anobii 虽然大量利用 Facebook 的平台，但这么做的目标并不是吸引 Facebook 用户来 anobii 网站买书。aNobii 不会给页面加上什么醒目的标识，不期望以此增加访问量：

“你很难（在 Facebook 上）找到 anobii 的标志。我不在乎 anobii 能不能通过 Facebook 增加流量。我希望占据尽可能多的 Facebook 图书页面，并给它们加上‘购买’按钮。”

Berlucchi 认为数字时代“商店”应该进化为“网络”，读者不再需要去书店购书——不论实体或是线上。理想状态是读者在社交网络里发现感兴趣的内容就可以直接购买。

对于投资 anobii 的出版社来说，这不但是开辟新型电子书销售模式的尝试，也是优化数据的手段。Berlucchi 坦率地表示出版社缺少读者数据，手上只有销售数字，难以根据数据对接下来出版什么书作出有效规划。相比之下，亚马逊的整个业务都构筑在数据之上。anobii 和 Facebook 有希望位出版社提供更多有价值数据。

目前 anobii 已经开始提供来自 15 家出版社的 10 万本付费图书，用户可以通过 iPad 上的 anobii Reader 应用阅读（暂时未登陆美国和中国商店）。用户也可以通过 anobii Reader 直接直接古腾堡计划收集的免费作品。anobii 的电子书采用 Adobe DRM 加密的 ePub 文件，能够在绝大多数平台阅读。

anobii 目前仍处于测试阶段，我提交的申请尚未获得回应，无从考证它具体表现。不过仅凭几家老牌出版社能够积极利用社交网络、尝试新模式这一点就值得称赞。国内的出版社或许也可以考虑和豆瓣之类的平台联手做一些事，而不是被动等待电商推动电子阅读。

题图来自 anobii

黄俊杰 (Logout)

关注电子阅读、任何有趣的设备、IC 以及“历史的草稿”，相信移动设备与互联网的结合正促成近百年来最重要的一次变革。

邮箱 Twitter 新浪微博

爱范儿 · Beats of Bits | 原文链接 · 4 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

最近数家大型电商都在大力引进原版书，可见国内英文内容消费市场不小。专注内容消费的亚马逊 Kindle Fire 自然也备受关注。收到 Kindle Fire 以后已有好几人问我亚马逊服务在国内的使用情况。简单说，Kindle Fire 附带的亚马逊服务除视频外都不用挂 VPN 即可正常使用。

亚马逊的大部分服务都注明“限制美国地区”字样，但它对用户所在地的判断并不严格。你只要在 amazon.com 注册帐号，填上符合规范的美国地址以及美国信用卡号即可正常使用亚马逊的应用商店、电子书、借书、有声书、杂志、云音乐服务，网上有很多相关教程。

国内付费可以通过亚马逊礼品卡充值完成。亚马逊不会像苹果一样扣款验证信用卡，所以你只要保证下单金额不超过礼品卡余额即可。接下来看看每一项服务在国内的使用体验：

Kindle 电子书

电子书是亚马逊的强项，Kindle 书店在过去几年保持着高速扩张，付费书目已从 2007 年发布时的区区 9 万册扩张至今天的 95 万册、免费书目更是不计其数。像其它成熟的在线商店一样，Kindle 书店经常有降价、限时免费活动，官方的每日 Kindle 优惠也很值得关注。

在国内购买 Kindle 图书没有什么限制，只需填写合乎规范的美国地址。如果担心亚马逊发邮件质询，可以挂 VPN 完成注册。在国内付费购书可以通过亚马逊美国的礼品卡（Gift Card）也可以通过国内银行的 VISA 信用卡以美元支付。

Kindle Fire 赠送一个月的 Prime 会员资格，在此期间你可以通过 Kindle 电子图书馆借一本书，在国内同样有效，但每个月只能借一本，而且选择不是很丰富。

Kindle 电子书阅读界面

Kindle Fire 内置阅读软件界面和 Android 版 Kindle 应用相似。这是亚马逊收购 Stanza 团队之后的作品，阅读界面非常纯粹，只显示文本与书的标题，不显示与作品无关的任何信息。单击屏幕调出的设置界面布局合理，功能全面。全平台同步阅读状态、书签以及笔记也是一大优势。目前 Kindle 应用支持平台包括 Windows、Mac、iOS、Android、Windows Phone、webOS 和黑莓。

Kindle Fire 在文字阅读方面的不足主要集中在两个方面。一是液晶显示屏的背光不及 E Ink 显示屏那么舒服，这是所有平板都面临的问题。相对的，E Ink 屏设备也对环境光有很高要求。二是重量偏大，Kindle Fire 重 413g，而 Kindle Touch WiFi 仅有 213g。单手拿 Kindle Touch 看书无疑舒服得多。不过由于 E Ink 屏比较脆弱，很多人都把 Kindle 阅读器放在皮套里，而 Kindle Fire 有康宁玻璃保护，可以裸奔，此时重量差距已经很小。

有顾客在亚马逊留言说一本通过 Kindle 2 购买的书无法通过 Kindle Fire 打开。我试了自己之前买的几十本书，都能正常阅读，其他用户也很少有类似反馈，应该只是能够很快解决的个例。

杂志

早在三四年前，亚马逊就开始推动 Kindle 电子杂志，不过一直未能推广开。仅 E Ink 屏幕不能显示彩色这一条就足以让很多用户拒绝 Kindle 杂志。Kindle Fire 采用 IPS 显示屏，不论可视角度还是色彩表现都相当出色，甚至好过售价高出一倍多的索尼 S1。

亚马逊也为推广 Kindle Fire 杂志提供了不错的优惠，包括《连线》、《纽约客》在内的十余种杂志订购即增三个月，其它杂志也都有 14 天免费试读。在此期间你若不满，可以退订。多数英文杂志倾向于让读者订阅，因此单价普遍较高，但订阅后单期价格往往低于国内同类杂志，比如在 Kindle Fire 订 15 个月《连线》不过 20 美元。就连向来昂贵的《经济学人》，按月订购一年也不过 120 美元，远低于国内四位数的印刷版定价。

看完几本杂志之后，我感觉 Kindle Fire 的表现虽然好过 Kindle 4，但依然与 iPad 有不小差距。Kindle Fire 杂志大体上可以根据阅读形式分两类，一类基于 Kindle 应用、另一类为独立应用。

基于 Kindle 应用的杂志有《经济学人》、《国家地理》、《新闻周刊》等等，这些杂志都提供了两种阅读界面——“页面视图”（Page View）和“文本视图”（Text View）。前者基本是纸质杂志的扫描版。Kindle Fire 屏幕尺寸有限，大多数时候得双击放大文字区域才能看清文字，而且放大比例无法在翻页后保留，基本不可用。“文本视图”将图片和文字内容区分开来，可以调整文字大小、行距等等，阅读体验比较好。但该模式下排版丧失殆尽，并不是大多数人想要的结果。订购之后这些杂志基本都能够在其它 iOS 和 Android 平板的 Kindle 应用中阅读，不过这些设备目前只能显示文本模式。

《国家地理》“页面视图”（左）、“文本视图”（右）

也有一些出版社通过独立应用提供内容。比如康泰纳什旗下的《连线》、《纽约客》、《名利场》。这些杂志的界面针对平板设备优化，和 iPad 版几乎完全相同，阅读体验比 Kindle 版更好。但很明显这些内容首先还是针对 iPad。Kindle Fire 版的图片和文字细节明显不及 iPad 版清晰，且不支持横屏模式。此外通过独立应用订购的杂志不会出现在 Newsstand 中，在桌面也只显示应用图标而不是像 iOS 5 一样显示杂志缩略图，看起来很别扭。Kindle Fire 杂志还需精心优化。

漫画

美式漫画基本都是彩色，Kindle Fire 是亚马逊第一款能够满足这方面需求的设备。亚马逊也很看重漫画市场，和 DC Comics 签约推出了上百册从未数字化的漫画。

漫画在 Kindle Fire 上同样有多个渠道，除了在 Kindle 商店直接购买以外，也可以通过 ComiXology 的应用购买。后者目前最大的数字漫画服务，iOS 上的 DC Comics 等漫画应用也基于 ComiXology，连帐号都通用。

纸质版《守望者》与 Kindle Fire 电子版对比

以美漫的页面尺寸，iPad 基本可以正常阅读，但字比较小。而 Kindle Fire 的屏幕已经无法保证阅读。所以 Kindle 漫画和 ComiXology 的漫画都对放大操作进行优化，双击操作即自动放大文字区域，此时翻页会自动切换至下一个需要放大的区域。区别在于 Kindle 漫画的放大比率较低，而 ComiXology 可以做到全屏，体验更好。就个人体验来说，Kindle Fire 可以用来看漫画，但需要频繁进行翻页操作，体验不及 iPad。不过现在也有每次只显示一格漫画的尝试，反响不错，可见进一步从软件层面优化也有望提升 Kindle Fire 漫画阅读体验。

在通用性方面，很多 Kindle 漫画购买后只能在 Kindle Fire 上阅读，目前还不能在其它平台的 Kindle 应用中打开。ComiXology 在这方面要好得多，不但支持所有 iOS、Android、Windows Phone 手机与平板，而且可以用电脑在线观看。

有声书

Kindle Fire 通过 Audible 提供有声书，我之前在 ifanr 介绍过 Audible，它是亚马逊收购来的服务，主推订阅服务，每月支付一定费用获得《纽约时报》或《华尔街日报》有声版文摘以及一个点数。每个点能换取一本书，相对于现金购买单本来说更为划算，而且初次注册有不少优惠。Audible 对用户所属国家和信用卡所在地没有任何限制，只要能付美元即可。

Kindle Fire 对 Audible 的集成一般，只是预装 Audible 应用。有声书的下载、播放都通过应用完成，不会在书架上显示一堆漂亮的封面。有声书的体验与硬件相关，Kindle Fire 内置的扬声器声音不算太大，但对于听书来说已经非常足够，而且音量最大也不会有爆音。以前我在家习惯用 iPod Classic 加 MD-11 小音箱听书，现在直接用 Kindle Fire 外放，也免去 iTunes 下载同步的麻烦。

云音乐

和很多人猜想的不一样，亚马逊的云音乐服务可以在国内正常使用。你可以将现有的 mp3 文件上传至亚马逊的网盘，也可以在亚马逊音乐商店购买音乐。所购音乐不会计入网盘容量限制。存储在云端的音乐可以通过在线客户端、Kindle Fire 或其它 Android 设备直接播放。用户最多可以在云端免费存储 5G 音乐，通过亚马逊音乐商店购买的音乐不计入此限制。

根据我在多个不同地点的测试，亚马逊云音乐上传速度很一般，但在线播放速度很理想。只有播放第一首歌的时候需要缓冲，而且时间不会超过 7 秒。Kindle Fire 内置闪存容量有限，云音乐是很好的补充，适合在室内 WiFi 覆盖环境下使用。

在线视频

亚马逊今年开始涉足在线视频业务，直接与 Hulu 和 Netflix 竞争。由于视频版权敏感，所以亚马逊在这方面管的也特别严。不但需要有效美国地址和信用卡号，而且必须在 IP 地址为美国时才能进行购买。购买后的播放和下载也需要保证 IP 地址在美国。

Kindle Fire 目前不支持 VPN，我试过全局模式的 SSH，但依然没法播放或下载已经购买视频。这可能是因为亚马逊禁止所有取得 Root 权限的设备使用在线视频服务——其它服务都可以在 Root 后正常使用。而全局 SSH 只能在 Root 后的设备上使用。所以 Kindle Fire 在国内只能通过 WiFi 分享而来的 VPN 网络观看亚马逊在线视频服务，非常麻烦。提醒一下，很多付费的 VPN 服务不支持 WiFi 再次分享。

我买了一部纪录片，最后不得不通过电脑上的 Amazon Unbox 软件下载。而且 Amazon Unbox 下载的视频分别是 DRM 保护的 WMV 和 AMZN 文件，前者用于桌面播放，后者是移动版。这两种格式拷入 Kindle Fire 后毫无反映。

应用商店

相对官方 Android 市场，亚马逊应用商店为开发者设置了一定门槛，起到过滤作用。每天赠送一款应用是它的特色，完全版 Documents To Go、Drawing Pad、IM+ Pro 等出色应用都曾在这里免费放出。

亚马逊应用商店目前限定地区为美国，但它只要求格式正确的美国地址和信用卡号，国内可以通过礼品卡支付。

用 Kindle Fire 会发现，商店里很多之前能够通过手机下载的应用消失了。一开始我以为是兼容性问题，后来将 News 360 等应用的 apk 文件从手机里取出，安装到 Kindle Fire 之后发现一切正常。这些应用显示不兼容 Kindle Fire 或许是因为图标的缘故。所有通过 Kindle Fire 在亚马逊应用商店下载的应用图标分辨率都比较高，目测应该有横向 300 像素。高分辨率保证了应用在 Kindle Fire 主屏的显示效果。亚马逊逼开发者升级对其它 Android 设备，特别是偏向高分的 Android 4.0 来说也是好事。

重复 Kindle 模式？

Kindle Fire 并不完美，小 bug 很多、界面特效大多不够流畅，显然连硬件加速都没支持好。我完全理解很多媒体作者和设计师的失望。不过 2007 年的初代 Kindle 一样谈不上完美，甚至可以说是简陋。在随后四年时间里，亚马逊平均每年一次硬件改版、软件升级不计其数，最终真正激活电子书产业，并且成功让很多国家用户养成为数字内容付费的习惯。

作为一款售价与低配 iPod Touch 相同的平板，Kindle Fire 目前的表现对我来说完全可以接受。而且从 Kindle 阅读器进化史就能看出亚马逊非常关注产品细节。例如亚马逊 Kindle 总监 Jay Marine 在 Kindle 3 开发阶段就把降低翻页键声响视为重要改进，这是真正的 Kindle 2 用户才会想到的小细节。类似例子还有不少，因此我对亚马逊持续改进 Kindle Fire 持乐观态度。

2007 年初代 Kindle 阅读器发售时，内容销售和硬件销售都局限在美国。电子书消费模式被大众接受以后，亚马逊开始向其它地区扩张，2010 年进军英国，今年又覆盖法、德、西、意四国。有很多迹象表明 Kindle 商店将很快进军南美洲，第一个目标就是巴西。

Kindle Fire 现在的情况也很类似，它在美国的销售已经取得成功，如果内容补贴硬件的模式被证明可行，进一步覆盖其它国家也只是时间问题。比 07 年好的地方在于电子书消费模式已经被推广开，亚马逊不需要去说服用户接受付费杂志。但不利因素也很多，特别是电子杂志、视频、音乐服务已经有了多家比较成熟的竞争对手。

至于国内，百度文库的收缩、一些小团队的尝试以及苹果应用商店开放人民币支付之后获得的积极响应也让人看到一丝希望。或许中国特色真的能够改变。

黄俊杰 (Logout)

关注电子阅读、任何有趣的设备、IC 以及“历史的草稿”，相信移动设备与互联网的结合正促成近百年来最重要的一次变革。

邮箱 Twitter 新浪微博

爱范儿 · Beats of Bits | 原文链接 · 17 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

上周微软称 Windows 8 将开启“个人云”时代， 很快 SkyDrive 就进行了升级，作出多项改进，使之更加易用。针对这些改进，BusinessInsider 给出评价：“惊喜！ Dropbox 和 Google Apps 的竞争者不再糟糕。”

有几个改进值得注意：

• 可以直接拖拽文件到 SkyDrive 中，并上传。然而这个过程不像 Dropbox 那样，直接把文件拖进文件夹就完成。SkyDrive 需要用户点击“上传”按钮，之后才允许拖拽文件。与 6 月份那次升级相比，多个文件的上传不再出现让人抓狂的“错误信息”。
• 可以方便地管理文件和文件夹。升级之后的 SkyDrive 允许用户通过鼠标的右键菜单来创建、改名、删除文件或文件夹。通过 SkyDrive 的左侧面板，用户可以把文件夹移动到别的地方，这个方式不如 Dropbox 方便直接。不过，在 6 月份时，SkyDrive 甚至不能允许用户调整文件夹的顺序。
• 简单的分享文件。如今 SkyDrive 用户可方便的通过邮件、社交网络（Facebook、LinkedIn 等），或是链接来向别人分享文件。在 Dropbox 中，在文件上点击鼠标右键便可获得分享链接，功能比较简单。

经过升级的 SkyDrive，操作还是不如 Dropbox 直接——两者设计思路本身就不一样，微软在这次升级中，强调“以应用为中心”，而不是“以文件为中心”。因此，用户大多数操作都需要通过应用本身的菜单、按钮才能完成。

至少微软解决了 6 月份时 SkyDrive 出现过的那些恼人的问题：同时上传文件不能超过 5 个、文件管理功能糟糕。

最后，附上最新版 SkyDrive 操作视频：

陈一斌

组织过软件汉化，写过时间管理文章，研究过个人知识管理。关注科技的发展，创投资讯、移动互联网。

邮箱 Twitter Facebook 新浪微博

爱范儿 · Beats of Bits | 原文链接 · 12 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！

Google＋ 上线已经有段时间了，前阵子我还收到了他们宣告自己正式上线的邮件。不过比较让用户和开发者门头疼的是 Google 并未放出 G＋ 的全套 API。根据 Launch.is 提供的资料，G+ 现在官方提供的 API 包括获取公开文章、Hangouts 等。

有人已经等不下去了。Google 认证开发者 Mohamed Mansour 有款评价很高的 Circle 管理插件，相关的 APIs Google 没有提供。所以他 hack 了他自己非官方版本用于 Circles，Followers，Profiles 和发送到 G＋ 的代码，呈放于 Github。

Mohamed 告诉 LAUNCH 他目前没有收到来自 Google 的官方回复。

Mohamed 的这一举动倒是赢得了其他极客的欢迎。来自澳洲的 Robert Norris 也曾对 Google Apps 做过 APIs 方面的反向工程研究，在看到 Mohamed 付出的努力后向其表示祝贺。

另一位开发者 Adi Rabinovich 在赞誉 Mohamed 的同时也表达了对 Google＋ 官方 API 的期待。Mohamed 对此回复说，“我也一样，但我三月前已经开发了一款插件了，我一直等着却没有结果。所以我就这么干了。这还挺简单的，我正着手做些调整以期能让插件开发人员更方便的使用。”

Mohamed 开发的细节这里就不赘述了，不过从他的 Google＋ 发布的信息看，应该是用到了 XHR(XmlHttpRequest) 调用，借助 Web Inspector ，他能精确处理每一项请求。现阶段他的主要任务是改进圈子（circle）管理。

Google＋ 代表着 Google 对社交应用的野心。不过他们开放 API 的速度倒也是业界少有的慢。在 Twitter、Facebook 三方应用遍地开花的时代，Google 你得加快自己的步伐了。

本文素材来自 LAUNCH

题图来自 Flickr，Courtesy of  Yang and Yun

April

「科技以人为本，Connecting People」—— 诠释了移动科技该有的魅力。

邮箱 Twitter Facebook 新浪微博

爱范儿 · Beats of Bits | 原文链接 · 4 热评 · 新浪微博 · 订阅全文 · Google+ · #ifanrlive · 加入爱范社区！