SSL Farm
在上面的讲解中，我们忽略了一个事情，那就是L7负载平衡服务器对于SSL的支持。在L7负载平衡服务器中，我们常常需要读写请求及响应中的Cookie。但是如果通讯使用的是SSL连接，那么L7负载平衡服务器将无法对请求及响应的内容进行读写操作。
解决该问题所曾经使用的一个解决方案就是：将负载平衡服务器以反向代理的方式使用。在这种方案中，负载平衡服务器将拥有服务的证书，并可以通过证书中的密钥对请求进行解密。解密完成后，负载平衡服务器就可以开始尝试读取Cookie中的内容并根据其所记录的信息决定该请求所需要派发到的服务实例。在对该请求进行派发的时候，负载平衡服务器可以不再使用SSL连接，进而使得各个服务实例不再需要再次解密请求，提高服务实例的运行效率。
在请求处理完毕之后，服务实例将通过服务实例与负载平衡服务器的非SSL连接返回一个响应。在负载平衡服务器接收到该响应之后，其将会把该响应加密并通过SSL连接发出：
但是这样做的问题在于，如果所有对SSL的处理都集中在L7负载平衡服务器上，那么它将会变成系统的瓶颈。绕过该问题的方法就是在L7负载平衡服务器之前使用一系列反向代理来负责SSL的编解码操作。
此时整个系统的架构将呈现如下的层次结构：
从上图中可以看到，整个解决方案分为了四层。在用户的请求到达了第一层的负载平衡服务器时，其将会把该请求根据自身的负载平衡算法转发给处于第二层的专门负责SSL编解码工作的反向代理。该代理会将传入的由SSL连接所传输的请求由非SSL连接传出。在请求到达第三层时，L7负载平衡服务器可以直接访问这些请求所包含的Cookie，并根据Cookie中的内容决定需要处理该请求的服务实例。
这么做的好处有很多。首先就是这些反向代理非常便宜，甚至只有常见负载平衡服务器的1/20左右的价格，却在处理SSL连接上拥有几乎相同的效率。除此之外，这些反向代理还提供了非常良好的扩展性和高可用性。一旦负载平衡系统在处理SSL连接的能力上显得有些吃力，我们就随时可以向系统中添加新的反向代理。而一旦其中一个反向代理失效，那么其它反向代理可以通过多承担一些负载来保证系统的安全运行。