CC BY
14ИТ-архитектура мобильного сервиса «Комментарии»
Груздев Всеволод Алексеевич,
ргс^и^-менеджер, ООО «Тинькофф Банк»
Васильева Елена Викторовна,
д.э.н., профессор Департамента бизнес-информатики, Финансовый университет при Правительств РФ
В статье рассматривается архитектура современного ИТ-продукта, целью которого является внедрение социальных механик в мобильное приложение крупного банка в России. В рамках данного мобильного сервиса подразумевается предоставление возможности общения между большим количеством пользователей одновременно. Подробно описывается архитектура данного продукта, которая предполагает связь бизнес-процессов с информационным и технологическим слоем. Рассмотрены технологические аспекты архитектуры предлагаемого решения. В работе показано, как данный ИТ-продукт способен трансформировать финансовую услугу, сделав ее более клиентоори-ентированной.
Ключевые слова: архитектура приложения, модель, бизнес-процессы, информационный слой, технологический слой.
Введение
В современных реалиях становится заметна тенденция, при которой рост потребностей клиента растет, при этом удовлетворение этих потребностей осуществляется через заказ услуги в мобильном приложении.
Клиенты должны знать обо всех продуктах, видеть преимущество от потребления сразу нескольких продуктов. А если для компании действительно важна лояльность как новых, так и старых клиентов, то нужно быть открытым, вкладываться в развитие клиента.
В данной работе основное внимание будет направлено на разработку ядра social-экосистемы - функционала комментариев, который является первым шагом к выдаче людям возможности открыто и публично взаимодействовать с банком и между собой.
1.1. Архитектура продукта комментарии 1.1.1. Опи-
сание взаимодействия с продуктом
Для описания взаимодействия с продуктом «Комментарии» было выбрано решение, реализуемое на базе им^-диа-граммы бизнес-юз кейсов. Результат работы отображен на рисунке 1.
Рисунок 1. Схема взаимодействия клиента с зос1а!-экосистемой. Источник: Составлено автором.
Как можно заметить из данной диаграммы, комментарии полезны не только клиентам, но и представителям компании. Клиентам комментарии позволяют создавать сообщества по интересам, быть уверенным, что все пользователи одобрены (за это ручается сервис), обсуждать новости. Для компании это продвижение продуктов, установка связей с клиентами, поддержка в них лояльного отношения к бренду [1 ].
Следующий актор, который взаимодействует с комментариями, - это сотрудник модерации, в чьи обязанности входит контроль контента, который создается пользователями. Его задача не допускать нарушения правил. Очень важно, чтобы внутри сообщества царила атмосфера здоровой дискуссии без признаков оскорблений. В рамках своих обязанностей модератор имеет возможность скрыть комментарий, если посчитает его не валидным, а в качестве дополнительного наказания может заблокировать автора этого комментария, если замечает, что данный клиент - постоянный нарушитель.
fO
es о es
to
о ш m
X
3
<
m О X X
Комментарии дают неоспоримое преимущество для компании, которая активно применяет продуктовый подход. Благодаря комментариям, которые размещены под определённым обсуждаемым объектом, управляя этим объектом можно навязать любую повестку для разговора. Это особенно полезно для бизнеса: есть возможность услышать здоровую критику или предложения, проработав которые клиент будет счастлив. Для бизнеса это дополнительная монетизация, для клиента - ощущение быть услышанным, что неминуемо влечет рост лояльности. Через комментарии можно общаться напрямую или проводить интересные игры/конкурсы - очередной канал вовлечения, формируемый редакцией - именно это планируется использоваться актором со стороны компании, а именно представителем банка, в частности он состоит из продукт-менеджера и редакции, однако на самом деле это еще более глубокая роль, которая может включать различных представителей бизнеса.
1.1.2. Верхнеуровневая модель продукта «комментарии»
В рамках нотации Archimate, использовался программный продукт Archi. В нем была создана верхнеуровневая модель архитектуры продукта.
Действующие лица - раздел акторов, которые взаимодействуют с сервисами комментариев: это сотрудники и клиенты мобильного банка.
В рамках бизнес-сервисов были агрегированы необходимые основные и поддерживающие процессы, которые позволяют пользоваться MVP. В данном случае к ним относятся:
• Сервис просмотра комментариев (загрузка страницы с соответствующими данными);
• Сервис работы с комментариями (отправка/удаление);
• Сервис модерации комментариев;
• Сервис отправки нотификаций (реализуется сторонней банковской системой);
• Сервис аналитики (бизнес-данные по продукту) - сторонний сервис «Amplitude»;
• Сервис мониторинг работы продукта (технический контроль работоспособности и предотвращений сбоев).
Отдельно стоит упомянуть слой приложений и технологический слой
Слой приложений представлен рядом программных продуктов, часть из которых являются внешними популярными решениями (отражено на диаграмме):
• Social - наименование внутреннего приложения, написанного командой «Комментариев», которая содержит в себе основную логику работы платформы.
• Kleks - наименование внутреннего приложения, создано внешней командой для производства модерации различных объектов. Комментарии являются клиентом данного приложения, проверяют валидность комментариев именно там.
• Центр Нотификации - наименование внутреннего приложения, создано внешней командой для отправки различных нотификаций, в том числе пуш-уведомлений. Данный функционал реализуется по отправке события от social при оставлении ответного комментария.
• Statist - наименование внутреннего приложения, создано внешней командой для производства первичной аналитики.
• ClickHouse - наименование внешнего приложения, которое позволяет собирать необходимую аналитику в больших объемах данных
• Amplitude - наименование внешнего приложения, которое позволяет собирать необходимую аналитику о поведении пользователя.
Технологический слой основан на базе независимой микроархитектуры API, в рамках которой выставляются необходимые ссылки. Мобильное приложение производит запрос операций именно через них. Вся архитектура продумана так, чтобы обеспечить постоянную и бесперебойную работу. Для этого существует балансировщик, который распределяет нагрузку между двумя стендами. Отдельно стоит проговорить про оставшиеся элементы:
• PostgreSQL - система управления реляционной базой данных, которая хранит необходимую информацию о продукте. Выбор данной системы обусловлен несколькими факторами: это очень надежная СУБД, которая отлично подходит для приложений с высоким объемом трафика, структура данных которого достаточно понятна и конечна, а обработка необходима в кратчайшие сроки (обработка происходит за счет хэш-индексов). Ряд преимуществ в том, что система предлагает управление транзакциями, контроль параллелизма и поддержка хранимых процедур и триггеров. Система показалась нам привлекательной, так как предлагает расширенные функции оптимизации запросов и настройки производительности, которые помогают повысить производительность сложных запросов, к тому же обеспечивает поддержку различных языков программирования, в частности Java, который использует в качестве основного при написании бек-энд архитектуры продукта.
• Reddis - это хранилище ключей и значений, которое поддерживает широкий спектр структур данных, включая строки, хэши, списки, наборы и отсортированные наборы.
Он хранит данные в памяти, что обеспечивает быстрый доступ к ним и их извлечение. Это быстрое, гибкое и надежное хранилище данных, которое хорошо подходит для широкого спектра вариантов использования. Продукт планирует использовать для кэширования тех данных, доступ к которым должен быть получен настолько быстро (чтобы не испортить клиентский опыт долгой загрузкой), что даже PostgeSQL не позволяет обеспечить это.
• Kafka - предоставляет эффективный и надежный механизм для передачи сообщений между различными приложениями и системами. Он основан на концепции публикация-подписка, когда производители сообщений публикуют данные в топик, а потребители подписываются на эти темы, чтобы получать сообщения. Инструмент позволяет обрабатывать потоки данных в режиме реального времени с высокой пропускной способностью и низкой задержкой. Он поддерживает разбиение на разделы и репликацию данных для обеспечения масштабируемости и отказоустойчивости.
• S3 - это облачное хранилище, которые используется для быстрого доступа к файлам, которые не совсем корректно хранить в собственной Базе данных, например, это могут быть различный медиа-контент: картинки или видео. S3 хранит данные в виде объектов, которые состоят из ключа, значения и метаданных. Размер объектов может достигать 5 терабайт, а S3 обеспечивает неограниченный объем хранилища. S3 также поддерживает управление версиями, что позволяет пользователям сохранять несколько версий объекта и при необходимости извлекать предыдущие версии.
1.1.3. Структура схем-таблиц на базе диаграммы классов
Углубляясь в проектирование системы, были выделены основные сущности, над которыми будут производиться операции. Данные о каждой сущности были размещены в концептуальной модели базы данных. Для описания которой была использована диаграмма классов в нотации UML (Рисунок 2) [2, 3].
Решение об использовании диаграммы классов обусловлено тем, что она представляет структуру приложения в терминах ее классов, атрибутов, методов и связей между объектами и обеспечивает визуальное представление объектов в системе и их взаимодействий, помогая выявлять потенциальные проблемы и оптимизировать дизайн.
При проектировании системы с реляционной базой данных была скомпилирована диаграмма классов в схеме базы данных, которая включает в себя сопоставление классов и их атрибутов таблицам и столбцам базы данных и определение связей между ними с помощью внешних ключей.
шегэгрл
id: int
moderation start: timestamp without moderation_end: timestamp without 1 is valid j boot commentjd: lot
id: int avatar: text
created date: timestamp without TZ blocked: boot thtjiameitext last name' tajit
bM(jrofile()
Cpmment
Id: ml
pareotjd: im objecLtype: text objectJt: int
createdjate: timestamp without TZ htoden date: timestamp without TZ moderation status: text cement: text content type: text profile jd: Int
change mcderation status!) create_comment()
id: lot path: text type: MedtaType comment jd: ml
createdjate: timestamp without TZ
Рисунок 2. Диаграмма классов продукта «Комментарии». Источник: Составлено автором.
Таким образом, учитывая нормализацию базы данных (3 тип нормализации) в рамках MVP social («Комментарии») была составлена база данных, состоящая из 4 основных таблиц:
• Comment - главная и связующая таблица, которая хранит в себе все основную информацию о комментарии, а также различные ссылки (внешние ключи) на остальные элементы, знание о которых необходимо (Например, id профиля и т.д.). Атрибуты таблицы описывают комментариев, место, где он был оставлен, дату, тип проверки модератором.
• Profile - это отдельная таблица, взаимодействие через которую с Comment осуществляется через связку (join) Profile.id = Comment.profilejd (связь один ко многим: один комментарий может написать только один автор, но один автор может написать несколько комментариев). Данная таблица содержит в себе всю необходимую информацию, которую необходимо знать об авторе комментария. Эта информация может быть предназначена для внешних пользователей, например: имя, фамилия и аватар автора комментария нужны для отображения этих данных на мобильном устройстве того пользователя, кто этот комментарий, непосредственно, просматривает для того, чтобы понимать, с кем идет диалог. Другие же данные больше полезны внутренним пользователям: система должна знать, например, заблокирован ли пользователь или нет: это необычайно важно, так как факт блокировки пользователя возможен только в том случае, если он неоднократно и серьезно нарушает правила пользования сообществом - в этом случае платформа «Комментариев» считает его неблагонадежным, мешающим элементом в построении отзывчивого комьюнити, инструментом для достижении цели которого используются комментарии как продукт. Однако это ни в коем
случае не должно сказаться на возможности клиента пользоваться другими услугами финтех-экосистемы, которые предлагает компания, например, просмотр контента историй, каналов комментариев (без возможности отправить) или оформление продукта: кредита, страхования и прочее, если он заблокирован внутри Комментариев.
• Attachments - это отдельная таблица, взаимодействие через которую с Comment осуществляется через связку (join) Attachments.commentjd = Comment.id. Связь допускает, что ни у каждого комментария возможны вложения (один комментарий может иметь несколько вложений), однако у каждого вложения обязательно есть комментарий. Данная таблица помогает «Разгрузить» информацию о вложениях, так как обычно это тяжелые файлы, к тому же это верно с точки зрения соблюдения нормализации. На данный момент функция отправки вложения выключена на мобильной части системы, однако продумать и спроектировать ее необходимо было при запуске, так как в последствии это упростило работу и позволило избежать несостыковок работы системы на бекэнде платформы.
• Moderation - это отдельная таблица, взаимодействие через которую с Comment осуществляется через связку (join) Moderation.comment_id = Comment.id. В данной таблице идет описание всего процесса оценки комментария на валидность правилам сообщества. В частности, фиксируется поэтапно проверка: время начало проверки комментария, время окончания проверки комментария, вердикт проверки.
Составление диаграммы классов для реляционной базы данных необходимо для обеспечения того, чтобы система была правильно спроектирована и могла эффективно хранить и извлекать данные. Это также помогает обеспечить целостность и непротиворечивость данных и облегчает разработку запросов и отчетов.
1.1.4. Описание бизнес-процессов MVP
В рамках данного раздела были представлены основные бизнес-процессы, которые вошли в MVP-модель платформы комментариев.
Бизнес-процесс загрузки комментариев (представлен на рисунке 3) требует взаимодействия нескольких объектов, именно поэтому было решено использовать диаграмму последовательности, так как эта визуализация максимально просто демонстрирует порядок взаимодействия систем.
Мобильное приложение
О
О
о
Получен список комментариев
Отобразить список комментариев >мментвриев пустой__
Рисунок 3. Диаграмма последовательности процесса загрузки списка комментариев продукта «Комментарии». Источник: Составлено автором.
Процесс начинается с целевого действия клиента - в своем мобильном приложении он должен нажать на кнопку «комментарии». В этот момент мобильный клиент обращается через «ручку» API в формате запроса GET к серверу. Запрос
X X
о
го
>
.с
X
го m
о
ю
2 О ГО
со
fO CS
о
CS <0
о ш m
X
3
<
m О X X
сервера должен включать ряд входных данных, которое передает устройство от клиента, например, его уникальный идентификатор. Серверная часть после получения запроса с входными данными вычисляет смотрел ли клиент до этого комментарии, если нет, то показывает список с самого начала, а если смотрел - то с места последнего сеанса. Вычислив это, идет обращение к базе данных комментариев, где для определенного объекта достаются «пачкой» комментарии и возвращаются на мобильный клиент посредством серверной части. Если в момент запроса произошла ошибка, к примеру, сервер недоступен или интернет клиента на устройстве не может обеспечить стабильное соединение, то мобильное устройство в этом случае должно показать клиенту экран ошибки с возможностью повторения операции по запросу комментариев.
Бизнес-процесс отправки комментария аналогично предусматривает последовательное взаимодействие нескольких элементов разработанной инфраструктуры. Процесс отправки не может предшествовать процессу загрузки комментария, он всегда идет далее (если пользователь решит отправить комментарий). Это обусловлено тем, что ввести текст комментария и отправить его можно только из экрана комментариев, что приравнивается к экрану загрузки списка комментариев (занимает отдельную область). Таким образом, будучи внутри успешно загруженного списка комментариев пользователь вводит текст и отправляет текст комментария нажатием на соответствующую кнопку. Мобильное устройство аналогично процессу выше делает запрос через сервер, однако это уже другой запрос (PUT). Комментарий с соответствующим текстом и дополнительной meta-информацией, согласно атрибутам таблицы Comment заносится в Базу данных. В формате асинхронной (независимой) обработки идет проверка данного комментария на валидность в специальной сервисе модера-ции (отдельная «ручка» другого backend-сервера, для которого комментарии являются клиентом). В случае успешно обработки (комментарий валидный) он опубликовывается и в базе данных ему проставляется соответствующий статус. Если сервис модерации предполагает, что комментарий нарушает правила сообщества, то он дополнительно отправляется на ручную модерацию для оценки человеком. Сотрудник выносит вердикт, если он одобряет комментарий, то ему проставляется соответствующий статус - он опубликовывается, иначе комментарию ставится иной статус, который отражает его не-валидность для нахождения внутри сервиса - комментарий скрывается из публичного пространства.
Бизнес-процесс модерации комментария (представлен на рисунке 4) рассмотрен детальнее. Проверка комментариев на их соответствие правилам - это отдельный сложный механизм, который заключается в проведении нескольких последовательных этапов. Бизнес-требование по тому, что можно публиковать внутри сообщества были сформированы совместно с Юридическим отделом и располагаются на отдельной вкладке внутри мобильного приложения. Процесс модерации должен быстро реагировать на то, что недопустимо. Так как идет работа с людьми, то предусмотреть все варианты недопустимого контента технически невозможно, поэтому был построен следующий процесс. Комментарий, отправленный пользователем, проверяется на наличие слов из Black list (список запрещенных слов, например, нецензурных), если комментарий содержит эти слова, то он блокируется, иначе идет оценка ML-моделью. Данная модель предоставляется сторонним сервисом: ее задача выставить оценку комментарию, если оценка не превышает допустимый порог комментарий будет опубликован. Если оценка превышает допустимый порог, то он
отправляется на оценку человеку, где сотрудник может ознакомиться с текстом комментария и точно решить: имеет ли он признаки запрещенного или нет.
Если комментарий имеет признаки запрещенного для сообщества контента - он будет заблокирован, его не увидят, иначе его опубликуют. Проверка должна происходить быстро, чтобы не испортить клиентский опыт, именно по этой причине первые два шага (автоматические) работают сразу, проверка человеком (ручная) может потребовать немного больше времени, так как поток комментариев постоянно увеличивается.
На этот случай мы допускаем, что комментарий может некоторое время оставаться в опубликованном состояние. Но как только человек решит, что он невалидный - он будет заблокирован. Модератор не может пропустить ни один комментарий, процесс построен так, что каждый комментарий представляет собой определенный заказ. Все заказы распределяются равномерно на сотрудников, преступить к выполнению следующего заказа можно только в порядке той очереди, которую сформировал механизм. Очередь сортируется исходя из даты и времени опубликования комментария. Получается, что все комментарии в одинаковом приоритете обрабатываются.
Рисунок 4. BPMN диаграмма бизнес-процесса модерации комментария продукта «Комментарии». Источник: Составлено автором.
Заключение
Таким образом, в рамках работы было проанализировано текущее состояние инфраструктуры предприятия. На момент возникновения идеи о создании продукта «Комментарии» внутри предприятия не существовало построенного бизнес процесса оставления комментариев пользователям внутри мобильного приложения. Для проработки данной идеи были проанализированы смежные с комментариями продукты, для которых комментарии являются дочерним суб - функционалом. На этапе планирования внедрения продукта «Комментарии» стало очевидно, что решение, в случае его успеха - будет необходимо масштабировать, именно по этой причине было решено делать платформенную реализацию, которая достаточно легко и быстро подключается к необходимым модулям. Необходимая для данного решения архитектура отражена в артефактах.
Литература
1. Алтухова Н.Ф., Васильева Е.В., Громова А.А. Опыт применения техники дизайн-мышления в курсе «Интернет-предпринимательство» // Современные информационные технологии и ИТ-образование. / МГУ им. М.В. Ломоносова. Факультет
Вычислительной математики и кибернетики. - М., 2016. Т. 1. № 12. С. 100-105
2. Долганова О.И. Моделирование бизнес-процессов: Учебник и практикум для академического бакалавриата / О.И. Долганова, Е.В. Виноградова, А.М. Лобанова. - Люберцы: Юрайт, 2016. - 289 с.
3. Елиферов В.Г. Бизнес-процессы: Регламентация и управление: учебник / В.Г. Елиферов. - Москва: ИНФрА-М, 2019. - 319 с. - ЭБС Znanium.com. - URL: http://znanium.com/catalog/product/1020015 (дата обращения: 24.03.2023). - Текст: электронный.
IT architecture of the mobile service "Comments" Gruzdev V.A., Vasilieva E.V.
"Tinkoff Bank", Financial University under the Government of the Russian Federation JEL classification: C10, C50, C60, C61, C80, C87, C90
The article discusses the architecture of a modern IT product aimed at introducing social mechanics into the mobile application of a large bank in Russia. Within the framework of this product, it is meant to provide the possibility of communication between a large number of users at the same time. The document describes in detail the architecture of this project, which involves the connection of business processes with the information and technological layer of the product. The technological aspects of the architecture of the proposed solution are considered. The paper presents a systematic analysis of a new solution that can potentially transform the financial services market, making it more customer-oriented. Keywords: application architecture, system design, business processes, information
layer, technological layer. References
1. Altukhova N.F., Vasil'eva E.V., Gromova A.A. Experience in the application of
design thinking techniques in the course "Internet entrepreneurship" // Modern information technologies and IT education. / Moscow State University. M.V. Lomonosov. Faculty of Computational Mathematics and Cybernetics. - M., 2016. T. 1. No. 12. S. 100-105
2. Dolganova O.I. Modeling of business processes: Textbook and workshop for
academic bachelor's degree / O.I. Dolganova, E.V. Vinogradova, A.M. Lobanova. - Lyubertsy: Yurayt, 2016. - 289 p.
3. Eliferov V.G. Business processes: Regulation and management: textbook / V.G.
Eliferov. - Moscow: INFRA-M, 2019. - 319 p. - EBS Znanium.com. - URL: http://znanium.com/catalog/product/1020015 (date of access: 03/24/2023). -Text: electronic.
X X О го А С.
X
го m
о
2 О M
со
