《大型网站系统与Java中间件实践》--大型网站及其架构的演进过程(上)

我们在此定义的大型网站的要素必须包括高并发的访问量和较大的数据量，此外本身业务和系统的复杂度也是考察的方面。大型网站要支撑海量数据和非常高并发的访问量，那么它肯定是一个分布式系统。
下面的演进过程将从一个单机的交易网站开始说起

单机（单服务器）负载警告，数据库与应用分离

当网站放置在公网对外访问后，访问量不断增大，单台服务器的负载持续升高。我们可以想到的就是把数据库与应用从一台机器分到两台机器。
那么 网站结构会如下图所示

调整以后我们能够缓解当前的系统压力，不过随着时间的推移，访问量继续增加，系统还是需要继续向前演进的

应用服务器负载告警，如何让应用服务器走向集群

应用服务器压力变大时，根据对应的监测结果，可以有针对性的进行优化，我们这里要介绍的是把应用从单机变化为集群的优化方式。当应用服务器从一台变成两台。两台应用服务器之间没有直接的联系，同时依赖数据库对外提供服务。那么我们需要解决以下两个问题

* 终端用户对两个服务器访问的选择问题，我们可以通过DNS来解决，也可以通过在应用服务器前增加负载均衡设备来解决，这里我们选择第二种
* Session的问题

引入负载均衡设备

引入负载均衡设备之后的架构如图

在此之后，我们会遇到Session的问题，下面来详细介绍Session问题，以及解决方案

解决应用服务器变为集群之后的Session问题

什么是Session

  用户使用网站的服务，都需要浏览器与Web服务器多次交互，Http协议本身是无状态的，需要基于Http协议支持回话状态(Session State)的机制，而这样的机制应该可以使Web服务器从多次单独的Http请求中看到回话，也就是知道那些请求是来自那个回话的，具体实现方式是：在回话开始时，分配一个唯一回话标识（SessionId），通过Cookie把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个回话标识来告诉Web服务器请求是属于那个会话的，在Web服务器上，各个会话有独立的存储，保存不同会话的信息，如果遇到禁用Cookie的情况，那么，一般的做法就是把这个会话标识放到URL的参数中

  当应用服务器由一台变为两台之后，我们就会遇到Session的问题了：当一个带有会话标识的Http请求到了Web服务器之后，需要在Http请求的处理过程中找到对应的会话数据（Session），而问题就在于，会话数据是需要保存在单机上的。

如上述架构图所示，当我们访问网站请求的是左边的服务器，那么Session解就会在左边的服务器上创建，如果我们不做处理，就不能保证接下来的每次请求都落到同一边的服务器上，这就是Session的问题。

Session问题的解决方案

1.Session Sticky

  在单机的情况下，Session会保存在同一个机器上，那么当我们变化为多台服务器集群后，我们如果能保证同一个会话的请求都在同一个Web服务器上处理，那么对这个会话来讲，与之前单机的情况是一样的。

如果要做到这样，就需要负载均衡器能够根据每次请求的会话标识俩进行请求转发，即成为Session Sticky方式

  这个方案本身非常简单，对于Web服务器来讲，该方案和单机的情况是一样的，只是我们对负载均衡器做了处理，这个方案可以让同样Session的请求每次都转发到同一个Web服务器进行处理，非常利于针对Session进行服务器本地的缓存，不过也带来了如下几个问题

• 如果处于会话状态的服务器宕机或重启，那么这台服务器上的会话数据会丢失。如果会话中有登录数据的话，那么用户就要重新登录了。
• 会话标识是应用层的信息，那么负载均衡器要将同一个会话的请求都保存到同一个Web服务器上的话，就需要进行应用层的解析，这个开销比较大
• 负载均衡器变为了一个有状态的节点，要将会话保存到具体的Web服务器的映射。和无状态的节点相比，内存消耗会更大，容灾方面会更麻烦

2.Session Replication

  Session Replication 的实现方式是在Web服务器之间增加会话数据的同步。通过同步就保证了不同Web服务器之间的Session数据的一致性问题，一般的应用容易都支持Session Replication。与Session Sticky相比，Session Replication方式对负载均衡器没有那么多要求，不过这个方案本身也有问题，而且在一些场景下问题非常严重。

• 同步Session数据造成了网络带宽的开销，只要Session数据有变化，就需要将数据同步到所有其他机器上，机器数越多，同步带来的网络带宽开销就越大。
• 每台Web服务器都要保存所有的Session数据，如果整个集群的Session数据很多（很多人在同时访问网站），每台机器用于保存Session数据的内存占用会很严重

这就是Session Replication方案，这个方案不适合集群机器数多的场景，如果只有几台机器，这个方案是可行的

3.Session数据集中存储

  这种方案从名称就可以得出，就是将数据集中存储到一个地方。而不是保存到那一个Web服务器中，这样，无论是那台Web服务器或者是那个Session数据，最终的修改都发生在这个集中存储的地方。而Web服务器使用Session数据时，也是从这个集中存储的地方读取，这样的方式，保证了不同Web服务器上读取的Session数据是一样的。而存储Session数据的具体放方式，可以使用数据库也可以使用其他分布式存储系统。这个方案解决了Session Replication中的内存占用问题，而对于网络带宽，这个方案也比Session Replication 要好。不过还是会有一下问题

• 读取Session 数据引入了网络操作，这相对于本机的数据读取来说，增加了时延和不稳定性，不过我们的通信基本都是发生在内网，问题不大。
• 如果集中存储Session的机器或者集群有问题，就会严重影响应用

相对于Session Replication，当Web服务器数量比较大，Session数量比较多的时候，这个集中存储的方案是非常明显的

Cookie Based

  Cookie Based方案对于同一个会话的不同请求也是不限制具体的机器的，这个方案是通过Cookie来传递Session数据的。
   我们将Session数据放在Cookie中，然后在Web服务器中从Cookie中生成对应的Session数据。这个方案不依赖外部存储系统，业绩不存在从外部系统获取，写入Session数据的网络时延和不稳定性了。不过这个方案依然存在不足

• Cookie长度的限制。我们都知道Cookie是有长度限制的，而这也会限制Session数据的长度
• 安全性 。Session数据本来都是服务器端数据，而这个方案是让服务器数据到了外部网络以及客户端，因此存在安全性上的问题。我们可以对写入Cookie的Session数据做加密，不过对于安全来说，物理上不能接触才是安全的
• 带宽消耗，这里不是指Web服务器集群内部的带宽消耗，而是我们数据中心外部的带宽消耗
• 性能影响，每次Http请求和响应都带有Session数据，对Web服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发请求就会越多

小结

  对于Web 服务器从单机到多机情况下的Session问题的解决方案，这四种都是可行的方案，不过对于大型网站来说，Session Sticky和数据集中存储是比较好的方案，而这两个方案又各有优劣，需要在具体的场景中做出权衡。
  不管采用的是何种解决方案，我们都可以在一定程度上通过增加Web服务器来提升应用的处理能力。