March 2011 Archives

很多团队都在学习、研究 Quora 。前段时间看到这篇 Quora's Technology Examined ，阐述了 Quora 的技术架构，有一些值得关注的信息，记录并分享一下。

使用云计算服务

Quora 大量使用 Amazon EC2 与 S3 服务；操作系统部署的是 Ubuntu Linux，易于部署和管理；静态内容用 Cloudfront.服务分发，图片先传到 EC2 服务器，使用 Pyhon S3 API 处理后后传到 S3。

从开始就使用云计算服务的的好处是节省了大量人工维护硬件服务器的成本，当然这个做法在咱这片土地上不太可行。

（refer: Copyright )

Web 层与 CMS

HAProxy 作为前端负载均衡服务器，反向代理服务器是 Nginx，Nginx 后面则是 Pylons (Pylons + Paste) , 承担动态 Web 请求。

Webnode2 与 LiveNode 这两个内部系统承担创建、管理内容的重任，Webnode2 生成 HTML、CSS 与 JavaScript ，并且与 LiveNode 轻度耦合。LiveNode 的作用用以显示 Web 页面内容。用 Python、C++ 与 JavaScript 写的。特别提到用到了 jQuery 与 Cython。LiveNode 有可能开源。

为什么用 Python?

前面已经提到了一些 Python 相关的技术组件。有意思的是从 Facebook 出来的团队居然用 Python 作为主要开发语言。Quora 对此有所解释: Facebook 选择 PHP 也并非是最佳选择，而是有历史原因。Quora 技术团队在考察了多个语言之后选择的 Python ，当然理由有一大堆，总体看来，并非很激进。

通信处理

后端通信使用的是 Facebook 开源出来的 Thrift，除了开发接口简单之外，可能更为熟悉也是一个因素吧 :) Comet 服务器使用的是 Tornado，用以处理 Long polling 以及 Push 更新(不知道知乎用的什么?)，Tornado 是前 FriendFeed 技术团队开源的产品。

实时搜索

因为 Sphinx 不能满足实时性方面的要求，Quora 启用了自己开发的搜索引擎，只使用了 Thrift 与 Python Unicode 库，此外没有用别的。Quora 的搜索比较特别，因为要对输入内容做关联并且要做有效提示，所以需要提供更好的前缀索引(Prefix indexing)功能。

Quora 搜索的实现还是挺有技术含量的，对后端的查询请求压力也不小(或许当前的并发请求量还没那么大)。对这个场景，做相关开发的朋友不妨仔细研究一下。如果大体框架类似，那么决定最后生出的因素很可能是那些细节。

数据持久层

大量使用 MySQL 作为存储方案，Memcached 作 Cache 层。没有使用当前比较火爆的 NoSQL 相关产品。Quora 这样做有自己的理由，用户量级没有达到百万的 SNS 站点完全没必要用 NoSQL 的东西。或许以后 Quora 也会启用。

创始人查理·奇弗（Charlie Cheever）与亚当·德安杰洛（Adam D'Angelo）之前都在 Facebook ，所以，Quora 的技术还真有不少 Facebook 的基因。Quora 的团队规模并不大，做技术的估计十余人而已，这么紧凑的团队利用了这么多的技术与产品，可见很多人都是多面手了。这是国内技术团队需要向国外同行学习的地方。

--EOF--

这只是一篇概要性的描述，如果要知道一些更为细节的东西，请看 Quora 上的相关评论，上文中已经给出相关链接。

不管技术团队规模如何，总要在内部用一些工具来支撑日常工作。这些工具的选择会影响整个团队的效率，不可不慎重。如何做这类产品的评估与选型？每个人都会有自己的方式，这里说说我在丁香园技术团队遇到类似场景的时候，一般会参考的几个维度和评估方法。

活跃分析

目前来看，Google Trends 是个不错的分析产品活跃度的工具，只是有些关键词选择需要注意一下，不要迷惑于表面的数据。

产品特性

一般来说，WikiPedia 的对同类产品的功能比较是非常详尽的。如果是一个相对陌生的产品，无论如何要看一下。真的佩服这些编辑者的水磨功夫，相比之下，国内的有些类似网站，没办法看。

主观评价

通过 Twitter 进行提问，可以收集到很多技术同行的反馈与评价。另外，如果没有候选产品，通过 Twitter 也可以征集产品列表，前提是平时要有不错的互动。

通过搜索引擎可能会找到一些评测文章，一定要注意各自的场景和团队规模以及技术风格，一般来说，此类文章参考价值不是很大。

国外技术人员接受程度

参考一些问答网站，比如 Stack Overflow 的讨论，一些产品的优缺点，几乎都会涉及到。

国内技术人员接受程度

通过新浪微博进行关键词搜索可以基本获知国内技术人员对某技术或者产品的使用与接受程度。比如，搜索一下 "Trac" 这个话题看看。

多方面沟通

尊重内部同事意见与建议，咨询一下更大规模的团队负责人的经验。有句话说得好，"听多数人的意见，和少数人商量，自己做决定"，对于这个场景，也是适合的。

我吸取的一个教训是要让相关的同事有"知情权"，避免黑箱操作。

选择与风险

团队负责人做最后的抉择，并且承担后续风险。如果经过一段时间，证实判断有问题，别硬着头皮往死胡同走，承认错误，尽快调整。

工具用不好或是不好用，团队效率可能会骤降许多，不得不重视。类似的惨痛教训还是不少的。

没错，我说的没有什么新奇的内容，都是常识。有时间我再改改。

--EOF--