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