架构演变的理解
一、前言
往往谈到架构，我们都会觉得很深奥，人云亦云之间，我们遇到了各种新的词汇，各种问题，很多都是我们很难回答的，比如负载均衡、高速缓存Redis、CDN、反向代理等等词汇，作为新一代的我们往往都是将这些东西死记硬背，知其然而不知其所以然，当我们站在更高的立场上去思考这些问题的时候，可能我们看到的风景将完全不同，我一直想写一篇这样的文章来整理一下自己的思路，同时感受一下思路清晰的理解什么叫做架构，如何产生的、如何演变的，现在是什么样，以后将会什么样，带着这些问题，让我们来分析。
二、架构演变
2.1、最原始的系统
我们能够想到的，最原始的架构应该是这样的，当客户访问服务器获得资源的时候，一般是发送请求到应用服务器，应用服务器处理相应的请求，可能访问数据库服务器或者文件服务器，从而将得到的结果返回给客户，架构如图。其中，我们的应用服务器可以和文件服务器、数据库服务器在同一台机器上，甚至客户都可以是我们本机，这样的架构也是我们开发时候常用的手段（当然后来的开发过程中可能是分离了）。
2.2、各个服务器分离
对于我们上面的系统，客户访问量为1~10个的时候还是可以接受的，可是随着用户的增多，这样的架构将会遭受巨大的压力，首当其冲的就是与前端交互的应用服务器，因此，我们需要对前端进行一次升级，我们将应用服务器和后端服务器（无特殊说明指的是文件服务器和数据库服务器）分别放到不同的电脑上，通过连接件jdbc/odbc等等连接到一起。
2.3、增加服务器内缓存和分布式缓存
当用户量进一步激增的时候，我们不得不想一些其他的办法了，这时候，最方便的方法就是增加缓存了，首先我们可以在应用服务器中增加缓存，这样可以避免一部分压力，另外我们可以在外面增加分布式缓存机制，比如Memcache来减轻压力。
2.4、应用服务器集群
如上图的架构，很容易造成单点失效，其中应用服务器受到了很大的压力，因此我们使用应用服务器集群来进一步提升服务器的性能。同时因为集群的原因，我们需要使用负载均衡机制将请求导向其中的一台服务器，负载均衡分为LVS和Load Balance，分别工作在不同的层次上，各有各自的优缺点。在这里我们注意一下集群和分布式系统的差异，集群是每台计算机都能执行相应的程序，而分布式指的是将一个任务分发给多台计算机来处理。
2.5、数据库服务器读写分离
当我们一直优化前端的时候，后端也必须进行相应的优化，对于后端的数据库和文件服务器都会发生单点失效，因此我们对于数据库服务器采用读写分离架构，采用主从数据库来存取数据，实现读写分离，同时我们在应用服务器中也应该根据读写的操作选择（路由）到相应的服务器中。
2.6、在前端使用CDN和反向代理加快查找速度
当我们的集群非常庞大，客户的访问量非常多的时候，可能相应的速度就成了一个大的问题，在这里我们可以使用反向代理和CDN等技术来加速用户查找服务器的速度，首先反向代理是运行在我们的机房的，离用户比较远，会缓存用户每次的访问记录加快反应速度，而CDN是我们向相应的公司租赁的，更加靠近用户边缘，当用户访问的时候，会通过DNS服务器重定向技术或者IP anycast技术，通过CName结构将用户的访问导向离用户很近的CDN服务器中进行访问。
2.7、分布式文件和数据库服务器
此前我们的系统前端已经比较完善了，而后端还是非常的简陋，虽然增加了数据库的主从复制、读写分离，可是还是很难应付超大规模访问量的读写，因此我们将后端也变成分布式系统，比如我们使用hadoop的HDFS，HBase、zookeeper等组件来进行组织。
2.8、使用搜索引擎技术和NoSQL
在我们的实际应用中，我们往往进行大规模的查询操作，一定数量的写操作，因此NoSQL就能派上很大的用场，我们可以使用NoSQL的特性来进行大规模的查询操作，当然我们也需要关系型数据库来作为辅助，实现更高层次上的读写分离；另外当我们的数据查询遵循一定的模式的时候，我们可以做一个简陋的搜索引擎，将我们的数据进行整理，省去用户每次访问都需要的计算量，更进一步提高访问速度，在这一方面我们可以使用nutch来实现。
2.9、应用拆分
迄今为止，我们还没对应用进行相应的拆分，导致程序内部有很多相互调用，大大影响了效率，特别是对于一个成熟的系统，我们将不同的功能模块拆分出来，分布在不同的服务器集群上通过负载均衡选定相应的功能去处理，得到的结果通过消息队列传到另一个服务器集群进行相应的处理之后写入数据库。
2.10、分布式应用服务器
我们将最常用的，各个模块都需要使用的，比如身份认证，访问控制，服务注册等基础设施放在平台的最底层，这样高内聚低耦合的设计可以大大地简化程序的流程。将这些常用的功能组成一个分布式系统，而其他各种功能的系统集群通过各种调用最终访问分布式集群基础设施得到或修改相应的资源。
