再有几天 QCon (Beijing) 技术大会 就开始了。QCon 是这几年出现的最有价值的技术会议，”绝对有技术含量”，相信北京这次也会让每个人不虚此行。这还是第一次在国内举办，很多国外的大师都来了，有机会能参加也是一件好事。
受邀主持网站架构案例分析这一场，所以有机会提前看到各位技术演讲人提交的 PPT。前天晚上看到豆瓣首席架构师洪强宁的 《豆瓣技术架构的发展历程》，击节称赞! 这个 PPT 会成为一份相当经典的架构参考文档。
据说现在已经一票难求了，如果要购票的话，可以用我的折扣代码。买票的时候报我的 BLOG 或者我的名字就可以省点钱。
–EOF–
这几天给我印象比较深的是 HeroKu ，提供 Ruby 快速部署环境并提供托管能力，他们的架构图做得十分漂亮，一幅图胜过千言万语，要是对 Web 架构感兴趣，都别问架构师了，看看 HeroKu 的架构估计就明白个差不多了 :)
概览图
好的架构图是画出来的，好的架构未必是设计出来的，最后架构好不好，还要看持续的改进能力。
HTTP 反向代理
使用 Nginx , 这一层只进行 HTTP-level 的处理。Nginx 现在是不二选择。
HTTP Cache
对于静态内容，使用 Varnish 进行缓存。如果你在 Squid 和 Varnish 之间作选择，这里已经投了一票。
路由网(Routing Mesh)
用 Erlang 实现的架构组件，路由寻址，用以提升可用性和扩展性。
动态网格(Dyno Grid)
用户部署的代码运行在这里，可以简单看成是应用服务器集群环境，只是粒度更小一点而已。
对于 Dyno Grid 的进一步信息：
服务器操作系统是 Debian ；Ruby VM 是 MRI ，开源，C 写的；App Server 用的 Thin，他们说 Thin 比 Mongrel 更精炼；Rack，应用服务器接口；Rack 中间件，可选组件；框架，任何 Rack 兼容的都成；最后是客户托管的代码。
数据库
PostgreSQL，也可以采用远程数据库。
Memory Cache
Memcached ，居家旅行架构必备。
这几张图看下来，多少算是对 Ruby 环境有了一些感性认识。可以进一步查看 HeroKu 提供的文档，包含了一些代码实现上的准则。
部署是基于 Git 的。不知道大家有没有注意到 Git 在最近一年来的爆发? 超过 SVN 或许不是不可能的。
国内热炒”云计算”的，跟人家学学吧，与其整天帮着客户开发定制软件，还不如给客户提供一些弹性应用托管环境，起码看起来靠谱一些。
HeroKu ，不读 Hero-Ku, 读作 Her-oh-koo, 挺有趣
–EOF–
最近北京奇遇花园咖啡馆举办了一场 “Beta 技术沙龙“, 关于”有道阅读器产品设计”的话题。
在杭州也没办法过去参加，倒是第一时间看到了 PPT。又问了以下，PPT 可以进行传播。所以截取了两张图(版权属于有道)学习一下。先是交互易用性问题。有道的数据库缓存策略是把当天的数据缓存起来，用 Memcached ，不知道改造过过还是默认方式使用。有道的 Ajax 交互的响应速度相对比较快。也是 用 JQuery — 几乎快成了居家旅行必备 JavaScript 库了。
用 YSlow 分析了一下有道前端的一些策略，发现大部分都做得不错，挺专业。Web 服务器是 Apache (不是 Nginx )，不过大部分图片设置为一周过期有些问题，太保守了，其实图片不过期也没啥问题，RSS 阅读器中的静态文件其实几乎不变化–除了用户的头像。应该说，判断一个网站是否合格，看看前端优化做得如何就可以了，如果做的不好，要么是太有钱，不担心带宽和计算资源的浪费，要么是根本不考虑用户的使用感受。
对于抓取的数据全部保存的问题，我不知道有道对 Feed 抓取过的内容更新问题如何处理。谁让咱没去现场呢，等下次有机会再了解一下吧。最后一点期望：有道什么时候能把订阅数让 FeedBurner 正确识别? 相信对大一点的网站 Google 多少能重视一点吧 ?
–EOF–
今年以来，一些小型但有针对性的技术沙龙逐渐活跃起来了，嗯，杭州，在 5 月份之后也将开搞，敬请期待。
肯定有人问哪里有 PPT ? 访问 Club.blogbeta.com
另参见：霍钜的 《关于有道阅读的beta技术沙龙》
一直比较好奇 FriendFeed 网站背后的技术信息。Bret Taylor 的一篇 How FriendFeed uses MySQL to store schema-less data 给出了不少有价值的经验。
FriendFeed 用 MySQL 存储绝大部分数据，超过 2.5 亿条记录。对待网站功能的态度: 让既有功能满足更多用户而不是添加更多的功能。
少添加新功能的好处是数据库 Schema 变化更小。在数据库Sharding 的情况下，如果修改 Schema 结构，必然会影响可用性。此外，几乎不进行复杂一点的关系型查询(比如 不做 JOIN 操作 — 这要用到传统意义上的索引机制 )。FriendFeed 也没有采用什么更新的数据库解决方案(比如 CouchDB )，原因无他，对 MySQL 更谙熟，知道其短长，扬长避短同样能发挥更大的作用。
这是 FriendFeed 对付数据库的基本策略。只存储基本的对象属性，如果需要修改 Schema 层面的东西，只需要存储新的属性即可。其实就是更加”面向对象”，由基本的「元数据」一步一步衍生到所有的数据对象。
坚持「去索引化」，因为维护索引带来了复杂度，将索引数据存储到到表上。我认为这也是反范式的一个新的思路。在 Bret Taylor 文章的 「Details」 一节中给出了具体的例子。比如要在 user_id 上进行索引，那么创建 index_user_id 表(存储来自所有 Shard 的数据)，以 user_id 和 entity_id 为主键即可。这样在修改基表的时候，不需要对其他「索引」表做变动。而删除「索引」也极为方便–删除创建的「索引表」即可。
关于一致性可能会有问题，但是可以确定基本原则：
写入数据的时候按照如下顺序：
在读取的时候可能会有短暂的数据不一致性的现象，但很快就能校正。考虑到 FriendFeed 业务的容忍性，这个问题并不严重。
总体感觉，FriendFeed 用了一种非常巧妙的方式进行数据库扩展（多耗费了一点存储空间)。不过这个方式总体上看来，极大减少了手工维护成本。相信 FriendFeed 分享的这个经验能给国内一些需要处理即时信息的站点一些启发。以上只是我的个人理解，如果去看一下 Bret 文章后面的留言，你肯定能得到更多信息（比如为何使用 UUID )。
最后提一下，FriendFeed 用 pickle 做 Python 的对象序列化。当然 Memcached 也是居家旅行必备佳品。
–EOF–