Implementación de Apache Ignite Zero: ¿Realmente cero?

Somos o departamento de desenvolvemento tecnolóxico dunha rede de venda polo miúdo. Un día, a dirección fixouse a tarefa de acelerar os cálculos a gran escala mediante o uso de Apache Ignite xunto con MSSQL e mostrou un sitio web con fermosas ilustracións e exemplos de código Java. Gustoume inmediatamente o sitio Implementación cero, cuxa descrición promete milagres: non tes que implementar manualmente o teu código Java ou Scala en cada nodo da grella e volver implantalo cada vez que cambie. A medida que avanzaba o traballo, resultou que Zero Deployment ten usos específicos, cuxas características quero compartir. Debaixo do corte hai pensamentos e detalles de implementación.

1. Enunciado do problema

A esencia do problema é a seguinte. Hai un directorio de puntos de venda de SalesPoint e un directorio de produtos Sku (Unidade de Mantemento de Stocks). O punto de venda ten un atributo "Tipo de tenda" cos valores "pequeno" e "grande". Conéctase un surtido (lista de produtos do punto de venda) a cada punto de venda (cargado desde o DBMS) e ofrécese información de que a partir da data especificada o produto especificado
excluídos do surtido ou engadidos ao surtido.

É necesario organizar unha caché particionada de puntos de venda e almacenar nela información sobre produtos conectados cun mes de antelación. A compatibilidade co sistema de combate require que o nodo cliente Ignite cargue datos, calcule un agregado do formulario (tipo de tenda, código de produto, día, número_de_puntos_de_vendas) e cárgueo de novo no DBMS.

2. Estudo da literatura

Aínda non teño experiencia, así que empezo a bailar dende o fogón. É dicir, a partir dunha revisión das publicacións.

Artigo 2016 Presentación de Apache Ignite: Primeiros pasos contén unha ligazón á documentación do proxecto Apache Ignite e ao mesmo tempo un reproche á vaguedade desta documentación. Volveino a ler un par de veces, a claridade non chega. Remítome ao tutorial oficial comezandoQue
promete con optimismo "Estarás en marcha nun santiamén!" Estou descubrindo a configuración da variable de ambiente, vendo dous vídeos de Apache Ignite Essentials, pero non foron moi útiles para a miña tarefa específica. Lanzo con éxito Ignite desde a liña de comandos co ficheiro estándar "example-ignite.xml", construíndo a primeira aplicación Aplicación de computación usando Maven. A aplicación funciona e usa Zero Deployment, que beleza!

Leo máis, e alí o exemplo usa inmediatamente affinityKey (creado anteriormente mediante unha consulta SQL) e incluso usa o misterioso BinaryObject:

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

lin un pouco: formato binario - algo así como reflexión, acceder aos campos dun obxecto polo nome. Pode ler o valor dun campo sen deserializar completamente o obxecto (aforrando memoria). Pero por que se usa BinaryObject en lugar de Person, xa que hai Zero Deployment? Por que IgniteCache transferido a IgniteCache ? Aínda non está claro.

Estou refacendo a aplicación Compute para adaptala ao meu caso. A clave principal do directorio de puntos de venda en MSSQL defínese como [id] [int] NON NULL, creo unha caché por analoxía

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

Na configuración xml indico que a caché está particionada

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

A partición por punto de venda supón que o agregado necesario se construirá en cada nodo do clúster para os rexistros salesPointCache dispoñibles alí, despois do cal o nodo cliente realizará a suma final.

Estou lendo o tutorial Aplicación First Ignite Compute, fágoo por analoxía. En cada nodo do clúster executo IgniteRunnable(), algo así:

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

Engado a lóxica de agregación e carga e executo nun conxunto de datos de proba. Todo funciona localmente no servidor de desenvolvemento.

Lanzo dous servidores de proba CentOs, especifico os enderezos IP en default-config.xml, executo en cada un.

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

Os dous nodos Ignite están en execución e poden verse. Especifico os enderezos necesarios na configuración xml da aplicación cliente, comeza, engade un terceiro nodo á topoloxía e inmediatamente hai dous nodos de novo. O rexistro mostra "ClassNotFoundException: model.SalesPoint" na liña

SalesPoint sp=salesPointCache.get(spId);

StackOverflow di que o motivo do erro é que non hai unha clase SalesPoint personalizada nos servidores CentOs. Chegamos. Que tal "non tes que implementar manualmente o teu código Java en cada nodo" e así por diante? Ou "o teu código Java" non é sobre SalesPoint?

Probablemente perdín algo: comezo a buscar de novo, a ler e a buscar de novo. Despois dun tempo, teño a sensación de que lin todo sobre o tema, xa non hai nada novo. Mentres buscaba, atopei algúns comentarios interesantes.

Valentín Kulichenko, Arquitecto principal en GridGain Systems, responder en 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ón con autoridade: Denis Magda, Director de xestión de produtos, GridGain Systems.

Artigo sobre Habré sobre microservizos fai referencia a tres artigos de Denis Magda: Microservizos Parte I, Microservizos Parte II, Microservizos Parte III 2016-2017. No segundo artigo, Denis suxire iniciar un nodo de clúster a través de MaintenanceServiceNodeStartup.jar. Tamén pode usar o lanzamento coa configuración xml e a liña de comandos, pero entón cómpre poñer manualmente clases personalizadas en cada nodo do clúster despregado:

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 feito, iso é todo. Aquí resulta, por que, este misterioso formato binario!

3.SingleJar

Denis ocupou o primeiro lugar na miña valoración persoal, en mi humilde opinión o titorial máis útil de todos os dispoñibles. No seu Exemplo de microservizos Github contén un exemplo completamente preparado de configuración de nodos de clúster, que se compila sen ningunha ocupación adicional.

Fágoo do mesmo xeito e consigo un único ficheiro jar que inicia "nodo de datos" ou "nodo cliente" dependendo do argumento da liña de comandos. A montaxe comeza e funciona. O despregamento cero foi derrotado.

A transición de megabytes de datos de proba a decenas de gigabytes de datos de combate mostrou que o formato binario existe por un motivo. Era necesario optimizar o consumo de memoria nos nodos, e aquí é onde BinaryObject resultou ser moi útil.

4. Conclusións

O primeiro reproche que se atopou sobre a vaguedade da documentación do proxecto Apache Ignite resultou ser xusto; pouco cambiou desde 2016. Non é fácil para un principiante montar un prototipo funcional baseado nun sitio web e/ou repositorio.

A partir dos resultados do traballo realizado, a impresión foi que Zero Deployment funciona, pero só a nivel de sistema. Algo así: BinaryObject úsase para ensinar aos nodos de clúster remotos a traballar con clases personalizadas; Implementación cero: mecanismo interno
Apache Ignite e distribúe obxectos do sistema por todo o clúster.

Espero que a miña experiencia sexa útil para os novos usuarios de Apache Ignite.

Fonte: www.habr.com