Java Web 应用程序的可扩展性和性能
假设您想要构建一个具有高可扩展性的 Web 应用程序（超过 10,000 个并发用户）。如何保证良好且稳定的性能？哪些设计模式值得推荐？最常见的错误是什么？
是否有框架迫使您编写可扩展的代码？您是否会考虑将 php 作为前端，将 Java 作为后端技术？或者说 JSF 也是合理的，并且这一切都与您的架构有关？在这种情况下使用 Grails 进行开发效果如何？
希望这个帖子不太主观，但我想收集你的一些经验:-)
Let's say you want to build a web application with high scalability (over 10,000 simultanious users). How do you guarantee good and steady performance? What design patterns are recommendable? What are most frequent mistakes?
Are there frameworks that force yourself to write scalable code? Would you maybe consider php as frontend and Java as backend technology? Or is let's say JSF reasonable as well and it's all about your architecture? And how good is developing with Grails in that context?
Hope this thread is not too subjective but I like to gather some experiences of you :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想构建一个高度可扩展的应用程序，那么它应该是无状态的，并尽可能使用无共享架构。如果节点之间不共享任何内容并且节点没有状态，则同步是最小的。有几个适合您要求的优秀 Web 框架（适用于 Java 的 Play Framework 和 Lift、适用于 Python 的 Django、适用于 Ruby 的 Ruby on Rails）。
至于 JSF 和相关技术，我认为在您的情况下使用它们并不明智。一个好的旧的请求-响应会更好。
If you want to build a highly scalable application then it should be stateless and use shared nothing architecture as much as possible. If you share nothing between nodes and a node dont have a state then synchronization is minimum. There are several good web frameworks suitable for your requirements (Play Framework and Lift for Java, Django for Python, Ruby on Rails for Ruby).
As for JSF and related technologies, I dont think it would be wise to use them in your case. A good old request-responce is better.
如果您希望应用程序能够很好地扩展并表现良好，那么您需要拥有分布式缓存。分布式缓存可以极大地提高应用程序性能，为此，您可以使用任何第三方分布式缓存，例如 NCache。
If you want your application to scale nicely and perform well then you need to have a Distributed Cache. Distributed cache can incredibly boost up application performance and for this purpose you can use any third party distributed cache like NCache.
对于如此多的并发用户（我承认我自己从未遇到过这种情况），我认为最重要的是能够在许多网络服务器之间平衡您的费用。
如果你想要故障转移（这可能是必须的），这意味着你必须非常小心状态：你拥有的状态越多，你需要的内存就越多，并且处理服务器之间的故障转移就越困难：要么您需要将会话状态保留在所有服务器共用的位置，或者需要跨服务器复制状态。
因此，我会选择一种不需要服务器上太多状态的架构。恕我直言，基于操作的框架比基于组件的框架更适合这种架构，除非状态是在客户端使用丰富的 JavaScript 组件进行处理的。
With so many simultaneous users (a situation I confess I've never encountered myself), what I think is the most important is to be able to load-balance your charge across many web servers.
If you want failover (which is probably a must-have), this means that you must be very careful about state : the more state you have, the more memory you need, and the more difficult it is to handle failover between servers : either you need to persist the session state in a location that is common to all the servers, or you need to replicate the state across servers.
So, I would choose an architecture where you don't need too much state on the server. IMHO, an action based framework is more suited to this kind of architecture than a component-based one, unless the state is handled at client side, with rich JavaScript components.