Вопрос архитектуры: клиентское решение кэширования REST API

Question

Я реализую веб-приложение с высоким трафиком, которое использует много REST API для своего уровня доступа к данным из базы данных облака. Я сказал клиент, потому что он реализует REST и не предоставляет его.

REST API реализованы как на стороне сервера, так и на стороне клиента, и мне нужно выяснить, какое решение подходит для кэширования. Приложение работает на веб-ферме, поэтому я склоняюсь к распределенному кешированию, например memcached. Это кэширующее решение должно быть похоже на прокси-уровень между моим приложением и API-интерфейсами REST и поддерживать как клиентскую, так и серверную сторону.

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

Я хочу как можно больше свести к минимуму звонки REST, и мне нужно будет хранить данные как можно больше, но это не обязательно должно быть на 100% точным.

Какое наилучшее решение для этого кэширующего прокси? Является ли это автономным приложением, которое работает на одном из серверов с локальным кешем или встроено в текущее решение с использованием распределенного кэширования? вы что идеи, предложения или проблемы

Спасибо,

Answer 1

Вы попали в ноготь на голове. Вам нужен уровень кэширования, который действует как прокси-сервер для ваших данных.

Я предлагаю вам создать слой, который немного абстрагирует концепцию облака. Ваш клиент не должен заботиться о том, откуда поступают данные. Я бы создал слой репозитория, который связывается с облаком и всеми другими данными. Затем вы можете поместить сервисный уровень поверх того, на который ваш клиент действительно будет звонить. Внутри этого уровня сервиса вы сможете реализовать такие вещи, как ваш слой кеширования.

Я всегда предлагал использовать MemCached или MemCached Win32 в зависимости от вашей среды. MemCached win32 работает очень хорошо, если вы находитесь в мире Windows! Посмотрите на клиента Enyim для MemCached win32 ... это наименее проблематично для всех других портов.

Если вы открыты для этого, и вы находитесь в мире .net, тогда вы можете попробовать Velocity. Наконец, MS поняла, что в их кэширующей структуре есть дыра, в которой они нуждаются в поддержке концепции фермы. Velocity в прошлый раз, когда я проверил, еще не вышел из бета-версии ... но все же стоит посмотреть.

Обычно я предлагаю использовать концепции хранилища и уровня обслуживания с первого дня ... даже если это вам не нужно. Гибкость, которую он обеспечивает для вашего приложения, стоит того, чтобы вы никогда не знали, в каком направлении вам потребуется приложение. Необходимость масштабирования - это, как правило, лучшая причина для этой гибкости. Но обычно, когда вам нужно масштабировать, вам нужно масштабировать сейчас и рефакторинг в слое репозитория, а уровень сервиса, хотя и не является невозможным, обычно является полукомплексом, чтобы делать это в будущем.