Comments 9
Когда говорят слово "микросервисы", часто забывают уточнить о каких именно аспектах микросервисности идёт речь. Независимые билды/деплойменты? Изоляция разных команд друг от друга? Использование разных ЯП для разных сервисов?
Если всё гарантированно пишется на джаве, лежит в одном репозитории, билдится и деплоится как монолит - можно просто сразу делать монолитную кодовую базу, в которой взаимодействие между модулями, в зависимости от профиля сборки, либо "напрямую" (обычные вызовы внутри ЯП), либо "через транспорт".
Такой подход упрощает разработку, потому что программируется фактически монолит - легко переиспользовать код, легко рефакторить, легко заставить работать локально, легко отлаживать, легко писать интеграционные тесты, а "микросервисность" появляется только при деплойменте.
Если изменения в одном сервисе требуют каскадных изменений в других, то это не микросервисы, а распределённый монолит.
А всякие переиспользование кода между именно микросервисами через общие зависимости де-факто не отменяет того, что придётся править в нескольких местах, т.к. как минимум надо поднимать версии в зависимостях и вносить правки в код, использующий эти самые общие библиотеки.
ИМХО - это слишком радикальный критерий. Например изменение API одного из микросервисов с потерей обратной совместимости гарантированно приведёт к каскадным изменениям в других микросервисах вне зависимости от того, используют они общие библиотеки или нет. Понятно, что обратную совместимость нужно всеми силами стараться сохранить. Но, жизнь штука сложная, и далеко не всегда получается это сделать.
Так об этом и речь. А если изменений всё равно не избежать, то и шарить общие библиотеки смысла нет.
Очень интересная мысль. Как то раньше я об этом не задумывался. Следуя вашей логике нам так же стоит отказаться от Maven'а с Gradle'ом. Ведь изменений в публичных open source библиотеках все равно не избежать! Зачем же нам тогда их шарить и управлять зависимостями? Скопипастить код библиотек в микросервисы - и дело с концом!
Только ситхи всё возводят в абсолют.
Скопипастить код библиотек в микросервисы - и дело с концом!
Такой подход также может быть вполне оправдан, например, в commons-lang куча полезных утилитных классов, но для чего тащить эту зависимость в свой сервис, если из этой кучи используется один-два даже не класса, а метода?
При большом количестве микросервисов в проекте приходится сталкиваться с тем, что в некоторых из них нужно дублировать один и тот же код, а обнаружив баг в одном месте, искать и исправлять его везде. При этом, если микросервисы поддерживаются разными разработчиками, то каждый будет исправлять баг по-своему и в дальнейшем будет сложнее привести всё к единообразию
Исходные предположения мне показались не совсем верными, поэтому и логика всей статьи нарушена.
Микросервис это прежде всего функциональная независимость и самостоятельность, причём и функциональная, и кодовая. И именно "дублировать один и тот же код", "исправлять его везде" и приводить "всё к единообразию" как раз не нужно !
А при переиспользовании общего кода исправление найденного в нём бага уж точно будет не по-своему, а сообща и согласованно всеми разными разработчиками ).
Но сама тема общей кодовой база в микросервисах кажется интересной и требует дополнительного раскрытия.
По-моему, я уже видел на Хабре похожую статью про попытки сделать переиспользуемый код микросервисов, ушедшую в минусы. А, да, это же ваша статья про управления зависимости в микросервисах!
Управление общей кодовой базой в микросервисной архитектуре