Альтернатива жирним JARs Hacker News

Зачекайте, поки вони не дізнаються, наскільки швидше виклики функцій у процесі, ніж RPC.

Я використовую фреймворк в Google, який базується на мікросервісах і дозволяє складати мікросервіси у збірку. В рамках збірки дзвінки між службами здійснюються в процесі; якщо ви викликаєте службу в іншій збірці, вона повинна зробити RPC.

Механіка, чи це місцевий дзвінок, чи RPC, обробляється на рівні рівня. Це робить розділення служби на власну збірку простим завданням (не потрібно оновлювати будь-який код, а лише конфігурацію; цим можуть керувати SRE).

Це дуже схоже на OTP.

У Java-land ви також можете просто мати так, щоб ваш клієнт і служба використовували один і той же інтерфейс. Просто вводьте різні реалізації для локальних та віддалених.

Після того, як ви пішли на проблему автоматичного генерування клею між локальним інтерфейсом та віддаленим об'єктом, стає просто вбудовувати подальші корисні речі - перевірки безпеки, транзакції, якщо ви використовуєте реляційну базу даних тощо. Ви навіть можете запросити код клею для лінивого створення копій службових компонентів, тому вам не потрібно фактично завантажувати їх, поки клієнт не зробить дзвінок.

Тим не менше, ти хотів би мати прохолодне ім'я. Екстремальне прив'язування Java? Покращений реактивний автобус? Відмінний Joy Bringer?

Чесно кажучи, якщо ви не можете довіряти своїм розробникам, щоб вони не вчинили безлад у моноліті, ви не можете довіряти їм, що вони не роблять розподіленого безладу з мікросервісами.

Обидва архітектурні зразки мають своє використання. І те, і інше не врятує вас від поганих розробників.

Я також можу помилитися в цьому, але мені подобається мікросервіс після досягнення проектами певного розміру.

За допомогою єдиного простору пам’яті легко просто обійти будь-яку архітектуру, якої ви “повинні” слідувати.

Мікросервіси не вирішують кульки грязі, але вони можуть ускладнити формування та легше помітити формування.

Це не панацея, схоже, ви просто штовхаєте складність в іншому місці.

І ні, не панацея, просто спосіб мислення, який, на мою думку, є корисним.

Я великий шанувальник добре розробленого SOA, але це не можна вести в блозі тут у 2016 році.

Зараз, добре, в екосистемі JVM на даний момент бракує хорошої модульної системи. Але Java 9 це виправить. Є також OSGi, хоча я не дуже багато про це знаю.

Перенесення складності на міжпроцесовий/машинний зв’язок просто призведе до підвищення рівня спагетті. Невже ви думаєте, що ті самі люди, які погано побудували б моноліт, краще замість цього зробили б роботу зі створення розподіленої системи?

Я не хочу бути занадто догматичним; існують випадки законного використання послуг. Я просто дуже скептично ставлюся до мікросервісів як до рішення складності.

2017 рік стане роком повернення моноліту: "Як ми замінили 946 мікросервісів на статично зв’язану двійкову систему іржі на 10 кБ і як насправді не врятувало нас від повної відсутності чогось, що нагадує узгоджену бізнес-модель".

Зараз, коли закон Мура закінчується, ми можемо з розумом очікувати, що він стане хибним протягом наступного десятиліття чи близько того. Тоді стане занадто очевидним розподіл між тими, хто може просто писати код, і тими, хто вміє правильно розробляти програмні системи.

Підхід, описаний у цій статті, - це спосіб роботи Java; але тоді всі сказали, що вам потрібен двійковий файл "самовиконання" для перенесення. Введіть JAR для жиру, контейнери, шари для оркестровки тощо.

