Вам не нужны микросервисы

[Algeps]

Возможно с самого начала требование по нагрузке и логике решалось модульным монолитом
Соглашусь с тем, что в enterprise секторе архитектура микросервисов приносит больше вреда чем пользы

С какой библиотекой выполнялась работа с pdf?
Есть возможность посмотреть на исходный код?

[tomskiyleonid]

Согласен. Но, так хотелось микросервисов :).
Основные данные извлекаются через pdfbox. Что-то берется от Docling, который работает локально на видеокарте Radeon mi50. Все остальное, внутренняя логика. Пишет в пдф также pdfbox.

К сожалению, это не открытый проект, поэтому исходный код увидеть нельзя.

[knekrasov]

Знаете, я в индустрии 18 лет, большую часть из которых так или иначе работаю на бэкенде с Java/Kotlin. С микросервисами встречался только на паре проектов и оба раза это был адовый enterprise.

В первом случае работа была более-менее изолирована, и подход с микросервисами явно был оправдан (можно было написать приложение сколь угодно плохого качества, но в целом система оставалась бы рабочей - что с т.з. архитектуры на самом деле очень хорошо, особенно в долгосроке и в перспективе работы многих команд над одной большой системой).

Во втором система была условно микросервисной, границы микросервисов были нарисованы сугубо административно (с выделением отдельных команд и выстраиванием бумажной бюрократии между командами и с обязательным пинг-понгом перекидывания ответственности друг другу).

Так что в целом я скорее за монолитный подход по умолчанию, пока не доказано иное. Из недавнего опыта могу только сказать, когда разделение на модули (вместо микросервисов) может сыграть дурную шутку: когда нет жестких границ между "микросервисами", слишком велик соблазн в разных модулях переиспользовать типы и прочие символы (тогда как микросервисы как будто заставляют "локализовать" типы в каждом конкретном сервисе). На нашем проекте это создало (несколько неожиданную) точку связности: вроде и код в целом хорош, и про GoF паттерны команда не забывала, а сделать, скажем, обфускацию кодовой базы оказалось весьма нетривиальной задачей (а у нас там еще и часть логики вынесена в KotlinScript'ы, которые тоже какие-то типы из core логики импортируют...). Впрочем, морали тут не будет :-)

[tomskiyleonid]

Спасибо, познавательно.
Я так понимаю, модуль shared постепенно будет разбухать)

[Akon32]

Микросервисная архитектура прежде всего предназначена для разделения работы на несколько команд разработчиков, когда вся система не может поместиться в головах одной команды на 10 человек. Есть и другие предпосылки типа горизонтального масштабирования отдельных частей, независимого деплоя частей... Но в одиночку пилить микросервисы - обычно немного смысла, и неудивительно, что получился монолит.

[upcFrost]

Мое личное мнение которое никому кроме своей команды не навязываю: микро, не микро, чистая архитектура, солид и прочее - оно все фигня и относительно. Разбивка и абстракции должны следовать некой цели: ресурсам, продуктовой, организационной. Классический пример из ЧА - делать интерфейс над слоем репозитория. Хрен, если мигрировать с условной монги на постгрес, то программный интерфейс будет прям последней из проблем, и если нет прямой необходимости его абстрагировать (например нет слоя кеширования и в ближайшие 3 года не предвидится) - оно нафиг не нужно и станет “+1 файлом с изменениями”. А вот если уже известно что нужно будет работать с 20 разными типами в одном пайплайне - вот тут точно нужна абстракция, безотносительно того что говорит очередная модная октогональная архитектура.

Конкретно для микросервисов имхо есть только три реально определяющих момента - структура компании, разделение cpu/io-bound сервисов и наличие общих зависимостей между продуктами (например общая авторизация или общая базовая модель юзера). В остальных случаях - монолит пока не доказано обратное.

[Oeaoo]

А я всматриваю в суету вокруг микросервисов психологию массового сознания ("оно" прийдет и нас спасет) или даже богословие (идолопоклонство). По сути, это слепое поклонение форме через тупое копирование, подражание. Уже поведение, но еще не разумное. Вспоминаются эксперименты (Виктории Хорнер и Эндрю Уайтена), сравнивающие обезьян и детей, где показано, что дети копируют больше обезьян. И, наверное, благодаря этому мы лучше учимся. Но в разработке архитектур подобная незрелая "бессознанка" скорее вредит, т. к. "очарованное сознание" не соотносит свою "прелесть" с реалиями и последствиями. Или, другими словами, это тупо магическое мышление, коварно маскирующееся под рациональность.

[Oeaoo]

Кстати. Есть чудесный фильм Гарри Бардина "Адажио", идеально отражающий подобную динамику сознания. Считайте, что в главной роли там микросервисы)