Fastgate – интеграционный шлюз для банков и крупного бизнеса, цель которого – обеспечить простоту в управлении трафиком и работе с решением на всех уровнях – как для IT службы с точки зрения развертывания решения, так и для бизнес-заказчиков с точки зрения настройки правил маршрутизации, организации и запуска рассылок и получении статистики по трафику.
Fastgate изначально создавался как коробочное решение для управления трафиком в банковском секторе, поэтому при разработке мы ориентировались на основные требования банков к подобным решениям:
- возможность развернуть шлюз в контуре банка, учитывая особенности IT окружения
- возможность провести интеграции банковских систем по привычным протоколам
- возможность просто и быстро интегрироваться с агрегаторами или операторами для отправки трафика.
- высокая пропускная способность, чтобы без задержек отправлять критичный трафик – пароли и 3D-Secure коды
Технологии шлюза
Для реализации был выбран стек технологий: компоненты шлюза разработаны на Java, это кроссплатформенный язык, а значит, шлюз будет работать в любом окружении. Серверную часть интерфейса шлюза, которая отвечает за логику работы и обрабатывает запросы от пользователей, сначала мы тоже разработали на Java, но после проверки скорости обработки запросов, решили использовать Python, так как он быстрее.
Изначально стандартная поставка Fastgate была предназначена для окружения PostgeSQL+Linux или Oracle+Linux. Для развертывания административного интерфейса по умолчанию мы использовали сервер Apache. В 2016 году к нам пришел клиент, который использовал IIS (Internet Information Services) и Apache для них не подходил. Мы развернули поставку Fastgate по стандартам клиента, подготовили инструкции и настройки для запуска веб интерфейса под IIS (Internet Information Services) и передали их специалистам.
Компоненты шлюза
Компоненты шлюза можно условно разделить на 5 элементов.
- Web-интерфейс
- За точки входа в систему Fastgate отвечает Adapter container server
- За обработку и маршрутизацию трафика отвечает Message processor
- Точки выхода — Container server
- Сбор статистики по сообщениям: Logger
Web-интерфейс
В web-интерфейсе производятся основные настройки системы: каналы отправки, подключения, настраиваются правила маршрутизации, шаблоны сообщений, определяются роли пользователей в системе и создаются пользователи. Там же есть доступ к отчетам, с помощью которых можно проводить сверки с контрагентами, анализировать объемы трафика, который генерируют внутренние системы компании (CRM, процессинг, интернет-магазин). Из веб-интерфейса можно также формировать отправку одиночных сообщений или рассылок.
Точки входа в систему: Adapter container server
Он внесен отдельно, чтобы его можно было бы легко дорабатывать в соответствии с требованиями банков к интеграциям, не трогая остальную часть системы. ACS отвечает за прием, валидацию и формирование сообщений для дальнейшего процессинга в Fastgate.
ACS также отвечает за переотправку сообщений при каскадной рассылке: на основании полученного статуса о недоставке сообщения через первый канал в каскаде переотправляет сообщение в другой канал. Такая схема позволяет добиваться гарантированной доставки информации до клиента и экономить на коммуникациях.
Он построен как набор плагинов: в базовой поставке мы предоставляем плагины, с помощью которых можно передавать данные по API, FTP или SMPP протоколу для отправки рассылок, сообщений и опросов. В случае необходимости разрабатываем новые, чтобы клиент удобно интегрировался с Fastgate по привычным протоколам.
Передача сообщений из Adapter container server в Messaging Processor производится в соответствии с приоритетом сообщения: High, Middle, Low.
Приоритет сообщения — это то очередность обработки сообщения в системе Fastgate
Приоритезация происходит следующим образом:
- В веб интерфейсе создаются шаблоны сообщений с заданным приоритетом. Этот шаблон прописывается в конфигурационном файле плагина, через который происходит отправка информации в Fastgate. Когда сообщение попадает в плагин, оно формируется в заданный шаблон, который уже заведен в системе, этому сообщению в том числе присваивается приоритет шаблона.
- При передаче сообщения из системы клиента в FG. Если на стороне клиента есть система, которая самостоятельно определяет приоритеты для разных типов сообщений, то мы используем приоритет, сформированный этой системой, и на этапе приема параметров «переводим» его в понятный Fastgate тип приоритета. Другой вариант – когда таких приоритетов в системе клиента нет, он присваивает сообщениям параметры, которые мы используем для приоритезации: High, Middle, Low.
- Приоритет также можно выставить при создании рассылки из веб-интерфейса.
Message processor. Обработка и маршрутизация трафика
Message processor обрабатывает сообщения, обогащает сообщения дополнительными данными, проверяет наличие ограничений на отправку и направляет его в нужное подключение в соответствии с правила маршрутизации.
Например, message processor проверяет наличие номера в черном списке, не заблокировано ли сообщение по IMSI Check, если этот сервис подключен, проверяет сообщения на дубликаты и блокирует отправку сообщения, у которого совпадает текст, номер телефона и тип сообщения.
Message processor также отвечает за управление PUSH сообщениями, которые отправляются через PUSH платформу i-Digital. В момент обработки компонент проверяет, указан ли адрес устройства абонента в объекте сообщения. В случае, если указан – абоненту уходит PUSH, если нет – отправка пуша блокируется. Message processor возвращает статус блокировки в ACS, и ACS переотправляет сообщение в резервный канал (SMS, Viber).
После обработки в message processor, сообщение уходит в подключение, заданное в правилах маршрутизации в веб интерфейсе.
Container server
Точки выхода – это транспортные коннекторы для интеграции по SMPP протоколу с операторами или агрегаторами и плагин для интеграции по HTTPS протоколу, для трафика, который уходит в подключение i-Digital. Благодаря этому компоненту мы можем обеспечить возможность интеграции с любыми партнерами в достаточно сжатые сроки.
Logger
Компонент, который собирает статистику обработки сообщений от всех остальных компонентов шлюза, в том числе статус обработки сообщения оператором и сохраняет их в базе данных Fastgate и передает её в системы клиента (CRM, интернет-магазин и тд) через ACS. При сохранении сообщений в базу logger маскирует конфиденциальную информацию.
Logger также расшифровывает коды статусов причин недоставки, которые Fastgate получает от разных операторов/агрегаторов и преобразовывает их в понятное текстовое описание.
База данных системы и взаимодействие с ней
База данных хранит статистику по сообщениям и справочники, которые используют при работе компоненты.
- web-интерфейс – наполняет и управляет справочниками.
- adapter container –подтягивает из базы шаблоны и все, что нужно для корректного формирования сообщений для дальнейшей их обработки в системе.
- message processor – выгружает из базы информацию по правилам маршрутизации входящих и исходящих сообщений
- logger –сохраняет в базу информацию по результатам обработки и отправки сообщений.
Fastgate разработан и протестирован в связке с двумя самыми распространенными базами данных: PostgreSQL и Oracle. Благодаря использованию фрейморка Hibernate, Fastgate можно интегрировать и с другими системами (например, Microsoft SQL Server или MariaDB).
Микросервисная архитектура, горизонтальное масштабирование и «горячий» резерв
Каждый компонент шлюза независим друг от друга, они обмениваются информацией друг с другом через шину данных Rabbit MQ. После того, как компонент обработал данные, результаты он складывает в шину, следующий компонент забирает данные из шины и передает их дальше. Такая логика обеспечивает скорость работы, снижает риски потери данных, помогает локально решать возникающие технические неполадки в компонентах.
Микросервисная архитектура делает доступным горизонтальное масштабирование – подход, при котором каждый компонент можно продублировать любое количество раз, при этом общая производительность системы увеличивается кратно количеству экземпляров компонента, а при выходе одного из них из строя его работу возьмут на себя остальные. Говоря об отказоустойчивости, горизонтальное масштабирование исключает простои серверного оборудования и связанные с ними затраты, т.к. резервные машины, не задействованные в обработке трафика, попросту отсутствуют.
Мы также используем «горячее» резервирование системы: для каждого компонента шлюза в отдельности создается дублирующий компонент, который подключен к тому же источнику трафика и берет на себя часть нагрузки. Это помогает повышать пропускную способность шлюза, а в случае падения одного из компонентов, его заменит дублирующий компонент. Трафик не остановится, и можно будет в спокойном режиме разбираться с причинами проблем.
Поставка и эксплуатация Fastgate
С учетом архитектуры, масштабирования и горячего резерва, обычная поставка Fastagte становится очень трудоемкой, поэтому для развертывания системы мы стали использовать
Kubernetes, который удобен с точки зрения поставки и эксплуатации.
До использования Kubernetes при поставке Fastgate IT службе клиента нужно было вручную настроить окружение для системы: выделить отдельный сервер, установить нужное окружение – базу данных, Rabbit MQ, установить Java, чтобы запустить работу компонентов. В случае обновления компонента, приходилось обновлять и окружение также в ручном режиме.
Сейчас мы поставляем Fastgate в виде набора Docker-образов, либо Helm-чарта, позволяющих при наличии у заказчика кластера Kubernetes развернуть шлюз в кратчайшие сроки без затрат на покупку, введение в эксплуатацию и обслуживание выделенных серверов. В «классическом» варианте, для использования вне облачных сред, Fastgate поставляется в виде gzip-архива с иерархией исполняемых файлов, файлов конфигурации и скриптов запуска. Для развертывания достаточно выполнить одну команду: Kubernetes автоматически поднимет сервер и развернет компонент со всем необходимым окружением и для первой поставки, и в случае обновления компонентов.
Еще одно удобство Kubernetes в том, что он контролирует работоспособность системы, отправляя запросы health check к каждому компоненту по API. Если компонент не отправит в ответ Ок, то Kubernetes его сносит и разворачивает заново.