Сервери додатків JVM, безсумнівно, найкращий шлях, якщо ви запускаєте купу Java. Але тоді ви берете на себе зобов’язання підтримувати купу залежностей на ваших серверах додатків, так що насправді ви штовхаєте технічну заборгованість своїм керівникам, яким зараз потрібно забезпечити синхронізацію залежностей, належну роботу та оновлення серверів Maven, проксі перфорований для нових зовнішніх залежностей тощо.

Джонатан: якщо ви слухаєте, ви, хлопці, дивилися на Maven як на джерело, а не на завантаження S3? Який відсоток ваших залежностей є внутрішніми чи зовнішніми? Ми отримуємо 10-20-кратну економію простору завдяки елізії лише для громадськості.

РЕДАГУВАТИ: ми також працювали над подібною технікою для виконуваних JAR-файлів, яка має однакові загальні цифри оптимізації та підхід. Це трохи складніше, оскільки ми хочемо зберегти той самий синтаксис 'java -jar', тому вимагає трохи розмитості завантажувача класів та відповідного розуміння завантажувача класів у коді.

Ми фактично все ще виробляємо виконувані файли JAR з таким підходом. Ми налаштовуємо плагін maven-jar на побудову шляху до класу під час побудови та додаємо його як запис Class-Path до маніфесту. Це спеціальний запис маніфесту, і при запуску JVM автоматично додає ці файли до шляху до класу, тому наші тонкі JAR можна запускати за допомогою java -jar за умови, що залежності скинуті в потрібному місці. Плагін slimfast-читає конфігурацію плагіна maven-jar, щоб переконатися, що він генерує правильні шляхи для залежностей. У підсумку ми маємо виконуваний JAR, і жодного робочого середовища та смішного бізнесу ClassLoader.

Ставтеся до будь-якого проекту з відкритим кодом, до якого ваш продукт залежить, так само, як і до всього, за що заплатили готівкою - зберігайте копію у сховищі коду та створюйте резервну копію разом із рештою вихідного коду.

- якщо випуск тієї ж версії був змінений вище за течією, і ви хочете, щоб ця зміна була підхоплена, це все одно не є повторюваною збіркою.

- якщо випуск було змінено вище, і ви не хочете його піднімати, налаштуйте Archiva на збій при невідповідності контрольної суми [1].

- або як альтернативу застосуванню контрольної суми, налаштуйте локальний репо як внутрішній, а не проксі-сервер, і обробляйте все самостійно [2].

Для воєн: На етапі збірки mvn:

- визначити залежності кандидатів, яких слід виключити з ВІЙНИ. Сюди входить крок фільтра для збереження внутрішніх залежностей у папці WEB-INF.

- генерувати маніфест JSON усіх виключених залежностей, включаючи їх локальні SHA, і зберігати маніфест у WEB-INF.

- скопіюйте сценарій оболонки до нового архіву Maven (MAR), який знає, як змінити описаний вище процес і вивести WAR

Потім, у процесі побудови, ми передаємо файли MAR до моменту розгортання, після чого ми знову розгортаємось у ВІЙНУ і розгортаємо.

Ми розглядали просто розгортання самих MAR, але те, як наші контейнери управляють простіром кешу файлів, було простіше регідрітувати їх перед розгортанням.

Для виконуваних JAR: знову ми починаємо з фази збірки Maven і знову визначаємо залежності, які потрібно включити, та залежності, які потрібно виключити та отримати пізніше. Ми створюємо абсолютно новий JAR, який містить усі класи в тонкому банку, побудованому Maven (я вважаю, що JAR є посиланням, а не як розширені класи). Потім ми об’єднуємо всі включені JAR безпосередньо в цільовий JAR і пишемо маніфест CSV, який визначає, які зовнішні залежності потрібні під час виконання. Потім ми копіюємо необроблений файл .class без залежностей [1] у цільовий JAR і пишемо маніфест, який ідентифікує цей клас як основний клас. Цей клас відповідає за виклик 'mvn' через виконання оболонки для завантаження залежностей, створення завантажувача класів з правильним шляхом до класу тощо, а потім передачу до початкового основного класу.