Somos um departamento de desenvolvimento de tecnologia de varejo. Uma vez, o gerenciamento definiu a tarefa de acelerar cálculos volumétricos usando o Apache Ignite em conjunto com o MSSQL e mostrou um site com belas ilustrações e exemplos de código Java. O site gostou imediatamente do Zero Deployment , 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 mudar. No decorrer do trabalho, verificou-se que o Zero Deployment tem um uso específico, cujos recursos eu quero compartilhar. Sob o gato reflexões e detalhes de implementação.
1. Declaração do problema
A essência do problema é a seguinte. Há um diretório de ponto de vendas para o SalesPoint e um diretório de produtos Sku (Stock Keeping Unit). O ponto de venda tem o atributo "Tipo de loja" com os valores "pequeno" e "grande". Um sortimento (uma lista de mercadorias de um ponto de venda) é conectado (carregado de um DBMS) a cada ponto de venda e são fornecidas informações de que o produto especificado foi datado
excluídos do sortimento ou adicionados ao sortimento.
É necessário organizar um cache particionado de pontos de venda e armazenar nele informações sobre mercadorias conectadas por um mês de antecedência. A compatibilidade com o sistema de combate requer que o nó do cliente Ignite faça o download dos dados, calcule um agregado do tipo (tipo de loja, código do produto, dia, número de pontos de venda) e faça o upload novamente no DBMS.
2. O estudo da literatura
Ainda não tenho experiência, então estou começando a dançar no fogão. Ou seja, com uma revisão de publicações.
Um artigo de 2016 Apresentando o Apache Ignite: As primeiras etapas contêm um link para a documentação do projeto Apache Ignite e, ao mesmo tempo, o reprovam por slurring. Li algumas vezes, a clareza não vem. Passando ao tutorial oficial de introdução, que
otimista promete "Você estará pronto e funcionando rapidamente!". Entendo as configurações das variáveis de ambiente, assisto a dois vídeos do Apache Ignite Essentials, eles acabaram não sendo muito úteis para minha tarefa específica. Inicio com sucesso o Ignite na linha de comando com o arquivo padrão "example-ignite.xml", coleciono o primeiro Aplicativo de computação usando o Maven. O aplicativo funciona e usa o Zero Deployment, que beleza!
Eu li mais, e aí o exemplo imediatamente usa affinityKey (criado anteriormente por meio de uma consulta SQL), e até o misterioso BinaryObject é aplicado:
IgniteCache<BinaryObject, BinaryObject> people = ignite.cache("Person").withKeepBinary();
Eu li um pouco : o formato binário é um pouco de reflexão, acesso aos campos de um objeto pelo nome. Ele pode ler o valor de um campo sem desserializar completamente o objeto (economizando memória). Mas por que o BinaryObject é usado em vez de Person, porque há Zero Deployment? Por que o IgniteCache <Key, Person> é traduzido para IgniteCache <BinaryObject, BinaryObject>? Ainda não está claro.
Eu refiz o Compute Application no meu caso. A chave primária do diretório do ponto de venda no MSSQL é definida como [id] [int] NOT NULL, eu crio um cache por analogia
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")
No xml-config, 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 pontos de venda pressupõe que o agregado necessário será construído em cada nó do cluster para os registros salesPointCache disponíveis no local, após o qual o nó cliente executará a soma final.
Eu li o tutorial Primeiro aplicativo de ignição de computação , faço por analogia. Em cada nó do cluster, eu executo IgniteRunnable (), algo como isto:
@Override public void run() { SalesPoint sp=salesPointCache.get(spId); sp.calculateSalesPointCount(); .. }
Eu adiciono agregação e lógica de upload, executo em um conjunto de dados de teste. Localmente, tudo funciona no servidor de desenvolvimento.
Eu inicio dois servidores de teste CentOs, especifique endereços IP em default-config.xml, execute em cada
./bin/ignite.sh config/default-config.xml
Os dois nós do Ignite são inicializados e se veem. Especifiquei os endereços necessários no xml-config do aplicativo cliente, ele inicia, adiciona um terceiro nó à topologia e imediatamente existem dois nós novamente. O log lê "ClassNotFoundException: model.SalesPoint" na linha
SalesPoint sp=salesPointCache.get(spId);
StackOverflow diz que a causa do erro é que os servidores CentOs não têm uma classe SalesPoint personalizada. Chegou. Então, como você não precisa implantar manualmente seu código Java em cada nó e em diante? Ou o seu código Java não é sobre o SalesPoint?
Provavelmente perdi alguma coisa - novamente começo a pesquisar, ler e pesquisar novamente. Com o tempo, há um sentimento de que eu li tudo sobre o tema, não há nada de novo. Durante a pesquisa, encontrei alguns comentários interessantes.
Valentin Kulichenko , arquiteto principal da GridGain Systems, resposta ao 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 da GridGain Systems.
Um artigo sobre Habré sobre microsserviços refere-se a três artigos de Denis Magda: Microsserviços Parte I , Microsserviços Parte II , Microsserviços Parte III 2016-2017. Em um segundo artigo, Denis sugere iniciar um nó de cluster por meio de MaintenanceServiceNodeStartup.jar. Você também pode usar o lançamento com a configuração xml e a linha de comandos, mas precisará colocar manualmente classes personalizadas em cada nó de 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.
De fato, é isso. Aqui acontece, por que, este misterioso formato binário!
3. SingleJar
Denis levou o primeiro lugar na minha classificação pessoal, IMHO o tutorial mais útil de todos os disponíveis. Seu github MicroServicesExample contém um exemplo completamente pronto de configuração de nós de cluster, que é compilado sem agachamentos adicionais.
Eu faço isso na imagem e na semelhança, recebo um único arquivo jar que inicia um "nó de dados" ou "nó cliente", dependendo do argumento da linha de comando. A montagem inicia e é executada. A implantação zero é 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 um bom motivo. Era necessário otimizar o consumo de memória nos nós, e aqui o BinaryObject era muito útil.
4. Conclusões
A primeira repreensão que encontramos sobre a documentação distorcida do projeto Apache Ignite acabou sendo justa, mudou um pouco desde 2016. Não é fácil para um iniciante criar um protótipo funcional com base em um site e / ou repositório.
Como resultado do trabalho realizado, parecia que a Implantação Zero funciona, mas apenas no nível do sistema. Algo assim: BinaryObject é usado para ensinar os nós do cluster remoto a trabalhar com classes personalizadas; Implantação Zero - Mecanismo Interno
Apache Ignite-se e distribui objetos do sistema pelo cluster.
Espero que minha experiência seja útil para novos usuários do Apache Ignite.