Кажется (но надо копаться), что если бы включение VT давало такой выигрыш, то Spring+Kotlin давал бы заметный выигрыш от Spring+Java. Но, насколько я помню, это не так. Но про "фигня полная" согласен )
Ну, VirtualThread не всегда решают. Какое-нибудь решение на реактивном движке может оказаться не хуже, там в основном все зависит от эффективности nio. Но вообще да, TechEmpower - больше про предельную производительность, которую смогли выжать, к средней скорости продакшен кода имеет очень дальнее отношение (
Антифрод - это, все-таки, внешний сервис для процессинга и его производительность сильно зависит от количества и сложности правил (если про rule-based антифрод). В этом тесте антифрод не использовался. А что именно интересует в реализации антифрода?
Так автор, похоже, скопировал документацию двухлетней давности, даже не попробовав посмотреть внутрь. А редактора у публикации, разумеется, не было. Впрочем, может быть, никакого "архитектора" тоже нет, просто маркетолог с Gigachat собрал пост, даже не попытавшись разобраться в содержании. А то текст не очень похож на текст от архитектора, даже в T1
Но можно написать свою библиотеку на тех же принципах, тогда миллисекунды будут вполне нормальной latency. Никакой особой магии нет, реализация библиотеки - 4-6 человекмесяцев сеньора.
А в чем отличие от шардирования через Citus? Там, вроде бы, примерно те же возможности, но запросы на чтение между шардами развиты несколько лучше, хотя балансировка шардов сделана чуть менее автоматической.
А чем простой select for update не проходит? Он же поставит блокировку, если ее нет. Впрочем, мне вообще не понятно, зачем при обработке платежа нужны подобные локи. Тут скорее проблема вообще всего процесса платежа, не нужны там ни мутексы, ни блокировки на БД.
Это понятно. Но тут же нет задачи "поставить блокировку на первую (первые) незаблокированную запись", а SKIP LOCKED предполагается именно для такой схемы, для реализации очередей с несколькими воркерами. Если не нужно ждать блокировки, то лучше уж NOWAIT?
Ну и очень, очень много вопросов к архитектуре. Не совсем понятно, почему "наличие нескольких ДЦ" приводит к "одновременному приходу одного и того же запроса". Вообще-то вполне можно решить эту проблему (и множеством разных способов). Валера так и не смог отличить "идемпотентность" от "безопасной логики". Идемпотентность - это характеристика запроса. А в данном случае правильно говорить не об идемпотентности, а о корректном процессе обработки изменений статуса платежа. Но, судя по всему, эта задача так и не была решена до конца (и даже не была корректно поставлена). И подобных вопросов очень много (
Написание платежных шлюзов - достаточно простая задача, но да, желательно, чтобы ее (хотя бы первый раз) реализовывал сеньор с хоть каким-то опытом в финтехе. Иначе будет так, как написано (и это далеко не худшее из того, что может быть, мне доводилось встречать и гораздо более неприятные истории при эквайринговых интеграциях)
А почему задачу по платежной интеграции поручили джуну без опыта? И при этом его решение даже миддл не посмотрел? И почему вообще нет стандартного шаблона для платежных интеграций? Обычно он появляется после третьей попытки...
Если быть совсем точным, то даже в 60х в США были политические движения, считающие себя неонацистами и к которым эпитет "фашистские" вполне применим (в его современном значении). Впрочем, даже тогда они воспринимались не слишком серьезно, но в фильм "Blues Brothers" они умудрились попасть (как комедийные персонажи, разумеется).
О, про зависимости при обмене через брокер весело. 1. У тебя для сценария с кафкой продюсер зависит от реализации консюмера, так как должен формировать ключ партиционирования в зависимости от требований консюмера. 2. Если ты хочешь что-то изменить на продюсере для одного консюмера, ты обязан убедиться, что все прочие консюмеры эту правку правильно отработают. Т.е. у тебя изменения одного консюмера зависит от всех прочих консюмеров, это очень жестко. Для http/grpc можно иметь несколько версий endpoint, а для брокеров это не пройдет ( 3. С брокером ты не можешь обновить "события в пути", т.е. тебе придется как-то реализовывать сложную логику, ээ, договора между всеми консюмерами и продюсером о смене версии события. Я знаю только один гарантированный сценарий для этого, но его никто не использует, так как слишком сложно )
Обычно обновить один сервис намного проще десятка сервисов
Не, без разницы. Всегда нужно думать про миграцию данных, фичафлаги, совместимость и так далее. И когда вокруг этого сделан тулинг - то обновление делается тривиально. А если нельзя договориться с соседними командами - то это проблема культуры и она не решается техническими средствами и будет проблемой вообще всегда. Впрочем, в твоем сценарии "прокси к данным" она будет сказываться вообще постоянно, так как любое изменение логики реконсиляции потребует (с большими шансами) изменение этого "прокси-сервера". А это происходит гораздо чаще, чем, ээ, переход с одной СУБД на другую. И, кстати, нет никакой проблемы выкатывать весь указанный функционал кусочками, с чего бы что-то не получилось?
О, я понял, где у тебя иллюзии. Нет, в современных БД в IO уже довольно сложно уткнутся, проблема обычно в ядрах и в оперативке. И тут гораздо дешевле сделать выборку прямо из БД и потом сделать массовый update, нежели прокинуть десятки миллионов записей через какой-нибудь микросервис. На сериализацию-десериализацию уходит очень, очень много ресурсов, поэтому любые массовые выборки стоит делать из своей БД, а не через микросервис. Попробуй протащить через сеть protobuf на 10 млн. записей (даже кусочками по 10k) и замерь, сколько у тебя уйдет ядер на это развлечение. Увы. но все современные протоколы обмена микросервисов не очень быстрые и с кучей дополнительных проблем (но почему gRPC почти всегда плохой выбор - отдельная тема). Ну и в конкретно этом случае у тебя еще и логика "сервиса доступа к базе" будет зависеть от всех сценариев реконсиляции, что увеличит зависимость.
И это не какой-то уникальный случай, это как раз нормальный кейс, который возникает всегда при работе со сколь-нибудь большими объемами данных и пристойной нагрузкой.
Смотря как делать. Если сделать общий Redis для всего проекта - так и получится, но так делать не нужно, у каждого микросервиса Redis должен быть свой собственный.
Почему должен? Если Redis используем для взаимодействия (pub-sub, общие блокировки и т.п.), то как раз нужен общий Redis. А если это локальный кэш, то зачем Redis?
контрактами и версионированием формата передаваемых сообщений
А ты пробовал это делать корректно? Там сразу вылезает взаимозависимость всех консюмеров по деплою и версионированию, это не лучше любой интеграции через view, только еще и миграцию хранимых данные сделать нельзя, что сильно все усложняет. То, что ты описываешь - обеспечивает потерю порядка и невозможность отката, так делать не надо ) На БД обеспечить совместимость гораздо проще, чем на очередях )
Хм, а какой один сервис ты написал бы что для первой задачи, что для второй? Да, в первой задаче нужно пропускать несколько миллионов записей за десятки минут на относительно дешевом железе. Во второй - общее число дочерних сервисов для отчетности - десятки с БД до терабайта. Да, при изменении схемы совместимым образом - нет проблем. При добавлении шардирования - вообще с реконсиляцией будет все нетривиально, проблемы работы с БД там будут вторичными (да, я знаю, пробовал). Замена одной СУБД на другую - всегда дорогая операция, для аналитических запросов - всегда требует их переписывать. Просто потому что все СУБД очень разные и с разными особенностями реализации. Кейсы, которые делаем на PG - нельзя сделать на CH и наоборот. А вот обновление пяти-десяти сервисов - это весьма тривиальная задача, кстати. Что там сложного-то? Точно проще, чем с помощью PG научить CH притворяться Вертикой )
Кажется (но надо копаться), что если бы включение VT давало такой выигрыш, то Spring+Kotlin давал бы заметный выигрыш от Spring+Java. Но, насколько я помню, это не так.
Но про "фигня полная" согласен )
Какие исследования показывают, что разработка на Python больше, чем на Java?
Из процитированных исследований - это ниоткуда не следует.
Ну, VirtualThread не всегда решают. Какое-нибудь решение на реактивном движке может оказаться не хуже, там в основном все зависит от эффективности nio.
Но вообще да, TechEmpower - больше про предельную производительность, которую смогли выжать, к средней скорости продакшен кода имеет очень дальнее отношение (
Антифрод - это, все-таки, внешний сервис для процессинга и его производительность сильно зависит от количества и сложности правил (если про rule-based антифрод). В этом тесте антифрод не использовался. А что именно интересует в реализации антифрода?
Так автор, похоже, скопировал документацию двухлетней давности, даже не попробовав посмотреть внутрь.
А редактора у публикации, разумеется, не было. Впрочем, может быть, никакого "архитектора" тоже нет, просто маркетолог с Gigachat собрал пост, даже не попытавшись разобраться в содержании. А то текст не очень похож на текст от архитектора, даже в T1
Но можно написать свою библиотеку на тех же принципах, тогда миллисекунды будут вполне нормальной latency.
Никакой особой магии нет, реализация библиотеки - 4-6 человекмесяцев сеньора.
Но при этом эти заметки будут в твоем Github или в чужом?
А в чем отличие от шардирования через Citus? Там, вроде бы, примерно те же возможности, но запросы на чтение между шардами развиты несколько лучше, хотя балансировка шардов сделана чуть менее автоматической.
А чем простой select for update не проходит? Он же поставит блокировку, если ее нет.
Впрочем, мне вообще не понятно, зачем при обработке платежа нужны подобные локи. Тут скорее проблема вообще всего процесса платежа, не нужны там ни мутексы, ни блокировки на БД.
Это понятно.
Но тут же нет задачи "поставить блокировку на первую (первые) незаблокированную запись", а SKIP LOCKED предполагается именно для такой схемы, для реализации очередей с несколькими воркерами.
Если не нужно ждать блокировки, то лучше уж NOWAIT?
Ну и очень, очень много вопросов к архитектуре.
Не совсем понятно, почему "наличие нескольких ДЦ" приводит к "одновременному приходу одного и того же запроса". Вообще-то вполне можно решить эту проблему (и множеством разных способов).
Валера так и не смог отличить "идемпотентность" от "безопасной логики". Идемпотентность - это характеристика запроса. А в данном случае правильно говорить не об идемпотентности, а о корректном процессе обработки изменений статуса платежа. Но, судя по всему, эта задача так и не была решена до конца (и даже не была корректно поставлена).
И подобных вопросов очень много (
Написание платежных шлюзов - достаточно простая задача, но да, желательно, чтобы ее (хотя бы первый раз) реализовывал сеньор с хоть каким-то опытом в финтехе. Иначе будет так, как написано (и это далеко не худшее из того, что может быть, мне доводилось встречать и гораздо более неприятные истории при эквайринговых интеграциях)
А зачем SKIP LOCKED? Тут же как раз нужна блокировка.
SKIP LOCKED сделан для очередей, а не для попыток установить лок.
А почему задачу по платежной интеграции поручили джуну без опыта? И при этом его решение даже миддл не посмотрел?
И почему вообще нет стандартного шаблона для платежных интеграций? Обычно он появляется после третьей попытки...
Если быть совсем точным, то даже в 60х в США были политические движения, считающие себя неонацистами и к которым эпитет "фашистские" вполне применим (в его современном значении). Впрочем, даже тогда они воспринимались не слишком серьезно, но в фильм "Blues Brothers" они умудрились попасть (как комедийные персонажи, разумеется).
Ага, автор не очень разобрался в понятии исключений и ошибок в Java, увы.
О, про зависимости при обмене через брокер весело.
1. У тебя для сценария с кафкой продюсер зависит от реализации консюмера, так как должен формировать ключ партиционирования в зависимости от требований консюмера.
2. Если ты хочешь что-то изменить на продюсере для одного консюмера, ты обязан убедиться, что все прочие консюмеры эту правку правильно отработают. Т.е. у тебя изменения одного консюмера зависит от всех прочих консюмеров, это очень жестко. Для http/grpc можно иметь несколько версий endpoint, а для брокеров это не пройдет (
3. С брокером ты не можешь обновить "события в пути", т.е. тебе придется как-то реализовывать сложную логику, ээ, договора между всеми консюмерами и продюсером о смене версии события. Я знаю только один гарантированный сценарий для этого, но его никто не использует, так как слишком сложно )
Обычно обновить один сервис намного проще десятка сервисовНе, без разницы. Всегда нужно думать про миграцию данных, фичафлаги, совместимость и так далее. И когда вокруг этого сделан тулинг - то обновление делается тривиально. А если нельзя договориться с соседними командами - то это проблема культуры и она не решается техническими средствами и будет проблемой вообще всегда. Впрочем, в твоем сценарии "прокси к данным" она будет сказываться вообще постоянно, так как любое изменение логики реконсиляции потребует (с большими шансами) изменение этого "прокси-сервера". А это происходит гораздо чаще, чем, ээ, переход с одной СУБД на другую.
И, кстати, нет никакой проблемы выкатывать весь указанный функционал кусочками, с чего бы что-то не получилось?
О, я понял, где у тебя иллюзии. Нет, в современных БД в IO уже довольно сложно уткнутся, проблема обычно в ядрах и в оперативке. И тут гораздо дешевле сделать выборку прямо из БД и потом сделать массовый update, нежели прокинуть десятки миллионов записей через какой-нибудь микросервис. На сериализацию-десериализацию уходит очень, очень много ресурсов, поэтому любые массовые выборки стоит делать из своей БД, а не через микросервис. Попробуй протащить через сеть protobuf на 10 млн. записей (даже кусочками по 10k) и замерь, сколько у тебя уйдет ядер на это развлечение. Увы. но все современные протоколы обмена микросервисов не очень быстрые и с кучей дополнительных проблем (но почему gRPC почти всегда плохой выбор - отдельная тема).
Ну и в конкретно этом случае у тебя еще и логика "сервиса доступа к базе" будет зависеть от всех сценариев реконсиляции, что увеличит зависимость.
И это не какой-то уникальный случай, это как раз нормальный кейс, который возникает всегда при работе со сколь-нибудь большими объемами данных и пристойной нагрузкой.
Смотря как делать. Если сделать общий Redis для всего проекта - так и получится, но так делать не нужно, у каждого микросервиса Redis должен быть свой собственный.Почему должен? Если Redis используем для взаимодействия (pub-sub, общие блокировки и т.п.), то как раз нужен общий Redis. А если это локальный кэш, то зачем Redis?
контрактами и версионированием формата передаваемых сообщенийА ты пробовал это делать корректно? Там сразу вылезает взаимозависимость всех консюмеров по деплою и версионированию, это не лучше любой интеграции через view, только еще и миграцию хранимых данные сделать нельзя, что сильно все усложняет.
То, что ты описываешь - обеспечивает потерю порядка и невозможность отката, так делать не надо )
На БД обеспечить совместимость гораздо проще, чем на очередях )
Хм, а какой один сервис ты написал бы что для первой задачи, что для второй? Да, в первой задаче нужно пропускать несколько миллионов записей за десятки минут на относительно дешевом железе. Во второй - общее число дочерних сервисов для отчетности - десятки с БД до терабайта.
Да, при изменении схемы совместимым образом - нет проблем. При добавлении шардирования - вообще с реконсиляцией будет все нетривиально, проблемы работы с БД там будут вторичными (да, я знаю, пробовал). Замена одной СУБД на другую - всегда дорогая операция, для аналитических запросов - всегда требует их переписывать. Просто потому что все СУБД очень разные и с разными особенностями реализации. Кейсы, которые делаем на PG - нельзя сделать на CH и наоборот.
А вот обновление пяти-десяти сервисов - это весьма тривиальная задача, кстати. Что там сложного-то? Точно проще, чем с помощью PG научить CH притворяться Вертикой )