Должен ли сервис существовать только для кэширования? - PullRequest
1 голос
/ 02 марта 2010

Должно ли кэширование, которое является сквозной задачей, когда-либо превращаться в веб-сервис?

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

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

Каково общее мнение по этому поводу?

Ответы [ 4 ]

3 голосов
/ 02 марта 2010

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

РЕДАКТИРОВАТЬ: Опять же, есть более чем один способ снять шкуру с кошки. Но вам не обязательно кэшировать определенный объект Person. Другая возможность - использовать службу кэширования для отображаемых данных, например, выписку по счету в формате PDF. Например, Hi5 (сайт социальной сети), использует memcache для кэширования полностью подготовленных профилей пользователей.

2 голосов
/ 02 марта 2010

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

Кэш должен быть чем-то быстрым, локальным и легкодоступным.

1 голос
/ 02 марта 2010

, если эта служба действует как Фасад для предыдущей некешированной службы, тогда да, это может быть "собственная служба". Это имеет смысл, особенно для данных только для чтения или в основном для чтения. Но помните, что кэширование как многопоточность - предательская область. Его легко «сделать», но чрезвычайно трудно сделать «правильно», и, сделав его неправильно, это может привести к смешному количеству проблем, которые трудно отладить и которые трудно исправить, когда вы найдете причину. Подумайте об этом, провайдеры распространения контента, такие как Akamai , построили весь свой бизнес на предоставлении кэширования как услуги.

0 голосов
/ 02 марта 2010

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

Думая об этом с точки зрения использования, что это означает на самом деле? Кажется, подразумевается, что клиенты сначала обращаются к веб-службе кэша, чтобы получить объект. Если его там нет, им нужно было бы получить его от реального веб-сервиса, а затем «вставить» объект обратно в кеш? Это требует много клиентов. Любой рабочий процесс кэширования должен быть прозрачным для клиента.

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

...