大型Java架构演变之路

前言

关于网站架构的一些演变之路，没有那个项目是凭空而造的，都是无数次的失败，无数次的尝试，才会有产生一个含金量很高的项目，以淘宝架构为例，下图还有一些我们看不见的功能的存在，但在初期肯定都是从小网站演变过来的。文章资料参考geely大神所讲的视频写出的，请指正批评。

1.初始网站
一台服务器已经足够了，文件、数据库还有我们的应用都在一个服务器上，俗称ALL IN ONE，随着我们用户越来越多，并发越来越大，CPU、硬盘、内存等资源开始吃紧，一台服务器已经满足不了。

2.第一次演进
我们将数据服务和应用服务进行分离，给应用服务器配置更好的CPU、内存等等，而给数据服务器配置更好更大更快的硬盘，如下图，我们使用了三台服务器，当我们进行一个分离后，可以提高一定的性能和可用性，例如我们文件服务器挂了，我们还是可以操控我们的应用和数据库。随着访问的并发越来越高，为了降低接口访问时间，提升服务性能，我们进行第二次演进。

3.第二次演进
到后面我们会发现，其实有很多业务数据不需要去数据库中查询，于是我们开始使用缓存，由于百分之八十的访问，其实都只使用了百分之二十的数据，如果我们将这一部分的数据缓存下来后，我们的性能一下子就上来了，通常缓存分为两种，本地缓存和远程缓存，远程缓存又分为单机缓存和分布式缓存，通常我们使用这个架构时，需要思考几点，具有哪种特点的数据去使用远程缓存？具有哪种特点的数据去使用本地缓存？分布式缓存在扩容时，会遇到什么问题？如何解决？分布式算法都有哪几种？各有什么优缺点？

4.第三次演进
随着访问的QPS不断升高，服务器的处理能力将成为一个瓶颈，这时候我们将做一个服务器集群，并加入一个新东西：负载均衡调度服务器，这样我们就可以横向扩展我们的服务器了，解决了服务器处理能力的一个瓶颈，这个时候我们还需要思考几个问题，负载均衡的调用策略都有哪些？各有什么优缺点？各适合什么场景？

5.第四次演进
当用户达到一定量时，而我们的读写操作都是访问数据库时，数据库将成为一个瓶颈，我们使用了数据库的读写分离，Master为主库，Slave从库，数据库的读写分离，将读操作都引入到从库中访问，将写操作都引入到主库中访问，

6.第五次演进
我们再次为我们的应用，增加了CDN和反向代理服务器，使用CDN可以很好的解决，不同地区的访问速度问题，反向代理则在服务器机房中可以缓存用户的资源。

7.第六次演进
这时候我们的文件服务器，将会出现一定的瓶颈，我们继续演进，这时候我们将文件服务器，改成了分布式文件集群，我们在使用分布式文件系统的时候，我们要考虑以下几个问题，如何不影响已部署在线上的业务访问？我们不能让某个图片突然访问不到了，是否需要业务部门帮忙清洗数据？是否需要备份服务器？是否需要重新做域名解析等等

8.第七次演进
我们还需对数据库进行一个架构的演进，我们使用一个专库专用的方式，进行一个垂直拆分，相关的业务都用自己的一个库，我们解决了一个写数据并发量大的问题，当我们把这些数据表分成不同的库的时候，又会带来哪些新问题呢？例如：我们跨业务、跨库的一个事务，如何解决？我们可以使用一个分布式事务。

9.第八次演进
当某个表的数据量远远大于其余数据表时，我们又需要对单个表进行一个水平拆分，将同一个表的数据，拆分到两个表中，这时候我们解决了单表数据量过大的问题，我们做此操作时需要注意哪些点呢，例如：都有哪几种水平拆分的方法？分页查询数据时，而用户数据又分布在User1和User2中,如何对其进行分页？

10.第九次演进
当我们对产品进行一个推广后，我们会发现我们应用服务器上的搜索量开始飙升时，当到这个时候，我们把应用服务当中的搜索功能抽取出来，单独做了一个搜索引擎，同时我们部分场景可以使用NoSQL提高性能，同时我们开发一个数据统一的访问模块，这个模块下边连着数据库集群，搜索引擎集群，还有NoSQL,解决上层应用开发的数据源问题，当然这是一个举例，各个服务的技术架构，还是需要跟进各个场景来做适配。

当然，这个架构还是最中的一个形态，这个架构还是存在很多要提升的地方，例如负载均衡服务器目前还是一个单点，一个好的架构还是需要不断的进行演进，这个过程中，我们还需要关注安全性、数据分析、监控、反作弊等，架构继续发展的话，可以发展为SOA架构，服务化，增加消息队列、任务调度、多机房部署等等。