高可用的应用
应用层主要处理网站应用的业务逻辑,因此有时也称作业务逻辑层,应用的一个显著特点是应用的无状态性。
所谓无状态的应用是指应用服务器不保存业务的上下文信息,而仅根据每次请求提交的数据进行相应的业务逻辑处理,多个服务实例(服务器)之间完全对等,请求提交到任意服务器，处理结果都是一样的。
通过负载均衡进行无状态服务的失效转移
负载均衡,顾名思义,主要使用在业务量和数据量较高的情况下,当单台服务器不足以承担所有的负载压力时,通过负载均衡手段,将流量和数据分摊到一个集群组成的多台服务器上,以提高整体的负载处理能力。
目前,不管是开源免费的负载均衡软件还是昂贵的负载均衡硬件,都提供失效转移功能。在网站应用中,当集群中的服务是无状态对等时,负载均衡可以起到事实上高可用的作用。
由于负载均衡在应用层实际上起到了系统高可用的作用,因此即使某个应用访问量非常少,只用一台服务器提供服务就绰绰有余,但如果需要保证该服务高可用,也必须至少部署两台服务器,使用负载均衡技术构建一个小型的集群。
应用服务器集群的Session管理
应用服务器的高可用架构设计主要基于服务无状态这一特性,但是事实上,业务总是有状态的,在交易类的电子商务网站,需要有购物车记录用户的购买信息,用户每次购买请求都是向购物车中增加商品;在社交类的网站中,需要记录用户的当前登录状态、最新发布的消息及好友状态等,用户每次刷新页面都需要更新这些信息。web应用中将这些多次请求修改使用的上下文对象称作会话(Session),单机情况下,可由部署在服务器上的web容器(如管理。在使用负载均衡的集群环境中,由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上,所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。
Session复制是早期企业应用系统使用较多的一种服务器集群管理机制。应用服务器开启web容器的复制功能,在集群中的几台服务器之间同步对象,使得每台服务器上都保存所有用户的Session信息,这样任何一台机器宕机都不会导致数据的丢失,而服务器使用时,也只需要在本机获取即可。这种方案虽然简单,从本机读取Session信息也很快速,但只能使用在集群规模比较小的情况下。当集群规模较大时,集群服务器间需要大量的通信进行Session复制,占用服务器和网络的大量资源,系统不堪负担。而且由于所有用户的Session信息在每台服务器上都有备份,在大量用户访问的情况下,甚至会出现服务器内存不够Session使用的情况。
Session绑定可以利用负载均衡的源地址Hash算法实现,负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上(也可以根据Cookie信息将同一个用户的请求总是分发到同一台服务器上,当然这时负载均衡服务器必须工作在HTTP协议层上。这样在整个会话期间,用户所有的请求都在同一台服务器上处理,即Sesion绑定在某台特定服务器上,保证Session总能在这台服务器上获取。这种方法又被称作会话黏滞。但是Session绑定的方案显然不符合我们对系统高可用的需求,因为一旦某台服务器宕机,那么该机器上的也就不复存在了,用户请求切换到其他机器后因为没有而无法完成业务处理。因此虽然大部分负载均衡服务器都提供源地址负载均衡算法,但很少有网站利用这个算法进行Session管理。
网站没有客户端,但是可以利用浏览器支持的Cookie记录Session。利用Cookie记录也有一些缺点,比如受大小限制,能记录的信息有限;每次请求响应都需要传输影响性能;如果用户关闭访问就会不正常。但是由于Cookie的简单易用,可用性高,支持应用服务器的线性伸缩,而大部分应用需要记录的信息又比较小。因此事实上,许多网站都或多或少地使用记录Session。
Session服务器是高可用、伸缩性好、性能好、对信息大小没有限制的服务器集群Session管理方案。利用独立部署的服务器(集群)统一管理应用服务器每次读写时,都访问服务器。这种解决方案事实上是将应用服务器的状态分离,分为无状态的应用服务器和有状态的服务器,然后针对这两种服务器的不同特性分别设计其架构。对于有状态的服务器,一种比较简单的方法是利用分布式缓存、数据库等,在这些产品的基础上进行包装,使其符合Session的存储和访问要求。如果业务场景对管理有比较高的要求,比如利用服务集成单点登录、用户服务等功能,则需要开发专门的Session服务管理平台。