Собственно данный блог я сделал с целью поэтапного отражения процесса создания процессинга/биллинга/распределенной системы собственными руками в течение нескольких недель. Так как постоянно наступаю на грабли (давно не программировал), которые слабо описаны в интернете, то решил поделиться впечатлениями и возможно собрать комментарии и советы от "коллег по цеху".
Предыстория:
На последнем месте работы потребовалось внедрить информационную систему для обслуживании в режиме 7x24 до 50.000 распределенных точек обслуживания (платежные терминалы самообслуживания, банкоматы, физические лица которые получают доступ через сотовые телефоны/компьютеры с интернет).
Все рассмотренные решения на рынке обладают теми или иными узкими моментами:
Об авторе:
В бывшем программист -- программировал на ассемблере и C/C++ лет так 20 назад и с тех пор системным программированием не занимался.
В бывшем "картёжник" -- сотрудник банка, эксплуатирующий сеть устройств и процессинговый центр, обслуживающий банковские карты международных платежных систем VISA/MasterCard
В бывшем системный архитектор -- разработка, развитие, доработка, IT аудит, поиск и исправление ошибок в распределенных информационных системах, АБС, процессинговых системах, биллингах и т.п.
Ныне -- в продолжительном отпуске...
Если честно, то мне не хватает
Задача:
Разработать мультиплатформенное решение:
Предыстория:
На последнем месте работы потребовалось внедрить информационную систему для обслуживании в режиме 7x24 до 50.000 распределенных точек обслуживания (платежные терминалы самообслуживания, банкоматы, физические лица которые получают доступ через сотовые телефоны/компьютеры с интернет).
Все рассмотренные решения на рынке обладают теми или иными узкими моментами:
- Требуемая система должна быть мультиплатформенной-- большинство ориентированы на Win32 или на определенный дистрибьютив Linux
- Требуемая система должна быть защищена от реверсинжениринга -- многие системы используют openssl для шифрации трафика, да и то не все. Практически все системы даже не представляют что такое ГОСТированное шифрование.
- Требуемая система должна быть оптимизирована на БОЛЬШУЮ нагрузку -- НИКТО и НИКОГДА не ставил такой задачи перед разработчиками или архитекторами на первоначальном этапе разработки. А на последующих этапах все скатывается к "если не нравится производительность -- купите сервер "по-больше"".
- Клиентская часть системы должна обладать ОТКРЫТЫМ интерфейсом на HTML+JS+AS, дабы можно было легко передать часть функционала параллельно работающей команде программистов.
Об авторе:
В бывшем программист -- программировал на ассемблере и C/C++ лет так 20 назад и с тех пор системным программированием не занимался.
В бывшем "картёжник" -- сотрудник банка, эксплуатирующий сеть устройств и процессинговый центр, обслуживающий банковские карты международных платежных систем VISA/MasterCard
В бывшем системный архитектор -- разработка, развитие, доработка, IT аудит, поиск и исправление ошибок в распределенных информационных системах, АБС, процессинговых системах, биллингах и т.п.
Ныне -- в продолжительном отпуске...
Если честно, то мне не хватает
- знаний тонкостей и опыта системного программирование параллельно под Win32 и POSIX
- настройки/эксплуатации многих пакетов, которые настраивались другими людьми собственными руками, т.к.я пользовался уже результатом их работ (танцев с бубнами).
Задача:
Разработать мультиплатформенное решение:
- Серверную часть -- модуль процессинга
- Клиентскую часть -- модель терминалов
При этом данная конструкция должна обладать следующими свойствами
- Быть мультиплатформенной как в серверной, так и в клиентской части.
- Обрабатывать до 1000 операций (обращений) в минуту на домашнем компьютере, что соответствует пример 20.000 устройств в обслуживаемой сети.
- Шифровать трафик на всем промежутке от клиента до сервера и препятствовать анализу и последующему искажению передаваемой/получаемой информации.
- Желательно не использовать платное программное обеспечение.
Вы замахнулись на большую задачу. Могу дать совет - хорошо продумать и зафиксировать интерфейс взаимодействия с процессингом. Это позволит разделить задачу по собственно приему и пропихиванию платежей. К тому же процессинги часто общаются между собой. Также хочу предостеречь от распространенной ошибки - делать интерфейс с расчетом на то, что его будут использовать только в терминале, т.е. предусматривать многоходовые визарды с выбором из выпадающего списка значений.
ОтветитьУдалитьЕсли вы хотите получить высокую производительность, методы по приему платежей от клиентов должны быть асинхронными, и быстро отрабатывать, иначе очень скоро упретесь в количество одновременных подключений.
Насколько я знаю, большинство терминального ПО (платежные терминалы, насчет банкоматов не знаю) пишется как полноэкранное десктоп приложение под Windows. Использование HTML+JS+AS приведет к тормозам, поскольку железо для терминалов обычно используется очень старое. Еще одна проблема - под Linux могут быть проблемы с драйверами тачскрина.
Если хочется кроссплатформенности в части процессинга - могу посоветовать связку java + Spring + Hibernate + JBoss. Быстро пишется код, есть множество уже готовых библиотек. Заявленную производительность обеспечивает легко. В java можно реализовать весь набор криптографии, какой существует, за исключением пожалуй самописной, заточенной под определенную систему (да, и такое бывает).
Я у себя в блоге выкладываю примеры с реализацией некоторых частей функционала, которые в будущем теоретически могут стать процессингом.