Scala/Lift：是否需要特殊的 http 路由？
由于 Lift 是有状态的，因此对页面/站点的每个后续请求都必须返回到同一服务器。据推测，这意味着前端负载均衡器需要跟踪哪个客户端正在与哪个服务器通信。
对于像 Heroku/Elastic Beanstalk 这样的地方进行托管，负载均衡器都是由服务自动为您完成的，效果如何？我知道如果您自己设置所有机器，您可以设置路由来执行正确的操作，但是它如何在这些 PaaS 类型主机上工作，而所有这些都是为您完成的？
编辑：如果我没有记错的话，Google App Engine 也会有同样的限制？
Since Lift is stateful, each subsequent request to a page/site must go back to the same server. Presumably that means that the front-end load balancer needs to keep track of which client is talking to which server.
How does that work out for hosting on places like Heroku/Elastic Beanstalk, where the load balancer is all done automagically for you by the service? I know if you are setting up all your machines yourself you can set the routing to do the correct thing, but how does it work on these PaaS type hosts where all this is meant to be done for you?
EDIT: Google App Engine would have the same limitations, if i am not mistaken?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Heroku 将在 dynos（进程）之间均匀分配请求，因此我相信您必须对有状态的 Lift 应用程序使用某种形式的会话序列化。我相信 Elastic Beanstalk 确实有一些工具来支持这一点（就像 ELB 所做的那样）。
David Pollock 撰写了有关如何以无状态方式使用 Lift 的文章，并概括性地讨论了 Lift 在该领域的设计 这里。
Heroku will distribute requests between dynos (processes) evenly so I believe you would have to use some form of sessions serialisation for a stateful Lift app. I believe Elastic Beanstalk does have some facilities to support this however (as ELB does).
David Pollock writes about how to use Lift in a stateless way and also talks generally about the design of Lift in this area here.
Lift 并不是真正打算用于纯粹的无状态模式，它是可能的，但它不是该框架擅长的地方。 ELB 确实支持粘性会话，这是您需要采用的配置，以便在几乎任何环境中成功使用 Lift。
更广泛地说，这种“粘性会话”功能可以通过 L4 硬件平衡软件来实现。您可能对 Lift in Action 的第 15 章感兴趣，如果您确实想要的话，该章花费了大量时间讨论这个主题以及各种会话序列化策略。
Lift is not really intended to be used in a pure stateless mode, its possible, but its not where the framework excels. ELB does indeed have support for sticky sessions, which is the configuration you need to take up in order to use Lift successfully in nearly any environment.
More broadly, this "sticky session" functionality can be achieved with either software of L4 hardware balancing. You might be interested in chapter 15 of Lift in Action which spends a fair amount of time discussing this very subject and the various session serialisation strategies if you really want that.