Тип работы:
Предмет:
Язык работы:


ОПТИМИЗАЦИЯ ПРОИЗВОДИТЕЛЬНОСТИ КЭШИРУЮЩЕГО СЕРВИСА В ВЫСОКОНАГРУЖЕННОЙ СИСТЕМЕ

Работа №182858

Тип работы

Бакалаврская работа

Предмет

программирование

Объем работы62
Год сдачи2025
Стоимость4600 руб.
ПУБЛИКУЕТСЯ ВПЕРВЫЕ
Просмотрено
20
Не подходит работа?

Узнай цену на написание


АННОТАЦИЯ 3
Перечень условных обозначений, сокращений, терминов 4
Введение 5
1 Анализ текущей архитектуры ОПК 7
1.1 Общая схема взаимодействия клиента, кэша и мастер-системы 7
1.2 Выявление причин проблем с производительностью 9
1.3 Нехватка потоков исполнения 10
1.4 Отключение кэша 13
1.5 Влияние кэша на производительность 14
1.6 Анализ причин деградации производительности 15
1.7 Асинхронная инвалидация кэша 15
1.8 Реагирование на недоступность кэша 15
2 Требования и метрики 17
2.1 Нефункциональные требования 17
2.2 Ключевые метрики оценки 17
2.3 Целевые SLO и допустимые пределы отклонений 18
3 Проектирование оптимизированной модели взаимодействия 20
3.1 Плавная деградация и перегрузки 20
3.2 Аварийный выключатель для плавного деградирования сервиса 20
3.2.1 Принцип действия аварийного выключателя 20
3.2.2 Механизм работы в системе ОПК 21
3.3 Управление перегрузками с помощью рейт-лимитера 22
3.4 Синхронная инвалидация кэша 25
3.5 Механизм реагирования на рост задержки потребления 26
4 Реализация спроектированного решения 28
4.1 Основные используемые технологии 28
4.2 Повышение числа потоков для задач обновления кэша 29
4.3 Реализация аварийного выключателя 29
4.3.1 Выбор библиотеки для реализации аварийного переключателя 29
4.3.2 Исключение неподходящих вариантов 29
4.3.3 Сравнение resilience4j и Alibaba Sentinel 30
4.3.4 Сценарии переключения состояния 31
4.3.5 Архитектурная структура сервиса ОПК 31
4.3.6 Мониторинг задержки потребления 32
4.3.7 Интеграция аварийного выключателя в сервис ОПК 33
4.4 Реализация распределенного рейт-лимитера 37
4.4.1 Выбор библиотеки 37
4.4.2 Алгоритм Token Bucket 38
4.4.3 Интеграция рейт-лимитера в ОПК 39
4.5 Интеграция мониторинга 41
4.5.1 Мониторинг аварийного выключателя 41
4.5.2 Мониторинг распределенного рейт-лимитера 41
4.5.3 Специфичные метрики сервиса ОПК 42
5 Экспериментальная оценка 44
5.1 Подготовка и проведение нагрузочного тестирования 44
5.2 Максимальная ступень нагрузки 44
5.3 Искусственное моделирование задержки потребления 45
5.4 Оценка отказоустойчивости 45
5.5 Анализ результатов 46
5.6 Заключение по результатам тестирования 46
Заключение 48
Список использованных источников и литературы 49


Важным процессом в банковской системе является предоставление информации о карточных продуктах клиентов, включающих данные по кредитным и дебетовым картам, их лимитам, статусам и связанным финансовым продуктам. В компании автора работы исполнение этого процесса осуществляется внешней системой - операционной платформой (ОП), которая отвечает за обработку сложных бизнес-операций. Каждый запрос к ОП требует выполнения ресурсоемких запросов к разным хранилищам данных. При этом ОП является внешней системой, интеграция с которой ограничена строгими контрактами, а ее модификация невозможна без согласования с поставщиком. Поэтому для снижения нагрузки на ОП и ускорения обработки часто запрашиваемых данных был разработан отдельный кэширующий сервис - операционный прокси-кэш (ОПК). Сервис хранит в распределенном кэше актуальные данные о карточных продуктах и предоставляет их клиентам напрямую, минуя ОП. Изначально это позволило снизить время ответа для клиентов и уменьшить частоту обращений к мастер-системе.
Однако кэширование данных в высоконагруженных системах требует решения двух ключевых задач: обеспечения актуальности данных и отказоустойчивости. Для синхронизации кэша с ОП используется событийный механизм, основанный на брокере сообщений. В таком механизме при возникновении задержек в обработке событий (например, из-за сетевых проблем или перегрузки системы) возникает отставание репликации изменений, что может привести к выдаче клиентам устаревшей информации.
В ходе эксплуатации выявлены случаи деградации производительности ОПК при массовых операциях синхронизации. Это оказывало негативное влияние на время выдачи ответа клиентами, а также на актуальность выдаваемых данных. Предположительно, деградация связана с тем ухудшением производительности кэша из-за большого числа операций обновления.
В процессе эксплуатации системы отмечены эпизоды снижения производительности сервиса ОПК при высокой интенсивности операций синхронизации данных. Данное поведение приводило к увеличению задержек в предоставлении информации клиентским приложениям, а также к нарушению актуальности предоставляемых данных. Гипотеза о причинах деградации предполагает корреляцию с повышенной нагрузкой на кэширующий слой.
Целью настоящей работы является проектирование, разработка и экспериментальная оценка оптимизированной модели взаимодействия сервиса ОПК для обеспечения высокой производительности, согласованности данных и отказоустойчивости под нагрузкой. Для достижения поставленной цели в работе решаются следующие задачи:
- анализ текущей архитектуры взаимодействия ОПК с мастер-системой ОП и выявление ключевых узких мест;
- формирование метрик оценки эффективности;
- проектирование нового решения;
- реализация прототипа предложенного решения;
- экспериментальная оценка

