Введение

Ранее автор работал только с кошельками обычных пользователей (физические лица, малый и средний бизнес), из-за этого для крупных юридических лиц создавалась масса проблем, таких как: жесткий контроль за балансом в конкретный момент времени, ограничение в масштабировании (разумеется горячие кошельки можно использовать для небольшой компании, для которой 1000 транзакций в секунду - достаточно, однако для крупного бизнеса с сотнями тысяч транзакций в секунду такой подход не подойдет). А так же различные организационные вопросы, которые невозможно решить в рамках кошельков обычных пользователей - например разграничение полномочий подразделений. Разумеется это решаемо через создание отдельных кошельков на каждое подразделение, но ведь удобнее, если все операции производятся со счета с идентификатором COUNTRY@COMPANY, нежели набор каких-то случайных чисел (пусть и со специальным кодированием для проверки ошибок).

В данной работе автор предоставляет возможность использовать корпоративные кошельки, которые позволяют не только уходить в минус в конкретный момент времени, но так же легко масштабируются при росте бизнеса и необходимости больших объемов обработки платежей.

Описание

Всю работу автора над данной фичей можно уместить в одну диаграмму, как показано ниже.

Путем добавления нового профиля для модели шардирования BALANCE, удалось совместить две разные реализации (balance-processor, balance-corp-processor), которые работают одинаково для сервиса контрактов. Оба обработчика возвращают корректные транзакции при проведении платежей и позволяют корпоративным клиентам проводить большее число транзакций, чем обычные пользователи. Это возможно за счет того, что balance-corp-processor - это упрощенная версия balance-processor, без проверок баланса на наличие средств. Все что делает новый микросервис - это создает транзакцию под заданные параметры платежа, а после получения подтверждения транзакции - передает ее дальше в микросервис balance-corp-manager-processor сервиса управления корпоративным балансом.

Читатель может возразить, что микросервис balance-processor и balance-corp-processor относятся к разным сервисам, ведь у них разные данные, разная реализация и даже схемы БД - разные. Тут нужно остановится по подробнее. Дело в том, что сервис - это не про данные, а функции. Какие конкретно данные и по какой причине - это вопрос вторичный. При проектировании систем новые сервисы добавляются не потому что появились какие-то новые данные или изменился их формат, а потому что появилась функция, которую можно и нужно выделить в отдельный сервис. В каком-то смысле технология aws-lambda являла собой возведением этой идеи в абсолют.

Применительно к обсуждаемому в данной части сервису - основной функцией сервиса балансов являлось проведение двухфазного коммита списаний и зачислений, проверка допустимости такой операции. Соответственно не важно какова реализация, пока поддерживается требуемое API - т.е. требуемая функция. Подходите к этому способу проектирования как дженерик типам, только теперь у нас параметризуется сервис.

Для добавления в сервис универсального шардирования нового профиля достаточно простых правок, которые теперь будут позволять отправлять сообщения (и получать ответы) новому микросервису. Так как наименование топиков стандартизированно, то все что требуется - это указать корректное название шарда.

sharding:
	models:
	- name: BALANCE
		allow-multiple: true
		allow-request-shard-ids: false
		shardIds:
		- id: "0"
		  profiles:
		  - 'DEFAULT'
		- id: "h0"
		  profiles:
		  - 'HOT'
		- id: "c0"
		  profiles:
		  - 'CORPORATE'
	- name: BALANCE_CORP
		allow-multiple: true
		allow-request-shard-ids: false
		shardIds:
		- id: "0"
		  profiles:
		  - 'DEFAULT'

Новая модель шардирования BALANCE_CORP используется сервисом управления корпоративным балансом. Так как клиентов может быть много, то необходимо предусмотреть возможность аллоцирования их в разные шарды, например из-за особенностей требований, прописываемых в SLA. В текущей реализации предполагается, что на один кошелек будет приходится только один такой шард, что ограничивает максимальную пропускную способность.

Эту проблему можно решить через добавление еще одного уровня агрегирования, но в рамках данной работы такая доработка осуществляться не будет. Текущей производительности достаточно для любой существующей корпорации. Можно довести до миллиона платежей в секунду при должных оптимизациях и соответствующем оборудовании. Следует учитывать, что замедление этого сервиса не замедлит прием/оплату платежей - они будут позже учитываться в отчетом периоде и сказываться на балансе, находясь какое-то время в "подвешенном" состоянии, пользователь все равно сможет их увидеть в списке необработанных транзакций.

Как работает сервис управления корпоративным балансом

Сервис разделен на части - обработка событий (точка входа), фоновая служба и отчетность.

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

Поступающие в точку входа события вычитываются из очереди сообщений пачкой и в одну транзакцию добавляются в БД сервиса. Это позволяет обрабатывать большее число сообщений, чем если на каждую транзакцию формировать отдельную транзакцию в БД.

Далее в дело вступает фоновая служба - основная задача которой поделить транзакции на периоды и вычислить для каждого периода дельту. Все транзакции прикрепляются к периоду согласно дате подтверждения транзакции, а не создания записи в БД, такой подход позволяет гарантировать, что все записи будут прикреплены к корректному периоду в отчете.

Дельта для периода вычисляется инкрементально по мере поступления новых транзакций.

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

Аналогичным образом осуществляется обработка пополнений с последующим списанием.

Ограничения на работу с крашенными средствами

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

Смысл будущих доработок в том, что при проведении платежа аккаунтом с использованием корпоративного кошелька - он не только будет подвержен ограничениям по лимитам (суточным, общим или иным), но так же и все выплачиваемые средства будут крашенными согласно политике компании относительно подразделения от имени которого и осуществляется платеж. Перефразируя: у подразделения все деньги при оплате будут окрашены принудительно, так отдел закупок сможет работать только с разрешенным списком поставщиков, а бухгалтерия выплачивать зарплату исключительно сотрудникам компании. Это позволит не только упростить процесс согласования выделения бюджета (так как подразделение просто не сможет физически потратить средства не целевым образом, исключая коррупционные варианты и схематоз), но так же проводить платежи когда они нужны, что ускорит работу подразделения и позволит оперативно решать вопросы, производить закупки или принимать платежи.

Заключение

Ранее платежная система MireaPay могла работать исключительно с обычными пользователями (физическими лицами, малым и средним бизнесом) из-за жесткого контроля баланса. Это не только приводило к невозможности работы крупных предприятий без значительных средств на балансе, но так же делало невозможным корректную работу кредитных организаций, так как для выдачи кредита у них на балансе обязана была быть полная сумма кредита, списываемая с баланса. Это делало невозможным существование кредитного мультипликатора.

В данной работе автор добавил поддержку корпоративных кошельков за счет профилей шардирования, введенных в прошлой статье. Новый микросервис корпоративных балансов (balance-corp-processor) бесшовно встроен в платежное API, с которым работает сервис контрактов. Из-за этого для него нет различия между обычными и корпоративными балансами, что позволило вообще не менять логику его работы, вся логика выбора реализации осуществляется исключительно на уровне сервиса универсального шардирования, который и выдает идентификатор шарда. А присвоение шарда (или шардов) для кошелька осуществляется при регистрации в системе.

Код системы по ссылке

Специфические методы шардирования