Транзакционные операции

Транзакция– группа последовательных операций с базой данных, которые либо выполняются все целиком, либо не выполняются вообще.

Транзакции позволяют не допустить ситуацию, при которой данные будут находиться в несогласованном состоянии.Иными словами, с помощью транзакций можно менять одно согласованное состояние системы на другое. Причем стоит заметить, что используются не только в базах данных. Например, брокеры сообщений уже давно позволяют публиковать и получать сообщения также внутри транзакций [18].

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

Проблему можно решать несколькими способами:

- Не использовать транзакции вообще.

- Использовать транзакции только в рамках одного микросервиса.

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

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

Связность данных

Данные в интернет-банках, хоть и распределены по различным доменам, однако же очень тесно связаны между собой. Это накладывает определенные сложности даже при разработке интернет-банка с нуля, не говоря уже о переводе существующей системы на целевую архитектуру. Проблему на данный момент можно решить с помощью сосредоточения наиболее близких друг к другу сущностей данных в рамках одного микросервиса, а на другие сущности ссылаться с помощью уникальных идентификаторов. Также существует вариант с использованием общей схемы базы данных для всех микросервисов, которая могла бы решить и проблемы согласованности данных, описанных в предыдущем пункте, однако же сводит на нет преимущество технологической разнородности, которое подразумевает, что микросервисы представляет собой совершенно отдельное приложение и может использовать источник данных, отличный от остальных и более подходящий [19]. И самое главное, совместно используемая схема данных вносит огромную путаницу и неразбериху в ряды разработчиков микросервисов, к разработка и доработка структур данных в базе становится с слишком рискованным и сложным делом. Поэтому в конкретном данном случае стоит сосредоточить наиболее связные данные в одном микросервисе, а если без ссылок на другие источники не обойтись, то использовать уникальные идентификаторы. Например, платеж в базе данных микросервиса вполне может содержать в себе номер счета и идентифиатор дебетовой карты, с которой производится платеж, или, например, автоплатеж может содержать номер счета и идентификатор кредитной карты, на которую прозводится постоянное регулярное пополнение с дебетовой карты [20].

Итог проектирования

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

РЕАЛИЗАЦИЯ СИСТЕМЫ

Макеты форм

В этом пункте представлены черновые макеты форм, поскольку на текущий момент разработка фронтовой части системы не осуществляется. Предполагается в итоге использовать js-фреймворк AngularJS 5.

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

Рисунок 28 - Макет формы входа в систему

На рисунке 29 представлен макет формы восстановления пароля к системе.

Рисунок 29 - Форма восстановления пароля к системе

Далее на рисунке 30 представлен макет главной страницы интернет-банка

Рисунок 30 - Главная страница интернет-банка

На рисунке 31 изображен макет страницы с банковскими продуктами, которые уже есть у клиента [21].

Рисунок 31. Страница продуктов клиента

На рисунке 32 показана форма создания платежа.

Рисунок 32. Форма создания платежа

На рисунке 33 показана форма создания перевода между своими счетами.

Рисунок 33 - Форма перевода между своими счетами

Рисунок 34 - Форма создания перевода в другой банк

На рисунке 35показана форма создания перевода по номеру телефона

Рисунок 35 - Форма создания перевода по номеру телефона

На рисунке 36 и рисунке 37 показана форма оформления заявки не кредит.

Рисунок 36 - Форма оформления заявки на кредит

Рисунок 37 - Продолжение оформления заявки

На рисунке 38 показана форма оформления вклада [22].

Рисунок 38 - Форма оформления вклада

Рисунок 39 наглядно показывает форму оформления дебетовой карты.

Рисунок 39 - Форма оформления заявки на дебетовую карту