Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
Возможно с самого начала требование по нагрузке и логике решалось модульным монолитом
Соглашусь с тем, что в enterprise секторе архитектура микросервисов приносит больше вреда чем пользы
С какой библиотекой выполнялась работа с pdf?
Есть возможность посмотреть на исходный код?
Знаете, я в индустрии 18 лет, большую часть из которых так или иначе работаю на бэкенде с Java/Kotlin. С микросервисами встречался только на паре проектов и оба раза это был адовый enterprise.
В первом случае работа была более-менее изолирована, и подход с микросервисами явно был оправдан (можно было написать приложение сколь угодно плохого качества, но в целом система оставалась бы рабочей - что с т.з. архитектуры на самом деле очень хорошо, особенно в долгосроке и в перспективе работы многих команд над одной большой системой).
Во втором система была условно микросервисной, границы микросервисов были нарисованы сугубо административно (с выделением отдельных команд и выстраиванием бумажной бюрократии между командами и с обязательным пинг-понгом перекидывания ответственности друг другу).
Так что в целом я скорее за монолитный подход по умолчанию, пока не доказано иное. Из недавнего опыта могу только сказать, когда разделение на модули (вместо микросервисов) может сыграть дурную шутку: когда нет жестких границ между "микросервисами", слишком велик соблазн в разных модулях переиспользовать типы и прочие символы (тогда как микросервисы как будто заставляют "локализовать" типы в каждом конкретном сервисе). На нашем проекте это создало (несколько неожиданную) точку связности: вроде и код в целом хорош, и про GoF паттерны команда не забывала, а сделать, скажем, обфускацию кодовой базы оказалось весьма нетривиальной задачей (а у нас там еще и часть логики вынесена в KotlinScript'ы, которые тоже какие-то типы из core логики импортируют...). Впрочем, морали тут не будет :-)
Микросервисная архитектура прежде всего предназначена для разделения работы на несколько команд разработчиков, когда вся система не может поместиться в головах одной команды на 10 человек. Есть и другие предпосылки типа горизонтального масштабирования отдельных частей, независимого деплоя частей... Но в одиночку пилить микросервисы - обычно немного смысла, и неудивительно, что получился монолит.
Мое личное мнение которое никому кроме своей команды не навязываю: микро, не микро, чистая архитектура, солид и прочее - оно все фигня и относительно. Разбивка и абстракции должны следовать некой цели: ресурсам, продуктовой, организационной. Классический пример из ЧА - делать интерфейс над слоем репозитория. Хрен, если мигрировать с условной монги на постгрес, то программный интерфейс будет прям последней из проблем, и если нет прямой необходимости его абстрагировать (например нет слоя кеширования и в ближайшие 3 года не предвидится) - оно нафиг не нужно и станет “+1 файлом с изменениями”. А вот если уже известно что нужно будет работать с 20 разными типами в одном пайплайне - вот тут точно нужна абстракция, безотносительно того что говорит очередная модная октогональная архитектура.
Конкретно для микросервисов имхо есть только три реально определяющих момента - структура компании, разделение cpu/io-bound сервисов и наличие общих зависимостей между продуктами (например общая авторизация или общая базовая модель юзера). В остальных случаях - монолит пока не доказано обратное.
А я всматриваю в суету вокруг микросервисов психологию массового сознания ("оно" прийдет и нас спасет) или даже богословие (идолопоклонство). По сути, это слепое поклонение форме через тупое копирование, подражание. Уже поведение, но еще не разумное. Вспоминаются эксперименты (Виктории Хорнер и Эндрю Уайтена), сравнивающие обезьян и детей, где показано, что дети копируют больше обезьян. И, наверное, благодаря этому мы лучше учимся. Но в разработке архитектур подобная незрелая "бессознанка" скорее вредит, т. к. "очарованное сознание" не соотносит свою "прелесть" с реалиями и последствиями. Или, другими словами, это тупо магическое мышление, коварно маскирующееся под рациональность.
Кстати. Есть чудесный фильм Гарри Бардина "Адажио", идеально отражающий подобную динамику сознания. Считайте, что в главной роли там микросервисы)
Обычная мода. Одни попробовали, выступили на конференциях, другие посмотрели и подумали, что это хорошо. Прошло немного времени... И уже моветон не использовать. Сейчас AI на базе LLM в этой фазе. До этого были микросервисы, NoSQL, agile, "чистый код", наверно паттерны...
А нужно или не нужно - это уже другой вопрос.
Сказали, что будет монолит, но почему приложение в итоге превращается в ациклицеский граф? То есть идея делать разработку через рабочий процесс, как создание функциональных узлов, и их переиспользование, в различных графах, является наилучшим решением? Мне графы нравятся тем, что можно их разделить на 2 слоя разной квалификации. Такие как узлы и их бэкенд. Узлы это по сути No-code логика, а бэкенд узлов это изолированный список функций в монолитной упаковке, который изолирован по умолчанию, но ему можно дать разрешение выйти в интернет и сделать запрос, прочитать или создать файл в указанной папке, просто обработать информацию на входе и выдать отформатированную на выходе. При этом тесты самой системы формирования узлов никуда не делась, необходимо брать тестовые данные и исполнять код узла без единой критической ошибки, чем круче среда тестирования, тем безопаснее узел. Есть такая среда новая как Windmill, там можно писать на любом языке, тестировать код и строить из кода ациклические графы визуально, по сути IDE следующего поколения. Сервер как таковой оно не заменяет. Но думаю вам будет полезно про такую вундервафлю узнать.
Прочитал только вступление по тому что меня заинтриговала затравка, но после описания того, что автор планировал сделать я не стал читать дальше. Очень странно что читая книги по микросервисам пришла в голову идея такого приложения. Микросервисная архитектура совсем другие вопросы решает. Я бы сказал что само приложение которое переводит пдф могло бы быть микросервисом в какой-то распределенной high load системе, но делать отдельное узкоспециализированное приложение микросервисами как будто бы оверкил.
Ну это приложение не просто переводит пдф, перевести пдф может любой переводчик. Это приложение, которое анализирует полную структуру пдф вместе с семантическим анализом, подбирает подходящие шрифты и пытается восстановить оригинальную верстку с уже переведенным текстом. Но, в целом соглашусь. Микросервисы здесь лишние и решают другие вопросы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вам не нужны микросервисы