关于Facebook技术架构的那些事

1. Scaling Facebook to 500 Million Users and Beyond

http://www.facebook.com/note.php?note_id=409881258919

Efficiency is important but we think of it as a separate project from scaling. Scaling usually hurts efficiency, and efficiency projects rarely give you enough improvement to have a big effect on scaling.

在CAP理论下，我觉得C一般是大家要选择的，否则的话会跟传统模型相差太远，风险也会比较大。那么在此基础上，Scale和efficiency 到底更重要呢？就Facebook而言，上面的解释回答了这个问题，Scale的重要性要大于Efficiency。本质上，Scale代表能不能，即如果不能scale out，那么就无法提供服务，就得死亡；而Efficiency代表好不好，即如果Efficiency做的不好就会比较浪费。归根结底，能不能的问题比浪费不浪费的问题更加重要。所以在运计算领域，Scale的优先级应该是高于Efficiency的。

2. Inside Message Application Server : Dark Launches

http://www.facebook.com/note.php?note_id=10150162742108920

Facebook在Message internal arch中第一次提到了"Dark Launches"这个词，看起来意思是新系统开发完成后，模拟线上实际压力来测试非常困难，那么就可以干脆直接迁移一部分线上用户到新的系统上以观察新系统的行为是否符合预期。Google也使用了类似的技术，比如Google会针对某些用户返回新的排序算法得出的结果，然后通过观察用户点击来判断新的排序算法是否更好。上面技术最大的好处是：真实，免费，当然，风险也不小，没有技术实力不要干这些事情。还是老老实实找点测试用户，发点银子吧。