Ну, так или иначе все равно нужна группировка разных функций, иначе "найти" нужное (тем более обеспечивать автоматический intellisense и прочие фишки) будет сложно. Классы+методы нужны, кроме прочего, и как метод структурирования кода - и тут никаких вариантов не предлагается, просто "группировка функций в неймспейсах" - недостаточная замена. А как только начнется группировка, то выяснится, что функции работы с, например, постами нужны вместе, вместе с необходимыми dataclass, и в неймспейсе вида Post, что приведет к модульному коду в духе старого Pascal, из которого Java и выросла. Ну, длинный путь чтобы дойти до ООП. Но для небольших проектов - да, вполне нормальный подход. Если еще и с ООА сочетать.
Не совсем понятно, а где тут отказ от ООП? Если у микросервиса есть персистанс - то он уже является объектом с точки зрения ООП (в изначальном смысле, объект - как стейт+список обрабатываемых событий, где стейт - это персистанс, а события - это entrypoints). Вот если от предлагаемой структуры микросервиса переходить к стилю Pipes&Filters - можно говорить об отказе от ОПП. Да и в предложенной структуре кода вместо класса просто используется namespace как объединение данных и методов, особой разницы (кроме сложностей в использовании) нет. Так что в чем смысл предложенного метода - не совсем понятно.
Я вот тоже задаюсь тем же вопросом. Или ошибка в тексте и там указаны ns (но тогда маловато) или использованы какие-то очень странные конфигурации, не связанные с реальной жизнью (где ответ от кэша больше 5ms уже выглядит слишком долгим).
А для каких целей нужна оценка? Если нужна оценка большой фичи, то там оценка вообще выглядит не как число, а как набор рисков и вероятностей, попытка свести к одному числу - бесполезно. При этом оценка в SP никак не коррелирует с реальной трудоемкостью задачи или временем на ее выполнение (так как ни к чему не привязано). Ну а сходимость велосити - это про "самосбывающийся прогноз", к реальным оценкам и трудоемкости никакого отношения не имеет, просто решение подгоняется под готовый ответ, это популярное заблуждение.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Но меня забавляет настойчивость в использовании плохих методов менеджмента, даже их авторами уже признанными неудачными )
Команда может быть исполнителем с предсказуемой производительностью только если: 1) структура команды не меняется 2) все сотрудники в команде являются одинаковыми по производительности 3) входящие задачи имеют рутинный характер.
Увы, в реальности ни один из этих пунктов не соблюдается. Команда постоянно меняется (отпуска, смена мест работы, личный рост). Люди в команде тоже все разные и то, что один из них умеет делать плохо - другой делает хорошо и без планирования ресурсов внутри команды нельзя определить трудоемкость задачи. Входящие задачи тоже крайне редко настолько похожи друг на друга, что можно их оценивать одной линейкой.
Ну и, конечно, трудоемкость задачи (даже кривая в SP) никак не соотносится с временем доставки, так что нет никакой возможности на основе оценок SP хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.
Есть куча сценариев, где данные все-таки нужно запрашивать (ответ нужен синхронно, объем чужих данных очень большой, другой сервис не умеет в стриминг изменений, нет ресурсов для хранения чужих данных, нельзя получать данные не под запрос) и в этом случае запрос все-таки нужен. Да и получение потока чужих данных дает довольно сильную логическую связность, большую чем синхронный запрос.
Например есть статья от человека, который придумал SP: https://ronjeffries.com/articles/019-01ff/story-points/Index.html Про оценки сроков и трудоемкости неплохо написано у ДиМарко и Листера в "Вальсируя с медведями", короткий пересказ, например, в https://dev.to/tlakomy/why-i-don-t-like-story-point-driven-estimates-28h7 Но вообще бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать. Вообще, Scrum как магнит притягивает к себе кучу разнообразных плохих практик, по вполне понятным причинам.
На самом деле SP вообще не пригодны для каких-то оценок, кроме оценок рисков (и тогда сводятся к майкам). Вообще использование SP в большинстве случаев антипаттерн, но в предложенной методике и так настолько много сомнительных решений, что одним больше или меньше - уже не важно.
Да и "по возможности стоит избегать" - не совсем верно. Скорее уж асинхронное взаимодействие по возможности лучше избегать - как сложно контролируемое, увеличивающее latency и сложность кода.
(Прошу прощения, промахнулся по оценке, постарался компенсировать в других ваших комментариях). В конкретных случаях - да, может быть, так как фактически речь идет о стриминге изменений между двумя bounded contexts. Правда, кролик тут неудачный выбор и нужно бы Transaction Outbox прикрутить. Впрочем, когда есть TO, то он может и синхронно отправлять события, зачем там асинхронный MQ. Но, в любом случае, это не про "синхронные взаимодействия вообще плохи".
Это неверно. Если нужен ответ от сервиса, то все равно вызывающий ждет response-сообщения от MQ, только при этом требуется гораздо больше времени. А если ответ не нужен - то зачем его ждать? Клиенту нужен результат и если для его получения нужно вызвать 10 методов - они все будут вызваны, не важно, через MQ или синхронно. Но если вызывать через http/grpc, то результат будет быстрее и нагрузка на систему будет гораздо меньше.
Если приляжет MQ, то нужно будет сделать точно то же, так что логика retry в коде все равно будет нужна. Впрочем, нормальный resilience для http есть во всех языках и странно его не использовать.
В общем, не видно, с чего бы вызовы через ненадежный и без гарантий рэббит был бы хоть по каким-то параметрам лучше, чем прямой http вызов. Ну а если в кролике включать гарантии доставки (или, лучше, ставить кафку), то latency вырастет еще выше. Да и проблему с отправкой сообщений все равно не решить (
Но это же не так. Сделать http вызов с serviceA на serviceB очевидно дешевле, чем с ServiceA к брокеру и с брокера на ServiceB. Я уж не говорю, что тот же кролик "из коробки" не дает никаких гарантий, а для доставки at-least-once нужно будет громоздить кластер, персистанс и специального человека на поддержку всего этого добра. Впрочем, чистый http call тоже не дает никаких гарантий, но хотя бы не является SPOF
На 10000 серверах на каждом есть пайтон для запуска скриптов, написанных разработчиком? И к каждому с доступом на выполнение скриптов? И с логами, которые пишутся в файлы? Я не верю )
Кстати, yaznahar, а вы действительно не знаете про современные подходы к observability? Про системы сбора и хранения метрик, про системы сбора и хранения логов, про разделение метрик, логов и трейсов, про алертинги, про концепцию сайдкаров, про изоляцию продакшена от админов и разработчиков, про контейнеризацию и так далее и так далее? Пост действительно выглядит как пришедший из прошлого тысячелетия.
Э, нет конечно. Мы просто вешаем алерт на систему логгинга (которых бесконечное количество на любой вкус). И делаем это без каких-либо операций с продакшен-системой (типа добавления однострочников), крона и так далее. В стандартном стеке это делается в несколько кликов в графане. Она при этом еще и письмо пришлет или в телегу напишет.
Ну вот серьезно, уже XXI век на дворе, откуда эти идеи времен "приходящих виндовс-админов"?
Ну, так или иначе все равно нужна группировка разных функций, иначе "найти" нужное (тем более обеспечивать автоматический intellisense и прочие фишки) будет сложно.
Классы+методы нужны, кроме прочего, и как метод структурирования кода - и тут никаких вариантов не предлагается, просто "группировка функций в неймспейсах" - недостаточная замена.
А как только начнется группировка, то выяснится, что функции работы с, например, постами нужны вместе, вместе с необходимыми dataclass, и в неймспейсе вида Post, что приведет к модульному коду в духе старого Pascal, из которого Java и выросла. Ну, длинный путь чтобы дойти до ООП.
Но для небольших проектов - да, вполне нормальный подход. Если еще и с ООА сочетать.
Не совсем понятно, а где тут отказ от ООП? Если у микросервиса есть персистанс - то он уже является объектом с точки зрения ООП (в изначальном смысле, объект - как стейт+список обрабатываемых событий, где стейт - это персистанс, а события - это entrypoints). Вот если от предлагаемой структуры микросервиса переходить к стилю Pipes&Filters - можно говорить об отказе от ОПП.
Да и в предложенной структуре кода вместо класса просто используется namespace как объединение данных и методов, особой разницы (кроме сложностей в использовании) нет.
Так что в чем смысл предложенного метода - не совсем понятно.
Я вот тоже задаюсь тем же вопросом.
Или ошибка в тексте и там указаны ns (но тогда маловато) или использованы какие-то очень странные конфигурации, не связанные с реальной жизнью (где ответ от кэша больше 5ms уже выглядит слишком долгим).
А для каких целей нужна оценка?
Если нужна оценка большой фичи, то там оценка вообще выглядит не как число, а как набор рисков и вероятностей, попытка свести к одному числу - бесполезно. При этом оценка в SP никак не коррелирует с реальной трудоемкостью задачи или временем на ее выполнение (так как ни к чему не привязано).
Ну а сходимость велосити - это про "самосбывающийся прогноз", к реальным оценкам и трудоемкости никакого отношения не имеет, просто решение подгоняется под готовый ответ, это популярное заблуждение.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Но меня забавляет настойчивость в использовании плохих методов менеджмента, даже их авторами уже признанными неудачными )
Команда может быть исполнителем с предсказуемой производительностью только если:
1) структура команды не меняется
2) все сотрудники в команде являются одинаковыми по производительности
3) входящие задачи имеют рутинный характер.
Увы, в реальности ни один из этих пунктов не соблюдается. Команда постоянно меняется (отпуска, смена мест работы, личный рост). Люди в команде тоже все разные и то, что один из них умеет делать плохо - другой делает хорошо и без планирования ресурсов внутри команды нельзя определить трудоемкость задачи. Входящие задачи тоже крайне редко настолько похожи друг на друга, что можно их оценивать одной линейкой.
Все это приводит к бесполезности и оценки в SP и в оценке velocity вообще.
Тот же Рон про велосити пишет "If I invented velocity, I'm sorry" ( https://twitter.com/RonJeffries/status/1488220234750246919)
Ну и, конечно, трудоемкость задачи (даже кривая в SP) никак не соотносится с временем доставки, так что нет никакой возможности на основе оценок SP хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.
Есть куча сценариев, где данные все-таки нужно запрашивать (ответ нужен синхронно, объем чужих данных очень большой, другой сервис не умеет в стриминг изменений, нет ресурсов для хранения чужих данных, нельзя получать данные не под запрос) и в этом случае запрос все-таки нужен.
Да и получение потока чужих данных дает довольно сильную логическую связность, большую чем синхронный запрос.
Например есть статья от человека, который придумал SP: https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Про оценки сроков и трудоемкости неплохо написано у ДиМарко и Листера в "Вальсируя с медведями", короткий пересказ, например, в https://dev.to/tlakomy/why-i-don-t-like-story-point-driven-estimates-28h7
Но вообще бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать.
Вообще, Scrum как магнит притягивает к себе кучу разнообразных плохих практик, по вполне понятным причинам.
На самом деле SP вообще не пригодны для каких-то оценок, кроме оценок рисков (и тогда сводятся к майкам). Вообще использование SP в большинстве случаев антипаттерн, но в предложенной методике и так настолько много сомнительных решений, что одним больше или меньше - уже не важно.
Да и "по возможности стоит избегать" - не совсем верно. Скорее уж асинхронное взаимодействие по возможности лучше избегать - как сложно контролируемое, увеличивающее latency и сложность кода.
Нет разницы, как запрашивать данные, синхронно или асинхронно, в обоих случаях результат можно сохранить, если он нужен.
(Прошу прощения, промахнулся по оценке, постарался компенсировать в других ваших комментариях).
В конкретных случаях - да, может быть, так как фактически речь идет о стриминге изменений между двумя bounded contexts. Правда, кролик тут неудачный выбор и нужно бы Transaction Outbox прикрутить. Впрочем, когда есть TO, то он может и синхронно отправлять события, зачем там асинхронный MQ.
Но, в любом случае, это не про "синхронные взаимодействия вообще плохи".
Это неверно. Если нужен ответ от сервиса, то все равно вызывающий ждет response-сообщения от MQ, только при этом требуется гораздо больше времени. А если ответ не нужен - то зачем его ждать?
Клиенту нужен результат и если для его получения нужно вызвать 10 методов - они все будут вызваны, не важно, через MQ или синхронно. Но если вызывать через http/grpc, то результат будет быстрее и нагрузка на систему будет гораздо меньше.
Если приляжет MQ, то нужно будет сделать точно то же, так что логика retry в коде все равно будет нужна. Впрочем, нормальный resilience для http есть во всех языках и странно его не использовать.
В общем, не видно, с чего бы вызовы через ненадежный и без гарантий рэббит был бы хоть по каким-то параметрам лучше, чем прямой http вызов. Ну а если в кролике включать гарантии доставки (или, лучше, ставить кафку), то latency вырастет еще выше. Да и проблему с отправкой сообщений все равно не решить (
Но это же не так.
Сделать http вызов с serviceA на serviceB очевидно дешевле, чем с ServiceA к брокеру и с брокера на ServiceB.
Я уж не говорю, что тот же кролик "из коробки" не дает никаких гарантий, а для доставки at-least-once нужно будет громоздить кластер, персистанс и специального человека на поддержку всего этого добра. Впрочем, чистый http call тоже не дает никаких гарантий, но хотя бы не является SPOF
Автор пишет "Такое взаимодействие называется синхронным. Его лучше избегать". Хотелось бы понять, чем обусловлена такая рекомендация?
А чем все-таки плох синхронный подход? Простой и, в данном сценарии, наиболее надежный, с минимальной latency, простотой контроля и развития.
На 10000 серверах на каждом есть пайтон для запуска скриптов, написанных разработчиком? И к каждому с доступом на выполнение скриптов? И с логами, которые пишутся в файлы?
Я не верю )
Хм, они нормально работают от масштабов "один маленький сервер в чужом облаке" и до масштабов Гугла. А у тебя какой масштаб?
Кстати, yaznahar, а вы действительно не знаете про современные подходы к observability?
Про системы сбора и хранения метрик, про системы сбора и хранения логов, про разделение метрик, логов и трейсов, про алертинги, про концепцию сайдкаров, про изоляцию продакшена от админов и разработчиков, про контейнеризацию и так далее и так далее?
Пост действительно выглядит как пришедший из прошлого тысячелетия.
Нет, зачем там метрика с хоста? Достаточно метрики на основании запроса в систему логов, так все и делают обычно.
Э, нет конечно. Мы просто вешаем алерт на систему логгинга (которых бесконечное количество на любой вкус). И делаем это без каких-либо операций с продакшен-системой (типа добавления однострочников), крона и так далее.
В стандартном стеке это делается в несколько кликов в графане. Она при этом еще и письмо пришлет или в телегу напишет.
Ну вот серьезно, уже XXI век на дворе, откуда эти идеи времен "приходящих виндовс-админов"?