A Word on Scalability
可扩展性经常被用作一种魔法咒语，用来表明某些东西设计不佳或者有问题。在讨论中经常听到“但那不可扩展”这样的话作为结束争论的魔法词汇。这通常表明开发人员遇到了系统架构限制其服务增长的情况。如果可扩展性被用于积极的意义上，通常是指一种期望的属性，如“我们的平台需要良好的可扩展性”。
那么，我们所说的可扩展性究竟是什么意思呢？如果在系统中增加资源会导致性能增加，且增长的方式与增加的资源成比例，那么我们说该服务具有可扩展性。一般来说，提高性能意味着需要使用更多的服务器个数，但也可以是更高的服务器配置，比如数据集增长时。
在分布式系统中，增加系统资源还有其他的原因，例如提高所提供服务的可靠性。引入冗余是防止故障的第一道重要的防线。如果增加资源而导致冗余不会导致性能下降，且始终可用的服务，则可以被称为具有可扩展性。
为什么可扩展性如此困难？因为可扩展性不能是一个事后的想法。它要求应用程序和平台在设计初就考虑到可扩展性，以便增加资源时真的能够改善性能，或者如果引入了冗余，系统性能不会受到不利影响。许多在低负载和小数据集下表现合理的算法，但是在其他情况下就会产生巨大的成本。比如请求速率增加、数据集增长或分布式系统中的节点数量增加。
第二个问题是，通过扩展规模来增长系统通常会导致系统必须适应异构性。随着新一代硬件的上线、更大或更强大的资源变得更具成本效益，或者当一些资源被放置得更远时，系统中的资源多样性增加（比如时间的流逝，系统会充斥着不同的硬件设备，不同的软件架构等）。异构性意味着系统中的某些节点能够比其他节点更快地处理或存储更多的数据，而依赖均匀性的算法在这些条件下要么崩溃，要么无法充分利用较新的资源。（比如对于一些分布式组件，他一般只将一台机器看做一个节点，但实际上不同节点的机器配置并不一样）
实现良好的可扩展性可能吗？绝对可能，但前提是我们必须在设计系统时考虑到可扩展性。对于我们构建的系统，我们必须仔细检查我们期望系统沿着哪个方向增长，在哪里需要冗余，以及如何处理系统中的异构性，并确保架构师知道在哪些条件下可以使用哪些工具，以及常见的陷阱是什么。
以上是第一篇翻译文，以后如果没有自己的想法时，会通过翻译优秀文章，保持更新blog。
翻译规则：1. 中文尽量通顺。 2. 小括号内为自己的见解
