Implantação do Apache Ignite Zero: realmente zero?

Somos o departamento de desenvolvimento tecnológico de uma rede varejista. Um dia, a administração definiu a tarefa de acelerar cálculos em larga escala usando Apache Ignite em conjunto com MSSQL e mostrou um site com belas ilustrações e exemplos de código Java. Gostei imediatamente do site Implantação zero, cuja descrição promete milagres: você não precisa implantar manualmente seu código Java ou Scala em cada nó da grade e reimplantá-lo sempre que ele for alterado. À medida que o trabalho avançava, descobri que o Zero Deployment tem usos específicos, cujos recursos desejo compartilhar. Abaixo do corte estão ideias e detalhes de implementação.

1. Declaração do problema

A essência do problema é a seguinte. Há um diretório de pontos de vendas SalesPoint e um diretório de produtos Sku (Stock Keeping Unit). O ponto de venda possui um atributo “Tipo de loja” com os valores “pequena” e “grande”. Um sortimento (lista de produtos do ponto de venda) é conectado a cada ponto de venda (carregado do SGBD) e é fornecida a informação de que a partir da data especificada o produto especificado
excluído do sortimento ou adicionado ao sortimento.

É necessário organizar um cache particionado de pontos de venda e armazenar nele informações sobre os produtos conectados com um mês de antecedência. A compatibilidade com o sistema de combate requer que o nó cliente Ignite carregue dados, calcule um agregado do formulário (tipo de loja, código do produto, dia, número_de_pontos_de_venda) e carregue-o de volta para o SGBD.

2. Estudo da literatura

Ainda não tenho experiência, então estou começando a dançar no fogão. Ou seja, a partir de uma revisão de publicações.

Artigo de 2016 Apresentando o Apache Ignite: primeiros passos contém um link para a documentação do projeto Apache Ignite e ao mesmo tempo uma censura pela imprecisão desta documentação. Eu reli algumas vezes, a clareza não vem. Refiro-me ao tutorial oficial começandoQue
promete com otimismo “Você estará pronto e funcionando em um instante!” Estou descobrindo as configurações das variáveis ​​de ambiente, assistindo a dois vídeos do Apache Ignite Essentials, mas eles não foram muito úteis para minha tarefa específica. Eu iniciei o Ignite com sucesso a partir da linha de comando com o arquivo padrão “example-ignite.xml”, construindo o primeiro aplicativo Aplicativo de computação usando Maven. O aplicativo funciona e usa Zero Deployment, que beleza!

Eu li mais e lá o exemplo usa imediatamente affinityKey (criado anteriormente por meio de uma consulta SQL) e até usa o misterioso BinaryObject:

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

Ler levemente: formato binário - algo como reflexão, acessando os campos de um objeto pelo nome. Pode ler o valor de um campo sem desserializar completamente o objeto (economizando memória). Mas por que BinaryObject é usado em vez de Person, já que existe Zero Deployment? Por que IgniteCache transferido para IgniteCache ? Ainda não está claro.

Estou refazendo o aplicativo Compute para se adequar ao meu caso. A chave primária do diretório de pontos de venda em MSSQL é definida como [id] [int] NOT NULL, crio um cache por analogia

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

Na configuração xml indico que o cache está particionado

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

O particionamento por ponto de venda pressupõe que a agregação necessária será construída em cada nó do cluster para os registros salesPointCache ali disponíveis, após o qual o nó cliente realizará a soma final.

estou lendo o tutorial Primeiro aplicativo de computação Ignite, eu faço isso por analogia. Em cada nó do cluster eu executo IgniteRunnable(), algo assim:

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

Eu adiciono lógica de agregação e upload e executo-a em um conjunto de dados de teste. Tudo funciona localmente no servidor de desenvolvimento.

Eu inicio dois servidores de teste CentOs, especifico os endereços IP em default-config.xml, executo em cada um

./bin/ignite.sh config/default-config.xml

Ambos os nós do Ignite estão em execução e podem se ver. Eu especifico os endereços necessários na configuração xml do aplicativo cliente, ele inicia, adiciona um terceiro nó à topologia e imediatamente há dois nós novamente. O log mostra “ClassNotFoundException: model.SalesPoint” na linha

SalesPoint sp=salesPointCache.get(spId);

StackOverflow diz que o motivo do erro é que não há classe SalesPoint personalizada nos servidores CentOs. Nós chegamos. Que tal “você não precisa implantar manualmente seu código Java em cada nó” e assim por diante? Ou “seu código Java” não é sobre o SalesPoint?

Provavelmente perdi alguma coisa - começo a pesquisar novamente, lendo e pesquisando novamente. Depois de um tempo, tenho a sensação de que li tudo sobre o assunto, não há mais nada de novo. Enquanto pesquisava, encontrei alguns comentários interessantes.

Valentin Kulichenko, arquiteto-chefe da GridGain Systems, responder no StackOverflow, abril de 2016:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

Outra opinião oficial: Denis Magda, Diretor de gerenciamento de produtos, GridGain Systems.

Artigo sobre Habré sobre microsserviços faz referência a três artigos de Denis Magda: Microsserviços Parte I, Microsserviços Parte II, Microsserviços Parte III 2016-2017. No segundo artigo, Denis sugere iniciar um nó de cluster por meio de MaintenanceServiceNodeStartup.jar. Você também pode usar a inicialização com configuração xml e linha de comando, mas será necessário colocar manualmente classes personalizadas em cada nó do cluster implementado:

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

Na verdade, é isso. Aqui acontece que esse misterioso formato binário!

3. Jarra única

Denis ficou em primeiro lugar na minha avaliação pessoal, IMHO o tutorial mais útil de todos os disponíveis. No dele Exemplo de microserviços O Github contém um exemplo totalmente pronto de configuração de nós de cluster, que compila sem qualquer ocupação adicional.

Eu faço da mesma maneira e obtenho um único arquivo jar que inicia “nó de dados” ou “nó cliente” dependendo do argumento da linha de comando. A montagem começa e funciona. A implantação zero foi derrotada.

A transição de megabytes de dados de teste para dezenas de gigabytes de dados de combate mostrou que o formato binário existe por uma razão. Foi necessário otimizar o consumo de memória nos nós, e foi aí que o BinaryObject se mostrou muito útil.

4. Conclusões

A primeira crítica encontrada sobre a imprecisão da documentação do projeto Apache Ignite acabou sendo justa; pouca coisa mudou desde 2016. Não é fácil para um iniciante montar um protótipo funcional baseado em um site e/ou repositório.

Com base nos resultados do trabalho realizado, a impressão foi que o Zero Deployment funciona, mas apenas no nível do sistema. Algo assim: BinaryObject é usado para ensinar nós de cluster remotos a trabalhar com classes personalizadas; Implantação Zero - mecanismo interno
O próprio Apache Ignite distribui objetos do sistema por todo o cluster.

Espero que minha experiência seja útil para novos usuários do Apache Ignite.

Fonte: habr.com