Возникли сложности?

Нужна помощь преподавателя?

Помощь в написании работ!


В рамках данной работы была разработана и экспериментально оценена оптимизированная модель взаимодействия сервиса ОПК с мастер-системой (ОП), ориентированная на обеспечение высокой производительности, актуальности данных и отказоустойчивости в условиях повышенной нагрузки.
На начальном этапе выполнено всестороннее исследование текущей архитектуры сервиса ОПК, позволившее выявить ключевые узкие места, включая рост очереди задач в контексте обновления кэша и увеличение времени обработки запросов. Анализ метрик и диагностика состояния системы подтвердили, что ограничение числа выделенных потоков в контексте кэширующего сервиса стало основной причиной деградации. Также были выявлены проблемы с отсутствием контроля интенсивности запросов в мастер -систему и отсутствием реакции на недоступность внешних сервисов.
В процессе проектирования предложено решение, объединяющее несколько механизмов: аварийный выключатель для плавной деградации, распределенный рейт- лимитер для управления интенсивностью запросов и контроль актуальности данных через определение задержки потребления.
Нагрузочное тестирование подтвердило эффективность предложенного подхода. Сервис стабильно обрабатывал нагрузку, превышающую промышленную в 1.6 раза, при этом доля ошибок, вызванных внутренними процессами ОПК, составила 0%. Все зафиксированные аномалии были связаны с истечением срока действия авторизационных элементов, что не является критическим для системы и не влияет на ее функциональность.
Результаты испытаний показали, что:
- производительность сервиса ОПК увеличена за счет выделения дополнительных ресурсов;
- актуальность данных обеспечена через интеграцию с Kafka Exporter, что позволяет оперативно реагировать на задержки потребления;
- отказоустойчивость достигнута благодаря аварийному выключателю, который изолирует сбои кэша и направляет запросы в мастер-систему без нарушения доступности.
Таким образом, разработанная модель соответствует поставленной цели и демонстрирует готовность к внедрению в промышленную среду. Предложенные изменения обеспечивают баланс между снижением нагрузки на мастер -систему и предоставлением актуальной информации клиентам, что соответствует требованиям программной инженерии и банковским стандартам.



1) Ричардсон, К. Микросервисы. Паттерны разработки и рефакторинга / К. Ричардсон. - СПб.: Питер, 2019. - 544 с.: ил. - (Серия «Библиотека программиста»).
2) Site Reliability Engineering: How Google Runs Production Systems / Google SRE Team. «Service Level Objectives» : [Электронный ресурс] / Google. - [Б. м.], 2016. - [Дата обращения: 10.10.2023]. - Режим доступа: https://sre.google/sre-book/servi ce-level- objectives/.
3) Фаулер, М. Circuit Breaker [Электронный ресурс]. - URL: https://martinfowler.com/bliki/CircuitBreaker.html (дата обращения: 29.04.2025).
4) Spring Framework [Электронный ресурс] / Broadcom Inc. - URL: https://spring.io/projects/spring-framework (дата обращения: 03.05.2025).
5) About the Documentation :: Reactor Core Reference Guide [Электронный ресурс] / Broadcom Inc. - URL: https://projectreactor.io/docs/core/release/reference/aboutDoc.html (дата обращения: 03.05.2025).
6) Overview | Prometheus [Электронный ресурс] / Prometheus; The Linux Foundation. - URL: https://prometheus.io/docs/introduction/overview/ (дата обращения: 04.05.2025).
7) CircuitBreaker [Электронный ресурс] / resilience4j. - URL: https://resilience4j.readme.io/docs/circuitbreaker (дата обращения: 04.05.2025).
8) How to Use | alibaba/Sentinel [Электронный ресурс]. - URL: https://github.com/alibaba/Sentinel/wiki/How-to-Use#circuit-breaking-rules-degraderule (дата обращения: 04.05.2025).
9) alibaba/Sentinel: A powerful flow control component... [Электронный ресурс]. - URL: https://github.com/alibaba/Sentinel (дата обращения: 04.05.2025).
10) Getting Started [Электронный ресурс] / resilience4j community. - URL: https://resilience4j.readme.io/docs/getting-started-3 (дата обращения: 04.05.2025).
11) open-source-framework-integrations - Sentinel [Электронный ресурс]. - URL: https://sentinelguard.io/en-us/docs/open-source-framework-integrations.html (дата обращения: 04.05.2025).
12) Examples [Электронный ресурс] / resilience4j community. - URL: https://resilience4j.readme.io/docs/examples-1 (дата обращения: 04.05.2025).
13) Circuit-Breaking | Sentinel [Электронный ресурс]. - URL: https://sentinelguard.io/en-us/docs/circuit-breaking.html (дата обращения: 04.05.2025).
14) Circuitbreaker [Электронный ресурс] / resilience4j. - URL:
https://resilience4j.readme.io/docs/circuitbreaker#create-and-configure-a-circuitbreaker (дата
обращения: 04.05.2025).
15) Micrometer [Электронный ресурс] / resilience4j community. - URL: https://resilience4j.readme.io/docs/micrometer (дата обращения: 04.05.2025).
..22


Работу высылаем на протяжении 30 минут после оплаты.




©2025 Cервис помощи студентам в выполнении работ