在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（1015或250）来计算——可伸缩性是生死交关的问题。
在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消 耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。
可伸缩性有很多侧面——事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验，本文总结了其中若 干关键的最佳实践。可能很多最佳实践你会觉得似曾相识，也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。
美国计算机科学家，LaTex的作者Leslie Lamport说：“分布式系统就是这样一个系统，系统中一个你甚至都不知道的计算机出了故障，却可能导致你自己的计算机不可用。”一语道破了开发分布式系统的玄机，那就是它的复杂与不可控。所以Martin Fowler强调：分布式调用的第一原则就是不要分布式。这句话看似颇具哲理，然而就企业应用系统而言，只要整个系统在不停地演化，并有多个子系统共同存在时，这条原则就会被迫打破。盖因为在当今的企业应用系统中，很难寻找到完全不需要分布式调用的场景。Martin Fowler提出的这条原则，一方面是希望设计者能够审慎地对待分布式调用，另一方面却也是分布式系统自身存在的缺陷所致。无论是CORBA，还是EJB 2；无论是RPC平台，还是Web Service，都因为驻留在不同进程空间的分布式组件，而引入额外的复杂度，并可能对系统的效率、可靠性、可预测性等诸多方面带来负面的影响。
常有人跟我讨论我在blog上发布过的博文，有时候他们还希望我来撰写某些文章。在讨论的过程中，我几乎总是会问为什么你自己不开一个博客，或者为其他人的博客做些贡献呢？当我在引导他们为技术类的主题写一些博文时，极少有人对此感兴趣。
我的母亲总是告诉我（以及她的学生们）每个人都有自己的故事。她说，写作可能是一种你不曾想到过的非常有益处的行为，直到你写的东西获得了其他人的喜爱和赞同。就像软件开发者为他们的用户开发软件一样，作家为他们的读者而写作。从来都没有什么论断说技术人员无法成为激励他人学习并乐于同他人分享知识的优秀作者。
我写这篇博文的目的就是想鼓励广大的技术人员去享受写作、高效的写作，并能够从中得到乐趣。我将翻出一些我曾经最常见到的关于为什么技术人员不愿意写博客的理由。
所谓”编程风格”（programming style），指的是编写代码的样式规则。不同的程序员，往往有不同的编程风格。
有人说，编译器的规范叫做”语法规则”（grammar），这是程序员必须遵守的；而编译器忽略的部分，就叫”编程风格”（programming style），这是程序员可以自由选择的。这种说法不完全正确，程序员固然可以自由选择编程风格，但是好的编程风格有助于写出质量更高、错误更少、更易于维护的程序。
所以，有一点应该明确，“编程风格”的选择不应该基于个人爱好、熟悉程度、打字工作量等因素，而要考虑如何尽量使代码清晰易读、减少出错。你选择的，不是你喜欢的风格，而是一种能够清晰表达你的意图的风格。这一点，对于Javascript这种语法自由度很高、设计不完全成熟的语言尤其重要。
