网站的架构演进

在这里总结一下网站的架构演进。最初，一个小型的网站系统，一般是在服务器上面搭建了相应的开发环境，DB和WEB Server都在一台机器上运行，之间通过jdbc来进行连接访问。
随着网站的访问量增加，服务器的负载压力也增大。那么就将数据库和应用分开，放到两个服务器上面。再次基础上一步步的进行演变。

应用服务器方向的演进

• 为了缓解应用服务器的压力，也为了保证一台服务器down机，还有别的服务器运行程序，应用服务器由单机变为了服务器集群。它们之间没有任何交互。都是独立的向外提供服务。变为集群后有两个问题：
  1.访问时对集群中的服务器进行选择。可以在dns解析时来确定，也可以在集群服务器前加个负载均衡器（管理进入的Web数据流量和网络带宽）。（负载均衡器不做任务上的均衡，是由master来做？？）
  2.session问题。session数据存在服务器端，变为集群后，用户每次访问的web服务器不同，服务器上存储的session数据不完整，就会出现问题。有四种解决方案 （1）.nginx中的ip_hash技术能够将某个ip的请求定向到同一台服务器上，这台服务器就固定存储这个用户的信息。（2）.cookie来存储session的信息，请求时都把cookie中的session信息同步到web服务器上。（cookie如果被禁用，就无法同步。cookie存储数据的安全性也需要考虑）（3）将session数据 集中存储在一个数据库中，每次都去这个库中取数据。（4）用数据库来同步session
• 应用的拆分，将应用按照业务分开，放到不同的服务器上。

数据库层面的演进

• 数据量变大，数据库的访问量增大，数据库的压力增加？

  • 采用读写分离的办法。读库（读“源”，可能不是一个数据库）只用来读数据提供读的服务，来分担主库的压力。主库来做写的事务，事务的读也要在主库中进行。
    这样结构的变化会产生两个问题: 数据的复制问题（一般数据库有自己的复制机制，如mysql 支持 master +slave 结构），数据延迟，读库数据源的选择。
  • 读写分离的基础上，对数据进行水平拆分和垂直拆分。
    垂直拆分：按照业务来拆分，将不同业务的表拆分到不同的库当中。解决了复杂业务在一个数据库中压力过大的问题，并且这样做可以针对业务的特点做更好的优化。
    水平 拆分：将业务表的数据记录水平拆开，放到在两个具有相同的表结构的数据库当中。由于数据库所能存储的标的数据量有限，水平拆分解决了这样的问题。 水平拆分带来的影响：1.一张逻辑表分为两张物理表后，对于主键的处理（主键的重复问题，自增问题）2.两张物理表之间在sql层面相互独立，那么查询时可能就需要在应用层写两条sql语句进行关联，会导致数据库访问次数增加很多。

• 为了加速应用在响应请求时的数据的读取速度，引入缓存机制。

  • 数据缓存：数据缓存一般是，对一些数据库常用，热点的数据缓存起来。通过业务来了解到什么样的数据放在缓存系统中，应用将这些数据填充到缓存系统当中。
  • 页面缓存: 对一些热点的页面，或者页面的一部分很“热”。就将这部分数据内存放入缓存系统中。页面缓存像是以页面为单位进行数据缓存，实质是还是数据的缓存。对于页面缓存的具体实现，有两种：1.采用esi 页面片段缓存技术 2.在application服务器上做渲染和缓存 （注：以下进行esi的解析）

• 为了弥补关系型数据库不足，实现高并发，高性能，可扩展。引入了分布式存储。（弱化了关系数据模型）

  • 分布式存储系统有 分布式文件系统，分布式key-value系统和分布式数据库。
    （对于分布式的概念，我所理解的，服务器集群，数据库的水平拆分都属于）

扩展
esi：ESI通过使用简单的标记语言来标记出需要缓存的页面和少量需要从服务其中动态获取的页面，把他们组合起来相应给用户。通过这种控制，可以降低原服务器的负载，提高用户访问的响应时间。
esi绑在了Web服务器上，首先解析到esi 标签，解析url生产key，到缓存中查询，如果能查询到，直接输出内容。
如果没有查询到，访问 Jboss（Application Sever），请求内容，请求到数据后，将数据写入缓存，并输出。