大型互联网公司应避免与初创公司争利

前几天关于卷豆网的“淘金链 LinkMiner”产品被抄袭的争论引起了不少业界朋友的关注。在这里我不想探讨抄袭与否或者谁是谁非，而是想说说大型互联网企业与初创公司争利这事儿。

我们常说硅谷有更多的创新，创新来自哪里？多数来自初创公司(Startup)。而大公司针对初创公司取得的创新产品，常常采用收购的策略，这样，不但拿到了产品，占领了潜在市场，重要的是，还收获了团队。但是国内大公司采取的做法呢？是抄袭，或者说的好听一点叫”模仿”，创新很难，模仿很容易，只要人手够，肯砸钱就成。这样下来的结果是，大公司内负责拷贝的小团队(或者是总算有了活干的产品经理)得到了短期的业绩，但公司长此以往则失去了创新的能力，而创业团队得不到益处。

这种中外差异，建硕认为是因为彼岸的人才在大公司之外，我觉得还是因为大公司心态问题。很多喊着开放的公司，为了一点小利而让整个社区齿寒，什么产品都弄一份”自己的”，试问如何构建所谓的”开放平台”？我想很多公司都梦想着把自己的拳头产品打造成行业平台吧，问题是你骨子里就不打算让第三方开发者真正的得到益处，或者说大家都是来陪着太子读书的，稻子成熟了都叫你圈地收割了，这样如何达成愿景呢？

所以我说，大型公司应避免与初创公司争利，相反，应该花点心思扶植一些这样的团队，毕竟这样，才对整个生态有利。长期来看，这才是划算的买卖。

–EOF–

相忘于江湖

