На какую нагрузку рассчитан движок PGSaga? Сколько «шагов» в секунду на сервер?
Как определяется логика шага для executor — это просто какой-то RCP вызов или что-то сложнее?
Сотни (и тысячи) и PostgreSQL держит. Но в Firebird нет skip locked (и вообще, насколько я помню, там очень ограничено управление блокировками и транзакциями).
С трудом себе представляю сценарий, в котором мне мог бы понадобиться Firebird.
А откуда взялась такая статистика «90 процентов имеют одинаковую обработку»? У нас категорически не так.
Впрочем, подозреваю, вы путаете процессинг (проведение онлайн платежа) и банковский учет (оформление проводок в АБСке). Я рассказываю в основном про процессинг, где задержки пользователя недопустимы, а проводок вообще нет (платеж, представляет собой первичный документ в терминах бухучета и в АБСку поступает только при удачном завершении).
Разумеется, интеграция с АБСкой делается пакетно, уже после завершения платежа. Проблемы возникают, скорее, из-за неторопливости нашей АБСки (впрочем, насколько я знаю, это проблема не столько нашей конкретной системы, сколько всех АБСок — они в основном сделаны по технологиям прошлого века), ну для этого мы и переводим потихоньку бухучет в процессинг (где он занимает, впрочем, совершенно незначительное время по сравнению с прочими этапами платежа).
Ну а изменение остатка и ликвидности в процессинге — совершенно не значимая операция, что там может быть сложного и тяжелого…
Ну, у нас, вроде бы, проблем с АБСкой нет. Там есть ограничения по производительности (слишком дорого получается масштабировать), так что мы тоже переносим банковский учет внутрь процессинга. И, конечно, внутри процессинга приходится делать проводки, счета и т.п, но это как раз относительно просто, хотя и муторно. Сложности там скорее в прекрасных отчетах из 255 полей для Финмониторинга и прочих вещах, связанных с персональными данными.
Кстати, а ты (или лучше на Вы) где работаешь?
О, содержательный комментарий, ура. По пунктам:
1) Если посмотришь на статью, то именно это мы и сделали. Только шаги набираются не заранее, а в процессе прохождения платежа. От чистого STM мы отказались вообще сразу, а дальше был длинный путь до осознания, что наша модель работы с платежами — это просто персистентные акторы.
2) Как раз с шлюзами у нас проблем нет, они на акторной модели пишутся просто и там легко можно вместо длинных транзакций внутри одного шага сделать несколько шагов, базы данных у шлюзов независимые, в производительность не упремся. Тут главное — в продуманном внутреннем API для шлюзов, если оно асинхронное, то все пишется достаточно просто.
3) Э, не надо путать учет в НКО и бизнес-аналитику. Учет в НКО — это управленческий и бухгалтерский, ведется в АБСке, и там все достаточно хорошо (по крайней мере и бизнес и аудит ЦБ довольны). А бизнес-аналитика нужна для ответов на вопросы вида «после обновления API у такого-то контрагента как изменилось распределение ошибок по соответствующему шлюзу» или «мы изменили дизайн формы оплаты через мобильных операторов, что стало с конверсией» или «один из клиентов начал рекламную акцию на Дальнем Востоке, как это изменило поток платежей по региону сравнительно с предыдущими подобными акциями». Это очень разные инструменты. Одним из требований к бизнес-аналитике, кстати, является интеграция с Google Analitics.
4) Как ты думаешь, кто проектировал самую первую очередь (еще на Oracle) на БД в Яндекс.Деньгах? И переписывал ее потом на skip locked? Да и появилась db-queue уже после того, как мы сделали свое собственное решение. И в нашем решении некоторые вещи сделаны заметно гибче и (для нас) удобнее. Например, возможность задавать свои стратегии повтора (произвольные) или добавлять действия на коммит транзакции обработки (для инвалидации или заполнения кэшей, например).
Собственно, то, что я делал в текущем проекте — это как раз попытка не наступить на те грабли, что были в Яндекс.Деньгах.
5) Сейчас у меня есть понимание, как это можно сделать еще проще, но пока не реализовано, так что доклада пока не будет )
6) Спасибо. Но идемпотемптность идет по одной операции, а не по цепочке. И не все контрагенты (почти никто, если честно) вообще не поддерживают идемпотемптность в платежах, так что все не так хорошо. Ну и пособеседовав кучу разработчиков и архитекторов из маленьких платежных систем — я понял, что спокойно готов пользоваться только теми, что сам писал (так что Яндекс.Деньгами я спокойно пользуюсь).
Ну, в документах по PCI DSS есть выжимки по организации безопасности, их можно использовать для убеждения. И есть же список общих практик по информационной безопаности (вечно забываю, как именно документ называется, но все безопасники на него всегда ссылаются), можно его использовать. Он тоже вполне конкретен.
Увы, это имело бы смысл, если бы контрагенты поддерживали бы пакетную обработку и если бы у всех платежей был бы одинаковый процесс прохождения.
Но это не так, контрагенты не поддерживают пакетной обработки и каждый платеж достаточно индивидуален.
А все, что можно сделать пачкой мы, конечно, сделали, но таких операций очень и очень мало. Да и логика обработки сильно усложняется.
Ну, вообще-то в начале сказано, что это система платежей для легального российского букмекерского бизнеса. Таковых на рынке ровно две и я рассказывал не про Qiwi.
В качестве требований — до 100 платежей в секунду, сквозные платежи, прямые платежи, интеграция с другими агрегаторами, карточными процессингами и другими платежными системами.
Почему платеж — это гораздо сложее, чем кажется, я довольно много рассказывал. Статусы, надежность переходов, юридические ограничения и так далее.
Ну и от этой системы зависит где-то половина российского онлайного букмекерского бизнеса, это не мало. Собственно, потому и на грани энтерпрайза.
Редактирование html не подходит по условиям задачи (с текстами должны работать люди, не разбирающиеся в верстке). Про плагин работы с Markdown я, конечно, знаю, но это именно плагин, не очень удобный в использовании для «не программиста» и не убирающий всю прочую сложность Idea. Я имел в виду отдельное решение типа WebStorm, но не для языка программирования, а для текстов (сложных текстов). С связями между файлами, возможностью добавить собственные CSS, возможностью добавить метаинформацию и т.п.
Так, что бы этот инструмент можно было дать редактору или маркетологу.
Теоретически, такое можно сделать из Eclipse, но это была бы уже более сложная разработка, нежели мы могли себе позволить.
Насколько я могу видеть, с ИБ вообще все довольно плохо. К нам на собеседования регулярно приходили разработчики из банков или платежных систем — и судя по ответам, далеко не всюду всерьез заботятся о безопасности.
У меня после нескольких сделанных платежных систем развилась легкая личная паранойя на теме доступа к данным и уязвимостям, но в большинстве проектов не готовы увеличивать стоимость разработки и поддержки ради безопасности. Хорошо, если аудитор грамотный и может показать какие-то реальные уязвимые точки, но обычно при PCI DSS аудите проверяются только система, связанная с карточными данными, а это далеко не полный список уязвимостей.
А вместо руководства «платежная система для чайников» — проще найти специалистов для отдельной консультации, все будет дешевле, чем самому грабли собирать. Так, в общем-то, почти в любых сложных проектах.
Как определяется логика шага для executor — это просто какой-то RCP вызов или что-то сложнее?
С трудом себе представляю сценарий, в котором мне мог бы понадобиться Firebird.
Впрочем, подозреваю, вы путаете процессинг (проведение онлайн платежа) и банковский учет (оформление проводок в АБСке). Я рассказываю в основном про процессинг, где задержки пользователя недопустимы, а проводок вообще нет (платеж, представляет собой первичный документ в терминах бухучета и в АБСку поступает только при удачном завершении).
Разумеется, интеграция с АБСкой делается пакетно, уже после завершения платежа. Проблемы возникают, скорее, из-за неторопливости нашей АБСки (впрочем, насколько я знаю, это проблема не столько нашей конкретной системы, сколько всех АБСок — они в основном сделаны по технологиям прошлого века), ну для этого мы и переводим потихоньку бухучет в процессинг (где он занимает, впрочем, совершенно незначительное время по сравнению с прочими этапами платежа).
Ну а изменение остатка и ликвидности в процессинге — совершенно не значимая операция, что там может быть сложного и тяжелого…
Кстати, а ты (или лучше на Вы) где работаешь?
1) Если посмотришь на статью, то именно это мы и сделали. Только шаги набираются не заранее, а в процессе прохождения платежа. От чистого STM мы отказались вообще сразу, а дальше был длинный путь до осознания, что наша модель работы с платежами — это просто персистентные акторы.
2) Как раз с шлюзами у нас проблем нет, они на акторной модели пишутся просто и там легко можно вместо длинных транзакций внутри одного шага сделать несколько шагов, базы данных у шлюзов независимые, в производительность не упремся. Тут главное — в продуманном внутреннем API для шлюзов, если оно асинхронное, то все пишется достаточно просто.
3) Э, не надо путать учет в НКО и бизнес-аналитику. Учет в НКО — это управленческий и бухгалтерский, ведется в АБСке, и там все достаточно хорошо (по крайней мере и бизнес и аудит ЦБ довольны). А бизнес-аналитика нужна для ответов на вопросы вида «после обновления API у такого-то контрагента как изменилось распределение ошибок по соответствующему шлюзу» или «мы изменили дизайн формы оплаты через мобильных операторов, что стало с конверсией» или «один из клиентов начал рекламную акцию на Дальнем Востоке, как это изменило поток платежей по региону сравнительно с предыдущими подобными акциями». Это очень разные инструменты. Одним из требований к бизнес-аналитике, кстати, является интеграция с Google Analitics.
4) Как ты думаешь, кто проектировал самую первую очередь (еще на Oracle) на БД в Яндекс.Деньгах? И переписывал ее потом на skip locked? Да и появилась db-queue уже после того, как мы сделали свое собственное решение. И в нашем решении некоторые вещи сделаны заметно гибче и (для нас) удобнее. Например, возможность задавать свои стратегии повтора (произвольные) или добавлять действия на коммит транзакции обработки (для инвалидации или заполнения кэшей, например).
Собственно, то, что я делал в текущем проекте — это как раз попытка не наступить на те грабли, что были в Яндекс.Деньгах.
5) Сейчас у меня есть понимание, как это можно сделать еще проще, но пока не реализовано, так что доклада пока не будет )
6) Спасибо. Но идемпотемптность идет по одной операции, а не по цепочке. И не все контрагенты (почти никто, если честно) вообще не поддерживают идемпотемптность в платежах, так что все не так хорошо. Ну и пособеседовав кучу разработчиков и архитекторов из маленьких платежных систем — я понял, что спокойно готов пользоваться только теми, что сам писал (так что Яндекс.Деньгами я спокойно пользуюсь).
Но это не так, контрагенты не поддерживают пакетной обработки и каждый платеж достаточно индивидуален.
А все, что можно сделать пачкой мы, конечно, сделали, но таких операций очень и очень мало. Да и логика обработки сильно усложняется.
Ну и уже давно не открывают, это не первая платежка в моей жизни )
В качестве требований — до 100 платежей в секунду, сквозные платежи, прямые платежи, интеграция с другими агрегаторами, карточными процессингами и другими платежными системами.
Почему платеж — это гораздо сложее, чем кажется, я довольно много рассказывал. Статусы, надежность переходов, юридические ограничения и так далее.
Ну и от этой системы зависит где-то половина российского онлайного букмекерского бизнеса, это не мало. Собственно, потому и на грани энтерпрайза.
Так, что бы этот инструмент можно было дать редактору или маркетологу.
Теоретически, такое можно сделать из Eclipse, но это была бы уже более сложная разработка, нежели мы могли себе позволить.
У меня после нескольких сделанных платежных систем развилась легкая личная паранойя на теме доступа к данным и уязвимостям, но в большинстве проектов не готовы увеличивать стоимость разработки и поддержки ради безопасности. Хорошо, если аудитор грамотный и может показать какие-то реальные уязвимые точки, но обычно при PCI DSS аудите проверяются только система, связанная с карточными данными, а это далеко не полный список уязвимостей.
А вместо руководства «платежная система для чайников» — проще найти специалистов для отдельной консультации, все будет дешевле, чем самому грабли собирать. Так, в общем-то, почти в любых сложных проектах.