Введение
Микросервисная архитектура в последние годы стала важным инструментом для разработки и поддержки сложных программных систем, включая финансовые приложения. В отличие от монолитных архитектур, микросервисы позволяют разбить приложение на небольшие, автономные компоненты, каждый из которых может разрабатываться, тестироваться и развертываться независимо. Этот подход предоставляет разработчикам значительные преимущества в плане гибкости, масштабируемости и устойчивости к сбоям, что особенно важно в контексте финансовых систем, где надежность и безопасность являются критически важными факторами.
Фреймворк NestJS, основанный на Node.js, предоставляет инструменты и механизмы, которые упрощают разработку микросервисов, обеспечивая структурированный подход к проектированию серверных приложений. NestJS предлагает модульную архитектуру, интеграцию с различными протоколами взаимодействия, а также поддержку популярных инструментов для обеспечения безопасности, таких как JWT и OAuth2. Эти возможности делают NestJS привлекательным выбором для создания и поддержания микросервисов в финансовых системах.
Актуальность исследования обусловлена возросшей потребностью финансовых учреждений в создании высоконадежных, масштабируемых и безопасных программных решений.
Целью данной работы является рассмотрение существующих особенностей взаимодействия микросервисов в сложных финансовых системах с использованием фреймворка NestJS.
1. Архитектурные особенности микросервисов в сложных финансовых системах
Архитектура микросервисов представляет собой подход к созданию и поддержке программных решений через использование независимых модульных компонентов, а не посредством единого монолитного приложения. Основная идея такого подхода заключается в разделении сложных программных систем на несколько отдельных, автономных модулей, которые можно управлять отдельно друг от друга. Это обеспечивает повышение гибкости в разработке, ускоряет процесс вывода продуктов на рынок, улучшает устойчивость к сбоям и упрощает сопровождение.
Каждый микросервис функционирует как независимая единица, имеющая свой собственный код, базу данных и интерфейсы для взаимодействия с другими компонентами системы. Они могут быть реализованы на различных языках программирования и с использованием разнообразных технологий. Взаимодействие между микросервисами обычно осуществляется через сетевые запросы или обмен сообщениями [1, с. 43].
Популярность микросервисной архитектуры возросла в крупных компаниях, которым потребовался более детализированный подход к разработке отдельных компонентов систем. Возникла необходимость увеличения отказоустойчивости, однако традиционные монолитные системы оказались плохо адаптируемыми к масштабированию. Характерные черты микросервисной архитектуры будут отражены в таблице 1.
Таблица 1
Характерные черты микросервисной архитектуры [2, с. 28-34]
Характерные черты микросервисной архитектуры | Описание характерных черт |
Масштабируемость | Микросервисы могут быть масштабированы независимо друг от друга, что позволяет эффективно распределять ресурсы и нагрузку между сервисами. |
Автономность | Каждый микросервис полностью независим, что означает возможность его разработки, развертывания и обновления без влияния на другие компоненты. |
Использование легковесных протоколов | Для обмена данными между микросервисами часто применяются легковесные протоколы, такие как REST или gRPC, что обеспечивает высокую скорость взаимодействия. |
Гибкость разработки | Разработчики могут использовать различные технологии и языки программирования для создания отдельных микросервисов, что повышает гибкость и эффективность работы команд. |
Управление сбоями | Каждый микросервис оснащен своими механизмами управления ошибками и восстановления после сбоев, что позволяет системе продолжать функционировать даже при отказе одного из компонентов. |
Удобство развертывания | Микросервисы легко развертываются на различных серверах или облачных платформах, что упрощает процесс их интеграции в инфраструктуру. |
Распределенная разработка | Архитектура микросервисов позволяет распределять разработку между несколькими командами, каждая из которых может сосредоточиться на своем сервисе, ускоряя процесс создания и внедрения новых функций. |
Замена компонентов | В случае необходимости замены одного из микросервисов, это можно сделать без значительного влияния на работу всей системы, что облегчает обновление и модернизацию. |
Несмотря на свои преимущества, микросервисная архитектура сопряжена с рядом сложностей, которые будут определены в таблице 2.
Таблица 2
Сложности микросервисных архитектур [2, с. 28-34]
Сложности микросервисных архитектур | Описание |
Управление | Необходимо эффективно управлять множеством микросервисов, каждый из которых имеет свои версии и зависимости. |
Сложность взаимодействия | Микросервисы взаимодействуют через сеть, что может привести к проблемам с производительностью и надежностью из-за возможных точек отказа. |
Обеспечение целостности данных | Разные микросервисы могут хранить и обрабатывать данные независимо, что создает сложности в поддержании их целостности и синхронизации. |
Трудности отладки и тестирования | Независимость микросервисов усложняет процесс выявления и устранения ошибок, так как необходимо точно определить источник проблемы. |
Безопасность | Уязвимость одного микросервиса может поставить под угрозу безопасность всей системы, что требует повышенного внимания к защите данных. |
Проектирование сервисов на основе микросервисной архитектуры сталкивается с множеством методологических вызовов, особенно в крупных проектах [2, с. 28-34]. Эти вызовы, как правило, обусловлены следующими факторами:
Во-первых, различные подходы к проектированию продуктов могут создавать неразбериху при взаимодействии между множеством микросервисов, что нарушает их слаженную работу. Во-вторых, различия в приоритетах и акцентах в работе могут привести к несогласованности действий, когда неясно, в каком направлении следует двигаться и с какой целью. В-третьих, неполное понимание потребностей клиента также представляет собой значительную проблему, так как основной задачей любого продукта является удовлетворение потребностей пользователей.
Для решения этих проблем следует внедрять стандартизированные принципы проектирования сервисов в контексте микросервисной архитектуры, на которые системные аналитики могут опираться в своей деятельности. Установление унифицированных стандартов качества предоставляемых услуг и выполнения задач, нацеленных на удовлетворение потребностей как внешних, так и внутренних клиентов, позволит аналитикам прояснить процесс согласования и облегчить взаимодействие. Таким образом можно минимизировать хаос, присущий разнородным подходам.
Принцип максимизации сквозной обработки данных направлен на устранение избыточного дублирования информации и атрибутов, исключение повторного ввода данных, а также автоматизацию процессов заполнения информации из основных источников данных. В итоге это ведет к сокращению человеческих ошибок при вводе данных, а также к автоматическому обогащению информации благодаря интеграции с другими сервисами. Ограниченные и независимые базы данных микросервисов способствуют этой автоматизации и повышению эффективности [3].
Принцип «Безопасность на всех этапах» (Secure-by-Design) предполагает, что безопасность сервиса учитывается на всех стадиях его жизненного цикла – от разработки концепции до завершения эксплуатации. Это позволяет избежать проблем, связанных с несовместимостью моделей статусов в различных системах, что часто приводит к серьезным нарушениям в работе сервисов.
Принцип эволюционного развития с использованием искусственного интеллекта подразумевает стремление владельцев микросервисов интегрировать AI для создания умных сервисов. Внедрение технологий ИИ, таких как рекомендательные системы, становится необходимостью для улучшения качества обслуживания и повышения конкурентоспособности. Однако, прежде чем начать интеграцию AI, необходимо провести тщательную проверку всех аспектов проекта, чтобы убедиться в готовности системы к таким изменениям. Если все критерии соответствуют требованиям, внедрение AI способно существенно повысить ценность сервиса для клиентов [4].
2. Взаимодействие микросервисов в NestJS: подходы и инструменты
NestJS – это мощный фреймворк для разработки серверных приложений, который функционирует на базе других популярных фреймворков, таких, как Express и Fastify. Его главная задача – предоставить более высокую степень абстракции, делая процесс разработки более структурированным и управляемым. Основные фреймворки, такие, как Express, позволяют разработчикам, самостоятельно решать, как организовать проект и какие абстракции использовать для обеспечения масштабируемости и удобства поддержки. NestJS, в свою очередь, добавляет к этим возможностям дополнительные инструменты и функциональные возможности, которые облегчают решение задач, связанных с ростом и масштабированием проекта. В таблице 3 представлены существующие компоненты NestJS.
Таблица 3
Существующие компоненты NestJS [5]
Существующие компоненты NestJS | Описание компонентов NestJS |
Модули | NestJS построен на модульной архитектуре, которая позволяет организовывать код в независимые и повторно используемые модули. Это упрощает интеграцию различных частей приложения и улучшает его масштабируемость. |
Контроллеры | Контроллеры в NestJS обрабатывают входящие HTTP-запросы и распределяют их по соответствующим маршрутам. Это позволяет отделить логику маршрутизации от бизнес-логики, что делает код более понятным и простым в сопровождении. |
Сервисы | Сервисы инкапсулируют бизнес-логику приложения. Они могут быть легко интегрированы и переиспользованы, что упрощает процесс тестирования и обслуживания приложения. |
Защитники и каналы | NestJS предоставляет встроенные механизмы для создания промежуточного программного обеспечения и добавления логики проверки, что способствует повышению безопасности и управляемости приложений. |
Декораторы | Декораторы используются для добавления метаданных к классам и их элементам. Это упрощает настройку приложения и управление его зависимостями. |
TypeScript | NestJS изначально поддерживает TypeScript, что обеспечивает более строгую типизацию и улучшенные инструменты разработки для создания масштабируемых приложений. |
CLI | Встроенный CLI NestJS значительно облегчает разработку и обслуживание приложения, предоставляя возможность быстро создавать шаблоны кода, модули, контроллеры и сервисы. |
Внедрение зависимостей | Этот паттерн позволяет легко управлять зависимостями в коде, что упрощает процесс их замены и модификации без негативного влияния на другие части системы. |
Для демонстрации возможностей NestJS рассмотрим создание бэкенда для финансового сектора. Основное внимание будет уделено разработке API для обработки данных о книгах [5]. После создания проекта для микросервиса необходимо установить дополнительную зависимость:
Таблица 4
bash npm install @nestjs/microservices |
Это позволит использовать необходимые методы для создания и настройки микросервиса. Основной файл main.ts будет настроен на использование TCP-протокола на порту 3000:
Таблица 5
typescript import { NestFactory } from '@nestjs/core'; import { AppModule } from './app.module'; import { MicroserviceOptions, Transport } from '@nestjs/microservices'; async function bootstrap() { const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, { transport: Transport.TCP, options: { port: 3000 } }); await app.listen(); } bootstrap(); |
Для работы с книгами создадим объект передачи данных (DTO):
Таблица 6
typescript export interface BookDTO { id: string; title: string; author: string; release_date: Date; } |
Этот интерфейс будет использоваться для определения структуры данных, с которыми работает микросервис.
Контроллер будет обрабатывать входящие запросы и передавать их на обработку в сервис. Основные методы контроллера включают добавление новой книги, получение информации о книге по идентификатору и получение списка всех книг. Сервис, в свою очередь, будет инкапсулировать логику работы с данными, обеспечивая сохранение, поиск и управление книгами в приложении.
Клиентское приложение будет взаимодействовать с микросервисом через HTTP API. Оно будет отправлять запросы на создание, получение и управление данными о книгах. Весь процесс взаимодействия будет происходить через указанный в конфигурации контроллера микросервис.
NestJS поддерживает два основных шаблона взаимодействия с микросервисами: через сообщения (запрос-ответ) и через события. Шаблон на основе сообщений подходит для задач с низкой задержкой, тогда как шаблон событий более гибкий и лучше подходит для асинхронных операций, обеспечивая мгновенное закрытие соединения [6, с. 247].
3. Обеспечение безопасности и соответствия стандартам при взаимодействии микросервисов в финансовых системах
Информационная безопасность в финансовом секторе вызывает серьезные опасения на глобальном уровне. В рамках Всемирного экономического форума 2018 года киберугрозы были признаны важнейшими составляющими мирового технологического риска. Наблюдается устойчивая тенденция, при которой кибератаки на финансовые учреждения преследуют две ключевые цели: увеличение финансовых потерь и подрыв стабильности работы банковской системы.
В 2022 году атаки на банковский сектор составляли 17% от общего числа глобальных кибератак, и их характер претерпел существенные изменения. Основной угрозой остается несанкционированное проведение операций по переводу средств, что может быть следствием как хакерских действий, так и внутреннего мошенничества [7].
Наряду с классическими кибератаками, в последние годы появился новый тип угроз – компрометация бизнес-процессов (BPC), который представляет собой перенастройку информационной системы для перенаправления прибыли. Этот вид мошенничества уже нанес значительный ущерб мировым финансовым учреждениям, включая кражу около 80 миллионов долларов у Банка Бангладеша.
В будущем планируется дальнейшее ужесточение нормативных требований в связи с появлением новых технологий, таких как Интернет вещей и искусственный интеллект, что обеспечит повышенную защиту информационных систем от новых угроз [8, с. 128-131].
При использовании микросервисной архитектуры каждый микросервис функционирует автономно, имея собственную точку входа, через которую осуществляется взаимодействие как с внешними пользователями, так и с другими сервисами. С ростом числа таких точек увеличивается и потенциальная площадь для атак, что представляет значительную проблему в контексте обеспечения безопасности приложений на основе микросервисов. Каждая точка входа должна быть надёжно защищена, чтобы исключить возможность несанкционированного доступа. Обычно пользователи не взаимодействуют с микросервисами напрямую, а микросервисы обмениваться данными от имени пользователей. Для защиты взаимодействия между микросервисами важно внедрять механизмы аутентификации и авторизации. В этом контексте широко применяются протоколы, основанные на токенах или сертификатах.
Одним из популярных решений для межсервисной аутентификации является использование JSON Web Token (JWT). Этот подход не только обеспечивает защищённое взаимодействие между сервисами, но и позволяет передавать пользовательский контекст. Пользовательский контекст включает данные, которые описывают пользователя, обращающегося к приложению, будь то человек или другой сервис. В условиях распределенной системы, такой как микросервисная архитектура, поддержание доступа к этому контексту становится более сложной задачей по сравнению с монолитными приложениями, где все компоненты используют единый сеанс. JWT позволяет надёжно передавать этот контекст между микросервисами.
Вопросы аутентификации пользователей и сервисов в микросервисных приложениях обширны и включают не только JWT, но и стандарты OAuth2 и OpenID Connect. Выбор между этими решениями или их комбинациями зависит от конкретных потребностей приложения и модели пользователей, которые оно обслуживает.
Передача данных между микросервисами или клиентской частью и микросервисом может подвергаться атакам, направленным на перехват или изменение данных. Это создает необходимость обеспечения целостности данных в процессе передачи. Одним из наиболее эффективных методов защиты является цифровая подпись. Например, если данные передаются по защищённому протоколу транспортного уровня (TLS), они сохраняют свою целостность. Использование HTTPS для обмена данными между микросервисами обеспечивает необходимый уровень защиты.
Разработку каждого микросервиса могут осуществлять разные команды, использующие различные языки программирования и технологии. Это приводит к увеличению сложности обеспечения безопасности, так как каждое технологическое решение требует разработки и внедрения соответствующих практик и инструментов для обеспечения его безопасности. Команды, отвечающие за безопасность, должны учитывать специфику используемых технологий, разрабатывать руководства по безопасному программированию, проводить исследования инструментов для анализа кода, и обеспечивать их интеграцию в процесс разработки. В то же время, основные принципы обеспечения безопасности в микросервисной архитектуре остаются схожими с таковыми в монолитных системах, хотя требуют большего объема ресурсов и более тщательного планирования, особенно с учетом новых технологий, таких как контейнеризация и оркестрация контейнеров, которые требуют особого внимания в контексте безопасности, включая разработку лучших практик, безопасных конфигураций и руководств для администраторов [9, с. 38-41].
Применение механизма взаимной аутентификации позволяет установить надёжный и защищённый канал связи между микросервисами. Этот процесс основывается на использовании асимметричной криптографии протокола Transport Layer Security (TLS). В исследовании приводятся примеры реализации mTLS на основе двух различных подходов, применяемых в Docker Swarm и Netflix. Оба метода задействуют удостоверяющий центр (Certificate Authority, CA), однако различия заключаются в сроках действия самоподписанных сертификатов. В первом случае сертификаты обновляются каждые три месяца, тогда как во втором предусмотрены как долгосрочные, так и краткосрочные сертификаты. Последние используются для решения проблемы отзыва сертификатов, что позволяет повысить надёжность аутентификации. Однако mTLS, несмотря на свои преимущества, не решает задач, связанных с авторизацией.
Безопасность микросервисов также можно повысить за счёт применения токенов безопасности, таких как JSON Web Token (JWT) или OpenID. Эти токены создаются после успешной аутентификации и содержат информацию, необходимую для авторизации. Использование таких токенов позволяет разграничить доступ между различными сервисами. Внедрение счётчика деактивации токенов является одной из лучших практик, так как это предотвращает повторное использование токена в случае его компрометации.
Управление доступом может осуществляться на основе различных политик, среди которых наиболее популярны две: Role Based Access Control (RBAC) и Attribute Based Access Control (ABAC). RBAC позволяет управлять доступом для крупных групп пользователей, тогда как ABAC предлагает более детальную настройку прав доступа, основанную на атрибутах. Эти подходы обеспечивают гибкость и точность в разграничении доступа, что особенно важно в сложных микросервисных системах.
В публикации NIST 800-162 предлагается использовать децентрализованную модель, которая предполагает, что безопасность каждого микросервиса находится в зоне ответственности его разработчиков. Этот подход повышает гибкость настройки, но усложняет интеграцию и тестирование системы в целом.
Этот метод позволяет централизованно управлять правилами доступа, что облегчает тестирование и управление политиками. Однако такая модель может увеличивать сетевую нагрузку, поэтому важно учитывать возможности кэширования для снижения этой нагрузки [10].
Заключение
Подводя итоги, можно заключить, что использование микросервисной архитектуры с применением NestJS в сложных финансовых системах обеспечивает значительные преимущества, такие как гибкость, масштабируемость и устойчивость к сбоям. Однако внедрение такой архитектуры связано с множеством вызовов, особенно в области управления безопасностью и взаимодействием микросервисов. Для успешного внедрения необходимо тщательно продумывать архитектуру и выбирать подходящие инструменты, учитывая специфику финансовых систем. Будущее развитие этой области предполагает дальнейшее исследование и применение новых технологий, таких как искусственный интеллект и автоматизация, для повышения эффективности и безопасности микросервисов.
