web-services - 为什么 lift Web 框架具有可扩展性？

Question

我想知道lift webframework具有高性能和可扩展性的技术原因？我知道它使用 scala，它有一个 actor 库，但根据安装说明，它的默认配置是使用 jetty。那么它是使用actor库来缩放的吗？

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

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

谢谢

Answer 1

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

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

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

JVM 在速度真正变慢之前只能支持一定数量的线程。线程调度、共享内存实体(例如连接池和监视器)的争用以及 native 操作系统限制都对 JVM 可以创建的线程数量施加了限制。

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

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

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

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