Альтернатива жирним JARs Hacker News
Зачекайте, поки вони не дізнаються, наскільки швидше виклики функцій у процесі, ніж RPC.
Я використовую фреймворк в Google, який базується на мікросервісах і дозволяє складати мікросервіси у збірку. В рамках збірки дзвінки між службами здійснюються в процесі; якщо ви викликаєте службу в іншій збірці, вона повинна зробити RPC.
Механіка, чи це місцевий дзвінок, чи RPC, обробляється на рівні рівня. Це робить розділення служби на власну збірку простим завданням (не потрібно оновлювати будь-який код, а лише конфігурацію; цим можуть керувати SRE).
Це дуже схоже на OTP.
У Java-land ви також можете просто мати так, щоб ваш клієнт і служба використовували один і той же інтерфейс. Просто вводьте різні реалізації для локальних та віддалених.
Після того, як ви пішли на проблему автоматичного генерування клею між локальним інтерфейсом та віддаленим об'єктом, стає просто вбудовувати подальші корисні речі - перевірки безпеки, транзакції, якщо ви використовуєте реляційну базу даних тощо. Ви навіть можете запросити код клею для лінивого створення копій службових компонентів, тому вам не потрібно фактично завантажувати їх, поки клієнт не зробить дзвінок.
Тим не менше, ти хотів би мати прохолодне ім'я. Екстремальне прив'язування Java? Покращений реактивний автобус? Відмінний Joy Bringer?
Чесно кажучи, якщо ви не можете довіряти своїм розробникам, щоб вони не вчинили безлад у моноліті, ви не можете довіряти їм, що вони не роблять розподіленого безладу з мікросервісами.
Обидва архітектурні зразки мають своє використання. І те, і інше не врятує вас від поганих розробників.
Я також можу помилитися в цьому, але мені подобається мікросервіс після досягнення проектами певного розміру.
За допомогою єдиного простору пам’яті легко просто обійти будь-яку архітектуру, якої ви “повинні” слідувати.
Мікросервіси не вирішують кульки грязі, але вони можуть ускладнити формування та легше помітити формування.
Це не панацея, схоже, ви просто штовхаєте складність в іншому місці.
І ні, не панацея, просто спосіб мислення, який, на мою думку, є корисним.
Я великий шанувальник добре розробленого SOA, але це не можна вести в блозі тут у 2016 році.
Зараз, добре, в екосистемі JVM на даний момент бракує хорошої модульної системи. Але Java 9 це виправить. Є також OSGi, хоча я не дуже багато про це знаю.
Перенесення складності на міжпроцесовий/машинний зв’язок просто призведе до підвищення рівня спагетті. Невже ви думаєте, що ті самі люди, які погано побудували б моноліт, краще замість цього зробили б роботу зі створення розподіленої системи?
Я не хочу бути занадто догматичним; існують випадки законного використання послуг. Я просто дуже скептично ставлюся до мікросервісів як до рішення складності.
2017 рік стане роком повернення моноліту: "Як ми замінили 946 мікросервісів на статично зв’язану двійкову систему іржі на 10 кБ і як насправді не врятувало нас від повної відсутності чогось, що нагадує узгоджену бізнес-модель".
Зараз, коли закон Мура закінчується, ми можемо з розумом очікувати, що він стане хибним протягом наступного десятиліття чи близько того. Тоді стане занадто очевидним розподіл між тими, хто може просто писати код, і тими, хто вміє правильно розробляти програмні системи.