我没有引用更深的文章，我只是引用了实用的两篇文章，呵呵，我很浅薄！
1、Oracle的Cameron Purdy分10个模式剖析可伸缩性的实现
- 10、理解问题Understanding the Problem
- 9、定义需求Define the Requirements
- 8、架构胜于技术Architecture Trumps Technology（对于这点，本人深表迷茫，可能是资历太浅，我并不是说技术会强于架构，因为一定程度上来说，架构其实也是一种技术。）
- 7、理解关键要素点Understand the Basics（这也是业务建模中的重点，详细可以参考NCR的相关建模资料书籍）
- 6、网络可视化Visualize the Networks（硬件上的部署应该进行可视化，而更多的是应该对系统周边的情况进行理解，例如BI项目的所谓三位一体论：管理、技术和应用，也正如ITIL的主旨所强调，一个项目的成功应该是有一个强势的领导。）
- 5、设计可视化Visualize the Design(在MSF中所说的Work toward a share vision)。
- 4a、负载计划Plan for overload.
- 4b、
分割度量Partition for Scalability（InfoQ上如是翻译，我觉得是否应该翻译成“分割以适应扩展性”更为妥当？SDN的网络实在垃圾，看不到WebCast，非常郁闷） - 3a、失败计划Plan for Failure
- 3b、复制可用性Replicate for Availability
- 2、
值得实现伸缩性的点Tier Where It Makes Sense（InfoQ上的这个翻译更加不靠谱，是不是“合理的进行分层”的意思？） - 1、简化Simplify
先生的开宗明义，将架构的伸缩性最终（最初）原则定义为“简化”真是出乎意料，但是从上面的角度来看，似乎很少有真正技术层面的东西——呵呵，难道这些都不是技术，只有编码才算么？
英文原文（ InfoQ 摘要），SDN上面先生的讲座。
2、eBay的伸缩性最佳实践 Scalability Best Practices: Lessons from eBay
这篇文章没有中文翻译，直接看英文原版了，俺的水平有限得很，翻译的有出入各位见谅。
- 按照功能点分割Partition by Function（横向分割）
- 基本思想就是按照编写程序中的不同域分割来对功能进行分割，文章支出，可以对应用池进行分割，例如销售是一个应用池、拍卖竞价是另外一个应用池，搜索又是一个应用池；在数据库方面则进行直接按照用户存储、业务数据存储、商品存储等等对数据库进行专属分割。
- 从这一点来看，eBay肯定是少不了一个类似分发器(Dispatcher)的总控台或许这个东西还支撑着一个叫做Processor的东西，专门处理用户请求。
- 但是不得不承认，这样的功能性划分有效的分割了功能热区和数据热区，的确增强和很大的伸缩性。
- 垂直分割Split Horizontally
- 看来作者也是不好对这个东西进行命名，呵呵，对应于上面的水平分割。
- 避免分布式事务Avoid Distributed Transactions
- 分布式事务，为啥是分布式事务啊，最近看了很多这方面的材料，作为学院派的人，都喜欢吧这个东西作为圭臬，因为他的优点的确无法反驳，而作为实用主义的人，我反对在系统中使用分布式事务，因为性能影响，可惜性能是根据不同的应用而定，这样就需要更多的实证，难道我拿着这条告诉我们的Manager说“eBay也不赞成使用分布式事务，我们也不应该如此”，很显然，这违背了实用主义最初的原则：实用的前提就是实证。
- 在实际应用中，我采用规避的方式绕开分布式事务，我无法估算出在大量并发的时候分布式事务会对性能带来多少负面影响，但是我能明确指出如果不使用分布式事务可能会出现的问题以及如何“尽可能”的规避这些问题。
- 在前面的项目中，我很遗憾的看到我最初提出的分布式事务的质疑在项目中重现，也很开心的看到，我们的团队在将分布式事务分布到我们的代码之外——最佳实践的确需要时间。
- 使用异步方式解藕函数Decouple Functions Asynchronously
- 将处理流程转移到异步“流”中Move Processing To Asynchronous Flows
- 尽可能的进行抽象Virtualize At All Levels
- 适当的进行缓存Cache Appropriately
- eBay的工程师很谨慎的采用了Appropriately这样的字眼，的确，缓存需要慎重，如果缓存使用的不好，很有可能造成另外一场灾难。
3、是否需要考虑技术？加速网站的最佳实践
本来我想继续写下去，看来链接的文章已经很详细了，我没有必要深究了，呵呵。继续准备下一篇文章吧。
最近在看文章的时候，我看到了两个比较遗憾的项目，一个是北京的自动售票的阶段性失败，另外一个是订单系统的失败。在这里我不想过多的评价这两个系统的失败，只想说，我看到我们的系统同样存在这些问题，以此为镜啊。