esb - 実稼働環境でのMuleスタンドアロンとTomcatの実行

Question

MuleESBを実稼働環境にデプロイする方法はたくさんあります。ドキュメントによると、Muleをスタンドアロンサービスとして実行することが推奨される方法のようです。

Muleを本番環境でスタンドアロンで実行しない理由はありますか？安定していると思いますが、パフォーマンス、信頼性、リソース使用率に関して、Tomcatと比べてどうですか？

何らかの理由でTomcat内で実行することを検討する必要がありますか？

Answer 1

Tomcat またはその他の Web コンテナを使用すると、Mule の HTTP または Jetty トランスポートの代わりに、そのコンテナの Web 層を HTTP インバウンド エンドポイント (サーブレット トランスポート経由) に使用できます。

その他の相違点は、クラスのロード、ホット再デプロイの処理、およびロギングにあります。

現在、人々が Mule をスタンドアロンで使用しない主な理由は、企業ポリシー、つまり「あなたは_にデプロイする必要があります」です。プロダクション チームが特定の Java アプリケーション/Web サーバーのベビーシッターの経験を積んだ場合、よく知られている一貫した方法で Mule プロジェクトを管理/監視できるように、そのコンテキストで Mule プロジェクトをデプロイすることを望んでいます。

しかし、Mule スタンドアロンで取得したインバウンド HTTP レイヤーに満足し、それを本番環境にデプロイできる場合は、それを実行してください。製作準備完了です。

Answer 2

Mule は、実際にはスタンドアロンのデプロイを推奨しています。たとえば、Tomcat のようなコンテナー内では、スレッドプール、ヒープなどを共有する必要があります。これにより、明らかに最高のパフォーマンスを発揮できなくなります。

Tomcat のようなコンテナー内に入れたい主な理由は、自動デプロイを取得することです。つまり、Mule アプリケーション .war を更新するだけで、コンテナは新しいアプリケーションで Mule を再起動します。これはテストに役立ちます。

また、一部のトランスポートは、サーブレット トランスポートのように、コンテナー内での実行に固有です。ソリューションを設計するときにOTOHを使用すると、Muleがコンテナとサーブレットの間で転送され、間違っています。