替代应用程序服务器

时间:2014-11-29 20:10:13

标签: java-ee osgi websphere-8 vert.x

我是一名Java EE开发人员,并且已经参与了一段时间的项目。该应用程序只是一个缓存。它通过EJBs / RMI从后端加载数据,通过JPA将其存储到数据库,并向前端应用程序提供SOAP Web服务以访问此数据库中的数据。应用程序本身以及所有整个后端都是在Websphere服务器上运行的Java EE应用程序。

这个设置的问题在于它是重量级的,在我看来很难维护。现在,试图找出所吸取的经验教训,我想知道有哪些替代方案 - 对于整个应用程序设计或部分应用程序。我想知道在2014年解决我的问题的(工作)企业解决方案中使用了哪些技术:

  • 运行基于OSGi的总线,而映射是通过Apache Camel的示例进行的,包括EJB访问?
  • 将技术用于像vert.x这样的前端服务?
  • Spring是否取代Java EE和Tomcat作为Websphere的替代方案?
  • 使用基于脚本等语言的技术,比如python省略服务器?
  • ...

感谢您的建议。 此致

1 个答案:

答案 0 :(得分:4)

我认为我工作的咨询公司中的任何人都没有在过去五年左右的时间内将新应用程序部署到Big Name,共享应用程序服务器。虚拟化将app服务器取代为app-to-iron多路复用器,而这些VM现在正被Docker容器取代。应用程序嵌入了自己的HTTP堆栈,可能是Tomcat,但越来越多的是异步堆栈,因为每个插槽的一个线程会抑制可伸缩性。

如果我们要构建一个API翻译器,就像你今天所描述的那样提取转发系统,它很可能是在Scala中使用Akka和Spray,可选地坐在Nginx后面。存在有趣的替代方案,例如在Clojure中,但这是我们最熟悉的堆栈。我不知道我们是否使用过vert.x,但它适合这个空间。

我们不再使用SOAP了。对于Spring Framework和Hibernate也是如此。

应用程序的本地数据存储可能不是RDBMS。我不知道你的系统的全部要求。听起来它已经存在了一段时间,所以当你把它描述为“只是一个缓存”时,我猜它会比那更复杂。根据上下文,我们已经部署了memcached,Redis,GemFire,MongoDB,Riak或者PostgreSQL。