大型分布式网站演变架构

       正文之前先和大家闲扯一下。作为一个程序员，我们还是需要思考未来的出路，但感觉一直做技术也不是个头。我不像其他博主那么牛叉，差不多都是百度，阿里，腾讯的大神级人物。但是归结于一点，不管你身在何处，总归还是想有自己的一番事业，有一家属于自己或者合伙的公司！这段时间我一直在思考自己未来的出路在哪里？面对家庭压力，事业瓶颈该怎么去突破，一直很困扰！如果有相似境遇的人大家可以一起交个朋友私下聊聊！

邮箱：zmdc5656@163.com

心里的话说出来也算好受一点，话不多说，下面切入正题

一、传统项目架构

      定义：传统项目其实就是一个Web工程，里面包含所有组件(数据库连接组件，数据持久层组件，业务逻辑层，控制器，页面资源)  + 单机数据库，同时如果有资源需要上传的   话，也是上传到本地工程服务器！

      优点：适合小型项目，能够快速开发，不需要针对环境做太多复杂的部署，灵活性强，增添功能，文件相对容易

      缺点：项目需求增多项目的会继续增大，不能灵活的拆分模块，随着业务的增大拆分极度困难，耦合高！用户量增大更加的容易导致单机瓶颈，响应慢，或者系统崩溃。

二、传统项目架构 + web负载均衡

      随着 "一" 中用户访问量的增加单机性能达到瓶颈那么我们可以通过添加web服务器的方式来提高访问量，可以进一步缓解大用户量的访问需求。这或许对经验不足的朋友看来有点难理解，下面我画一幅草图大家可以大致明白。

     这里引入一个新的概念就是负载均衡服务器，apache服务器本身也有负载均衡的作用，但是这里不是很常用因为其并发性和稳定性不是特别高，因此不推荐。再有就是市面上比较流行Nginx，各大互联网公司应该都在使用，其性能极高，大家可以百度一下Nginx的各方面性能，极力推荐。如果公司预算充足的话，可以买硬件资源来做负载均衡器，比如H5服务器等，但是价格会比较高！

     补充(负载均衡器的定义)：负载均衡机就好比一个汽车调度中心，所有的汽车到来都先经过调度中心，然后告知每辆车停哪个车位，最后在停到具体车位上去，车位就相当于(Web服务器)

三、传统项目架构 + web负载均衡 +  数据库集群 

       “二“ 中服务器架构可以进一步增大系访问量，但是随着时间的推移，发觉数据库的数据量越来越大，有点跑不动了，那么这个时候又需要针对系统做另一部改进了。大家看如下图。

相对于二中我们增加了一台数据库服务器，这里只是一个例子，如果数据库还不够用，可以考虑多增加一些写入数据库和读取数据库，博主在这里，只举一个典型的例子，能够起到抛砖引玉，举一反三的作用。

架构难点详解：1：写入数据库和读取数据库之间如何进行数据同步呢。2：怎么通过web服务实现读写分离呢？请大家带着问题细细的往下看。

问题一数据库同步的问题相对来说比较容易解决网上有很多解决方案,MySql数据同步，搜索就一大把这里就不多做解释。

问题二可能相对来说有点难：其实这里有两种解决方案，一是引入数据中间件，二是在Web运用层开启AOP，通过切面的方式动态切换数据源，前提是需要自己制定好切面的规则。

四、传统项目架构 + web负载均衡 +  数据库集群 + 数据库垂直拆分

备注：数据库集群也叫数据库的水平扩展

继续随着用户访问量增加，以及单表数据达到上限(数据库达到几千万，甚至上亿条数据)，这个时候应该考虑针对每张表做水平切分，切分的规则由自己制定！

因此架构的整体难度又将大大增加，如果继续在Web层面做一些改进会导致耦合性增加，而且不利于再扩展，因此需要对“三”中架构做相对改造，引入数据中间件，先看如下图

架构越来越庞大，大家一定要细心的读取和看博文，下面我解释一下大概思路：

我们不能够继续沿用三中的架构方式，不能够在Web层面开启AOP做一个读写分离了(原因上面已经说过)，这里需要引入数据中间件服务器。每当有数据访问的时候，我们先访问中间件，在通过规则引擎分配到切片上，如果有写入操作直接走分片的写数据库，读操作直接走读服务器，这样把原本一张表的的数据可以分别分配到两个不同的数据库中，大大的缓解了数据访问的压力。

五、传统项目架构 + web负载均衡 +  数据库集群 + 数据库垂直拆分 + 缓存技术

但是随着数据量再次增多，还是发觉系统可能会响应较慢，这个时候，我们可以通过缓存技术来提升访问销量，目前常用的缓存技术：ehcache，memcached，redis,Mongo...

这些技术也是普遍常用的,各个技术的优劣大家可以下来百度查找一下。