如何在 60 天内“慢悠悠”的实现一个高伸缩的 Google Reader 替代服务 － 关于 36kr 上的 “90天创造奇迹：Digg与时间赛跑，打造Google Reader替代品”

刚才看到 36kr 上的这篇文章：http://www.36kr.com/p/204123.html , 5个人3个月开发 Google Reader 应该算很了不起了，尤其在时间压力下。

“这是一段一个小团队如何在 90 天内冲破不可能，创造奇迹的故事。”

我想说的是，如果选择合适的平台的话，完全有可能可以更快。

下边是在 Google App Engine 上开发 Favo Reader （ https://www.favo.me/reader/view ）的一些记录，如果也按开始测试时间算的话，扣除假期的话，60 天不到。
实际上我对 GAE 和 Java 都不算擅长，如果你是个熟悉 GAE 的 Java/Python 程序员的话，你会发现下边这个过程完全可以更快。

*** 或许你会认为 Digg Reader 和 Favo Reader 这两个是不同“级别”的东西，但是如果考虑到 GAE 惊人的伸缩性的话，很难断定哪个性能更好
参考基于 GAE 的可汗大学一个流量回放视频： http://bjk5.com/post/30813320623/what-traffic-from-60-minutes-looks-like

=====
开发过程:
3/29 开始，4/25 爬虫算法及核心 API 基本完成，5/15 Web 版内部测试，5/28 开始邀请测试，以上包括 10多天 假期



=====
结果:
实现 Google Reader Web 版常用功能，兼容 Google Reader 的 OAuth API，很快的响应速度，可以支持大量用户，可接受的运行成本

stream 请求平均在 100ms-200ms 之间（来自 Dashboard 统计，不含网络延迟）
向上的更新接口通过 Memcache + Queue, 10ms-30ms
用户之间没有数据关系，理论上 1 万用户 和 1000 万用户没有明显瓶颈

***非常不靠谱估算*** 100万用户一年成本大约 ¥20万

=====
使用到的技术:
GAE/Java, URLFetch, Datastore, Queue, Memcache, Google 帐号集成

=====
API 实现：
基于 Google Reader API，因为这个 API 已经经过反复验证。
网络上有许多文档，其中比较全面的是：http://undoc.in/

最核心的是 stream 接口： http://undoc.in/stream.html ，一旦实现了这几个接口，其它都变的非常简单

这部分关键和存储使用方式有关，基本上就是把 article 索引在 feed 和 user 对象中

API 的 OAuth 部分 GAE 直接支持，几乎不花时间

API 原型约一周（3/29-4/5），在后续的调试上花了不少时间

=====
爬虫实现：
GAE 的 URLFetch 配合 Queue 作为 feed 爬虫非常理想，一天抓取数千万次都没问题，我们现在抓取大约 150万次/天

这其中关键在于爬虫的调度算法，后来算法改为根据历史抓取记录来训练，明显提高了抓取命中率。

其次通过批量请求减少 request 降低 CPU 时间，并且把抓取任务放在一个独立的版本中，提高 GAE 的 instance 分配效率

另外就是用多个任务队列（闸）来“平滑”，避免突发请求导致创建大量 instance，最终的 CPU 有效利用率大概是 35%, 如果内存使用更好的话，应该还有较大优化空间

爬虫用 ROME 做 feed 解析（有时间格式和一些编码问题）, 主要工作在调度算法和防止 SPAM 等，第一次负载测试就超过当时 Newsblur 每天的抓取量

4/5-4/25, 花了大约 3 周时间，其中许多时间是调试 API。爬虫部分没多少代码，但是发现问题比较费劲。


=====
Web 版
Web 版用 Backbone + Marionette + JQuery，这个三个都是第一次用，花了比较多时间看文档

4/25 开始，到 5/15 基本完成，5/28 开始邀请测试 (中间有许多天在休假中)

=====
之后
后来陆陆续续在完善一些细节，前几天把之前的 iOS 客户端转移到 Favo Reader 后端，OAuth2 改为 OAuth1 (App Engine 不支持 OAuth2)因为OAuth1签名部分问题花了2天时间调试，真正同步代码移植只花了几个小时，因为接口/参数/结果几乎完全一样

虽然开发了这么个服务挺快的，最初也只是打算作为 RSS to Kindle 的替代，后边开发也不太专心，要不可以更快一些。

写这么多，想顺便劝劝 v2ex 上的朋友们，如果不把眼光局限在 GAE 的免费限额，GAE 可以是个非常好的平台，尤其 GAE + GCE