Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Все круто, но при чем тут микросервисы? Вероятность таких проблем в монолитах точно такая же. Ты, случаем, не путаешь монолитную архитектуру и полное отсутствие масштабирования и HA?
Не путаю. Тут где-то были претензии, что монолит рассчитан на эксклюзивный доступ к БД, вот там да, можешь предъявлять.
На мой взгляд микросервисы намного легче нарушают yagni и kiss. Поэтому в них описанные мной проблемы (кстати, никак не связанные с масштабированием и HA) наступают быстрее.
Здравствуйте, Ziaw, Вы писали:
Z>На мой взгляд микросервисы намного легче нарушают yagni и kiss.
Потому что там это намного легче обходится.
Z> Поэтому в них описанные мной проблемы (кстати, никак не связанные с масштабированием и HA) наступают быстрее.
Если бы они наступали быстрее, тогда бы принципы нарушались намного реже. А то что они нарушаются чаще как раз и говорит, что микросервисы много ошибок прощают.
Здравствуйте, Ziaw, Вы писали:
НС>>Включаешь трейсинг и смотришь в каком нибудь егере где мы утыкаемся. И 50 сервисов схлопываются до одного. Z>А где мы там утыкаемся?
Где задержка.
Z> Обычно берешь ты трейс (хоть ягера, хоть профайлера) и видишь ровно столько, сколько у тебя знаний по каждому участку. Без этой экспертизы трейс малополезен.
По трейсу смотришь тормозящий сервис, дальше переадресуешь авторам сервиса. Все как в профайлере, только проще в силу более простой структуры связей.
Z>Впрочем этим примером я иллюстрировал другую проблему. Когда мы нагружаем систему на тестовом стенде мы видим какие-то закономерности потребления ресурсов от нагрузки и как-то умозрительно пытаемся их экстраполировать на прод.
Зачем? Включаешь трейс на проде, набираешь в егере дату, потом отключаешь и принимаешься за изучение. Все это намного проще, чем пытаться пользоваться профайлером на монолите.
Z>в микросервисах оно осложняется тем, что request/limit/hpa надо считать для каждого МС
Здравствуйте, Ziaw, Вы писали:
Z>В целях микросервисов ты прав, но даешь свое определение монолита. Монолит это единица деплоймента (архитектура межмодульного взимодействия, организация кодовой базы и ее CI/CD цикла). Сколько команд разрабатывают и как — дело десятое.
Нет, не десятое. В монолите команды всегда тесно связаны, даже если их несколько. Проблема этого в фиговой масштабируемости. При резком росте размера продукта не получится резко увеличить команду/команды.
Z>Границы модулей можно провести и внутри монолита
Провести то можно, но не все этими границами можно ограничить, и намного сложнее контролировать.
S>>Если подумать, то он не один программист на проекте. НС>Но в монолите все связано намного сильнее. У тебя программист на проекте напишет код, которых жрет CPU или память, и проблемы начнутся во всем сервисе.
И? Занятся оптимизацией, покамест масштабировать через LB или очередь. Нашему программисту надо будет все
в транзакции оборачивать. Т.е. придется думать над бд, над распр. системами пока на этом этапе
(несклько инстансов монолита) можно не думать.
S>>И? Ну буду шарить бд или очередь НС>И чем это отличается от микросервисов?
Тем что наше приложение по-прежнему монолит (см.выше если что). Т.е. это скрее SOA.
S>>Именно, НС>И получаем ровно ту же распределенную схему, что и у микросервисов.
Нет, не ту же -- SOA.
S>>Т.е. про рестарт думать особо не надо -- "все само". НС>А почему в микросервисах надо?
Можно не делать, никто не заставляет.
S>>Если работает с другим модулем, как-то надо восстановить или сохранить консистентность. НС>Какую такую консистентность?
Консистентность расшариваемого между инстансами стейта.
S>>А если не stateless? НС>То это фиговый микросервис.
Нефиговый сделать сложно.
S>>Наверх в случае мс это куда, и что делать -- пытаться достучаться или падать? НС>У тебя есть еще какие то варианты?
Я первый спросил.
S>>Да, но это надо еще изучить. НС>Как и в монолите.
А nosql в монолитах сильно нужен?
S>>Это не входило в компетенции нашего монолитного разработчика. НС>Чего вдруг? Монолит каким то волшебным образом избавлен от необходимости использовать БД или шардинг в ней?
Зависит от. Но нашему программисту это зачем?
S>>Что нужно знать нашему разработчику для HA? Что-то кроме транзакций? НС>А что нужно знать разработчику микросервиса?
НС>>>Все обработчики на одной машине, при этом message broker выделен в отдельный сервис — тоже весьма странное решение. message broker предназначен для решения двух основных задач — fault tolerance и buffering. Первое в первую очередь потребует HA, которого при одном инстансе нет, а уж потом очереди, а второе при одном инстансе намного проще и эффективнее сделать in process.
НС>У тебя как то с пониманием текста не очень. Попробуй перечитать внимательно что ты процитировал и понять, что такое "второе" (нет, не message broker).
Ясно, предлагается сделать in process буфферизацию, а с брокером это, очевидно, не получится.
Соотв. "S>Вы предложили брокер сделать in-proc:" забираю обратно. Неправ-с.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Типа необходимо уметь им пользоваться и понимать для чего он нужен, так? S>>Ну т.е. у нас не только сложная кодовая база, при которой натурально в блокноте
приходится писать, S>>но теперь и докер впихнули. Фортануло, че! НС>Опять ничего не понял. Ты точно понимаешь что такое докер и длоя чего он нужен.
Изоляция и простота деплоя. Что мы в огромном монолите будет изолироать? Сам монолит?
S>>Рефакторинг арх-ры? Можно, конечно, но чем это лучше чем переписать с нуля? НС>Ты точно понимаешь что такое рефакторинг?
Возврат тех. долга.
НС>>>Не надо все сводить до абсурда. Давай я тебе примером проиллюстрирую. Вот есть такой паттерн Посетитель. Если у тебя 2 реализации — точно нужно его использовать, вместо того чтобы написать просто свитч? А если реализаций 50 штук — разумно ли будет писать свитч на 50 кейсов? S>>50 это хорошо, а почему не 49? Свитч на 49 разумно, а на 36 свитч разумно? Вы понимаете всю абсурдность Ваших аргументов? НС>На вопрос ответь.
Свитч на 50 кейсов делать не разумно. А на 49 или 36 самое то?
S>>. Я первый раз услышал про количественные метрики применения паттернов НС>Количество, оно со временем переходит в качество, слышал про такое?
К чему эта крайне странная фраза написана? К количеству кода, т.е. чем больше кода тем лучше?
Это, очевидно, не так. Чем больше паттернов применили к кодовой базе, тем он, код, стал лучше?
Тоже сомнительный довод. Что сказать то хотели?
S>>, типа 49 свитчей еще рано, а вот 50 уже самое то. НС>Сам придумал, сам посмеялся.
Придумал не я, я только посмеялся.
S>>Скорее важно уметь читать, т.е. для монолитов важен навык чтения и понимания. А вот при переходе на мс арх-ру код приходится писать. НС>Ты сам прочти что ты пишешь. В монолите писать код не надо?
Для мс писать приходится чуточку больше кода, так лучше?
S>>Тем более, к чему тогда был этот довод? НС>К тому что чем выше требования к определенной экспертизе, тем выше нужна квалификация программиста. Маленький микросервис напишет обычный миддл, а ковыряться в огромном монолите не каждый сеньор потянет.
С такой формулировкой согласен. А если микросервис не маленький, а монолит не огромный?
Здравствуйте, VladiCh, Вы писали:
C>>В Гугле была сервисная система с самого начала, со своим аналогом контейнеров. Не знаю про MS. C>>Сервисы были не "микро", это да. Но именно микро-сервисы не очень-то нужны. VC>Микро или нет — это понятие растяжимое конечно, но в каких-то пределах. "Микро" здесь для утверждения разницы по сравнению с монолитами. Чем больше сервис по размеру тем он ближе к монолиту и его проблемам и наоборот.
Ну таки "микросервисы" — это всё же немного другое. Это архитектура, где реально МНОГО сервисов. В некоторых компаниях, которые полностью перешли на идеологию микросервисов, бывает, что на каждого программиста приходится несколько микросервисов. Это уже немного ненормально.
VC>То есть в реальности существует спектр конечно, от сервисов поменьше до сервисов побольше, но на каком-то масштабе размер становится таким что проявляются уже проблемы специфические для монолитов VC>и значит этот сервис скорее всего нужно дробить на более мелкие.
Согласен.
Здравствуйте, Sharov, Вы писали:
C>>В некоторых больших проектах не работает нормально даже автодополнение в IDE. S>Ну т.е. требуется навык писать как минимум компилируемый код в блокноте, чтобы лишний раз компилятор не гонять, ибо долго? S>Или как, к чему это замечание?
Навык писать без надёжного автокомплита, умение навигации в сложном коде, организация систем тестирования для всего этого счастья и т.п. Или хотя бы то, как делать изменения в общем коде для нескольких команд.
C>>Организация репозитория и структуры работы вокруг неё, тестирование (бывает, что тесты часами работают), и т.д. S>А к разработчику-то какие требования в связи с этим? Ну организовали репо, структуру работы с кодом.
Ну так а кто "организовали"? Вот кто-то этим и должен заниматься, причём на практике постоянно.
S>Это делается один раз и в начале проекта. Ну понятно, приходится больше думать над кодом, т.к. S>лишний раз гонять компилятор и тесты дорого. Довод, согласен. В мс с компиляцией проще, но думать S>тоже желательно.
На практике система постройки крупных проектов требует постоянной поддержки и развития. В качестве примера, рекомендую собрать современный Chrome или Firefox. Это как раз примеры достаточно крупных монолитов (35 миллионов строк кода в Chrome).
Здравствуйте, Ночной Смотрящий, Вы писали:
Z>>А где мы там утыкаемся?
НС>Где задержка.
Что считать задержкой? Вот у тебя 43 сервиса дернуты, разное количество раз с разными таймингами от 3 до 60мс. В сумме, 200. В какой утыкаемся?
НС>По трейсу смотришь тормозящий сервис, дальше переадресуешь авторам сервиса. Все как в профайлере, только проще в силу более простой структуры связей.
Авторы говорят, что это нормальное поведение, их сервис всегда так работал и другие команды не жаловались.
НС>Зачем? Включаешь трейс на проде, набираешь в егере дату, потом отключаешь и принимаешься за изучение. Все это намного проще, чем пытаться пользоваться профайлером на монолите.
И чем проще? Включаешь трейс на проде, выбираешь дату и принимаешься за изучение.
НС>И что в этом сложного?
В кратном увеличении объема работы. Если я правильно понимаю твою мысль — микросервисы позволяют легче размазывать ответственность по командам. И упрощение именно в этом. Мой поинт в том, что это достигается ценой сильного суммарного увеличения сложности (и цены) разработки. С тем, что у монолита есть свои пределы, при которых управление его разработкой становится все сложнее — спорить не буду.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич.
Это очевидно. И в монолите решаемо (достаточно немного подтюнить реалии скрама). А вот в микросервисах, которые прощают чуть больше, какой-то глобальный рефакторинг практически невозможен.
Здравствуйте, Ziaw, Вы писали:
НС>>Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич. Z>Это очевидно. И в монолите решаемо (достаточно немного подтюнить реалии скрама).
Нет, не решаемо при более менее большом размере.
Z>А вот в микросервисах, которые прощают чуть больше, какой-то глобальный рефакторинг практически невозможен.
Решаемо (достаточно немного подтюнить реалии скрама).
Здравствуйте, Ziaw, Вы писали:
НС>>Где задержка. Z>Что считать задержкой?
Несоответствие SLA.
Z>Вот у тебя 43 сервиса дернуты, разное количество раз с разными таймингами от 3 до 60мс. В сумме, 200. В какой утыкаемся?
Так на практике бывает очень редко, на хорошо оттюненом сервисе. А чаще из этих 200 на один сервис приходится 180.
НС>>По трейсу смотришь тормозящий сервис, дальше переадресуешь авторам сервиса. Все как в профайлере, только проще в силу более простой структуры связей. Z>Авторы говорят, что это нормальное поведение, их сервис всегда так работал и другие команды не жаловались.
Нормальное тут совсем неверный термин. Правильный — соответствующее требованиям. Есть SLA, есть нагрузка, нужно на этой нагрузке соответствовать SLA. Авторы, которые не хотят работать над соотвествием требованяим идут в сад.
НС>>Зачем? Включаешь трейс на проде, набираешь в егере дату, потом отключаешь и принимаешься за изучение. Все это намного проще, чем пытаться пользоваться профайлером на монолите. Z>И чем проще?
Я отвечал на этот вопрос предложением ранее.
НС>>И что в этом сложного? Z>В кратном увеличении объема работы.
Практика показывает, что трейсы упрощают жизнь, в монолите в том числе. Микросервисность тут особо не влияет.
Z>С тем, что у монолита есть свои пределы, при которых управление его разработкой становится все сложнее — спорить не буду.
А с чем тогда ты споришь? С тем что у микросервисов тоже есть предел снизу? Это кто то тут оспаривал?
Здравствуйте, Sharov, Вы писали:
S>>>Если подумать, то он не один программист на проекте. НС>>Но в монолите все связано намного сильнее. У тебя программист на проекте напишет код, которых жрет CPU или память, и проблемы начнутся во всем сервисе. S>И?
И изоляция микросервисов позволяет быстрее локализовать проблему и команду, которая за нее ответственна. Ты прям в графане в реальном времени видишь проблемный сервис, вылезший за лимиты по цпу или памяти.
S> Занятся оптимизацией,
Оптимизацией чего?
S> покамест масштабировать через LB или очередь.
Это если оно масштабируется.
S>>>И? Ну буду шарить бд или очередь НС>>И чем это отличается от микросервисов? S>Тем что наше приложение по-прежнему монолит (см.выше если что).
Монолит отличается от микросервисов тем что он монолит. Прекрасно.
S>>>Именно, НС>>И получаем ровно ту же распределенную схему, что и у микросервисов.
S>Нет, не ту же -- SOA.
Микросервисы — частный случай SOA. Монолиты — как повезет. Судя по твоим рассказам про ужасы рестартов — твои монолиты не так чтобы SOA.
S>>>Если работает с другим модулем, как-то надо восстановить или сохранить консистентность. НС>>Какую такую консистентность? S>Консистентность расшариваемого между инстансами стейта.
Так не надо велосипедить расшариваемый стейт. Если же ты его таки навелосипедил — у тебя будут проблемы и в монолите.
S>>>А если не stateless? НС>>То это фиговый микросервис. S>Нефиговый сделать сложно.
Это все касается и монолита, причем в большей степени.
S>>>Наверх в случае мс это куда, и что делать -- пытаться достучаться или падать? НС>>У тебя есть еще какие то варианты? S>Я первый спросил.
Т.е. нет. ЧТД.
S>>>Да, но это надо еще изучить. НС>>Как и в монолите. S>А nosql в монолитах сильно нужен?
Ровно настолько же, насколько и в микросервисах. У тебя по прежнему какое то крайне странное представление о микросервисах. Монолиты у тебя почему то что то довольно маленькое, без особой нагрузки, без требований к даунтайму, масштабируемости и НА.
S>>>Это не входило в компетенции нашего монолитного разработчика. НС>>Чего вдруг? Монолит каким то волшебным образом избавлен от необходимости использовать БД или шардинг в ней? S>Зависит от.
Я не буду все это читать в поисках доказательств тому, что ты тут заявляешь. Есть конкретно список тем, которые нужны в микросервисах и не нужны в аналогичного масштаба монолите?
Здравствуйте, Sharov, Вы писали:
НС>>Опять ничего не понял. Ты точно понимаешь что такое докер и длоя чего он нужен. S>Изоляция и простота деплоя.
Нет. В первую очередь это снижение оверхеда ВМ, т.е. контейнер это быстрее и дешевле. Потому что альтернатива докеру это прежде всего виртуалки.
S> Что мы в огромном монолите будет изолироать? Сам монолит?
Да, сам монолит. Но см. выше реальную причину существования контейнеров.
S>>>Рефакторинг арх-ры? Можно, конечно, но чем это лучше чем переписать с нуля? НС>>Ты точно понимаешь что такое рефакторинг?
S>Возврат тех. долга.
Возврат техдолга это не только рефакторинг, так что неверно.
НС>>На вопрос ответь. S>Свитч на 50 кейсов делать не разумно. А на 49 или 36 самое то?
А как по твоему?
S>>>. Я первый раз услышал про количественные метрики применения паттернов S>НС>Количество, оно со временем переходит в качество, слышал про такое? S>К чему эта крайне странная фраза написана?
К разговору. Количественные значения приводят к качественным скачкам.
S>К количеству кода, т.е. чем больше кода тем лучше?
Удивительная логика. Не пояснишь?
S>Тоже сомнительный довод. Что сказать то хотели?
Ровно то что сказал.
S>>>, типа 49 свитчей еще рано, а вот 50 уже самое то. НС>>Сам придумал, сам посмеялся. S>Придумал не я, я только посмеялся.
Нет, какую то абсолютную границу придумал именно ты. И именно над ее абсолютностью и посмеялся. Т.е. посмеялся сам над собой. У Чапека этот прием называется имаго.
В целом, у тебя какое то странное восприятие для инженера. Это вполне нормально, когда некая конструкция имеет оверхед, зависящий от количественных показателей. И на каком то количестве оверхед превышает пользу, на каком то польза сравнивается, а на каком то начинает превышать. Совершенно стандартная в инженерии ситуация, почему она вызывает у тебя какие то неуемные фантазии мне непонятно.
S>>>Скорее важно уметь читать, т.е. для монолитов важен навык чтения и понимания. А вот при переходе на мс арх-ру код приходится писать. НС>>Ты сам прочти что ты пишешь. В монолите писать код не надо? S> Для мс писать приходится чуточку больше кода, так лучше?
Доказательства где? Перейдя с общей сложности системы на количество кода, который надо писать, ты ступил на совсем тонкий лед. Потому что для микросервисов существует масса софта, который реализовывает то, что в монолите тебе придется велосипедить. И даже если ты используешь этот софт в монолите, количество разных чужих сервисов существенно приблизят твой монолит к микросервисам.
К примеру, твой монолит умеет хелсчеки, и чтобы если хелсчек стал выдавать проблему, сервис бы автоматически рестартанул? Если да, то как это реализовано?
НС>>К тому что чем выше требования к определенной экспертизе, тем выше нужна квалификация программиста. Маленький микросервис напишет обычный миддл, а ковыряться в огромном монолите не каждый сеньор потянет.
S>С такой формулировкой согласен. А если микросервис не маленький,
В моей практике SLA не константа, а какие-то вводные типа "15 февраля в 14:00 к нам придет 20к юзеров в промежутке около 5 минут. Они пройдут примерно по _____ сценарию. Остальная нагрузка будет примерно на прежнем уровне. Платформа должна выдержать.".
НС>Так на практике бывает очень редко, на хорошо оттюненом сервисе. А чаще из этих 200 на один сервис приходится 180.
У меня другой опыт, обычно сервис более-менее оттюнен и его надо развивать, не забывая прошлые вводные и добавляя новые. Если у нас какие-то явные проблемы, найти и оттюнить их обычно дело разовое и редкое. Чаще все работает неплохо, но возникает вопрос, а что если нагрузка вырастет вдвое, сколько ресурсов нам понадобится и сможем ли мы это переварить деньгами и девопсами.
НС>Нормальное тут совсем неверный термин. Правильный — соответствующее требованиям. Есть SLA, есть нагрузка, нужно на этой нагрузке соответствовать SLA. Авторы, которые не хотят работать над соотвествием требованяим идут в сад.
В теории все верно. Если авторы говорят, что они не хотят работать над соответствием требованиям рецепт известен. На практике у авторов есть своя правда и основания так говорить и их поход в сад ситуацию возможно даже ухудшит.
НС>Практика показывает, что трейсы упрощают жизнь, в монолите в том числе. Микросервисность тут особо не влияет.
Вот здесь плюсану. Не влияет.
НС>А с чем тогда ты споришь? С тем что у микросервисов тоже есть предел снизу? Это кто то тут оспаривал?
Хочется вернуть этот вопрос тебе, так как ты начал дискуссию со мной. Я лично отстаивал точку зрения, что микросервисы не "технология которая хорошо изучена, описана и делает все гораздо проще", а очень тяжелая и дорогая артиллерия, которую далеко не каждый бизнес способен вытащить. И в технических вопросах она уступает монолиту по части простоты, цены и скорости вплоть до бюджетов небольшого уездного города. Потом может начаться проще, с этим спорить не буду.
Z>>Вот у тебя 43 сервиса дернуты, разное количество раз с разными таймингами от 3 до 60мс. В сумме, 200. В какой утыкаемся? НС>Так на практике бывает очень редко, на хорошо оттюненом сервисе. А чаще из этих 200 на один сервис приходится 180.
Хм, видимо, практика у всех разная. Я все чаще наблюдаю именно такую ситуацию, что каждый конкретный сервис отвечает быстро, но суммарное время большое, потому что все выполняется последовательно, и везде сплошные RPC. Организовать же асинхронную обработку (scatter/gather какой) бывает очень непросто. Потому что те самые 100500 "параллельно работающих инженеров" слышали про RPC и про другие синхронные модели, а вот с message passing, однако, не могут. Да и языки не располагают, если не брать экзотику.
НС>Нормальное тут совсем неверный термин. Правильный — соответствующее требованиям. Есть SLA, есть нагрузка, нужно на этой нагрузке соответствовать SLA. Авторы, которые не хотят работать над соотвествием требованяим идут в сад.
Каждый конкретный сервис обычно в рамках SLA. А вот все вместе, увы, нет.
Интересно, что в монолитах (или просто больших сервисах) есть аналогичные проблемы. Но обычно не с latency, а с производительностью. Обычно это результат "работы с профайлером", люди смотрят "о, вот эта функция занимает 10% времени выполнения, щас мы ее оптимизируем". И начинают разносить ее на кусочки. Разнесут, доложат, что теперь cumulative time всего 2%. Берешь в зубы load test, смотришь — конечный результат стал... хуже, теперь сервис тянет на 3% меньше нагрузки.
А все почему? Да потому, что метрика так ставится, "не иметь функций, что кушают много кумулятивного времени".
Аналогично с latency. Есть медленный сервис. Окей, смотрим, он, оказывается, не то чтоб неделимый. Отлично, делим его пополам. Два результирующих сервиса уже укладываются в SLA. Problem solved.
Здравствуйте, Ziaw, Вы писали:
НС>>Решаемо (достаточно немного подтюнить реалии скрама). Z>Интересно, что там можно подтюнить, не теряя главный бенефит микросервисности — множество независимых команд, каждая со своими процессами.
Здравствуйте, Ziaw, Вы писали:
НС>>Несоответствие SLA. Z>В моей практике SLA не константа,
Круто. Клиентам вы тоже говорите, что SLA не константа, когда они к вам с вопросами приходят?
НС>>Так на практике бывает очень редко, на хорошо оттюненом сервисе. А чаще из этих 200 на один сервис приходится 180. Z>У меня другой опыт, обычно сервис более-менее оттюнен и его надо развивать, не забывая прошлые вводные и добавляя новые. Если у нас какие-то явные проблемы, найти и оттюнить их обычно дело разовое и редкое. Чаще все работает неплохо, но возникает вопрос, а что если нагрузка вырастет вдвое, сколько ресурсов нам понадобится и сможем ли мы это переварить деньгами и девопсами.
Для этого делают нагрузочное тестирование не планируемой нагрузке, которое таки начнет выявлять бутылочное горлышко.
А ты как делаешь?
НС>>Нормальное тут совсем неверный термин. Правильный — соответствующее требованиям. Есть SLA, есть нагрузка, нужно на этой нагрузке соответствовать SLA. Авторы, которые не хотят работать над соотвествием требованяим идут в сад. Z>В теории все верно.
На практике тоже.
Z>На практике у авторов есть своя правда
Что это за правда такая, позволяющая игнорить требования?
Z>и основания так говорить и их поход в сад ситуацию возможно даже ухудшит.
Извини, но это уже не техническая проблема.
НС>>А с чем тогда ты споришь? С тем что у микросервисов тоже есть предел снизу? Это кто то тут оспаривал? Z>Хочется вернуть этот вопрос тебе, так как ты начал дискуссию со мной.
Я ответил на конкретный вопрос по поводу поиска узких мест. Ты же начал теоретизировать обобщенно.
Z> Я лично отстаивал точку зрения, что микросервисы не "технология которая хорошо изучена, описана и делает все гораздо проще", а очень тяжелая и дорогая артиллерия, которую далеко не каждый бизнес способен вытащить.
Здравствуйте, SkyDance, Вы писали:
Z>>>Вот у тебя 43 сервиса дернуты, разное количество раз с разными таймингами от 3 до 60мс. В сумме, 200. В какой утыкаемся? НС>>Так на практике бывает очень редко, на хорошо оттюненом сервисе. А чаще из этих 200 на один сервис приходится 180. SD>Хм, видимо, практика у всех разная. Я все чаще наблюдаю именно такую ситуацию, что каждый конкретный сервис отвечает быстро, но суммарное время большое, потому что все выполняется последовательно, и везде сплошные RPC.
Так это другая проблема, для лечения которой нужны другие подходы.
SD>Каждый конкретный сервис обычно в рамках SLA. А вот все вместе, увы, нет.
Я ж говорю, это другая проблема, больше из области архитектуры всей системы.
Для мс писать приходится чуточку больше кода, так лучше?