有些时间没写新的东西。关注我的朋友应该已经从Twitter或是业界新闻获知（refer)，我已经告别阿里巴巴集团旗下的支付宝，加入丁香园(http://dxy.cn)创业团队。所以近期比较忙，写东西的频率一下子也降了下来。

很多人认为我转换了行业，其实没有，接下来要做的依然是互联网，而且有更多的机会可以把想法变成现实，要做的业务也不排除会更多涉及电子商务。我非常认同丁香园的愿景，可能是因为多少还有点生物技术知识背景的缘故吧，我相信我们要做的事情会让这个社会更加美好一些。

从2005年加入阿里巴巴到现在，我在支付宝工作已五年多的时间。现在支付宝是国内最大的第三方支付公司，已彻底改变了电子商务的环境。自己有幸目睹支付宝从最初的数百万用户到今天为数亿用户提供服务的发展历程，对一个技术人员来说，有机会面对这样难得的技术挑战，是一份非常难得的成长机遇。在这个过程中，有艰辛和痛苦，但真是获益良多，更值得自豪的是，有幸在这个过程中奉献了一点微薄之力。若干年后回首往事也足以感到欣慰了。

要做的已经做过，想得到的业已得到，接下来在新的公司要面对更大的挑战。临别之际，想到的不是一些大事，倒是一些小事更让人感慨。还记得，一起和同事们奋战过的日子，还有那些欢笑和眼泪…

“相濡以沫，不如相忘于江湖”
–《庄子·大宗师》

–EOF–
PS. 部分内容来自我的告别邮件.

Get Architecture Done -《分布式Java应用：基础与实践》

按：承蒙林昊( @Bluedavy )看得起，嘱托我为他的大作《分布式Java应用：基础与实践》写序，倍感荣幸之余也颇有压力。读完本书的绝大部分章节后，这相信这会是我今年要向朋友们推荐的关于架构的图书。毕竟我在阿里系工作有年，对几家子公司的技术还算有所了解，内容有没有料还是可以一目了然的分辨的出来的。下文是推荐序。

提起诸如”高性能”、”高可用”、”大规模并发”、”可扩展性”这些词汇，我相信多数技术人的心情都是激动而稍有点复杂的，当然，也或许是不屑一顾。毕竟不是谁都有机会面对这些富有挑战的技术场景，也不是每个架构师在面对这些挑战之前都能做好技术上的准备。那些意外故障总是不期而至，疲于奔命的解决问题的场景回顾起来对架构师来说犹如一场噩梦。

本书阐述当一个面向数以亿计用户的网站经过几年高速发展，技术团队不得不面临大规模、高并发、高扩展性等挑战带来的技术困境的时候，一个出色的架构师经过多年一线实践后累积的经过时间考验的解决方案以及宝贵的实战经验。在这本书里，你会看到作者在解决一些关乎Web应用问题的指导原则、实践方法、多重工具的综合运用以及作者本人的感悟。要强调的是，本书讲述的内容是一个Web应用从小到大过程中遇到的棘手问题的解决之道，并非宏观解析，亦非屠龙之技。无论您面对的站点是大是小，皆会有参考作用，毕竟大站点会越来越复杂，而小站点总有一天也将变大。

如今到计算机书店里走一下，会发现Java架构相关的技术图书业已不少，但仍有理由相信本书内容填补了在Java架构实战方面的空白。在互联网应用大行其道的今天，有些名义上主题为Java架构的图书，要么单从Java本身阐述，缺乏整体应用的大局观；要么是高屋建瓴，从编程思想的高度坐而论道，缺乏实践性；要么是闭门造车之作，缺乏验证性。本书作者林昊多年来致力于推动OSGi在国内的发展，不乏理论技术功底，而后加盟淘宝网 (Taobao.com)的几年间奋战在架构一线，爬摸滚打积累了丰富的实践心得。所以，本书是一本不折不扣的”理论结合实践“之作。

考虑国内的技术图书出版环境以及必须尽力迎合读者的预期，写书本身是一件费力不讨好的事情，但将知识传递给更多人无疑是让人快乐的。现在，经过作者近两年的梳理与总结，这本书即将出版，相信您在研读本书之后有所收获并运用到您所面对的Web应用上，也期待将来有更多朋友能够分享架构实践经验，不亦快哉！

–EOF–
　　

探索Google App Engine背后的奥秘(6)- 总结

按：此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究，现在正致力于研究云计算技术。

本篇是本系列的最终章，将总结一下App Engine在使用方面的注意点，最佳实践和适用场景，最后会谈一下我对App Engine的一些期望。

注意点

执行速度偏慢：由于其分布式的设计，所以在速度方面不是最优的，比如普通的Memcache能在几毫秒完成操作，而App Engine的Memcache则大概需要50(毫)秒才能完成操作。
私有API：其API有很多都是私有，特别是在其服务方面，虽然Google提供了很不错的文档，但是在学习和移植等方面，成本都很高。
执行会出现失败的情况：根据很多人的实际经验，App Engine会不定时出现执行失败的情况，特别是Datastore和URLFetch这两部分，虽然Google已经将Datastore方面出现错误的几率从原先的0.4降至现在的0.1，但是失败的情况是很难避免的。
有时会停机：虽然总体而言，停机并不频繁，但是在今年初出现长达136分钟故障导致部分用户的应用无法正常运行，其发生原因来自于其备份数据中心出现了问题。
无法选择合适的数据中心：比如，你应用所面对的用户主要在欧洲，但是你应用所属App Engine服务器却很有可能是被部署在一个美国的数据中心内，虽然你的应用很有可能在将来移动至欧洲某个数据中心，但是你却无法控制整个过程。
有时会处理请求超时：虽然能平均在100至200ms之间完成海量的请求，但是有时会出现处理请求超时的情况。
不支持裸域名：只支持类似CNAME的子域名。

最佳实践

适应App Engine的数据模型：因为其数据模型，并不是传统的关系模式，而且在性能方面表现也和关系型数据库差别很大，所以如果想要用好非常关键的Datastore，那么理解和适应其数据模型是不可或缺的。
对应用进行切分：由于App Engine对每个应用都有一定资源限制，而且为了让应用更SOA化和更模块化，可以对一个应用切分多个子应用，比如，可以分成一个用于前端的Web应用和多个用于REST服务的后台应用。
极可能多地利用Memcache，这样不仅能减少昂贵的Datastore操作，而且能减轻Datastore的压力。
在上面提到过，由于App Engine在执行某些操作时会出现失败的情况，比如Datastore方面，所以要在设计和实现这两方面做好相应的异常处理工作。
由于Datastore不是关系型数据库，导致在执行常见的求总数操作时显的有点”捉襟见肘”，所以最好使用Google推荐的Sharded Counters技术来计算总数。
由于Blobstore还只是刚走出试验期而已，而且其他模块对静态文件（比如图片等）支持不佳，比如Datastore只支持1MB以内的对象，同时每个应用只能最多上传一千个文件，而且速度不是最优，所以推荐使用其他专业的云存储，比如Amazon的S3或者Google马上就要推出的Google Storage等。
尽量使用批处理方式，不论是在使用Datastore还是发送邮件等。
不要手动创建Index：因为App Engine会自动根据你在代码中查询来创建相关的Index。

适用场景

现在而言，App Engne主要适用于下面这三个场景：

Web Hosting：这是最常见的场景，在App Engine上已经部署了数以十万计的小型网站（其中有很多主要为了学习目的），而且还部署了一些突发流量很大的网站，其中最著名的例子就是美国白宫的”Open For Questions”这个站点，主要用于让美国人民给奥巴马总统提问的，这个站点在短短的几个小时内处理接近百万级别的流量。
REST服务：这也是在App Engine平台上很常见的场景，最出名的例子就是BuddyPoke，BuddyPoke的客户端就是一个Flash应用，在用户的浏览器上运行，而它的服务器端则是以REST服务的形式放置在App Engine上，每当Flash客户端需要读取和存储数据的时候，它都会发请求给后端的REST服务，来让其执行相关的Datastore操作。
依赖Google服务的应用：比如应用能够通过App Engine的Email服务来发送大规模的电子邮件。

未来的期望

更稳定的表现，更少的超时异常和更快的反应速度，特别是在Datastore和Memcached这两方面。
支持对数据中心的选择，虽然现在App Engine会根据应用的用户群的所在地来调整应用所在的数据中心，但由于整个过程对开发者而言是不可控的，所以希望能在创建应用的时候，能让用户自己选择合适的数据中心。
SLA，如果App Engine能像S3那样设定一些SLA条款，这样将使用户更放心地在App Engine上部署应用。
新的语言：比如PHP，但是如果在现有的App Engine架构上添加一门新的语言，整个工作量会非常大的，因为App Engine有接近一半的模块是语言特定的，比如应用服务器和开发环境等，所以短期内我认为不太可能支持新的语言。

总体而言，Google App Engine是Google大战略中一个不可分割的一部分，因为Google希望能通过App Engine来降低Web应用开发的难度，只要难度降低了，那么Web应用替代客户端应用的整体速度将会加快，如果出现这样的情况的话，那么将会对Google今后的发展非常有利。

本系列文章结束。

参考资料：

–EOF–