Распределенное кэширование Java в облаке с помощью нового плагина Azure discovery для Hazelcast

Большое спасибо Альпарслан Авчи и Месуту Челику из Hazelcast за их очень ценную помощь при написании этой записи в блоге!

Необходимость распределенного кэширования в облаке

Масштабирование приложений без состояния в облаке несложно, масштабирование базы данных вызывает гораздо больше проблем.

Если вы хотите эффективно запускать приложения в облаке, вам необходимо использовать механизм кэширования: если вы не кэшируете свои данные, любой скачок трафика автоматически приведет к скачку запросов к вашей базе данных. И ваша база данных, вероятно, является частью вашей архитектуры, которая масштабируется меньше, особенно если вы используете базу данных SQL. Кроме того, это, вероятно, самая дорогостоящая часть вашей архитектуры, поэтому, даже если она будет расширяться, ваш счет тоже увеличится, а вы, вероятно, этого не хотите.

Вот почему в Hipster , мы много лет очень усердно работали с несколькими крупными поставщиками кэша, чтобы предоставить вам наилучшее возможное решение.

Как правило, у нас есть два типа использования кэша:

Кэш второго уровня в режиме гибернации (часто называемый “кэш L2”), который непосредственно кэширует ваши объекты.
Абстракция Spring Cache, которая будет кэшировать более сложные бизнес-объекты.

У обоих есть свои преимущества, и именно поэтому мы разместили их в Hipster.

Затем у нас есть различные реализации кэширования, которые подпадают под следующие 3 основные категории:

Локальные кэши (например, Caffeine): они наиболее эффективны, но они не масштабируются по узлам. Поэтому, когда вы добавите больше узлов приложения, у вас возникнут проблемы с синхронизацией кэша, и вы увидите старые (устаревшие) данные.
Удаленные кэши (например, Redis): они используют удаленный сервер, поэтому их легко масштабировать, но их производительность часто на порядок ниже (чтобы получить объект, вам нужно извлечь его по сети, а затем десериализовать его – когда для локального кэша вы просто делаете указатель на объект, который уже находится внутри вашей кучи).
Распределенные кэши (например, Hazelcast): они будут действовать как локальный кэш, но могут масштабироваться при добавлении узлов приложения благодаря механизму распределенной синхронизации. Высокопроизводительные решения, такие как Hazelcast, также могут работать в качестве удаленных кэшей, но выиграют от наличия локального кэша (часто называемого “ближним кэшем”) для повышения производительности. Они выглядят как лучшее решение, но за них приходится платить: их сложнее настроить! Много лет назад люди использовали бы многоадресную рассылку для автоматического поиска узлов, но в облаке вы не можете использовать такую сетевую функцию, и вам нужен определенный механизм, чтобы узлы находили друг друга.

В этом посте мы рассмотрим новое решение, плагин Azure discovery для Hazelcast: он использует специальный Azure API для автоматического масштабирования, решая сложную проблему настройки распределенного кэша.

Знакомство с новым плагином Azure discovery для Hazelcast

Плагин Azure discovery для Hazelcast – это проект с открытым исходным кодом, разработанный Альпарслан Авчи из Hazelcast и доступен на GitHub по адресу/| https://github.com/hazelcast/hazelcast-azure .

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

Служба метаданных экземпляра Azure – это конечная точка REST, доступная для всех виртуальных машин IaaS, созданных с помощью диспетчера ресурсов Azure. Конечная точка доступна по хорошо известному не маршрутизируемому IP-адресу (169.254.169.254), доступ к которому возможен только из виртуальной машины.

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

Установка плагина Azure discovery для Hazelcast

Весь код, показанный в этой статье, взят из конкретного проекта с открытым исходным кодом, который я создал, и который вы можете проверить по адресу https://github.com/jdubois/jhipster-hazelcast-azure .

Это модифицированное приложение JHipster , так как этот плагин работает только с недавно выпущенным Hazelcast 4, который еще не полностью поддерживает Spring Boot (Привод Spring Boot не совместим с Hazelcast 4, но это будет исправлено со следующим выпуском Micrometer).

Чтобы установить Hazelcast 4 и новый плагин Azure discovery для Hazelcast, вам необходимо добавить их в качестве зависимостей в свой pom.xml файл:


    com.hazelcast
    hazelcast
    4.0


    com.hazelcast
    hazelcast-hibernate53
    2.0.0

Поскольку мы не собираемся его использовать, если у вас есть поддержка Spring Boot для Hazelcast в ваших зависимостях (что было бы в случае приложения JHipster), вы можете удалить эту зависимость, а именно com.hazelcast:hazelcast-spring .

Настройка плагина Azure discovery для Hazelcast

Для этого примера мы будем использовать Hipster’s CacheConfiguration object, но значительно упростите его, чтобы вы могли легко использовать его в любом классическом приложении Spring Boot, а также для облегчения понимания:

package com.mycompany.myapp.config;

import com.hazelcast.config.Config;
import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.env.Environment;
import org.springframework.core.env.Profiles;

@Configuration
public class CacheConfiguration {

    private final Logger log = LoggerFactory.getLogger(CacheConfiguration.class);

    private final Environment env;

    public CacheConfiguration(Environment env) {
        this.env = env;
    }

