web-services - 为什么 lift web 框架是可扩展的？

Question

我想知道lift web框架具有高性能和可扩展性的技术原因？我知道它使用 scala，它有一个演员库，但根据安装说明，它的默认配置是使用码头。那么它是否使用演员库进行缩放？

现在是开箱即用的可扩展性。只需添加额外的服务器和节点，它就会自动扩展，是这样工作的吗？它可以处理 500000+ 与支持服务器的并发连接。

我正在尝试为企业级创建一个 Web 服务框架，它可以击败现有的东西，并且易于扩展、可配置和可维护。我对扩展的定义只是添加更多服务器，您应该能够容纳额外的负载。

谢谢

Answer 1

Lift 的可扩展性方法是在一台机器内实现的。跨机器扩展是一个更大、更棘手的话题。简短的回答是：Scala 和 Lift 不会做任何事情来帮助或阻碍水平扩展。

就单个机器中的参与者而言，Lift 实现了更好的可扩展性，因为单个实例可以处理比大多数其他服务器更多的并发请求。为了解释，我首先必须指出经典的每请求线程处理模型中的缺陷。请耐心等待，这需要一些解释。

典型的框架使用线程来服务页面请求。当客户端连接时，框架会从池中分配一个线程。该线程然后做三件事：它从套接字读取请求；它进行一些计算（可能涉及到数据库的 I/O）；它在套接字上发送一个响应。几乎在每一步，线程最终都会阻塞一段时间。在读取请求时，它可以在等待网络的同时阻塞。在进行计算时，它可能会阻塞磁盘或网络 I/O。它也可以在等待数据库时阻塞。最后，在发送响应时，如果客户端接收数据缓慢并且 TCP 窗口被填满，它会阻塞。总体而言，线程可能会花费 30 - 90% 的时间被阻塞。然而，它把 100% 的时间都花在了这个请求上。

JVM 在真正变慢之前只能支持这么多线程。线程调度、共享内存实体（如连接池和监视器）的争用以及本机操作系统限制都对 JVM 可以创建的线程数量施加了限制。

那么，如果JVM的最大线程数是有限的，而线程数决定了一个服务器可以处理多少并发请求，那么并发请求数将由线程数决定。

（还有其他问题可以施加较低的限制——例如，GC 抖动。线程是一个基本的限制因素，但不是唯一的！）

Lift 将线程与请求分离。在 Lift 中，请求不会占用线程。相反，一个线程执行一个操作（例如读取请求），然后向参与者发送一条消息。演员是故事的重要组成部分，因为他们是通过“轻量级”线程安排的。线程池用于处理参与者中的消息。避免在actor内部阻塞操作很重要，因此这些线程会迅速返回到池中。（请注意，该池对应用程序不可见，它是 Scala 对参与者的支持的一部分。）例如，当前在数据库或磁盘 I/O 上阻塞的请求不会保持请求处理线程被占用。请求处理线程几乎立即可用，以接收更多连接。

这种将请求与线程分离的方法允许 Lift 服务器比一个线程请求服务器有更多的并发请求。（我还想指出，Grizzly 库支持类似的没有参与者的方法。）更多并发请求意味着单个 Lift 服务器可以支持比常规 Java EE 服务器更多的用户。

Answer 2

在 mtnyguard

“Scala 和 Lift 不会帮助或阻碍水平扩展”

不太对。Lift 是高度有状态的框架。例如，如果用户请求一个表单，那么他只能将请求发布到表单来自的同一台机器上，因为表单处理操作保存在服务器状态中。

这实际上在某种程度上阻碍了可扩展性，因为这种行为与无共享架构不一致。

毫无疑问，lift 是高性能的，但性能和可扩展性是两个不同的东西。因此，如果您想通过提升水平扩展，您必须在负载均衡器上定义粘性会话，这将在会话期间将用户重定向到同一台机器。

Answer 3

Jetty 可能是入口点，但参与者最终会为请求提供服务，我建议看一下 twitter-esque 示例，“skitter”，看看您将如何创建一个非常可扩展的服务。IIRC，这是让推特人们注意到的事情之一。

Answer 4

我真的很喜欢@dre 的回复，因为他正确地指出lift 的状态是水平可扩展性的一个潜在问题。

问题 - 我不再描述整个事情，而是查看这篇文章的讨论（不是内容）。http://javasmith.blogspot.com/2010/02/automagically-cluster-web-sessions-in.html

解决方案是@dre 在前面的负载均衡器上说粘性会话配置并添加更多实例。但是由于 Lift 中的请求处理是在线程 + Actor 组合中完成的，因此您可以期望一个实例处理比普通框架更多的请求。这将比在其他框架中具有粘性会话提供优势。即单个实例处理更多的能力可以帮助您扩展

• 你有 Akka 电梯集成，这将是另一个优势。