skyANA https://habrahabr.ru/post/249183/
https://habrahabr.ru/company/it-grad/blog/273583/

в общем случае эти все микросервисы такой-же тупик, как и микроядра.

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

а какие ожидают прелести трассировки микросервисов (а поди собери трейс лог по десяткам нод в реалтайме) - это вообще неописуемо.

RMagistr2015Как правильно составлять карту модулей приложения?
Есть большое запутанное приложение, в котором много различных модулей, и они постоянно друг друга вызывают и связи эти по первой можно вообще запутаться в этих макаронных вызовах, хочется понять спросить узнать, есть ли какие-нибудь методики описания структуры связей модулей приложения? как-то отслеживать вложенность вызовов, документировать этот процесс в наиболее понятную форму? Придать этому многообразию структурированный вид?
Кто сталкивался и чкакие подходы использвал в этом случае?

и какой смысл в этом описании, если не секрет?

ну составишь ты деревья всякие и графы, да еще и с картинками миллионов стрелочек туда-сюда, что потом с этим предполагается делать? положить в архив и забыть?

проблема/задача то какая стоит, на самом деле? "задокументировать все" - это не задача, это ИБД

softwarerdbpatchмало того, что цена межмодульных вызовов возростает многократно
Если не доходить до идиотизма в микромизации, то эти расходы можно сделать приемлемыми, а возможно и оказаться в итоговом плюсе. .
Мы живем не в идеальном мире, и чаще всего мотицация на подобные "структурые имзменения" продиктована как раз локальными искажениями сознания, вида - наш босс прочитал в CIO Magazine статью, что микросервисы - это престижно, уменшает TCO и увеличивает ROI, или ... программист-архитектор Вася решил поиграть в "новые" технологии и попробовать эдакое.

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

К примеру сервис аунтетификации об FB/VK/G+/etc - значительно проще поставить рядом сервер с HybridAuth на борту, и туда проксировать эти вызовы. Аналогично с модулями платежей - там иначе просто и не сделать.

Но разбивать сильносвязанное приложение на отдельные не модули, но сервисы, если это все контролируется одной командой - это еще надо трижды подумать.

softwarerdbpatchтак еще и порождается целый пласт новых проблем
Как и пласт новых возможностей.
Все имеет свою цену. Добавить новый слой сложности очень легко - а вот обслуживать его кто потом будет?

softwarerdbpatchмониторить и деплоить монолитное приложение куда проще, чем следить за здоровьем тысяч микросервисов.
Если добавить в "деплоить" условие "без прерывания обслуживания" - ещё вопрос, назовём так.
ой, да ладно. в мире вебсервисов (а какие бывают еще?) вопрос деплоя без прерывания обслуживания давно решен за счет обратного proxy, в т.ч. и для внутренних соединений (haproxy, nginx - как без них?).

softwarerdbpatchа какие ожидают прелести трассировки микросервисов (а поди собери трейс лог по десяткам нод в реалтайме) - это вообще неописуемо.
Прелести есть везде. Просто для примера - давайте просчитаем сценарий "одна из операций снабжена устойчивой утечкой памяти" для случая монолитного приложения и для случая микросервисов.

не нужно путать понятие "монолитное приложение" и "общая разделяемая куча".

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

ну потечет что-то, и что? время жизни сессии не более десятка секунд, и любой монитор моментально вычислит аномально вспухший PID и отстрелит его при случае, бояться подобного в наше время - даже как-то странно

skyANAdbpatchпропущено...


в общем случае эти все микросервисы такой-же тупик, как и микроядра.

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

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

с тобой никто и не спорит, я лишь подчеркнул некую абсурдность твоих сугубо теоретических ссылок выше в контесте изначального вопроса топикстартера.

абсурдность - он спрашивал про модульность, а ты зачем-то привел микросервисы. не знаешь или не понимаешь разницы?
ок, попробуй даже сугубо теоретически распилить софт масштаба Office на микросервисы, ибо монолит-же, все плохо!

обычно для наведения порядка в модулях вполне достаточно выделить пакеты, и разделить интерфейсы и реализацию, в любой среде есть та или иная реализация понятия package, описанного еще в IT-ном средневековье: https://books.google.com/books?id=AuMpAQAAMAAJ&redir_esc=y

Глава 7 - вполне четко поясняет, чем Package отличается от Component и от Class (последний часто приравнивают к Module, особенно в мире Java/C++, из-за чего у программистов получается сдвиг в понятийном аппарате сущностей для управления сложностью)

softwarerda17softwarer, и как все это делали?
Пришёл я однажды к начальству и сказал: я понимаю, что вы на эту хрень дышать боитесь, чтобы она окончательно не развалилась, но вот тут совсем задница, и я уже набрался достаточно нахальства, чтобы в неё лазить, поэтому предлагаю переписать вот это вот так. Получилось, стало получше. Внёс ещё несколько изменений. А там параллельно и у меня всё больше чесались руки, и у руководства разгорались и разгорались аппетиты.

da17Почему решили не переделывать все с нуля?
Самое главное - просто в голову не пришло Ну и никто бы мне этого не разрешил и не выделил бы ресурсов. Не говоря уже о том, что я на практике убедился, что риски такого вот аккуратного последовательного продвижения несравнимо ниже, чем у "а давайте всё сломаем и напишем с нуля". По сути, именно успех первых улучшений доказал, что стоит двигаться дальше.

микросервисы тут абсолютно ни при чем.
просто кто-то взял и переписал изначально хрупкое и плохо спроектированное решение, говоря проще - получил knowledge ownership

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

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