Tomcat / JettyにデプロイされたSpringブートアプリと.warファイル
私の場合、Spring Bootで作成および構成された簡単なRESTfulサービスを考えてみましょう。このサービスは、データベース（Postgresなど）と通信します。
次の違いは何ですか？
- スプリングブートの構築
.jarファイルを作成し、Java -jar myservice.jar？
または
- パッケージ化して
.warファイルしてTomcat/Jettyにデプロイしますか？
最初のオプションの方がはるかに簡単なようです。.jar。 2番目のオプションでは、Tomcatインスタンスを作成して実行し、.warファイル。他に違いはありますか？両方の方法の長所と短所はありますか？
.warファイルにパッケージ化し、Tomcat/Jettyにデプロイしますか？
しない可能であればこれを行います。 理由：Tomcat（またはundertow、netty、jettyなどの他のサーバーランタイム）が組み込まれているため、マイクロサービスアーキテクチャの構築がはるかに簡単です。
ジョシュ・ロングがかつて彼の春の1つで言ったようにIO talks “make Jar, not War”
一方、サーブレットコンテナを備えた既存のインフラストラクチャがあり、それらのサーブレットコンテナで複数のapplication.warsが既に実行されており、アプリケーションをwarファイルとしてパッケージ化して、それをリリースチーム（または、単に既存のインフラストラクチャを再利用することを余儀なくされます）、それは別の話です...しかし、技術の世界はすでにこのプラクティスから離れています。
繰り返しになりますが、マイクロサービスの精神で、スプリングブートが意図したものの精神で、従来の展開ではなく、組み込みサーバーを使用して実行可能なjarファイルを作成することをお勧めします。
編集
アプリケーションをドッキングする場合、Tomcatを「最終成果物」にパッケージ化する2つのオプションがあります（「最終成果物」とは、jarではなくdockerイメージを意味します。Jarはここでの中間成果物です）。
- Tomcatがjarにパックされ、JVM Dockerイメージが使用されるように、埋め込みTomcatを使用します
OR
- Tomcatをjarから除外し、アプリケーションをパックしてTomcat Dockerイメージを使用するだけです。
それでも、いつでも第1のオプションを選択します。これにより、開発プロセスがはるかに簡単になります（そして、新しい開発者のオンボーディングが簡単になることは言うまでもありません）。
製品ページ で説明したように、これらのjarにはサーブレットコンテナが含まれており、直接起動します。
Tomcat、Jetty、またはUndertowを直接埋め込みます（WARファイルをデプロイする必要はありません）
あるホストでアプリケーションを実行する予定がある場合（ドッカー？）、これは素晴らしい可能性があります-ホストに他のアプリが含まれている場合、戦争を展開するアプローチは、それらのサーブレットコンテナのみを持つことができるため、より興味深いでしょうホストで一度。