Комментарии 13
Как-то странно видеть в одной статье сначала тезис что "минусы микросервисов настолько велики", а потом что была такая годная технология OSGI. В чем автор видит принципиальную разницу между микросервисами и OSGI-бандлами?
На Хабре было сравнение модулей и микросервисов:
Там нет ответа на мой вопрос. Суть одна: иметь не монолит, а N приложений с независимыми жизненными циклами. Все остальное - детали реализации.
На моем текущем проекте 30 микросервисов на спринг буте, которые коммуницируют через RMQ и REST. Это с тем же успехом могли быть 30 OSGI-приложений на Apache ServiceMix, коммуницирующих через ActiveMQ и SOAP. Я так и не понимаю, в чем автор видит разницу.
Автор оригинала: Nicolas Fränkel. Я переводил эту статью.
Его идея, что можно сделать монолит модульным.
Но если вы успешно реализуете и поддерживаете вашу систему с помощью микросервисов на спринг буте, то эта статья не для вас.
Да, я видел статьи об использовании OSGI для реализации микросервисов. Но не видел сравнений разработки и скорости в продакшн.
>OSGi была мощной, но разработка OSGi bundle (название модуля) была сложной.
Ну и кстати, нифига. Как опять же делавший бандлы массово, скажу что эта сложность сильно преувеличена. Кто умеет в спринг — умеет в блюпринт уже.
Я щупал OSGi до того как появился блюпринт. И да. Делать модули тогда было очень больно. Это как J2EE первой версии. Не хочу туда снова :)
P.S. У нас три человека сейчас их делают. Никакого обучения вообще не проводили. Ноль проблем.
Я с OSGI не работал, но всегда думал что бандлы эти можно в рамках одной JVM подгружать, тем самым, например, решать проблему перекрытия классов для разных версий одной и той же библиотеки (а не мучиться с шейдингом в maven). Поправьте, если не прав.
Думаю, не надо объяснять в чем разница между несколько модулей в одной JVM на одной машине и несколько микросервисов, скорее всего, на разных.
Ну вы почти правы, но не совсем. Современный karaf, на котором строится большинство коммерческих OSGI решений типа Fuse, умеет в кластер много лет. Это ничуть не сложнее микросервисов, а с точки зрения мониторинга к примеру, одна JVM конечно же даст много очков форы куче микросервисов на разных технологиях.
>не мучиться с шейдингом в maven
Таки иногда приходится. Пользующиеся механизмом services классы запускать в OSGI сложно. Но вы можете замаскировать внутри бандла некоторые тонкости. Но большинство проблем такого сорта OSGI конечно решает с полпинка.
Разница между микросервисами и osgi - это как разница между sql и java package-ем. Это же абсолютно разные вещи.
Микросервис - новомодное слово. Как правило под ним понимают отдельное, достаточно независимое, распределённое приложение, выполняющую какую либо функцию и поддерживаемое одной командой. Т.е. микросервис как правило общается с другими микросервисами по сети, имеет свою базу и должен уметь работать даже если сервис, от которого он зависит, упал. Поскольку за один микросервис отвечает не более одной команды, то у него волей - неволей приходится выстраивать чёткие границы.
Ну про плюсы и минусы микросервисов писать нет смысла. Как говорится если вы не можете рассказать о минусах микросервисов, значит вы не знаете, что это такое.
Вот эти границы между микросервисами, без которых микросервис не микросервис, и есть модульность. И автор сообщает, что модульность можно получить и другими, более простыми и дешёвыми путями. А использовать микросервисы только ради модульности по меньшей мере глупо. И перечисляет несколько вариантов обеспечения модульности java приложений. Osgi - это в первую очередь способ обеспечения модульности (и независимости). А заодно и ioc и di - аналог спринга, но обязывает разделять публичную и приватную части. То, что некоторые фреймворки предоставляют удалённый доступ для разных частей - ну почему бы и нет. Никто же не запускает eclipse распределённо на кластере osgi. Приложение из сотни osgi бандлов в одной jvm - это эклипс. Приложение из тысячи спринговых бинов в одной jvm - это монолит. Несколько микросервисов в одной jvm - это оксюморон. Монолит - плохо, микросервис - хорошо - это часто неправда.
Сапсибо, прочел с интересом! Единственное - " нарезать одну или несколько функций на их единицы развертывания" - похоже на сырой Google Translator.
Spring Modulith: достигли ли мы зрелости модульности