Худий на товстій, тонкій, порожній та Uber - DZone Java

Ось майже все, що ви хотіли б знати про ваші улюблені методи упаковки для Java - тонкі JAR, жирні/uber JAR, тонкі JARS і порожні JAR.

Приєднуйтесь до спільноти DZone та отримуйте досвід повного членства.

Нещодавно я бавився з різними техніками упаковки мікросервісів Java та запуску на OpenShift з використанням різних середовищ виконання та фреймворків, щоб проілюструвати їхні відмінності (WildFly Swarm проти WildFly, Spring Boot проти світу тощо). Приблизно в той самий час, коли я це робив, запалився внутрішній потік списку електронних адрес, обговорюючи деякі відмінності та використовуючи такі терміни, як Uber JAR, Тонкі ВІЙНИ, Худі ВІЙНИ та деякі інші. Деякі люди підкреслювали плюси і мінуси кожного, особливо переваги тонкого підходу WAR у поєднанні з шарами зображень докера.

І я подумав собі: чи це не те, що вже всі роблять? Чи справді розробникам доводиться думати про це? Але перед тим, як вникнути в це, я хочу визначити різні терміни, які я чув, і, принаймні, зрозуміти це у власній голові.

Кваліфікатори (у порядку збільшення логічного розміру):

  • Худий - Містить ТІЛЬКИ біти, які ви буквально вводите у свій редактор коду, і НІЩО ще.
  • Тонкий - Містить усі вищезазначені ПЛЮС прямі залежності програми від вашого додатка (драйвери db, бібліотеки службових програм тощо).
  • Порожнистий - Зворотній тонкий - Містить лише біти, необхідні для запуску вашого додатка, але НЕ містить самого додатка. В основному заздалегідь упакований «сервер додатків», на якому ви можете пізніше розгорнути свою програму, у тому ж стилі, що і традиційні сервери програм Java EE, але з важливими відмінностями ми перейдемо пізніше.
  • Жир/Uber - Містить біт, який ви буквально пишете собі ПЛЮС, прямі залежності вашого додатка ПЛЮС, біти, необхідні для запуску вашого додатка «самостійно».

тонкій

Тепер давайте визначимо, як кваліфікатори відображаються у світі програм Java та типів пакетів (JAR, WAR тощо).

Жир/Uber JAR

Maven і, зокрема, Spring Boot популяризували цей добре відомий підхід до упаковки, який включає все необхідне для запуску всієї програми в стандартному середовищі Java Runtime (тобто, щоб ви могли запускати програму за допомогою java -jar myapp.jar). Кількість додаткових матеріалів під час виконання, включених до Uberjar (та їх розмір файлу), залежить від фреймворку та функцій виконання, які використовує ваш додаток.

Тонка ВІЙНА

Якщо ви розробник Java EE, швидше за все, ви вже робите це. Це те, що ви робите більше десяти років, тож вітаємо, ви все ще круті! Тонкий WAR - це веб-програма Java EE, яка містить лише веб-вміст та бізнес-логіку, яку ви написали, разом із незалежними залежностями. Він не містить нічого, що забезпечується часом виконання Java EE, отже, він "тонкий", але не може працювати "самостійно" - його потрібно розгорнути на сервері додатків Java EE або контейнері сервлетів, що містить "останню милю" бітів запустити програму на JVM.

Тонкий JAR

Те саме, що і Тонка ВІЙНА, за винятком використання формату упаковки JAR. Як правило, це використовується спеціалізованими архітектурами додатків/плагінів, які використовують формат упаковки JAR для спеціально створених плагінів чи артефактів середовища виконання. Наприклад, формат .kjar із Drools.

Худа ВІЙНА

Хоча менш відомий, ніж його побратими, худий WAR тонший, ніж Thin WAR, оскільки він не включає жодної сторонньої бібліотеки, від якої залежить додаток. Він містить ТІЛЬКИ (байтовий) код, який ви як розробник буквально вводите у своєму редакторі. Це має великий сенс у докерному світі багатошарових зображень контейнерів, де розмір шару важливий для розумності DevOps, і Адам Бієн провів чудову роботу, продемонструвавши та пояснивши це. Про це далі.

Худий JAR

Те саме, що і Skinny WAR, за винятком використання упаковки JAR та фреймворків, побудованих навколо неї, таких як WildFly Swarm та Spring Boot. Це також має масу сенсу для осудності CI/CD (і вашого рахунку AWS) - просто запитайте Hubspot. Тут ви берете Тонку ВІЙНУ і видаляєте всі сторонні залежності. У вас залишилася найменша атомна одиниця програми (спроба перейти на менші звучить як жахлива ідея, але з Java 9/JPMS це можливо), і її потрібно розгорнути в середовищі виконання, яке очікує цього, і має всі інші необхідні біти для запуску програми (наприклад, Hollow JAR)

Порожнистий JAR

Це середовище виконання додатків Java, яке містить “достатньо” сервера додатків для запуску програм, але не містить жодних додатків. Він може працювати самостійно, але це не так корисно, коли він працює самостійно, оскільки він не містить додатків і не робить нічого, крім самоініціалізації. Деякі проекти, такі як WildFly Swarm, дозволяють налаштувати, скільки «просто достатньо», тоді як інші (наприклад, Paraya Micro або TomEE) пропонують заздалегідь побудовані розподіли популярних комбінацій компонентів середовища виконання, таких як ті, що визначені Eclipse MicroProfile.

Інші комбінації

  • Порожня війна - теоретично ви можете упакувати якусь програму для запуску на іншому сервері додатків, а потім розгорнути програми на цьому внутрішньому рівні. Удачі вам у цьому!
  • FAT/Uber WAR - Не має сенсу в загальній ідеї про те, що Fat/Ubers можна запускати за допомогою java-jar.
  • Файли EAR - за визначенням файл EAR не може бути порожнім, жирним або худим, тому все, що ви можете створити, - це Тонке EAR (що воно вже є, за визначенням). Рухайтесь далі, тут нічого не можна побачити, за винятком того, що файли EAR можуть бути транспортним засобом, який несе залежності для худих ВІЙ в межах EAR.

Чому турбувати?

Зростання орендованих обчислювальних машин та популярність процесів DevOps, контейнерів Linux та архітектур мікросервісів зробили знову важливим слід програми (кількість байтів, з яких складається ваш додаток). Коли ви розгортаєтеся в середовищах для розробки, тестування та виробництва кілька разів на день (іноді сотні на годину або навіть 2 мільярди разів на тиждень), мінімізація розміру вашого додатку може мати величезний вплив на загальну ефективність DevOps та вашу роботу осудність. Вам не потрібно мінімізувати рядки коду у вашій програмі, але слід зменшити кількість випадків, коли ваша програма та її залежності повинні переходити через мережу, переходити на диск чи вимикати його з диска або обробляти програмою . Це означає розбиття програми на різні упаковані частини, щоб їх можна було належним чином розділити та обробляти як такі (і навіть версії, якщо ви так вирішите).