Изменить архитектуру модуля для корректной обработки транзакций - PullRequest
Новая
       11

Изменить архитектуру модуля для корректной обработки транзакций

0 голосов
/ 09 июля 2019

У меня есть приложение с модульной архитектурой. Каждый модуль в этом приложении связывается между собой через протокол RPC. Это приложение построено поверх пользовательского фреймворка, основанного на пружине и гибернации внутри. Каждый модуль имеет трехуровневую архитектуру внутри, поэтому существует прикладной уровень для предоставления API для разных модулей или для части пользовательского интерфейса, а также сервисный уровень для определения бизнес-логики и обработки транзакций, уровень доступа к данным для доступа / управления ДБ данных. Кроме того, каждый модуль этого приложения развертывается как отдельный сервис (WAR) на выделенном порту сервера приложений. Кроме того, каждый модуль имеет собственный пул соединений с БД. В настоящее время мы работаем над темой производительности, и существует следующий сценарий, где производительность должна быть улучшена: 

Given: Module1.Component1 marked as @Transactional
And: Component1.method1() makes call to Module2.Component1
And: Module2.Component1 responds in 
  1sec;
  30sec;
  1min; 
  not responding;
  responds with exception.

There are the following load on Module1Componet1
  1 request/sec
  10 requests/sec

При высокой нагрузке на Module1 и медленном отклике Module2 оба пула соединений jdbc заполнены, и оба модуля не могут реагировать на дальнейшие запросы.

В качестве идеи по улучшению производительности для Модуля1 могут быть сделаны следующие изменения: 

Extract external call to another module out of open transaction for Module1

Это исправит проблему с производительностью, и Module1 будет вести себя должным образом, даже если ответ Module2 будет слишком медленным и будет большой объем запросов к Module1. Это исправление может быть сделано на уровне сервиса с перемещением аннотации @Transaction в другое место для выполнения внешнего вызова из транзакции. Но вопрос в том, как сделать это правильно, чтобы избежать подобных проблем в будущем, когда разработчики сделают подобные изменения. Не могли бы вы посоветовать, как можно ограничить это через архитектуру, а именно, как принудительно вызывать удаленные вызовы RPC из транзакции db для будущего развития?

...