日前参加了一场淘宝网架构师黄裳带来的技术分享，在最后他总计了淘宝这几年来的架构经验，这里和大家分享一下：
- 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--
拜读了，放弃一致性是很无耐的事情，异步和批处理难免遭遇IO瓶颈，只能根据用户体验来做相应优化了，感觉不到的延迟就不管了。
是否可以分享ppt之类呢，或者更多一些内容。
CAP三角原则和业务需求
可用性，一致性，可扩展性原则
根据业务的需要才是本质，首先搞清楚业务的需求。
技术只是手段，总有变通的方法。
eBay的经验有道理，不可以完全照搬。
比如，第二条，asyns什么，什么可以async，一定是要清楚了才可以做到架构里面。
支持laotudou的意见。前段时间玩MPI就深刻体会到了不是什么都async就好的。async需要有memory buffer，在memcpy本来就昂贵的时候用async反而会有挺大的性能损失（50%～100%）。
@liuliu
你可能只是看单个模块的影响，这里更多是从应用调用的角度上去说"异步"
经常的关注一些来自淘宝UED的东西，最近才订阅你的博客，对于你们经常讲的架构师、紧耦合之类的对我来说的新名词真的很茫然，是不是你们开始也会遇到这样的情况，那是不是都需要再学习才可以慢慢的成长，对于学习或者成长之路望指点一二，在此先谢过了！
是啊。我依稀记得有句话是： 坚决抵制分布式事务。但是好像还听到有人说过在一些非常核心的地方(比如帐务)还是需要分布式事务的。不知道老大们有什么建议没？
对，坚决地址分布式事务。这是一条准则。