问题描述
有许多方法可以将Mule ESB部署到生产环境中.根据文档，似乎建议将Mule作为独立服务运行.
There are many ways of deploying Mule ESB into a production environment. According to the documentation, it appears that running Mule as a standalone service is the recommended way of doing so.
有什么理由不能在生产环境中独立运行Mule?我确信它是稳定的，但是就性能，可靠性和资源利用率而言，它与Tomcat相比如何?
Are there any reasons for NOT running Mule standalone in production? I'm sure its stable, but how does it compare to Tomcat as far as performance, reliability, and resource utilization go?
出于任何原因，我仍应考虑在Tomcat中运行它吗?
Should I still consider running it within Tomcat for any reason?
推荐答案
使用Tomcat或任何其他Web容器，可以使该容器的Web层(通过Servlet传输)用于HTTP入站终结点，而不是Mule的任何一个HTTP或Jetty传输.
Using Tomcat, or any other web container, allows you to use the web tier of that container for HTTP inbound endpoint (via the Servlet transport) instead of either Mule's HTTP or Jetty transports.
在类加载，热重新部署和日志记录的处理中发现其他差异.
Other differences are found in class loading, handling of hot redeployment and logging.
现在，人们不使用Mule单机版的主要原因是公司政策，即您应该部署在 _ 上".当生产团队获得照顾特定Java应用程序/Web服务器的经验后，他们希望您在该上下文中部署Mule项目，以便他们可以以众所周知的一致方式来管理/监视它.
Now the main reason why people do not use Mule standalone is corporate policy, ie "thou shalt deploy on _". When production teams have gained experience babysitting a particular Java app/web server, they want you to deploy your Mule project in that context so they can administer/monitor it in a well-known and consistent manner.
但是，如果您对入站HTTP层感到满意，那么您可以独立使用Mule，并且可以将其部署到生产环境中，然后继续进行.准备生产了.
But if you're happy with the inbound HTTP layer you get in Mule standalone and you are allowed to deploy it in production, then go for it. It's production ready.
这篇关于在生产环境中运行Mule Standalone与Tomcat的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！