架构的发展过程
一个成熟的大型网站系统架构并不是一开始就设计的非常完美的,也不是一开始就具备高性能，高可用，安全性等特性，而是随着用户量的增加，业务功能的扩展慢慢完善演变过来的。在这个发展过程中,开发模式,技术架构等都会发生非常大的变化。
假如系统具备一下功能：
用户模块：用户注册和管理
商品模块：商品展示和管理
交易模块：创建交易及支付结算
阶段一：单应用架构
系统的初级都是应用和数据库都放在一台服务器上。
阶段二：应用服务器和数据库服务器分离
随着网站的用户量增大，流量增大,对应用服务器和数据库服务器单独的部署机器,这样可以增加系统的性能,提高访问的效率,提高单机的负载能力和容灾的能力。
阶段三：应用服务器集群-应用服务器负载告警
随着访问量和流量的增加,假设数据库没有遇到瓶颈,对应用服务器集群来对请求进行分流,提高程序的性能。存在的问题:用户的请求由谁来转发,session如何来管理的问题。
阶段四：数据库压力变大-数据库读写分离
读写分离的话,这样以后的请求，查询的请求就可以去从库里面读数据,写的数据可以到主库中了,但是会带来几个问题：
1. 主从的数据库之间的数据同步：可以使用mysql自带的master-slave方式实现主从复制
2. 对应的数据源的选择：采用第三方数据库中间件，例如：mycat
阶段五：使用搜索引擎缓解读库的压力
数据库做读库的话,常常对模糊查询的性能不是很好，特别是对于大型的互联网公司来说，想搜索的模块就比较核心了，这是可以使用搜索引擎了，虽然可以大幅度的提高查询的速度,但是同时也会带来一些问题比如索引的构建。
阶段六：引入缓存机制缓解数据库的压力
对一些热点的数据,可以使用redis，memcache来作为应用层的缓存;另外在某些场景下,可以使用mongodb来替代关系型数据库来存储。
阶段七：数据库的水平/垂直拆分
垂直拆分：把数据库中不同的业务数据拆分到不同的数据库中。
水平拆分：把同一个表中的数据拆分到两个甚至更多的数据库中,水平拆分的原因是某些业务量数据量大的已经达到了单个数据库的瓶颈,这时候可以采取将表拆分到多个数据库中。
阶段八：应用的拆分
随着业务的发展，业务越来越多，应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑将应用拆分，按照领域模型将我们的用户，商品，交易分拆成子系统。
这样拆分以后，可能会有一些相同的代码，比如用户操作，商品的交易查询，所有会导致每个系统都会有用户查询和访问相关的操作。这些相同的代码和模块一定要抽象出来。这样有利于维护和管理。
服务拆分以后，服务之间的通信可以通过RPC技术，比较典型的有：webservice、hession、http、RMI等。