Java 应用程序的常见 Web 架构是什么？
我目前正在开发一个 Java Web 应用程序，并且正在研究如何结合不同类型的技术，以便充分利用单个 Web 服务器。
到目前为止我的计划是采用以下架构设置
Internet ->
Varnish (reverse proxy) ->
Apache2 (mod_pagespeed, mod_jk) ->
Ehcache-web (caching html page fragments,spring-cache) ->
Tomcat (java appsrv) ->
Ehcache (cache layer) ->
MySQL (persistance layer)
这个设计有什么问题吗？谈到这一点，缩放和集群怎么样？还有其他（更好）的解决方案吗？
谢谢！
Im currently developing a java web application, and im researching how i should combine different types of technology in order to get the most use of a single webserver.
My plan so far is to have the following architecture setup
Internet ->
Varnish (reverse proxy) ->
Apache2 (mod_pagespeed, mod_jk) ->
Ehcache-web (caching html page fragments,spring-cache) ->
Tomcat (java appsrv) ->
Ehcache (cache layer) ->
MySQL (persistance layer)
Is there any problems with this design? What about scaling and clustering when it comes to that? Is there any other (better) solutions?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我并不以传统的方式设想网络应用程序——而是以服务提供商和消费者的方式。在工作中，我们有一个在 Tomcat 下运行的 RESTful API 层，它是通过实现 Shindig 接口构建的。该层与 MySQL 以及 MongoDB 交互。我们使用 Memcached 进行近/远缓存，考虑到我们使用大量基于列表和集合的操作，我们计划将其迁移到 Redis。该层还与 Twitter 和 Facebook 接口以实现某些 API（例如推送状态更新）。所有端点都可以通过符合 OpenSocial 的 REST/XML 调用进行访问。我们使用 NewRelic 来监控服务性能和 SLA。目前我们的转速略高于 30K RPM，响应时间为 10ms。我们有一个由 4 个 Tomcat、3 个 memcached、3 个 MySQL（1M 2S）和 3 个 MongoDB（副本集）组成的集群。所有堆栈都运行在 XenServer 托管的虚拟机上，运行 Centos。我们使用 RabbitMQ 进行消息传递/异步操作，例如发送通知或与第 3 方 (Twitter/Facebook) 对话，以免阻塞 VM 线程。随着该平台的流行，我们计划在不久的将来转向 HornetQ+Scala Actors。搜索在 Solr 上运行，但我们正在积极迁移到 ElasticSearch。
我们在这一基于 API/服务的模型中构建了系统，以便我们可以为多个客户端平台提供服务。因此，当我们的移动应用程序启动时，可以重复使用 API，而不是为移动应用程序单独设置一组相同的堆栈。该架构抽象了后端产品，不与前端耦合。我们的前端是用 PHP/Zend 构建的，并且广泛使用 JQuery。我们正在使用 HTML5、Phonegap 和 Sencha touch 构建移动前端。
为了安全起见，我们有开放的 GET，但写入是通过 2-legged oauth 来保护的。一旦我们向外部消费者和应用程序开发人员开放API，我们将需要提供三足oauth。
我希望这个总结有所帮助。如果您需要更多信息或有任何疑问，请随时发表评论。
I do not envision a webapp in a traditional manner - but in terms of service providers and consumers. At work we've a RESTful API layer running under Tomcat, built by implementing Shindig interfaces. The layer interacts with MySQL as well as MongoDB. We have near/far caching using Memcached, which we plan to move to Redis given that we use a lot of list and set based operations. This layer also interfaces with Twitter and Facebook for certain APIs (like pushing out the status updates). All the endpoints are accessible as OpenSocial compliant REST/XML calls. We use NewRelic to monitor the service performance and SLA. Currently we're doing a little over 30K RPM with a response time of 10ms. We have a cluster of 4 Tomcats, 3 memcacheds, 3 MySQL (1M 2S) and 3 MongoDB (replicaset). All of the stack runs on Virtual Machines hosted by XenServer, running Centos. We use RabbitMQ for messaging/async operations like sending notifications out or talking to 3rd parties (Twitter/Facebook) so as to not block the VM threads. We plan to move to HornetQ+Scala Actors in the near future as the platform gets popular. The search runs on Solr but we're actively migrating to ElasticSearch.
We architected the system in this API/Services based model so that we can serve more than one client platform. So when our Mobile app launches, that can re-use the APIs instead of having a separate set of the same stack for Mobile. This architecture abstracts the back-end offerings with no coupling to the front end. The front end we have is built in PHP/Zend, and it uses JQuery extensively. We are building a mobile front-end using HTML5, Phonegap and Sencha touch.
For security we have open GETs but the writes are secured via 2-legged oauth. We will need to provide 3-legged oauth once we open up the API to external consumers and app developers.
I hope this summary helps. Please do not hesitate to comment if you need further information or have any questions.
我们正在为我们的高流量门户（约 5500 万 PI /月）使用 3 个 Varnish 代理、3 个 Apache (2) 负载均衡器，在 6 台服务器专业服务器上使用 4 个 tomcats 通过 mod_jk 与 apache 进行通信。作为 RDBMS，我们有 Oracle。我认为数据库的选择至关重要。我们的内容就是我们的存在，因此我们需要一个响应灵敏、健壮、可扩展、可靠、高可用性等的数据库产品。在最坏的情况下我们可能需要支持。因此我们选择了 Oracle。
Tomcat/应用程序服务器的选择取决于您的应用程序架构。
在我们的例子中，我们有 Coremedia CMS（基于 Spring 的 CMS，其中包含分布式服务，如内容服务器、主实时服务器、馈送器等，通过 CORBA 进行通信）和集群 Tomcat 就足够了。
我认为您的列表/设置和这种组合对于大多数情况来说似乎非常好并且足够了。
We are using for our high traffic portal ( ca 55 mil. PI /month ) 3 Varnish proxies, 3 Apache (2) load balancers, on 6 servers pro server 4 tomcats communicating with apaches over mod_jk. As RDBMS, we have Oracles. I think the DB selection is critical. Our contents are our existence, for that reason we need a DB product, which's responsive, robust, scalible, reliable, high available, so on. We could need support in worst cases. For that reason our selection was Oracle.
Tomcat / Application Server selection depends on your application architecture.
In our case, we have Coremedia CMS (Spring based CMS which contains distributed services like content server, master live server, feeder, etc. communicating over CORBA) and clustered Tomcats are sufficient.
I think that your list / setup and this combination seem very well and sufficent for most cases.