为什么提升web框架可扩展？
我想知道为什么lift webframework具有高性能和可扩展性的技术原因？ 我知道它使用Scala，它有一个演员库，但根据安装说明默认configuration是与jetty。 那么它是否使用演员库来扩展？
现在是开箱即用的可扩展性。 只需添加额外的服务器和节点，它会自动扩展，是如何工作的？ 它能处理500000+支持服务器的并发连接吗？
我正在尝试为企业级创build一个Web服务框架，这个框架可以打败那些容易扩展，可configuration和可维护的东西。 我对扩展的定义是增加更多的服务器，你应该能够容纳额外的负载。
谢谢
Lift的可扩展性方法在一台机器内。 跨机器扩展是一个更大，更棘手的话题。 简单的答案是：Scala和Lift不会做任何事情来帮助或阻碍水平缩放。
就单个机器中的angular色而言，Lift可以实现更好的可伸缩性，因为单个实例可以处理比大多数其他服务器更多的并发请求。 为了解释，我首先必须指出传统的线程每请求处理模型中的缺陷。 忍受着我，这是需要一些解释。
典型的框架使用线程来处理页面请求。 当客户端连接时，框架从一个池中分配一个线程。 那个线程然后做三件事：它从一个套接字读取请求; 它做了一些计算（可能涉及数据库的I / O）; 并在套接字上发送一个响应。 几乎每一步，线程都会阻塞一段时间。 读取请求时，可能会在等待networking时阻塞。 在进行计算时，可能会阻塞磁盘或networkingI / O。 它也可以在等待数据库时阻塞。 最后，在发送响应时，它可以阻止客户端缓慢接收数据，并且TCP窗口被填满。 总体而言，该线程可能会花费30-90％的时间被阻止。 然而，它花费了100％的时间来处理这个请求。
一个JVM只能支持如此之多的线程才能真正减速。 线程调度，争用共享内存实体（如连接池和监视器）以及本机操作系统限制都会对JVM创build多less个线程施加限制。
那么，如果JVM的最大线程数是有限的，而且线程数决定了一个服务器可以处理多less个并发请求，那么并发请求数将由线程数决定。
（还有其他问题可能会导致下限 – 例如，GC抖动，线程是一个基本的限制因素，但不是唯一的限制因素！）
提升从请求中分离线程。 在提升中，请求不会占用线程。 而是一个线程执行一个动作（如读取请求），然后向一个actor发送一个消息。 演员是故事的重要组成部分，因为他们通过“轻量级”的线程来安排。 线程池被用来处理actor中的消息。 避免在actor中阻塞操作是非常重要的，所以这些线程会迅速返回到池中。 （请注意，该池对于应用程序是不可见的，这是Scala对actors的支持的一部分。）例如，数据库或磁盘I / O上当前阻塞的请求不会占用请求处理线程。 请求处理线程几乎立即可用来接收更多的连接。
这种从线程中分离请求的方法允许Lift服务器比一个请求线程的服务器有更多的并发请求。 （我也想指出，Grizzly库支持类似的方法没有演员。）更多的并发请求意味着一个单一的提升服务器可以支持比普通的Java EE服务器更多的用户。
在mtnyguard
“Scala和Lift没有做任何事情来帮助或阻碍水平缩放”
不完全正确。 电梯是高度稳定的框架。 例如，如果用户请求表单，那么他只能将请求发送到表单来自的同一台机器，因为表单处理操作将保存在服务器状态中。
这实际上是阻碍可伸缩性的一个方面，因为这种行为对于无共享体系结构是不一致的。
毫无疑问，提升是高性能的，但性能和可扩展性是两回事。 所以如果你想用lift来横向扩展，你必须在负载平衡器上定义粘性会话，这会在会话期间将用户redirect到同一台机器。
docker也许是进入点，但是演员最终要为请求提供服务，我build议看一下twitter-esque的例子，“skitter”，看看你将如何创build一个非常可扩展的服务。 IIRC，这是让Twitter人们注意的事情之一。
我真的很喜欢@dre的回答，因为他正确地说明了提升的有状态是水平可伸缩性的潜在问题。
问题 – 而不是我再次描述整个事情，检查这个post的讨论（不是内容）。 http://javasmith.blogspot.com/2010/02/automagically-cluster-web-sessions-in.html
解决scheme将作为@DRE在前面的负载平衡器上粘稠的会话configuration，并添加更多的实例。 但是由于lift中的请求处理是在thread + actor组合中完成的，所以你可以期待一个实例处理比一般的框架更多的请求。 这会在其他框架中有粘性会话的优势。 即个体实例处理更多的能力可以帮助您扩展
- 你有Akka电梯整合，这将是另一个优势。
