我想知道为什么电梯网络框架具有高性能和可扩展性的技术原因？我知道它使用具有 Actor 库的scala，但是根据安装说明，默认配置是使用jetty。那么它是否使用actor库进行缩放？
现在，可扩展性立即可用。只需添加其他服务器和节点，它将自动扩展，这是如何工作的？它可以处理与支持服务器的500000+并发连接。
我正在尝试为企业级创建一个Web服务框架，该框架可以超越现有的框架，并且易于扩展，可配置和可维护。我对扩展的定义只是添加更多服务器，您应该能够容纳额外的负载。
谢谢
最佳答案
Lift的可扩展性方法是在一台机器上。跨机器扩展是一个更大，更困难的话题。简短的答案是:Scala和Lift不会做任何帮助或阻碍水平缩放的事情。
就单个计算机中的参与者而言，Lift实现了更好的可伸缩性，因为单个实例可以处理比大多数其他服务器更多的并发请求。为了解释，我首先必须指出经典的每个请求线程处理模型中的缺陷。忍受我，这将需要一些解释。
典型的框架使用线程来服务页面请求。当客户端连接时，框架从池中分配一个线程。然后，该线程执行三件事:从套接字读取请求；它进行一些计算(可能涉及到数据库的I / O)；并在套接字上发送响应。在几乎每个步骤中，线程最终都会阻塞一段时间。读取请求时，它可能会在等待网络时阻塞。计算时，它可能会阻塞磁盘或网络I / O。在等待数据库时，它也会阻塞。最后，在发送响应时，它可能会阻止客户端是否缓慢接收数据以及是否填充了TCP窗口。总体而言，该线程可能会花费30-90％的时间被阻止。但是，它在该请求上花费了100％的时间。
JVM仅能支持这么多线程，然后才真正减慢速度。线程调度，共享内存实体(如连接池和监视器)的争用以及本机OS限制都对JVM可以创建多少个线程施加了限制。
好吧，如果JVM的最大线程数受到限制，并且线程数确定服务器可以处理的并发请求数，那么并发请求数将由线程数确定。
(还有其他一些问题可以施加较低的限制，例如，GC抖动。线程是一个基本的限制因素，但不是唯一的限制因素!)
提升使线程与请求脱钩。在Lift中，请求不会占用线程。而是，线程执行操作(例如读取请求)，然后将消息发送给参与者。 Actor 是故事的重要组成部分，因为它们是通过“轻量级”线程安排的。线程池用于处理参与者中的消息。避免阻塞参与者内部的操作非常重要，这样这些线程才能迅速返回池中。 (请注意，该池对于应用程序是不可见的，它是Scala对actor的支持的一部分。)例如，当前在数据库或磁盘I / O上被阻止的请求不会保留请求处理线程。请求处理线程几乎可以立即用于接收更多连接。
这种将请求与线程解耦的方法使Lift服务器比每个请求线程服务器拥有更多的并发请求。 (我还想指出，Grizzly库支持类似的方法，但没有参与者。)更多的并发请求意味着，一个单一的Lift服务器比常规的Java EE服务器可以支持更多的用户。
关于web-services - 为什么Lift Web框架具有可伸缩性？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/648964/