• «Пора валить из фронтенда»: Андрей Ситник о стагнации сообщества, опенсорсе и не только
    0
    Ну, надо подождать, пока JS догонит Java по списку имеющихся полезных новшеств — и тогда можно будет посмотреть, где что новое появится. Пока заметные новшества скорее сначала появляются в мире Java, а потом уже проникают на фронтенд (тот же Netty старше Ноды лет на пять, Future появился в стандартной библиотеке примерно тогда же, где раньше реактивщина появилась — сложно сказать).
    Развитию JS сильно способствует мода переделывать фронтенд каждые год-два, в Java такое реже. Но новые проекты уже делают и функциональные и асинхронные (если это нужно) и довольно давно.
  • Оркестрируемая сага или как построить бизнес-транзакции в сервисах с паттерном database per service
    0
    Ага, т.е. столько же, сколько у меня на персистентных акторах получалось (для решения примерно тех же задач).
    Хотя пока мне кажется, что акторная модель для описания бизнес-транзакций более удобна. Ну и вместо блокировок можно использовать актор-на-блокируемый объект.
  • Максимально простой в поддержке способ интеграции java-клиента с java-сервером
    0
    Ну, если нужно обновлять большой кластер с кучей сервисов без простоя, то без версионности не обойтись.
  • БД — это не только хранилище данных
    +1
    «Касаемо безопасности внутри защищённого периметра — спорно. Если к вам во внутреннюю сеть влезли враги, то у вас уже всё плохо и наличие/отсутствие ident там погоды не сделает.»
    Тут все зависит от проекта. Если это соцсеточка, то можно надеяться на периметр, все равно безопасность никого не волнует. А вот если это финтех или приличный энтерпрайз, то уже неплохо бы защищаться и от собственных админов (и тут разделение паролей сильно помогает).
  • Максимально простой в поддержке способ интеграции java-клиента с java-сервером
    0
    Теоретически — да. Но если в системе много разных сервисов и необходимо поддерживать работу с интерфейсами разных версий, то стандартная сериализация уже не очень удобна, так как в ней нет удобных механизмов разрешения конфликтов. Jackson тут заметно удобнее.
  • Максимально простой в поддержке способ интеграции java-клиента с java-сервером
    0
    Кроме Feign еще можно посмотреть на замечательную github.com/briandilley/jsonrpc4j
    Просто и очень удобно.
  • Оркестрируемая сага или как построить бизнес-транзакции в сервисах с паттерном database per service
    0
    На какую нагрузку рассчитан движок PGSaga? Сколько «шагов» в секунду на сервер?
    Как определяется логика шага для executor — это просто какой-то RCP вызов или что-то сложнее?
  • Архитектура платежной системы. Банальности, проверенные опытом
    0
    Сотни (и тысячи) и PostgreSQL держит. Но в Firebird нет skip locked (и вообще, насколько я помню, там очень ограничено управление блокировками и транзакциями).
    С трудом себе представляю сценарий, в котором мне мог бы понадобиться Firebird.
  • Архитектура платежной системы. Банальности, проверенные опытом
    +2
    А откуда взялась такая статистика «90 процентов имеют одинаковую обработку»? У нас категорически не так.
    Впрочем, подозреваю, вы путаете процессинг (проведение онлайн платежа) и банковский учет (оформление проводок в АБСке). Я рассказываю в основном про процессинг, где задержки пользователя недопустимы, а проводок вообще нет (платеж, представляет собой первичный документ в терминах бухучета и в АБСку поступает только при удачном завершении).
    Разумеется, интеграция с АБСкой делается пакетно, уже после завершения платежа. Проблемы возникают, скорее, из-за неторопливости нашей АБСки (впрочем, насколько я знаю, это проблема не столько нашей конкретной системы, сколько всех АБСок — они в основном сделаны по технологиям прошлого века), ну для этого мы и переводим потихоньку бухучет в процессинг (где он занимает, впрочем, совершенно незначительное время по сравнению с прочими этапами платежа).
    Ну а изменение остатка и ликвидности в процессинге — совершенно не значимая операция, что там может быть сложного и тяжелого…
  • Архитектура платежной системы. Банальности, проверенные опытом
    0
    Ну, примерно так, подозреваю.
  • Архитектура платежной системы. Банальности, проверенные опытом
    0
    Ну, у нас, вроде бы, проблем с АБСкой нет. Там есть ограничения по производительности (слишком дорого получается масштабировать), так что мы тоже переносим банковский учет внутрь процессинга. И, конечно, внутри процессинга приходится делать проводки, счета и т.п, но это как раз относительно просто, хотя и муторно. Сложности там скорее в прекрасных отчетах из 255 полей для Финмониторинга и прочих вещах, связанных с персональными данными.
    Кстати, а ты (или лучше на Вы) где работаешь?
  • Архитектура платежной системы. Банальности, проверенные опытом
    0
    О, содержательный комментарий, ура. По пунктам:
    1) Если посмотришь на статью, то именно это мы и сделали. Только шаги набираются не заранее, а в процессе прохождения платежа. От чистого STM мы отказались вообще сразу, а дальше был длинный путь до осознания, что наша модель работы с платежами — это просто персистентные акторы.
    2) Как раз с шлюзами у нас проблем нет, они на акторной модели пишутся просто и там легко можно вместо длинных транзакций внутри одного шага сделать несколько шагов, базы данных у шлюзов независимые, в производительность не упремся. Тут главное — в продуманном внутреннем API для шлюзов, если оно асинхронное, то все пишется достаточно просто.
    3) Э, не надо путать учет в НКО и бизнес-аналитику. Учет в НКО — это управленческий и бухгалтерский, ведется в АБСке, и там все достаточно хорошо (по крайней мере и бизнес и аудит ЦБ довольны). А бизнес-аналитика нужна для ответов на вопросы вида «после обновления API у такого-то контрагента как изменилось распределение ошибок по соответствующему шлюзу» или «мы изменили дизайн формы оплаты через мобильных операторов, что стало с конверсией» или «один из клиентов начал рекламную акцию на Дальнем Востоке, как это изменило поток платежей по региону сравнительно с предыдущими подобными акциями». Это очень разные инструменты. Одним из требований к бизнес-аналитике, кстати, является интеграция с Google Analitics.
    4) Как ты думаешь, кто проектировал самую первую очередь (еще на Oracle) на БД в Яндекс.Деньгах? И переписывал ее потом на skip locked? Да и появилась db-queue уже после того, как мы сделали свое собственное решение. И в нашем решении некоторые вещи сделаны заметно гибче и (для нас) удобнее. Например, возможность задавать свои стратегии повтора (произвольные) или добавлять действия на коммит транзакции обработки (для инвалидации или заполнения кэшей, например).
    Собственно, то, что я делал в текущем проекте — это как раз попытка не наступить на те грабли, что были в Яндекс.Деньгах.
    5) Сейчас у меня есть понимание, как это можно сделать еще проще, но пока не реализовано, так что доклада пока не будет )
    6) Спасибо. Но идемпотемптность идет по одной операции, а не по цепочке. И не все контрагенты (почти никто, если честно) вообще не поддерживают идемпотемптность в платежах, так что все не так хорошо. Ну и пособеседовав кучу разработчиков и архитекторов из маленьких платежных систем — я понял, что спокойно готов пользоваться только теми, что сам писал (так что Яндекс.Деньгами я спокойно пользуюсь).
  • Архитектура платежной системы. Банальности, проверенные опытом
    +1
    О да, давно ли я приходил к тебе и смотрел на большие машины )
  • Архитектура платежной системы. Банальности, проверенные опытом
    0
    Ну, в документах по PCI DSS есть выжимки по организации безопасности, их можно использовать для убеждения. И есть же список общих практик по информационной безопаности (вечно забываю, как именно документ называется, но все безопасники на него всегда ссылаются), можно его использовать. Он тоже вполне конкретен.
  • Архитектура платежной системы. Банальности, проверенные опытом
    +2
    Увы, это имело бы смысл, если бы контрагенты поддерживали бы пакетную обработку и если бы у всех платежей был бы одинаковый процесс прохождения.
    Но это не так, контрагенты не поддерживают пакетной обработки и каждый платеж достаточно индивидуален.
    А все, что можно сделать пачкой мы, конечно, сделали, но таких операций очень и очень мало. Да и логика обработки сильно усложняется.
  • Архитектура платежной системы. Банальности, проверенные опытом
    +1
    Хм, а что можно было бы использовать вместо велосипедов? Мы же их изобретали не просто так (

    Ну и уже давно не открывают, это не первая платежка в моей жизни )
  • Архитектура платежной системы. Банальности, проверенные опытом
    0
    Ну, вообще-то в начале сказано, что это система платежей для легального российского букмекерского бизнеса. Таковых на рынке ровно две и я рассказывал не про Qiwi.
    В качестве требований — до 100 платежей в секунду, сквозные платежи, прямые платежи, интеграция с другими агрегаторами, карточными процессингами и другими платежными системами.
    Почему платеж — это гораздо сложее, чем кажется, я довольно много рассказывал. Статусы, надежность переходов, юридические ограничения и так далее.
    Ну и от этой системы зависит где-то половина российского онлайного букмекерского бизнеса, это не мало. Собственно, потому и на грани энтерпрайза.
  • Архитектура платежной системы. Банальности, проверенные опытом
    –1
    Редактирование html не подходит по условиям задачи (с текстами должны работать люди, не разбирающиеся в верстке). Про плагин работы с Markdown я, конечно, знаю, но это именно плагин, не очень удобный в использовании для «не программиста» и не убирающий всю прочую сложность Idea. Я имел в виду отдельное решение типа WebStorm, но не для языка программирования, а для текстов (сложных текстов). С связями между файлами, возможностью добавить собственные CSS, возможностью добавить метаинформацию и т.п.
    Так, что бы этот инструмент можно было дать редактору или маркетологу.
    Теоретически, такое можно сделать из Eclipse, но это была бы уже более сложная разработка, нежели мы могли себе позволить.
  • Архитектура платежной системы. Банальности, проверенные опытом
    0
    Насколько я могу видеть, с ИБ вообще все довольно плохо. К нам на собеседования регулярно приходили разработчики из банков или платежных систем — и судя по ответам, далеко не всюду всерьез заботятся о безопасности.
    У меня после нескольких сделанных платежных систем развилась легкая личная паранойя на теме доступа к данным и уязвимостям, но в большинстве проектов не готовы увеличивать стоимость разработки и поддержки ради безопасности. Хорошо, если аудитор грамотный и может показать какие-то реальные уязвимые точки, но обычно при PCI DSS аудите проверяются только система, связанная с карточными данными, а это далеко не полный список уязвимостей.
    А вместо руководства «платежная система для чайников» — проще найти специалистов для отдельной консультации, все будет дешевле, чем самому грабли собирать. Так, в общем-то, почти в любых сложных проектах.