Somos un departamento de desarrollo de tecnología minorista. Una vez, la administración estableció la tarea de acelerar los cálculos volumétricos utilizando Apache Ignite junto con MSSQL, y mostró un sitio con hermosas ilustraciones y ejemplos de código Java. Al sitio inmediatamente le gustó Zero Deployment , cuya descripción promete milagros: no tiene que implementar manualmente su código Java o Scala en cada nodo de la cuadrícula y volver a implementarlo cada vez que cambie. En el curso del trabajo, resultó que Zero Deployment tiene un uso específico, cuyas características quiero compartir. Bajo el gato reflexiones y detalles de implementación.
1. Declaración del problema
La esencia del problema es la siguiente. Hay un libro de puntos de venta de SalesPoint y una referencia de producto Sku (Stock Keeping Unit). El punto de venta tiene el atributo "Tipo de tienda" con los valores "pequeño" y "grande". Se conecta un surtido (una lista de productos de un punto de venta) (cargado desde un DBMS) a cada punto de venta y se proporciona información de que el producto especificado ha sido fechado
excluido del surtido o agregado al surtido.
Se requiere organizar un caché particionado de puntos de venta y almacenar en él información sobre productos conectados con un mes de anticipación. La compatibilidad con el sistema de combate requiere que el nodo del cliente Ignite descargue datos, calcule un agregado del tipo (tipo de tienda, código de producto, día, número de puntos de venta) y vuelva a cargarlo en el DBMS.
2. El estudio de la literatura.
Todavía no tengo experiencia, así que estoy empezando a bailar desde la estufa. Es decir, con una revisión de publicaciones.
Un artículo de 2016 que presenta Apache Ignite: los primeros pasos contienen un enlace a la documentación del proyecto Apache Ignite y, al mismo tiempo, reprocharlo por el slurring. Lo leí un par de veces, la claridad no llega. En cuanto al tutorial oficial de inicio , que
promete optimistamente "¡Estarás listo y funcionando en un santiamén!". Entiendo la configuración de las variables de entorno, miro dos videos de Apache Ignite Essentials, resultaron no ser muy útiles para mi tarea específica. Lanzo con éxito Ignite desde la línea de comandos con el archivo estándar "example-ignite.xml", construyo la primera aplicación de cómputo usando Maven. La aplicación funciona y utiliza Zero Deployment, ¡qué belleza!
Leí más, y allí el ejemplo usa inmediatamente affinityKey (creado anteriormente a través de una consulta SQL), e incluso se aplica el misterioso BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people = ignite.cache("Person").withKeepBinary();
Leí un poco : el formato binario es un poco reflejo, el acceso a los campos de un objeto por su nombre. Puede leer el valor de un campo sin deserializar completamente el objeto (guardar memoria). Pero, ¿por qué se usa BinaryObject en lugar de Person, porque hay Zero Deployment? ¿Por qué se traduce IgniteCache <Key, Person> en IgniteCache <BinaryObject, BinaryObject>? Aún no está claro.
Rehago Compute Application a mi caso. La clave principal del directorio de punto de venta en MSSQL se define como [id] [int] NOT NULL, creo un caché por analogía
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")
En xml-config indico que el caché está particionado
<bean class="org.apache.ignite.configuration.CacheConfiguration"> <property name="name" value="spCache"/> <property name="cacheMode" value="PARTITIONED"/> </bean>
El particionamiento por puntos de venta supone que el agregado requerido se construirá en cada nodo del clúster para los registros de salesPointCache disponibles allí, después de lo cual el nodo del cliente realizará la suma final.
Leí el tutorial de la primera aplicación de cómputo de encendido, lo hago por analogía. En cada nodo del clúster ejecuto IgniteRunnable (), algo como esto:
@Override public void run() { SalesPoint sp=salesPointCache.get(spId); sp.calculateSalesPointCount(); .. }
Agrego la lógica de agregación y carga, ejecuto un conjunto de datos de prueba. Localmente, todo funciona en el servidor de desarrollo.
Lanzo dos servidores de prueba CentOs, especifico direcciones IP en default-config.xml, ejecuto en cada
./bin/ignite.sh config/default-config.xml
Ambos nodos de encendido se inician y se ven. Especifico las direcciones necesarias en la configuración xml de la aplicación cliente, se inicia, agrega un tercer nodo a la topología e inmediatamente hay dos nodos nuevamente. El registro dice "ClassNotFoundException: model.SalesPoint" en la línea
SalesPoint sp=salesPointCache.get(spId);
StackOverflow dice que la causa del error es que los servidores CentOs no tienen una clase personalizada de SalesPoint. Llegado Entonces, ¿cómo no tiene que implementar manualmente su código Java en cada nodo y en adelante? ¿O su código Java no se trata de SalesPoint?
Probablemente me perdí algo, nuevamente comienzo a buscar, leer y buscar nuevamente. Con el tiempo, siento que leo todo sobre el tema, no hay nada nuevo. Mientras buscaba, encontré algunos comentarios interesantes.
Valentin Kulichenko , arquitecto jefe de GridGain Systems, respuesta a 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.
Otra opinión autorizada: Denis Magda , Director de gestión de productos, GridGain Systems.
Un artículo sobre Habré sobre microservicios se refiere a tres artículos de Denis Magda: Microservicios Parte I , Microservicios Parte II , Microservicios Parte III 2016-2017. En un segundo artículo, Denis sugiere iniciar un nodo de clúster a través de MaintenanceServiceNodeStartup.jar. También puede usar el inicio con la configuración xml y la línea de comando, pero luego debe colocar manualmente clases personalizadas en cada nodo del clúster desplegado:
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 hecho, eso es todo. ¡Aquí resulta, por qué, este misterioso formato binario!
3. SingleJar
Denis tomó el primer lugar en mi calificación personal, en mi humilde opinión el tutorial más útil de todos los disponibles. Su github MicroServicesExample contiene un ejemplo completamente listo de configuración de nodos de clúster, que se compila sin ningún tipo de sentadillas adicionales.
Lo hago a imagen y semejanza, obtengo un solo archivo jar que ejecuta el "nodo de datos" o "nodo de cliente" dependiendo del argumento de la línea de comando. El ensamblaje comienza y se ejecuta. Zero Deployment es derrotado.
La transición de megabytes de datos de prueba a decenas de gigabytes de datos de combate mostró que el formato binario existe por una buena razón. Era necesario optimizar el consumo de memoria en los nodos, y aquí BinaryObject fue muy útil.
4. Conclusiones
La primera reprimenda que encontramos sobre la documentación borrosa del proyecto Apache Ignite resultó ser justa, ha cambiado un poco desde 2016. No es fácil para un principiante construir un prototipo funcional basado en un sitio y / o repositorio.
Como resultado del trabajo realizado, parecía que Zero Deployment funciona, pero solo a nivel del sistema. Algo como esto: BinaryObject se usa para enseñar a los nodos remotos del clúster cómo trabajar con clases personalizadas; Implementación cero: mecanismo interno
Apache se enciende y distribuye objetos del sistema a través del clúster.
Espero que mi experiencia sea útil para los nuevos usuarios de Apache Ignite.