    @PreDestroy
    public void destroy() {
        log.info("Closing Cache Manager");
        Hazelcast.shutdownAll();
    }

    @Bean
    public HazelcastInstance hazelcastInstance() {
        log.debug("Configuring Hazelcast");
        Config config = new Config();
        config.setInstanceName("hazelcasttest");
        // If running in Azure, use the Hazelcast Azure plugin
        if (env.acceptsProfiles(Profiles.of("azure"))) {
            log.info("Configuring the Hazelcast Azure plug-in");
            config.getNetworkConfig().getJoin().getMulticastConfig().setEnabled(false);
            config.getNetworkConfig().getJoin().getAzureConfig().setEnabled(true);
        }
        return Hazelcast.newHazelcastInstance(config);
    }
}

Важной частью здесь является следующая строка:

config.getNetworkConfig().getJoin().getAzureConfig().setEnabled(true);

Есть еще много доступных вариантов конфигурации, подробно описанных по адресу https://github.com/hazelcast/hazelcast-azure , но эта настройка по умолчанию уже достаточно хороша для большинства обычных нужд: плагин будет использовать Службу метаданных экземпляра Azure для поиска других виртуальных машин в той же группе ресурсов и создаст кластер со всеми их.

Некоторые важные замечания по этому кластеру:

Он будет использовать частную виртуальную сеть по умолчанию, которая создается при создании виртуальных машин. Это означает, что все коммуникации будут скрыты от внешнего мира и что вам не нужно настраивать для этого брандмауэр (он уже открыт по умолчанию в этой частной сети).
Эта сеть использует IP-адреса 10.0.0.0\24 , поэтому вы, вероятно, увидите, что ваши виртуальные машины используют IP-адреса типа 10.0.0.4 и 10.0.0.5 для общения.

Настройка виртуальных машин для доступа к службе метаданных экземпляра Azure

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

Вам нужно будет перейти на Azure Portal , и для каждой виртуальной машины вам нужно будет выполнить следующие операции.

Включите систему, назначающую управляемое удостоверение каждой виртуальной машине

Для каждой виртуальной машины посмотрите на пункт меню Identity в левом меню и включите идентификатор “Присвоенный системе”.:

Это позволит вам назначить роли этой виртуальной машине.

Присвоите каждой виртуальной машине роль “ЧТЕНИЕ” в группе ресурсов

Все еще находясь в Azure Portal , перейдите к группе ресурсов, в которой были созданы ваши виртуальные машины.

В левом меню выберите Управление доступом (I AM) и введите Reader роль для всех виртуальных машин , которые вы хотите использовать в своем кластере:

Запуск всего и тестирование кластера

Теперь, когда все настроено, вы можете запускать свои приложения Spring Boot на каждой виртуальной машине.

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

В этом примере мы видим, что у нас есть 2 узла, использующих частную сеть, которую мы описали выше (IP-адреса 10.0.0.4 и 10.0.0.5 ). Вы можете видеть, что текущий узел является 10.0.0.4 (рядом с ним есть this ), и, очевидно, вы увидите противоположное на другом узле ( 10.0.0.4 ... это ).

Если вы хотите проверить, что кластер работает нормально, простое решение с помощью примера приложения, которое мы создали на https://github.com/jdubois/jhipster-hazelcast-azure состоит в том, чтобы выполнить следующее:

Откройте порт 8080 на общедоступном IP-адресе каждой виртуальной машины
Получите доступ к каждому приложению, используя этот общедоступный IP-адрес
Измените некоторые кэшированные данные на одном узле (поскольку мы используем кэш Hibernate L2, все данные базы данных кэшируются) и проверьте на другом узле, что данные изменились соответствующим образом

Вывод

Распределенный кэш – лучшее решение для масштабирования облачных приложений, но его настройка в облаке может быть сложной задачей: новый плагин Azure discovery для Hazelcast – отличное решение для эффективного решения этой проблемы.

Это решение будет отлично работать при запуске виртуальных машин в Azure, но как оно будет работать с более продвинутыми службами Azure?

Если вы используете Azure App Services , предложение PaaS от Azure, вы не сможете использовать частный интерфейс для подключения узлов. Однако вы по-прежнему сможете использовать плагин Hazelcast Azure Discovery с клиентом Hazelcast для подключения к кластеру Hazelcast, работающему на виртуальных машинах Azure. Документация доступна здесь .
Если вы используете Azure Kubernetes Service , посмотрите на диаграмму управления Hazelcast и Hazelcast Kubernetes Operator .
Если вы используете JHipster с Azure Kubernetes Service или Azure Spring Cloud , вам следует взглянуть на то, как JHipster использует реестр JHipster для обнаружения узлов, который будет работать так же, как и плагин Azure discovery для Hazelcast, используя Eureka для обнаружения узлы вместо службы метаданных экземпляра Azure.
Если вам нужно чисто Java-решение, но вы не используете JHipster, взгляните на плагин Hazelcast Eureka , который работает так же, как реестр JHipster, используя Eureka для обнаружения узлов.

Если вы хотите проверить код, используемый в этой статье, он доступен по адресу https://github.com/jdubois/jhipster-hazelcast-azure .

Оригинал: “https://dev.to/azure/java-distributed-caching-in-the-cloud-with-the-new-azure-discovery-plugin-for-hazelcast-bme”