Есть ли шаблоны проектирования, которые могли бы работать в этом сценарии?

Question

У нас есть система (веб-приложение Java), которая уже долгое время находится в активной разработке / обслуживании (что-то около десяти лет).

То, что мы смотрим, это реализация RESTful API для веб-приложения. Это веб-приложение, использующее Джерси, будет отдельным проектом с намерением, чтобы оно могло запускаться вместе с основным приложением или развертываться в облаке.

Из-за характера и возраста нашего приложения нам пришлось реализовать (несколько) всеобъемлющий уровень кэширования поверх базы данных (postgres), чтобы помочь снизить нагрузку. В любом случае, для RESTful API идея заключается в том, что GET-запросы сначала будут идти в кеш, а не в базу данных, чтобы поддерживать загрузку базы данных.

Кэш будет заполняться таким образом, чтобы обеспечить наличие большинства вещей, которые понадобятся зарегистрированным пользователям API.

В случае отсутствия кэша необходимые данные должны быть извлечены из базы данных (также в процессе ввода в кэш).

Очевидно, это должно оставаться прозрачным из методов конечной точки RESTful в моем коде. Мы придумали идею создания «брокера» для обработки связи с БД и кешем. Слой REST будет просто передавать идентификаторы (если вы хотите получить) или заполненные объекты Java (если вы хотите вставить / обновить), а посредник позаботится о получении / обновлении / аннулировании и т. Д.

Существует также проблема расширяемости. Начнем с того, что API будет жить вместе с остальными серверами, поэтому доступ к базе данных не будет проблемой, однако, если мы развернем в облаке, нам понадобится другая реализация Broker, которая будет взаимодействовать с системой ( а именно базы данных) другим способом (возможно, посредством использования внутреннего API).

У меня уже есть приблизительное представление о том, как я могу это реализовать, но меня поразило, что это, вероятно, проблема, для которой может существовать подходящий шаблон. Если бы я мог следовать установленному шаблону, а не придумывать собственное решение, это, вероятно, будет лучшим выбором. Есть идеи?

Answer 1

Ehcache имеет реализацию именно такого кеша, что он вызывает SelfPopulationCache .

Запросы делаются в кеш, а не в базу данных.Затем, если произойдет ошибка кэша, Ehcache вызовет базу данных (или любой другой источник данных, который у вас есть) от вашего имени.

Вам просто нужно реализовать CacheEntryFactory , который имеет единственный метод:

Object createEntry(Object key) throws Exception;

Итак, как следует из названия, Ehcache реализует эту концепцию с помощью довольно стандартного фабричного шаблона ...

Answer 2

Лучший шаблон проектирования для прозрачного кэширования HTTP-запросов - это использование и HTTP кеш .

Answer 3

Похоже, шаблон декоратора подойдет вам: http://en.wikipedia.org/wiki/Decorator_pattern.

Вы можете создать DAO интерфейс для доступа к данным, например:

Value get(long id);

И сначала создайте непосредственную реализацию БД, затем создайте реализацию Cache, которая вызывает базовый экземпляр DAO, в этом случае это должна быть реализация БД.

Реализация Cache попытается получить значение из своего собственного управляемого кэша и из нижележащего DAO в случае сбоя.

Таким образом, как ваше старое приложение, так и REST будут видеть только интерфейс DAO, не зная подробностей реализации, и в будущем вы сможете свободно изменять реализацию.

Answer 4

Там нет шаблона. Просто скройте исходные службы БД за интерфейсами, постройте тесты вокруг их предполагаемого поведения, затем включите реализацию, которая использует уровень кэширования. Я полагаю, что внедрение инъекций зависимостей будет лучшим способом помочь вам в этом?