Хранить часто используемые объекты микросервиса в кэше Hazelcast?

Question

У нас есть заказ и заказ микросервисов. У нас также есть много других, но между ними часто используются Пользователь и Заказ.

Имеет ли смысл кэшировать объекты Пользователь и Заказ в распределенном кеше Hazelcast для использования другими (для увеличения задержки между микросервисами), или следует Я кеширую только на уровне микросервиса и вызов REST от другого микросервиса?

Если для этого подходит кэш, как я могу отключить обновления кеша на микросервисах, которые не владеют этими объектами?

Спасибо.

Answer 1

Я бы сказал, что это скорее дизайнерское решение. Это во многом зависит от уровня изоляции, который вы выбираете для микросервисов. Вы можете выбрать запуск одного кластера для всех ваших микросервисов с полным контролем доступа, при котором сервисам может быть разрешен доступ к кэшам на основе уровней авторизации, которые вы можете определить. Так, например, создайте 2 кэша - Пользователь и Порядок, сделайте их доступными для User_ms (ms = micro-service) и Order_ms и ограничьте доступ для других.

Для других микро-служб для доступа к кластеру, либо для кэшей пользователей и заказов или других кэшей в одном кластере вы можете контролировать и определять их уровень доступа. Подробнее смотрите здесь: https://docs.hazelcast.org/docs/3.12.5/manual/html-single/index.html#security

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

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

Answer 2

Ну, это хороший вопрос, и ответ таков: "это зависит". Используя кеш, вы делаете компромисс. Между правильностью (или, точнее, свежестью) данных и скоростью их получения вы предпочитаете скорость. Вы на самом деле предпочитаете устаревшие данные сейчас вместо данных fre sh позже.

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

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