Встала задача реализации системы электронных платежей для оплаты всевозможных служб в пределах города.

Система примитивная: профиль пользователя, электронный счет в нашей системе, осуществление операций оплаты со счета и ввода денег на счет.

Хочется сделать так:

реализовать SOAP/REST over HTTP API и к нему написать несколько "морд": web, desktop, mobile (android, symbian, iOS)

Возник ряд вопросов:

1) Балансировка нагрузки/масштабируемость сервиса. Хочется сервисную часть (морда, api) крутить на несколких серверах. Соединения к которым разбрасываются каким-нибудь балансировщиком аппаратным или программным. Кто в теме как это обычно выглядит? Хочется по единому DNS имени попадать на один из серверов эдакого HA (high avail...) кластера, прозрачно дщля пользователя. Т. е. его перекидывает балансировщик сам.

2) Балансировка нагрузки/масштабируемость БД. Что лучше применить? Шардинг какой-нибудь дикий с репликациями? Или кластер предлагаемый той или иной СУБД. Рассматривается использование Oracle или MS SQL.

Спасибо. Буду рад любой информации.

Здравствуйте, Аноним, Вы писали:

А>Встала задача реализации системы электронных платежей для оплаты всевозможных служб в пределах города.

А>Спасибо. Буду рад любой информации.

раз любой...
то это однозначно распил бюджета
тем более, что исполнитель задает вопросы на рсдн

оптимальное решение — договориться с уже имеющимся известным сервисом,
который раз в сутки будет вам скидывать в csv список транзакций прошедших за день, а вы их написанной за 5 минут утилиткой будете импортировать в 1С

вот так

Здравствуйте, <Аноним>, Вы писали:

А>Встала задача реализации системы электронных платежей для оплаты всевозможных служб в пределах города.
А>Система примитивная: профиль пользователя, электронный счет в нашей системе, осуществление операций оплаты со счета и ввода денег на счет.
А>Хочется сделать так:
А>реализовать SOAP/REST over HTTP API и к нему написать несколько "морд": web, desktop, mobile (android, symbian, iOS)
В вашем случае (разнообразные клиентские платформ, балансировка), наверно лучше именно REST.

А>Возник ряд вопросов:
А>1) Балансировка нагрузки/масштабируемость сервиса. Хочется сервисную часть (морда, api) крутить на несколких серверах. Соединения к которым разбрасываются каким-нибудь балансировщиком аппаратным или программным. Кто в теме как это обычно выглядит? Хочется по единому DNS имени попадать на один из серверов эдакого HA (high avail...) кластера, прозрачно дщля пользователя. Т. е. его перекидывает балансировщик сам.
При разработке достаточно только помнить, что вас сервис должен быть stateless — и все. Такие сервисы легко размещаются, к примеру, в IIS, и ничего не знают о том, что работают они, кроме того, внутри программной балансировщики Windows Server Network Load Balancing. См. TechNet море статей по этой теме. Аналогично, и по аппаратному балансировщику: вашему приложению не нужно ничего о нем знать. Кроме того, балансировку организовывают на основе DNS, с этим не работал. Балансировку может настроить любой вменяемый администартор, лишь бы вы ему дали поддающееся балансировке приложение.

А>2) Балансировка нагрузки/масштабируемость БД. Что лучше применить? Шардинг какой-нибудь дикий с репликациями? Или кластер предлагаемый той или иной СУБД. Рассматривается использование Oracle или MS SQL.
Конкретно, кластер SQL Server опирается на отказоустойчивый кластер Windows Server (Failover Cluster): в его задачу не входит балансировка нагрузки, а совершенно иное — повышение доступности SQL Server (при сбое на одном узле сервис прозрачно для клиентов стартует на другом узле кластера). По простому масштабируют с помощью добавления мощностей серверов (CPU, RAM), увеличением IOPS (к примеру, используя SAN), распределением сервисов по разным серверам. С шардингом не работал.

А вы уверены, что сервис "оплаты всевозможных служб в пределах города" нуждается в такой навороченной инфраструктуре развертывания?

