来自淘宝的架构经验

日前参加了一场淘宝网架构师黄裳带来的技术分享，在最后他总计了淘宝这几年来的架构经验，这里和大家分享一下：

1、适当放弃一致性
2、备份和隔离解决稳定性问题
3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
4、自动化降低人力成本(类似 eBay 的 Automate Everything)
5、产品化管理

在这里不妨对比一下 eBay 的架构经验：

1、 Partition Everything
2、 Asynchrony Everywhere
3、 Automate Everything
4、 Remember Everything Fails
5、 Embrace Inconsistency
6、 Expect (R)evolution
7、 Dependencies Matter
8、 Be Authoritative
9、 Never Enough Data
10、Custom Infrastructure

关于一致性，可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外，强调了”放弃集中的紧耦合处理”的原则。”备份”这里可以理解为”提供可用的副本”。”分割”是说水平拆分。

架构这东西说起来大致原则，其实都是类似的，但是具体如何在一些通用原则上做到运用自如，是很难的事情。前几天我还感慨，很多架构师对与”异步”与”批量处理”所能带来的益处的理解仍然相去甚远。

–EOF–

企业员工应遵守的 Twitter / 微博准则

在 Twitter ( @Fenng )上发布了几条关于 “员工应遵守的Twitter 准则” 的建议。如果你也是 Twitter (或微博) 用户，以下这几条准则或许可以用来参考：

准则一：不要发布不为公众所知的和公司相关的业务数据。如果要引用公司的公开数据，不要加主观的断言。对于关注你的人来说，小道消息并非那么有价值。

准则二：不要匿名攻击公司(包括自己的雇主和竞争对手)。尽管”在互联网上没有人知道你是一条狗”，但是，雇主还是很容易知道你是公司里面的哪一位。

准则三：Twitter 上的信息具有不可修改性，被转发后会引来不同的解读。所以发布消息前要衡量是否会对同事或团队造成负面影响。如果回答为”是”，不要发布。

准则四：倾听用户的声音，收集用户反馈而不要和用户争辩，如果能够解释，进行必要的解释，但是记住不要推脱责任，尤其不要攻击或是嘲讽用户。

准则五：如果你的主管或同事不能理解或者认可Twitter会对公司带来的价值，向他们解释，同时最好能证明使用 Twitter 并非是在浪费工作时间–用 Twitter 或许比用 IM 更节省时间。

准则六：必要的时候尽可能转发对用户的警示信息，比如”系统维护公告”或”费用调整”等信息应更快更及时的传递给用户。

准则七：团队的内部规划，正在进行的项目及相关实施细节，未经相关负责人允许也尽量不要披露，以免带来各种不可预期的不利影响。

很多人在 Twitter 上发消息，不可避免的会提及自己的雇主。新用户或许意识不到 Twitter 对消息传播的便捷性会带来的破坏力，如果没有一个类似指导原则的话，可能不经意间就会对雇主造成负面干扰，也会给自己带来一定的麻烦。这里的准则或许不能覆盖所有的情况，所以更多的时候要依赖于常识来判断。

如果你在鼓励同事或者朋友来用 Twitter 或者其它微博，要向他(她)说明这些。( 感谢 @hutuworm 同学贡献了准则七)。

–EOF–

技术出版的危机

这个话题的缘起是今天我在 Twitter 上感慨了一下关于翻译稿酬的事情。我和两位同事一起翻译 Troubleshooting Oracle Performance 这本书(中文版《Oracle性能诊断艺术》），三个人，六个月时间出头，稿酬大约 15000 RMB 多一点。很多朋友可能会把这当成抱怨而非提醒。

对此，图灵出版社刘江先生回应到，”技术出版的危机。此书首印 3000 册，定价75 元（不低），利润空间仅两三万，如果部分滞销或退书，很容易就赔了。” 而且，”这本书如果按5%给版税，还不如千字稿酬。” 这实际上道出了当前英文 IT 图书引入国内的一个困境。国外出版社版权费用本已经不低(所以博文视点更倾向于做原创图书，别搞错，我说的是武汉的那个博文)，加上纸张以及印刷成本的上涨，以及图书销量连年受到网络媒体的冲击，做一本纸版书不亏本已经不容易了，现在据说在国内一本技术图书能做到 5000 册的销量就是不错的成绩了，出版社不得不通过一些不得以的手段控制成本。有一次和蔡学镛聊天，他说台湾现在的 IT 图书出版已经萎缩得不成样子，而大陆因为市场太庞大，所以一时半刻还能撑下去。

李笑来老师曾经质疑过”为什么引进书籍的翻译普遍都很差？“，他认为直接原因就是”稿费太低”。对于译者来说，如果只是为了稿费而做技术翻译的的话，绝对是一件收益不大的事情，何况，这事情本身就是一件”瓷器活儿”。翻译得好的话，必然需要投入更大的精力，而译文质量不过关，读者不会饶过你。我相信像余晟这样把翻译当作一种乐趣的人已经凤毛麟角了，而像阮一峰那样偶尔的”头脑发热“一回也是值得我们欣赏的。

国内出版社有的时候自己也扮演杀鸡取卵的事情，据我所知，多数出版社对于翻译时间的限制都比较紧，一本书，一般只给译者 3-6 个月的翻译时间，为了能在既定时间之内完工，要么找更多的的合作者–这会带来翻译风格不统一的问题，译稿质量也难免下降，要么拖延，而拖延，在合同里是写着明确条款的，会根据不同的时间扣除稿费。也就说，如果遇到了不良出版社，而你的合同时间又签得比较不利，那么可能一分钱拿不到。当然，我们这本书总体来说编辑还是比较宽松的，这是非常值得庆幸的一件事。其实话说回来，我认识的几个出版人如果他们转身去做畅销书，至少不会比做 IT 差，或许他们为了理想也在咬牙坚持。

危机，危机，危险之中机遇何在?

–EOF–

MySQL 数据库版本调查与分析

针对 MySQL 数据库的版本也做个调查。分析一下大家使用 MySQL 的趋势与习惯。选择大家都选择的，总不会有更大的错误。而如果使用了一个不太合适的版本，或许会后患无穷。

点击访问在线调查 (如果你不能访问这个 URL，需要动动脑子想想为什么)。

现阶段收集到的统计数据：

国内用户用 5.0 的是最多的。如果小版本加起来还是 5.1 的居多。4.1 的版本渐渐推出历史舞台。如果你也在考虑选择 MySQL 的版本，这个数据是否对你有参考性呢?

–EOF–