Хм, например задача "реконсиляции" при обработке платежей. У тебя есть история эквайринговых транзакций банка (т.е. прошедших через банк транзакций магазинов, интернет-сайтов и так далее). И есть представление об этой истории у контрагентов (тех же магазинов, платежных систем и так далее). Раз в сутки нужно сверить твои представления о реальности с пришедшими от контрагентов файлами. Форматов файлов много, процессы сверки тоже заметно отличаются. По факту сверки нужно пометить транзакцию как "проверенную". Одно из решений - каждый тип сверки делается отдельным сервисом, но при этом все эти сервисы смотрят в одну общую базу "истории транзакций". Сами транзакции пишутся процессингом, а вот сервисы реконсиляции умеют только читать из конкретной вьюшки и изменять одно поле. Получается удобная интеграция через базу, с очень понятным и легко контролируемым контрактом (в том числе и через гранты). Прочие решения будут на порядок менее удобные.
Второй популярный кейс - аналитическая база. Куда пишут (через разные варианты ETL) куча разных сервисов и читают оттуда данные тоже куча разных сервисов для отдачи в bff или для долгосрочного хранения или для отчетности. Собственно, в МСА без этого вообще UI нормальный не сделать, не будешь же джойны и сложные фильтры делать ручками на bff?
А с распределенными базами типа YDB интеграция через базу вообще становится еще и масштабируемой по производительности. Ну и, если честно, kafka, redis или hazelcast - это тоже все про интеграцию через общее хранилище (общую базу). А используются все эти паттерны для обмена между сервисами очень широко.
"Изложите свой вариант, хотя бы тезисно?" Вариант чего? Проблемы взаимодействий в MSA? У меня минимум три доклада разных на эту тему - и это все равно про весьма поверхностный подход к теме.
Хм, а где там усиление связи? Какая разница, контракт описывает entrypoint или view или вообще strored procedure - это все описание контрактов. И версионирование для view сделать не сложнее, чем для http calls (и, в среднем, проще, чем для gRPC).
И чтение - это совсем не мелочь, подход с кэшированием данных в своей базе (то, что ты называешь подпиской) - очень сложный, очень трудоемкий (при обеспечении минимальных гарантий), очень сильно повышающий связность, почти никак не версионируемый и, в большинстве случаев, вообще антипаттерн.
Общие транзакции для разных сервисах, разумеется, не реализуемы. Но и подобных потребностей при "интеграции через БД" несколько меньше, так как не нужно инвалидировать кучу кэшей в других сервисах, достаточно поменять данные только в одном месте.
Автор статьи, подозреваю, вообще никогда не видел ни MSA, ни монолита. Так как при наличии хоть какого-то опыта в статье было бы хоть что-то содержательное )
MSA это, в первую очередь, про упрощение арх.контроля и, реже, про возможность работать с разными НФТ для разных частей продукта (скорее про безопасность и надежность, чем про масштабируемость). Других плюсов там особо и нет. Но какой-нибудь ArchUnit вполне решает задачу контроля.
Вообще, при современных распределенных БД не совсем понятно, в чем проблема в общей БД для множества сервисов. Контракт интеграции, особенно для чтения, легко реализуется через view и, при этом, будет много эффективнее, чем тот же gRPC.
Впрочем, в статье столько всякой чуши написано, что нет смысла даже критиковать. Как будто плохую книжку по сисдизайну пересказывают, еще и десятилетней давности...
По DDD лучше всего читать собственно Эванса (первую книжку). Ну и Хорикова (но там больше статьи). Но книжки по DDD не помогут нарезать домены, тут лучше что-нибудь базовое по теории систем (хоть вузовский учебник, хоть Акоффа).
Какие еще языки для корпоративной разработки вы пробовали? В каких у вас есть серьезные компетенции? Без разнообразного опыта сложно говорить про "хороший" или "плохой" язык. А вот те, у кого есть достаточно разнообразный опыт - обычно относятся к Python с большим сомнением, тем более при использовании динамической типизации.
По МСА совсем уж хороших книг как не было, так и нет. Есть база типа Клеппмана, есть неплохие идеи в разных книжках у Ньюмана и Ричардса, но любые советы и рекомендации нужно читать осторожно и сверять с реальностями вашего проекта и потенциальными проблемами. Часто рекомендации не очень соответствуют реальности. Кстати, вместо Building Microservices лучше бы почитать Software Architecture: The Hard Parts тех же авторов.
А вот про выбор подхода - нет каких-то четких условий. В среднем, если домены хорошо нарезаны, то необходимости ходить в чужую БД вообще нет. Но иногда все-таки нужные чужие данные и тут Shared DB надежнее (не нужна синхронизация, реконсиляция и так далее), но хуже масштабируемо и требует аккуратного арх.контроля. Если команда не слишком опытная, инфраструктура хорошая и много денег - то можно смело идти в Databse-per-service. В реальности, конечно же, приходится думать над конкретным проектом и выбирать подходящее решение.
Так у AI вообще плохо с арифметикой. А статью, судя по всему, сгенерила LLMка (и вряд ли это был платный ChatGPT, скорее что-то бесплатное и поднятое на ноутбуке, судя по результату). Судя по всему, в МТС примерно так и относятся к своим разработчикам, не видя разницы между тимлидами и устаревшими LLMками.
Ну, студенты вряд ли лучше пишут, чем профессионалы (причем в конкретном языке). Но я про то, что дизайн исследования изначально такой, что даже за курсовую не засчитать, не говоря уж за публикацию.
Хм, а может это МТС тестирует просто AI-агента по написанию статей и ответам на комментарии? Но лучше бы взяли модель посовременнее, да и температуру лучше понизить.
Похоже, что вы недостаточно компетентны для понимания того, что написано в исследованиях. Возможно, вам стоит попробовать проанализировать дизайн исследований, их ограничения, актуальность - и делать выводы уже на этой базе. В текущем изложении эти исследования не доказали ничего )
Спасибо, я забыл про researchgate. Прекрасно. Там на Java/C/C++ код писали студенты старших курсов в 1997(!) году. А на Python - волонтеры из профессиональной тусовки. Дальше, по идее, можно уже и не читать, никакой ценности статья не имела даже в момент публикации )
Так Python - не язык более высокого уровня, нежели Java. Вот на чистом C писать чуть дольше, да. А все остальные современные языки примерно одинаковые по уровню.
Ни одно из этих утверждений, увы, не соответствует истине. Ну, сахара в питоне много, но в Котлине и современной java не меньше. Остальное - просто набор заблуждений )
Хм, например задача "реконсиляции" при обработке платежей. У тебя есть история эквайринговых транзакций банка (т.е. прошедших через банк транзакций магазинов, интернет-сайтов и так далее). И есть представление об этой истории у контрагентов (тех же магазинов, платежных систем и так далее). Раз в сутки нужно сверить твои представления о реальности с пришедшими от контрагентов файлами. Форматов файлов много, процессы сверки тоже заметно отличаются. По факту сверки нужно пометить транзакцию как "проверенную".
Одно из решений - каждый тип сверки делается отдельным сервисом, но при этом все эти сервисы смотрят в одну общую базу "истории транзакций". Сами транзакции пишутся процессингом, а вот сервисы реконсиляции умеют только читать из конкретной вьюшки и изменять одно поле.
Получается удобная интеграция через базу, с очень понятным и легко контролируемым контрактом (в том числе и через гранты). Прочие решения будут на порядок менее удобные.
Второй популярный кейс - аналитическая база. Куда пишут (через разные варианты ETL) куча разных сервисов и читают оттуда данные тоже куча разных сервисов для отдачи в bff или для долгосрочного хранения или для отчетности. Собственно, в МСА без этого вообще UI нормальный не сделать, не будешь же джойны и сложные фильтры делать ручками на bff?
А с распределенными базами типа YDB интеграция через базу вообще становится еще и масштабируемой по производительности.
Ну и, если честно, kafka, redis или hazelcast - это тоже все про интеграцию через общее хранилище (общую базу). А используются все эти паттерны для обмена между сервисами очень широко.
"Изложите свой вариант, хотя бы тезисно?"
Вариант чего? Проблемы взаимодействий в MSA? У меня минимум три доклада разных на эту тему - и это все равно про весьма поверхностный подход к теме.
Хм, а где там усиление связи? Какая разница, контракт описывает entrypoint или view или вообще strored procedure - это все описание контрактов. И версионирование для view сделать не сложнее, чем для http calls (и, в среднем, проще, чем для gRPC).
И чтение - это совсем не мелочь, подход с кэшированием данных в своей базе (то, что ты называешь подпиской) - очень сложный, очень трудоемкий (при обеспечении минимальных гарантий), очень сильно повышающий связность, почти никак не версионируемый и, в большинстве случаев, вообще антипаттерн.
Общие транзакции для разных сервисах, разумеется, не реализуемы. Но и подобных потребностей при "интеграции через БД" несколько меньше, так как не нужно инвалидировать кучу кэшей в других сервисах, достаточно поменять данные только в одном месте.
Автор статьи, подозреваю, вообще никогда не видел ни MSA, ни монолита. Так как при наличии хоть какого-то опыта в статье было бы хоть что-то содержательное )
MSA это, в первую очередь, про упрощение арх.контроля и, реже, про возможность работать с разными НФТ для разных частей продукта (скорее про безопасность и надежность, чем про масштабируемость). Других плюсов там особо и нет. Но какой-нибудь ArchUnit вполне решает задачу контроля.
Вообще, при современных распределенных БД не совсем понятно, в чем проблема в общей БД для множества сервисов. Контракт интеграции, особенно для чтения, легко реализуется через view и, при этом, будет много эффективнее, чем тот же gRPC.
Впрочем, в статье столько всякой чуши написано, что нет смысла даже критиковать. Как будто плохую книжку по сисдизайну пересказывают, еще и десятилетней давности...
По DDD лучше всего читать собственно Эванса (первую книжку). Ну и Хорикова (но там больше статьи).
Но книжки по DDD не помогут нарезать домены, тут лучше что-нибудь базовое по теории систем (хоть вузовский учебник, хоть Акоффа).
Какие еще языки для корпоративной разработки вы пробовали? В каких у вас есть серьезные компетенции?
Без разнообразного опыта сложно говорить про "хороший" или "плохой" язык. А вот те, у кого есть достаточно разнообразный опыт - обычно относятся к Python с большим сомнением, тем более при использовании динамической типизации.
А у автора есть реальный опыт проектирования и защиты сайзинга для сколь-нибудь сложных систем? А то тут что не пункт - то ошибка проектирования (
Хм, из этих статей можно сделать только один выводы - их автор не умеет читать и не умеет в бенчмарки. Что-то еще есть?
И откуда такой вывод? И качество библиотек при этом учитывалось или в расчет принимались любые работы джунов?
По МСА совсем уж хороших книг как не было, так и нет. Есть база типа Клеппмана, есть неплохие идеи в разных книжках у Ньюмана и Ричардса, но любые советы и рекомендации нужно читать осторожно и сверять с реальностями вашего проекта и потенциальными проблемами. Часто рекомендации не очень соответствуют реальности. Кстати, вместо Building Microservices лучше бы почитать Software Architecture: The Hard Parts тех же авторов.
А вот про выбор подхода - нет каких-то четких условий. В среднем, если домены хорошо нарезаны, то необходимости ходить в чужую БД вообще нет. Но иногда все-таки нужные чужие данные и тут Shared DB надежнее (не нужна синхронизация, реконсиляция и так далее), но хуже масштабируемо и требует аккуратного арх.контроля. Если команда не слишком опытная, инфраструктура хорошая и много денег - то можно смело идти в Databse-per-service.
В реальности, конечно же, приходится думать над конкретным проектом и выбирать подходящее решение.
Для высоконагруженных - Rust, Java,
Go - скорее для очень простых и не слишком нагруженных микросервисов.
Ну или для средненагруженных системных утилит, тут он вообще идеален (так как для этого и проектировался).
Так у AI вообще плохо с арифметикой. А статью, судя по всему, сгенерила LLMка (и вряд ли это был платный ChatGPT, скорее что-то бесплатное и поднятое на ноутбуке, судя по результату).
Судя по всему, в МТС примерно так и относятся к своим разработчикам, не видя разницы между тимлидами и устаревшими LLMками.
Ну, студенты вряд ли лучше пишут, чем профессионалы (причем в конкретном языке).
Но я про то, что дизайн исследования изначально такой, что даже за курсовую не засчитать, не говоря уж за публикацию.
Хм, а может это МТС тестирует просто AI-агента по написанию статей и ответам на комментарии? Но лучше бы взяли модель посовременнее, да и температуру лучше понизить.
Похоже, что вы недостаточно компетентны для понимания того, что написано в исследованиях. Возможно, вам стоит попробовать проанализировать дизайн исследований, их ограничения, актуальность - и делать выводы уже на этой базе.
В текущем изложении эти исследования не доказали ничего )
Спасибо, я забыл про researchgate.
Прекрасно. Там на Java/C/C++ код писали студенты старших курсов в 1997(!) году. А на Python - волонтеры из профессиональной тусовки. Дальше, по идее, можно уже и не читать, никакой ценности статья не имела даже в момент публикации )
Так Python - не язык более высокого уровня, нежели Java.
Вот на чистом C писать чуть дольше, да. А все остальные современные языки примерно одинаковые по уровню.
Ни одно из этих утверждений, увы, не соответствует истине. Ну, сахара в питоне много, но в Котлине и современной java не меньше. Остальное - просто набор заблуждений )