任何的大型系统架构都不是一朝一夕出现的，全部都是从微小之时从最小的架构不不断发展出来的。目前来说，最常见的网站架构如下图所示：

    

     在网站最微小的时候，所有的服务都部署在一台服务器上，也就是所谓的all in one。即如下所示：

       如上图所示，这里的后台Application、数据库、文件服务器全部都部署在一个服务器Application Server上，但是随着业务量的上升，这里的性能开始逐渐无法跟随上业务量，这时，最简单的做法，就是将这三个服务分离部署在三台服务器上，每一个专门负责一项业务。也就是如下的架构：

       这时候，如果此时，并发访问量激增，数据库database就会成为该系统的瓶颈，此时我们就可以进一步对该架构进行优化，开始引入缓存机制，也就是所谓的80%的访问内容都集中在那20%上，所以此时架构就变成了这样。

       系统引入了Distributed Cache Server Cluster，即分布式缓存集群和Local Cache本地缓存。来应对大批量的并发访问请求操作，他们会先去访问Cache，只有当Cache中不存在时才回去访问Database，这样做不仅仅提高了用户的访问速度，也大大降低了数据库DataBase的访问压力。

      但随着访问量仍在增加，此时的Application便已经开始十分吃力了，这时候就可以引入负载均衡，对Application进行横向拓展为Application集群，即如下图所示：

      引入负载均衡之后，需要考虑的一个重点就在于负载均衡服务器的负载均衡策略了，是选择随机轮询策略、最小负载选择策略、权重策略、还是本地IpHASH策略等等，这些都有各自的优缺点，需要架构者自己进行权衡。

     这里一定要注意一点就是，用户在登录时，它的session是存储在服务器端的，如果这里的负载均衡策略选择不当，就会造成下次再进行登录时，用户Session的丢失，所以通常这里就会出现一些对应的解决方案，例如Session存储在cookie里面、Session负责到集群其他机器中去、或者建立一个统一的Session服务器，如下图所示：

      统一的Session Server可以保证了浏览器用户对于Session的一致性不会丢失，但是所有Session都保存在session服务器上，这里就会造成session服务器很重要，最好事做主从备份。

      随着业务量的不断发展，此时数据库明显感觉到了瓶颈，这时就可以对数据库进行主从备份，读写分库，读取时全部链接至Slave数据库，而写入则写入到master中去，再利用主从机制将两者数据库的数据备份一致，但是此时数据库主从的一致性则是开发者需要重点关注的一件事。

      

      如上图所示，数据库采取了主备，然后又采用了CDN保证了用户访问的稳定性和网络的低延时可靠性能，通过反向代理实现了用户数据的缓存，使用了分布式文件系统代替了传统的文件服务器，拓展了文件服务器的各项性能。

     此时伴随着发展，如果数据库仍然压力巨大，则可以对数据库进行分库分表，即按照表将数据库进行分库以减轻压力，同时一个表由于数据量巨大，也可以分为多个库。就演变成了以下的架构：

   

       此时各张表都独立成库，甚至容量大的表格划分成了好几个Database，但是此时又会引入一系列问题，例如两个表之间的联合查询就会带来额外的性能问题，对于Users的分页已经搜索也会产生额外的开销和问题。而且伴随着搜索量的激增，这些问题仍然得不到解决，此时数据库索引和NoSQL就出现了。

      将数据库进行分离，搜索作为一个主要负载 和业务场景承接单独的数据库，引入NoSQL Server，大大降低了某些应用数据的业务压力。

     再到后续其实还有一大堆需要关心和了解的问题需要开发者去解决，此时架构发展到这里，就已经算是一个大型的项目架构了，当然，伴随着技术的演进和发展，后续的架构发展只会越来越复杂，但是万变不离其宗，只要抓住架构发展的痛点，就可以找到解决之道。