Address of this article: http://yunjiechao-163-com.iteye.com/blog/2126981
When a developer increases the load on a computer system, there are usually two ways to consider vertical scaling and horizontal scaling. Which strategy to choose depends largely on the problem to be solved and the constraints on system resources. In this article we will describe both strategies and discuss the advantages and disadvantages of each strategy. If you already have a software system that needs to grow, then you will choose one of these two strategies, either intentionally or unintentionally.
Vertical expansion
In the vertical expansion model, wanting to increase the system load means working on the existing components of the system, that is, by increasing the capabilities of the system components. For example, let's say you are currently in charge of harvesting a batch of lumber.
In this example, we assume that there are 3 trucks, each of which can transport 25 pieces of wood at a time, and calculate the amount of wood that can be transported to a designated location for processing if it takes 1 hour. From these numbers we can calculate the maximum load on our system:
3 trucks * 25 logs * 1 hour = 75 logs/hour
If we choose the vertical expansion model, what will we do so that we can process 150 logs per hour? We need to do at least one of the following two things:
Double the transport volume per truck (50 trees per hour), or halve the transport time per truck (30 minutes per truck).
3 trucks * 50 trees * 1 hour = 150 trees/hour
or
3 trucks * 25 trees * 30 minutes = 150 trees/hour
We did not increase the number of members of the system, but we achieved the desired load by increasing the productivity of the system members.
Horizontal expansion
In the horizontal scaling model, we do not simply increase the load on a single system member but simply by adding more system members. That is, in the above example of transporting lumber, lumber is transported by increasing the number of trucks. So when we need to increase the load from 75 trees per hour to 150 trees per hour, then only 3 trucks need to be added.
6 trucks * 25 trees * 1 hour = 150 trees/hour
If we have chosen to scale vertically, what do we need to do when we want to process 150 felled trees per hour? We need to do one of two things: either double the transport per truck (50 lumber at a time) or halve the transport time per drive (30 minutes).
3 trucks * 50 trees * 1 hour = 150 trees/hour
or
3辆卡车 * 50棵树 * 30分钟 = 150棵树／每小时
在这个例子中，系统每个成员的生产力依然没变，我们通过增加更多的卡车来提高系统的能力。
扩展你的web数据库
通过对水平扩展和垂直扩展的基本了解，下面让我们来关注web系统的扩展。一个网站通常有很多组件都需要去考虑它们的扩展性，但是我通常喜欢关注处在最边缘的一个：数据库。为什么数据库是最边缘的？因为数据库通常是共享资源，是几乎所有请求最终的连接点。
你的系统是什么类型的？
在 扩展你的数据库时，你必须要问的一个重要问题是：“我所面对的系统是什么类型的？”你所面对的是一个读操作多还是写操作多的系统？读操作多的网站一般包 括：在线商城，在商城里用户大部时间是在浏览(读操作)，只有少数时间在付款(写操作)、或者博客，在博客上人们大部分时间是在浏览博文(读操作)，只有 少数时间是在评论或者发表博文(写操作)。相反的，关于写操作非常多的很好的例子包括：信用卡交易处理器，这个系统的主要负载时在处理记录交易(写操 作)，偶尔会查找交易(读操作)、或者Google分析，主要工作实在记录业务数据(写操作)，偶尔会展示分析图(读操作)。
了解你所创建的网站是什么类型的，可以在网站成长过程中帮助你选择正确的技术。
读操作扩展
如 果你的系统读操作非常多，那么通过关系型数据库如mysql或者PostgreSql来垂直扩展数据存储是一个不错的选择。结合你的关系型数据库通过使用 memcached或者CDN来构建一个健壮的缓存系统，那么你的系统将非常容易扩展。在这种模式中，如果数据库超负荷运行，那么将更多的数据放入缓存中 来缓解系统的读压力。当没有更多的数据往缓存中放时，可以更换更快的数据存储硬件或者买更多核的处理器来获取更多的运行通道。摩尔定律使通过这种方法来垂 直扩展变得和购买更好的硬件一样简单。
写操作扩展
如 果你的系统写操作非常多，那么你可能更希望考虑使用可水平扩展的数据存储方式，比如Riak，Cassandra或者HBase。和大多数关系型数据管理 系统不同，这种数据存储随着增长增加更多的节点。由于你的系统大部分时间是在写入，所以缓存曾并不能像在读操作比较频繁的系统中起到那么大作用。很多写频 繁的系统一开始使用垂直扩展的方式，但是很快发现并不能根本解决问题。为什么？因为硬盘数和处理器数在某一点达到平衡，在这个边界上再增加一个处理器或者 一个硬盘都会是每秒钟的I/O操作数成指数性增长。相反，如果对写频繁的系统采取水平扩展策略，那么你将达到一个拐点，在这个拐点之后如果在增加一个节点 都远比使用更多的硬盘来的实惠。
其他注意事项
另 一件事需要记住的是每种扩展策略下预想不到的开销。采用垂直扩展的系统将开销凡在单独的组件上。当我们去提升系统负荷时，这些单独的组件需要在管理上花费 更多。拿我们运送木材的例子来说，如果需要使每辆卡车的货运量翻倍，那么我们需要更宽、更长、或者更高的车厢。也许有的路因为桥的高度对车辆高度有要求， 或者基于巷子宽度车宽不能太大，又或者由于机动车安全驾驶要求车厢不能太长。这里的限制就是对单个卡车做垂直扩展做的什么程度。同样的概念延伸到服务器垂 直扩展：更多的处理器要求更多的空间，进而要求更多的服务器存储架。
相反的，采用水平扩展的系统将额外的开销放在系统中连接起来的共享组件 上。当我们去提升系统负荷时，共享的开销和新增加的成员之间的协调性有关。在我们运送木材的例子中，当我们在路上增加更多卡车时，那么路就是共享资源也就 成了约束条件。这条路上适合同时跑多少量卡车？我们是否有足够的安全缓冲区使得所有的车可以同时装运木材？如果再来看我们水平扩展的数据库系统，那么经常 被忽略的开销就是服务器同时连接时的网络开销(译者注：网络为各个系统的共享资源)。当你为系统增加更多的节点时，共享资源的负荷也就越来越重，通常呈非 线性改变。
综合说明
和 计算机的大多数东西一样，好的解决办法通常并不像我这里列出来的这么简单。而我在这里尝试简化这种思想用来来说明这中概念而不是讲具体的解决办法。扩展是 个困难的问题，这是个需要在实际处理的每个步骤中都要思考的问题。扩展策略没有魔法，也没有魔法般的软件帮你建立一个完整可靠的可扩展系统。就像扩展中的 其他问题一样，一个大的解决方案通常是由很多个一起协调工作的小的解决办法组成的。这需对每一个中解决方案进行精心正确的设计和开发。