похоже на малопродуманную монолитную двузвенку, и данные - это прям коннект до базы? Помнится в виртуалках запускали копии на одном сервере именно по этой причине. А по сути решения проблемы, архитектура конечно в корне неверная тут. Да и базу можно (и возможно нужно) порезать в зависимости от функционала. Хотя ясно что этот монолит такое уже не позволит, и его "необходимо пилить", или вообще рушить и писать на его месте что-то грамотное и более-менее гибкое, в том числе умеющее создавать "витрины".
Разные стеки всё равно можно синхронизировать между собой, это обычная интеграционная задача, и многие тут её решали. Проще всего описать "формат взаимодействия" (некий обменный формат данных) утвердить его с обеих сторон и придерживаться его. Обычная задача стандартизации. Да, можно (и нужно) обернуть модули ETL сервисами и обмениваться данными по Сети, но это не микро сервисы. Сервисы как сервисы, выполняющие только сериализацию и десериализацию по сути, на стыке разных стеков.
Есть ещё тут один секрет. Когда стэки разные, а команды нет, (команда одна) ну или команды умеют общаться между собой как единое целое, то можно перейти к метапрограммированию и генерации кода. Тогда вопросов стандартизации вообще не возникает, точнее они уходят на уровень мета-генерации и описания метаданных.
Административные задачи никак не влияют на архитектуру. Она изначально должна правильно проектироваться на первых же этапах, дабы не было мучительно больно всё потом рушить до основания.
Бог миловал. Но опыт подобных инжекций "был". К примеру один московский заказчик спускал нам таблицу где были поля fa, im, ot. Когда их стало не хватать (ну дамы меняют же фамилии), он добавил поля fa2, im2, ot2, fa3, im3, ot3 и т.д. а т.к. система была связана с бабками , то были ещё и кучи полей типа p1, p2, p3 и т.п. В общем что такое нормализация БД этот заказчик даже не слышал.
Про олдов я не вам писал. Промахнулся где-то видимо. Сорри
Не смотря на то что якобы Сильвер Буллет не существует, есть вполне золотая середина, оправдывающая себя годами. И это точно не крайности в виде огромного плохо пахнущего монолита или огромного неуправляемого роя мух Аля микросервисы.
Сарказм.это весело конечно. Но монолитная архитектура есть зло.
Хотя микросервисная архитектура, а точнее сказать фактически отсутствие архитектуры как таковой, ещё большее зло, как по мне.
И, повторюсь, истина где-то посередине, как по мне это модульная, плагинная архитектура + сервисы при необходимости.
Ну и собирать и тестить из этого надо только то, что трогали. Хотя если там найт билд, то вообще пофигу сколько это собирается и тестится, хоть до утра.
Всегда есть золотая середина. И это всегда плагинно модульная архитектура. В том числе часть плагинов и модулей вы можете обернуть сервисами. Но только часть. И только если это реально необходимо.
Микросервисы же всё оборачивают сервисами что неимоверно увеличивает латентность всей системы, дублирование данных и кучу лишних манипуляций по сериализации и десериализации данных как минимум. Опять таки код надо копировать в памяти под каждым сервисом, хотя модуль мог исполнять его в одиночку.
Кривой монолит, без модулей и плагинов это крайность. Микро именно микро сервисы это тоже крайность. Истина как известно где-то между . По середине. Ну и под конкретную задачу.
А так я лично убеждён что модульная /сервисная архитектура универсальна. И модулей может быть немного. И они могут быть мелкими и смешными по функционалу. Но они обязаны быть! Их надо закладывать в архитектуру на начальном этапе проектирования.
Хотя бы для того, чтобы в будущем не переписывать весь этот монолит.
Ошибки архитектуры зачастую бывают ошибками нулевого дня.
Очень многие, приступая к реализации проекта, не видят дальше своего носа и не предполагают проблем роста. Притом типичных проблем, описанных сотни раз и с готовыми решениями, известными уже по полвека.
Потом приходится ломать такие проекты до основания и писать их практически заново и с нуля под "новые" требования ТЗ.
Модульная архитектура помогает снижать риск таких проблем в разы.
А том числе возможно переписывание/правка только одного или нескольких модулей.
К сожалению проблемы будут всё те же. Вопрос кеширования данных довольно серьезный и далеко не все смогут его обойти. Более того, если нет версионности в структуре данных, то кеши вообще не смогут понять и выявить проблему.
Если добавить версионность, то можно извне управлять кешем, т.е. По сути синхронизировать их.
Проблема эта решаемая в общем да. Но далеко не все умеют её решать.
похоже на малопродуманную монолитную двузвенку, и данные - это прям коннект до базы? Помнится в виртуалках запускали копии на одном сервере именно по этой причине.
А по сути решения проблемы, архитектура конечно в корне неверная тут. Да и базу можно (и возможно нужно) порезать в зависимости от функционала.
Хотя ясно что этот монолит такое уже не позволит, и его "необходимо пилить", или вообще рушить и писать на его месте что-то грамотное и более-менее гибкое, в том числе умеющее создавать "витрины".
Разные стеки всё равно можно синхронизировать между собой, это обычная интеграционная задача, и многие тут её решали.
Проще всего описать "формат взаимодействия" (некий обменный формат данных) утвердить его с обеих сторон и придерживаться его. Обычная задача стандартизации.
Да, можно (и нужно) обернуть модули ETL сервисами и обмениваться данными по Сети, но это не микро сервисы. Сервисы как сервисы, выполняющие только сериализацию и десериализацию по сути, на стыке разных стеков.
Есть ещё тут один секрет. Когда стэки разные, а команды нет, (команда одна) ну или команды умеют общаться между собой как единое целое, то можно перейти к метапрограммированию и генерации кода. Тогда вопросов стандартизации вообще не возникает, точнее они уходят на уровень мета-генерации и описания метаданных.
Административные задачи никак не влияют на архитектуру. Она изначально должна правильно проектироваться на первых же этапах, дабы не было мучительно больно всё потом рушить до основания.
Бог миловал. Но опыт подобных инжекций "был". К примеру один московский заказчик спускал нам таблицу где были поля fa, im, ot. Когда их стало не хватать (ну дамы меняют же фамилии), он добавил поля fa2, im2, ot2, fa3, im3, ot3 и т.д.
а т.к. система была связана с бабками , то были ещё и кучи полей типа p1, p2, p3 и т.п. В общем что такое нормализация БД этот заказчик даже не слышал.
Про олдов я не вам писал. Промахнулся где-то видимо. Сорри
Не смотря на то что якобы Сильвер Буллет не существует, есть вполне золотая середина, оправдывающая себя годами. И это точно не крайности в виде огромного плохо пахнущего монолита или огромного неуправляемого роя мух Аля микросервисы.
Что должно помешать обернуть пару критических модулей сервисами, и разнести их?
Зачем сразу стрелять из пушки по воробьям? Скорее даже по микроворобьям. Мухам видимо.
Сарказм.это весело конечно. Но монолитная архитектура есть зло.
Хотя микросервисная архитектура, а точнее сказать фактически отсутствие архитектуры как таковой, ещё большее зло, как по мне.
И, повторюсь, истина где-то посередине, как по мне это модульная, плагинная архитектура + сервисы при необходимости.
Ну и собирать и тестить из этого надо только то, что трогали. Хотя если там найт билд, то вообще пофигу сколько это собирается и тестится, хоть до утра.
А порезать монолит на слои / модули/ сервисы что мешает?
И зачем каждый раз собирать весь проект , а не только ту часть, которую меняли?
Да. И если вы будете пересобирать кучей все микросервисы, с чего это будет быстрее?
Всегда есть золотая середина. И это всегда плагинно модульная архитектура. В том числе часть плагинов и модулей вы можете обернуть сервисами. Но только часть. И только если это реально необходимо.
Микросервисы же всё оборачивают сервисами что неимоверно увеличивает латентность всей системы, дублирование данных и кучу лишних манипуляций по сериализации и десериализации данных как минимум. Опять таки код надо копировать в памяти под каждым сервисом, хотя модуль мог исполнять его в одиночку.
Кривой монолит, без модулей и плагинов это крайность. Микро именно микро сервисы это тоже крайность. Истина как известно где-то между . По середине. Ну и под конкретную задачу.
А так я лично убеждён что модульная /сервисная архитектура универсальна. И модулей может быть немного. И они могут быть мелкими и смешными по функционалу. Но они обязаны быть! Их надо закладывать в архитектуру на начальном этапе проектирования.
Хотя бы для того, чтобы в будущем не переписывать весь этот монолит.
Согласен. Инженерные технологии это не мир мод. Тут надо руководствоваться опытом и расчетами, а не сказками и слухами.
Но кто чем руководствуется каждый решает сам. И сам обязан отвечать за свои модные, но не оправданные, решения.
Не не не. Микросервис вполне осмысленное понятие. Из области одна функция= один микросервис.
Более масштабные решение уже сервисы или мини сервисы хотя бы.
Но вы правы с том, что очень многие уже наелись с микросервисами, с крайность этой, и возвращаются к золотой середине в виде сервисов .
У микросервисов есть своя ниша и свои плюсы. Но использовать их надо очень аккуратно и по минимуму.
Ошибки архитектуры зачастую бывают ошибками нулевого дня.
Очень многие, приступая к реализации проекта, не видят дальше своего носа и не предполагают проблем роста. Притом типичных проблем, описанных сотни раз и с готовыми решениями, известными уже по полвека.
Потом приходится ломать такие проекты до основания и писать их практически заново и с нуля под "новые" требования ТЗ.
Модульная архитектура помогает снижать риск таких проблем в разы.
А том числе возможно переписывание/правка только одного или нескольких модулей.
А кто сказал что монолит надо целиком масштабировать? Попилить его на модули или крупные сервисы нельзя чтоль?
Если грамотно проектировали монолит, то он минимум на 10 подсистем пилится обычно.
А вообще надо исходить из поставленной задачи. И решать её без лишней теории и фантазии.
Это написано кстати и в статье.
Очень часто хотелки бывают необоснованны, а проблемы придуманными и высланными из пальца
К сожалению проблемы будут всё те же. Вопрос кеширования данных довольно серьезный и далеко не все смогут его обойти. Более того, если нет версионности в структуре данных, то кеши вообще не смогут понять и выявить проблему.
Если добавить версионность, то можно извне управлять кешем, т.е. По сути синхронизировать их.
Проблема эта решаемая в общем да. Но далеко не все умеют её решать.
Им вон микросервисы легче запилить
Административная задача (менеджмент) вдруг стала решаться программно? Сервисами? Интерфейсов и тестов с документацией мало? Вы о чём вообще?
Ключевое тут "вроде как".
Так у вас нет ни одного аргумента. Закидывание опытнейших олдов не аргумент совершенно. Скорее показывает ваш уровень, чем уровень олдов
Не вижу аргументов. Обоснуйте
И ничем не обоснованное
Прилагать усилия? Термин архитектура вам знаком?
Эти части называются модули. Ну иногда это сервисы. Но точно не микросервисы!