如何扩展 ZK 框架？
我目前正在开展一个项目，我们将使用 ZK 框架的 Web 应用程序迁移到桉树云环境，但我们想知道如何使该框架可扩展。它甚至可以扩展吗？
提前致谢。
I'm currently working on a project where we migrate a web application, which uses the ZK-framework, to a eucalyptus cloud enviroment, but we wonder how we can make the framework scalable. Is it even scalable?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当然，ZK 可以很好地扩展。 ZK 的一个客户正在构建一个面向 2000 万用户的应用程序。该应用程序在几个月前通过了压力测试。
与 JSF 或其他服务器端解决方案一样，ZK 必须在服务器上保存 UI 的状态（除非您采用纯客户端方法）。这意味着如果您想支持故障转移，则必须使状态可序列化。您可以参考http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Clustering更多信息。
另一方面，在一个浏览器窗口中访问 UI 状态不会阻止另一个浏览器窗口的访问。访问是完全并行完成的。根据我们的咨询经验，瓶颈通常来自后端服务而不是 UI。无论如何，根据您的目标规模和应用程序的复杂性，有几种架构方法，例如在 UI 层前面使用负载平衡调度程序，在单独的服务器中运行 UI 层等。
我对 eucalyptus 不熟悉，所以不确定是否有什么值得注意的地方。
Sure, ZK can be scaled well. One of ZK's clients is building an application targeting 20 millions users. The application passed the stress test a couple months ago.
Like JSF or other server-side solutions, ZK has to hold the states of UI at the servers (unless you take the pure-client approach). It means you have to make the states serializable if you'd like to support failover. You could refer to http://books.zkoss.org/wiki/ZK_Developer%27s_Reference/Clustering for more information.
On the other hand, the access of UI states in one browser window won't block the acess of another browser window. The access is done in fully parallel. The bottleneck, from our consulting experiences, is usually from the backend services rather than UI. Anyway, depending on your targeting scale and the application's complexity, there are several architectural approaches, such as using a load-balance dispatcher in front of UI layer, running UI layer in a separated server, etc.
I am not familiar with eucalyptus, so not sure if anything worth to notice.