А>Спасибо. Буду рад любой информации.

Здравствуйте, Аноним, Вы писали:

А>Спасибо. Буду рад любой информации.

Все сайты с высокой посещаемости начинали с простых решений, типа поставить все на один комп и работать, решая проблемы по мере поступления.

Здравствуйте, rsn81, Вы писали:

А не подскажите как дело обстоит с HTTPS при балансировке. Ведь я так понимаю это уже НЕ stateless приложение получится. Спасибо. Читал про "привязку" в балансировщиках.

Здравствуйте, Аноним, Вы писали:

А>А не подскажите как дело обстоит с HTTPS при балансировке. Ведь я так понимаю это уже НЕ stateless приложение получится. Спасибо.
Почему это не stateless? Опять же к разработке это не имеет отношения. Сертификат просто создается на ферму серверов, см. опять же в TechNet: http://technet.microsoft.com/en-us/library/cc728028(WS.10).aspx.

А>Читал про "привязку" в балансировщиках.
Это крайняя мера при балансировке того, что писалось без ориентации на масштабирование. Использование affinity может ведь потенциально свести балансировку на нет.

Здравствуйте, gandjustas, Вы писали:

G>Все сайты с высокой посещаемости начинали с простых решений, типа поставить все на один комп и работать, решая проблемы по мере поступления.

Не всегда. Например, веб-сайт написанный на классическом ASP.NET с интенсивным использованием сессии (в общем stateful по самый помидоры), очень тяжело будет завести на кластере. Ну разве что использовать костыли вроде BigIP...
А вот приложение, написанное под два сервера, обычно легко масштабируется в широком диапазоне серверов в кластере.

Здравствуйте, Аноним, Вы писали:

А>Встала задача реализации системы электронных платежей для оплаты всевозможных служб в пределах города.

А>Система примитивная: профиль пользователя, электронный счет в нашей системе, осуществление операций оплаты со счета и ввода денег на счет.

А ввод каким способом? Это ключевой момент.

А>Хочется сделать так:
А>реализовать SOAP/REST over HTTP API и к нему написать несколько "морд": web, desktop, mobile (android, symbian, iOS)

В общем правильно. Если большинство клиентов мобильные, то SOAP из-за своей "пухлости" может составить проблему.

А>1) Балансировка нагрузки/масштабируемость сервиса. Хочется сервисную часть (морда, api) крутить на несколких серверах. Соединения к которым разбрасываются каким-нибудь балансировщиком аппаратным или программным. Кто в теме как это обычно выглядит? Хочется по единому DNS имени попадать на один из серверов эдакого HA (high avail...) кластера, прозрачно дщля пользователя. Т. е. его перекидывает балансировщик сам.

Тоже правильно. По поводу балансировки. В одной крупной ПС, в которой я работал, балансировка полностью отдана цисковской железке. И сам сервис, и сайт. Настраивается гибко по правилам, дальше балансирует сама и перебалансирует в случае падения или затупа отдельных серверов. Привязка HTTP сессии происходит путем добавления специальной куки, в которой закодирован IP сервера, инициировавшего сессию. В случае HTTPS Циска берет его на себя (шифрование, дешифрование, проверку клиентских сертификатов, если есть), а на сервера передает обычный HTTP. За счет этого сервера меньше нагружаются.

А>2) Балансировка нагрузки/масштабируемость БД. Что лучше применить? Шардинг какой-нибудь дикий с репликациями? Или кластер предлагаемый той или иной СУБД. Рассматривается использование Oracle или MS SQL.

Вот тут все очень индивидуально, уинверсальных рекомендаций дать нельзя. Разве только одну — не жалеть денег на грамотных разработчиков и ДБА. Как правило это место масштабируется сложнее всего.
В утешение могу сказать, что в масштабах города вам это не грозит. Любая современная промышленная СУБД на достаточно мощном железе справится и в одном экземпляре (резервный сейчас не учитываем).

А>Спасибо. Буду рад любой информации.

