L7负载平衡
还有一种较为经常使用的负载平衡解决方式则是L7负载平衡。顾名思义，其主要通过OSI模型中的第七层应用层中的数据决定怎样分发负载。
在执行时。L7负载平衡server上的操作系统会将接收到的各个数据包组织成为用户请求，并依据在该请求中所包括的的数据来决定由哪个服务实例来对该请求进行处理。其执行流程图大致例如以下所看到的：
相较于L3/4负载平衡服务所使用的数据，L7负载平衡服务所使用的应用层数据更贴近服务本身，因此其具有更精确的负载平衡行为。
在前面对L3/4负载平衡的解说中我们已经介绍过，对于某些具有关联关系的各个请求。L3/4负载平衡server会依据某些算法（如计算IP的哈希值）来决定处理该请求的服务实例。可是这样的方法并非非常稳定。
当一个服务实例失效或用户的IP发生变化的时候，用户与服务实例之间的相应关系就将发生改变。此时用户原有的会话数据在新的服务实例上并不存在。进而导致一系列问题。
事实上产生这个问题的最根本原因就是用户与服务实例之间的关联关系是通过某些外部环境创建的，而并非由用户/服务实例本身来管理。因此它不能抵御外部环境变化的冲击。假设要在用户和服务实例之间建立稳定的关联关系。那么就须要一种稳定的在用户和服务实例之间传递的数据。在Web服务中。这样的数据就是Cookie。
简单地说。基于Cookie的负载平衡服务实际上就是分析用户请求中的某个特定Cookie并依据其值决定须要分发到的目标地址。
其主要分为两种方式：Cookie Learning以及Cookie Insertion。
Cookie Learning是不具有侵入性的一种解决方式。其通过分析用户与服务实例通讯过程中所传递的Cookie来决定怎样分派负载：在用户与服务第一次通讯时，负载平衡服务将找不到相应的Cookie。因此其将会把该请求依据负载平衡算法分配到某个服务实例上。
而在服务实例返回的时候，负载平衡server将会把相应的Cookie以及服务实例的地址记录在负载平衡server中。当用户再次与服务通讯时，负载平衡server就会依据Cookie中所记录的数据找到前一次服务该用户的服务实例，并将请求转发到该服务实例上。
这么做的最大缺点就是对高可用性的支持非常差。假设一旦负载平衡server失效，那么在该负载平衡server上所维护的Cookie和服务实例之间的匹配关系将全部丢失。这样当备份负载平衡server启动之后。全部的用户请求都将被定向到随机的服务实例。
而还有一个问题就是会话维护功能对内存的消耗。与L3/4server上的会话维护不同，一个Cookie的失效时间可能非常长，至少在一次用户使用中可能会持续几个小时。对于一个訪问量达到每秒上万次的系统而言，负载平衡server须要维护非常多的会话，甚至可能会将server的内存消耗殆尽。反过来，假设将负载平衡server中的Cookie过期时间设置得太短，那么当用户又一次訪问负载平衡server的时候，其将被导向到一个错误的服务实例。
除了Cookie Learning 之外，还有一种经常使用的方法就是Cookie Insertion。其通过向响应中加入Cookie以记录被分派到的服务实例，并在下一次处理请求时依据该Cookie所保存的值来决定分发到的服务实例。在用户与server进行第一次通讯的时候。负载平衡server将找不到分派记录所相应的Cookie，因此其会依据负载平衡算法为该请求分配一个服务实例。在接收到服务实例所返回的数据之后。负载平衡server将会向响应中插入一个Cookie。以记录该服务实例的ID。
当用户再次发送请求到负载平衡server时，其将依据该Cookie里所记录的服务实例的ID派发该请求。
相较于Cookie Learning，Cookie Insertion不须要在内存中维护Cookie与各个服务实例的相应关系，并且在当前负载平衡server失效的时候，备用负载平衡server也能够依据Cookie中所记录的信息正确地派发各个请求。
当然，Cookie Insertion也有缺陷。
最常见的问题就是浏览器以及用户自身对Cookie的限制。在Cookie Insertion中。我们须要插入一个额外的Cookie 来记录分配给当前用户的服务实例。可是在某些浏览器中，特别是移动浏览器中，经常会限制Cookie的个数。甚至只同意出现一个 Cookie。为了解决问题，负载平衡server也会使用一些其他方法。如Cookie Modification，即改动一个已有的Cookie使其包括服务实例的ID。
而在用户禁用了Cookie的时候，Cookie Insertion将是全然失效的。此时负载平衡服务所能利用的将不过JSESSIONID等信息。因此在一个L7负载平衡server中，Cookie Learning和Cookie Insertion经常同一时候使用：Cookie Learning会在用户启用Cookie的时候起主要作用。而在Cookie被用户禁用的情况下则使用Cookie Learning来依据JSESSIONID来保持用户与服务实例之间的关联关系。
也许您会想：L3/4负载平衡server在处理各个关联请求的时候是通过IP的哈希值来决定处理该请求的服务实例的。
既然这些基于Cookie的解决方式能达到100%的准确，为什么我们不在L3/4负载平衡server中使用它们呢？答案是：因为L3/4负载平衡server主要关注于数据包级别的转发。而Cookie信息则藏匿于数据包之中，因此L3/4负载平衡server非常难决定单一的数据包该怎样转发。
比如在执行Cookie Insertion操作的时候，原有数据包中的全部数据都将被后移。此时须要负载平衡server接收到全部数据包之后才干完毕：
试想一下接收全部数据包所可能发生的事情吧。在网络的一端发送多个数据包的时候，网络的还有一端所接收到的数据包的顺序可能与原有的发送顺序并不一致。
甚至在网络拥堵的时候，某些数据包可能会丢失，进而再次加长接收到全部数据包所须要的时间。
因此相较于将数据包直接转发的方法，等待全部的数据包到齐然后再插入Cookie的性能非常差。在后面对于解决方式的解说中您会看到，L3/4负载平衡server对于性能的要求一般来说是非常高的。而L7负载平衡server则能够通过一个集群来解决自身的性能问题。基于DNS的负载平衡，L3/4负载平衡server以及L7负载平衡server经常协同工作。以组成一个具有高可用性以及高可扩展性的系统。