应用从单机到分布式的演变

最近看了一篇关于Mysql优化的文章，里边有句话，不是特别理解如今大家都会搞点分布式，应用程序扩容比数据库要容易得多，所以实施原则是数据库少干活，应用程序多干活。

看完这段话，心里有两个问题：
1，分布式我听的太多了，但还真是不知其所以然，那分布式到底是什么？。
2，为什么应用程序扩容比数据库容易？

带着这两个问题，于是查了很多概念，看了很多文章，做了总结。最终总结出了这篇文章。

网上一些很抽象的解释就不往这上边粘了，直接进入主题，看完就有答案了（本文以一个最常引用的电商系统为例）。

阶段一：

单台服务器部署应用，电商系统应用和数据库部署在同一台服务器上。如图：

阶段二：

应用服务与数据库服务分离，将电商系统和数据库分开部署，置于两台服务器上。此时仅需要让电商系统远程连接数据库即可，能有效缓解应用服务器的压力。如图：

阶段三：

将电商系统多服务器部署，其实也就是集群。这样可以缓解单服务器的压力。如图：

阶段四：

增加负载均衡器。不仅能够解决请求转发问题，同时还能避免请求在服务器之间的负载不均衡问题，可以有效的提高系统的性能。

**负载均衡器可以对服务器的运行状况进行监控，而且能够及时发现运行异常的服务器，当发现某一台服务器异常后，它可将访问请求转移到其它可以正常工作的服务器上。**这样的话，系统以后就可以根据业务量的增长情况灵活增加服务器，使系统的扩展能力得到提高，同时也简化了管理。如图：

阶段五：

多机部署数据库服务。一台数据库服务器处理读操作，一台数据库服务器处理写操作。如图：

阶段六：

增加缓存服务器，降低查询数据库的查询频率，减轻查库带来的压力。如图：

阶段七：

该阶段对数据库进行垂直/水平拆分。当表数据量增大，一张表中的字段过多的情况下对表进行垂直拆分。当单表数据量过大时对表进行水平拆分，从而提高数据库的DDL/DML操作效率。

阶段八：

对我们的电商应用系统进行垂直拆分。将电商系统拆分成，用户系统、商品系统和订单系统。

阶段九：

SOA服务，直到现在才算是一个分布式的架构。将整个电商服务拆分成多个服务节点。

看完这九个演变之后，再进行总结什么是分布式，会容易理解很多。我觉得通过区别集群和分布式，更容易让我们理解分布式。

分布式是指将不同的业务分布在不同的地方（就好比我们将电商系统分成了用户、商品、订单三个服务，分别部署到不同的服务器中）。而集群指的是将几台服务器集中在一起，实现同一业务（就像最开始，我们将电商系统部署到多台机器上，通过负载均衡器处理分发请求给这些服务器，每一台服务器都可以处理）。分布式中的每一个节点，都可以做集群（这个也很好理解，拿用户服务这个节点来说，我们可以将其部署在多台服务器中，在处理用户请求的时候可以将请求分发给不同的用户服务器进行处理，此时这个用户服务节点就是一个集群）。 而集群并不一定就是分布式的（这个就不用解释啦）。

分布式中的一个节点挂掉，那么该节点提供的业务就不可访问了。但是集群中若有一台服务器出现故障，其它的服务器可以顶上。

分布式和集群各自是如何提升我们系统的效率的？

先举个栗子。假设一个请求需要n步操作才能完成，假设每一步执行需要1s，则在一台服务器上执行该请求需要ns。

采用分布式：提供n台服务器，每台服务器只处理一步（可以理解成一个任务，不考虑依赖），则执行这一个请求，只需要1s。
采用集群：依然提供n台服务器，每台服务器都可以独立处理这个请求。此时假设有n个请求同时到达，这n台服务器同时工作，1s后，这n个任务都完成了。其实这还是1s完成了一个请求。

总结：分布式是通过缩短单个请求执行的时间来提高效率，集群是通过提高单位时间内执行的任务数来提高效率。