Рекомендую прислушаться к советам:

rsn81>ваш сервис должен быть stateless
Не обязательно, но желательно.

rsdn2010>договориться с уже имеющимся известным сервисом
Конкурировать с ними будет очень непросто. Рынок уже достаточно консолидирован, а будет еще больше.
Кроме того, выполнить требования 103-ФЗ тоже не два байта переслать. (уже изучили вместе с юристами?)

И еще один: с самого начала тщательно продумывайте безопасность, все аспекты. Ошибка может стоить очень дорого. Если нет специалиста по ИБ, найдите.

Здравствуйте, wildwind, Вы писали:

W>А ввод каким способом? Это ключевой момент.

Первоначально — выпуск карт оплаты, активируя которую у плательщика в личном кабинете пополняется счет на сумму карты.

Но в последующем хотелось бы работать и с банковскими картами VISA/MSATER CARD. Не подскажите как это выглядит на практике? Я так полагаю некоторые банки предоставляют API для работы с картами или как? Спасибо.

А>1) Балансировка нагрузки/масштабируемость сервиса. Хочется сервисную часть (морда, api) крутить на несколких серверах. Соединения к которым разбрасываются каким-нибудь балансировщиком аппаратным или программным. Кто в теме как это обычно выглядит? Хочется по единому DNS имени попадать на один из серверов эдакого HA (high avail...) кластера, прозрачно для пользователя. Т. е. его перекидывает балансировщик сам.

Вам оно, скорее всего, не нужно, разве что для надежности, но тут зависит от выбранных технологий — на каком стеке будете реализовывать?
В общем, главное — придумать, где и как надежно хранить данные о сессиях.



А>2) Балансировка нагрузки/масштабируемость БД. Что лучше применить? Шардинг какой-нибудь дикий с репликациями? Или кластер предлагаемый той или иной СУБД. Рассматривается использование Oracle или MS SQL.

А вот масштабирование БД не нужно будет точно, нагрузка всех платежных систем РФ легко держится одним сервером Oracle
Но вот стоимость лицензий стоит прикинуть заранее — и решить, а что вы можете себе позволить.
Более менее надежное решение на Оракл — это от 100K$
Про аналог DataGuard от MS — не знаю, кажется, все еще нет.
Я бы делал на DB2, но тут свои тонкости (впрочем, разницой в цене лицензий вполне окупаемые)

А вообще, нашли бы вы кого-нибудь с опытом. Не RocketScience, но куча подводных камней и тонкостей — что с работой с магазинами, что с вводом денег, что с безопасностью (особенно внутренней), что с кредитными картами. А цена ошибки очень и очень немаленькая.

Здравствуйте, Аноним, Вы писали:

W>>А ввод каким способом? Это ключевой момент.
А>Первоначально — выпуск карт оплаты, активируя которую у плательщика в личном кабинете пополняется счет на сумму карты.

По сравнению с терминалами это менее удобно, поэтому чтобы конкурировать, нужно что-то вкусное предложить взамен.

А>Но в последующем хотелось бы работать и с банковскими картами VISA/MSATER CARD. Не подскажите как это выглядит на практике?

Если подразумевается оплата через интернет, то примерно так. Довольно сложно, участвует много сторон. Если вы хотите стать "процессором", нужно выбрать провайдера(ов) и запросить у них условия. Стать "провайдером" намного сложнее. Ему доверяются все реквизиты карт, поэтому куча требований, расходов, сертификация от Визы и т.д. В общем в масштабах одного города скорее всего смысла нет.

Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>нагрузка всех платежных систем РФ легко держится одним сервером Oracle

Не совсем так. Держится, но не легко.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>>нагрузка всех платежных систем РФ легко держится одним сервером Oracle

W>Не совсем так. Держится, но не легко.

Ну, зависит от сервера. Хотя, по идее, эти несчастные e6 платежей в сутки (это с банкоматами и оценкой сверху) можно и на вполне себе дешевом железе держать.
Хотя, конечно, у всех еще куча легаси, которая мешает сделать все совсем легко