Nous sommes un département de développement technologique de vente au détail. Une fois, la direction a défini la tâche d'accélérer les calculs volumétriques en utilisant Apache Ignite en conjonction avec MSSQL, et a montré un site avec de belles illustrations et des exemples de code Java. Le site a immédiatement aimé Zero Deployment , dont la description promet des miracles: vous n'avez pas à déployer manuellement votre code Java ou Scala sur chaque nœud de la grille et à le redéployer à chaque fois qu'il change. Au cours du travail, il s'est avéré que Zero Deployment a un usage spécifique, dont je souhaite partager les fonctionnalités. Sous les réflexions de chat et les détails de mise en œuvre.
1. Énoncé du problème
L'essence du problème est la suivante. Il existe un annuaire des points de vente pour SalesPoint et un annuaire des produits Sku (Stock Keeping Unit). Le point de vente a l'attribut "Type de magasin" avec les valeurs "petit" et "grand". Un assortiment (une liste de produits d'un point de vente) est connecté (chargé à partir d'un SGBD) à chaque point de vente et des informations sont fournies indiquant que le produit spécifié a été daté
exclus de l'assortiment ou ajoutés à l'assortiment.
Il est nécessaire d'organiser un cache partitionné des points de vente et d'y stocker des informations sur les biens connectés pendant un mois à l'avance. La compatibilité avec le système de combat nécessite que le nœud client Ignite télécharge les données, calcule un agrégat du type (type de magasin, code produit, jour, nombre de points de vente) et les télécharge à nouveau dans le SGBD.
2. L'étude de la littérature
Aucune expérience pour le moment, donc je commence à danser du poêle. Autrement dit, avec un examen des publications.
Un article de 2016 Présentation d'Apache Ignite: Les premières étapes fournissent un lien vers la documentation du projet Apache Ignite et en même temps lui reprochent de créer un flou. Je l'ai lu plusieurs fois, la clarté ne vient pas. Passant au didacticiel de démarrage officiel, qui
promet avec optimisme "Vous serez opérationnel en un tournemain!". Je comprends les paramètres des variables d'environnement, regarde deux vidéos Apache Ignite Essentials, elles se sont avérées peu utiles pour ma tâche spécifique. Je lance avec succès Ignite à partir de la ligne de commande avec le fichier standard "example-ignite.xml", je crée la première application de calcul à l' aide de Maven. L'application fonctionne et utilise Zero Deployment, quelle beauté!
J'ai lu plus loin, et là l'exemple utilise immédiatement affinityKey (créé plus tôt via une requête SQL), et même le mystérieux BinaryObject est appliqué:
IgniteCache<BinaryObject, BinaryObject> people = ignite.cache("Person").withKeepBinary();
Je lis un peu : le format binaire est un peu une réflexion, l'accès aux champs d'un objet par son nom. Il peut lire la valeur d'un champ sans désérialiser complètement l'objet (sauvegarde de la mémoire). Mais pourquoi BinaryObject est-il utilisé à la place de Person, car il n'y a aucun déploiement? Pourquoi IgniteCache <Clé, Personne> est-il traduit en IgniteCache <BinaryObject, BinaryObject>? Ce n'est pas encore clair.
Je refais l'application Compute à mon cas. La clé primaire du répertoire de point de vente dans MSSQL est définie comme [id] [int] NOT NULL, je crée un cache par analogie
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")
Dans la configuration xml, j'indique que le cache est partitionné
<bean class="org.apache.ignite.configuration.CacheConfiguration"> <property name="name" value="spCache"/> <property name="cacheMode" value="PARTITIONED"/> </bean>
Le partitionnement par points de vente suppose que l'agrégat requis sera construit sur chaque nœud du cluster pour les enregistrements salesPointCache, après quoi le nœud client effectuera la sommation finale.
J'ai lu le tutoriel First Ignite Compute Application , je le fais par analogie. Sur chaque nœud du cluster, je lance IgniteRunnable (), quelque chose comme ceci:
@Override public void run() { SalesPoint sp=salesPointCache.get(spId); sp.calculateSalesPointCount(); .. }
J'ajoute une logique d'agrégation et de téléchargement, exécutée sur un ensemble de données de test. Localement, tout fonctionne sur le serveur de développement.
Je lance deux serveurs de test CentOs, spécifie les adresses IP dans default-config.xml, exécute sur chaque
./bin/ignite.sh config/default-config.xml
Les deux nœuds Ignite démarrent et se voient. Je spécifie les adresses nécessaires dans la configuration xml de l'application cliente, elle démarre, ajoute un troisième nœud à la topologie et immédiatement il y a à nouveau deux nœuds. Le journal indique "ClassNotFoundException: model.SalesPoint" dans la ligne
SalesPoint sp=salesPointCache.get(spId);
StackOverflow indique que la cause de l'erreur est que les serveurs CentOs n'ont pas de classe SalesPoint personnalisée. Arrivé. Alors, comment n'avez-vous pas à déployer manuellement votre code Java sur chaque nœud et au-delà ? Ou votre code Java ne concerne-t-il pas SalesPoint?
J'ai probablement raté quelque chose - je recommence à chercher, à lire et à chercher. Au fil du temps, on a l'impression que j'ai tout lu sur le sujet, il n'y a rien de nouveau. En cherchant, j'ai trouvé des commentaires intéressants.
Valentin Kulichenko , architecte en chef chez GridGain Systems, réponse à StackOverflow, avril 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.
Autre avis faisant autorité: Denis Magda , directeur de la gestion des produits, GridGain Systems.
Un article sur Habré sur les microservices fait référence à trois articles de Denis Magda: Microservices Part I , Microservices Part II , Microservices Part III 2016-2017. Dans un deuxième article, Denis suggère de démarrer un nœud de cluster via MaintenanceServiceNodeStartup.jar. Vous pouvez également utiliser le lancement avec la configuration xml et la ligne de commande, mais vous devez ensuite placer manuellement des classes personnalisées sur chaque nœud de cluster déployé:
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.
En effet, c'est tout. Ici, il s'avère, pourquoi, ce mystérieux format binaire!
3. SingleJar
Denis a pris la première place dans ma note personnelle, à mon humble avis le tutoriel le plus utile de tous disponibles. Son github MicroServicesExample contient un exemple complètement prêt à l'emploi de configuration de nœuds de cluster, qui se compile sans squats supplémentaires.
Je le fais à l'image et à la ressemblance, j'obtiens un seul fichier jar qui exécute le "nœud de données" ou le "nœud client" selon l'argument de la ligne de commande. L'assemblage démarre et s'exécute. Le déploiement zéro est vaincu.
Le passage de mégaoctets de données de test à des dizaines de gigaoctets de données de combat a montré que le format binaire existe pour une bonne raison. Il était nécessaire d'optimiser la consommation de mémoire sur les nœuds, et ici BinaryObject était très utile.
4. Conclusions
Le premier reproche que nous avons rencontré avec la documentation floue du projet Apache Ignite s'est avéré juste, il a un peu changé depuis 2016. Il n'est pas facile pour un débutant de construire un prototype fonctionnel basé sur un site et / ou un référentiel.
À la suite du travail effectué, il semblait que Zero Deployment fonctionne, mais uniquement au niveau du système. Quelque chose comme ceci: BinaryObject est utilisé pour enseigner aux nœuds de cluster distants comment travailler avec des classes personnalisées; Déploiement zéro - Mécanisme interne
Apache s'enflamme et distribue les objets système à travers le cluster.
J'espère que mon expérience sera utile aux nouveaux utilisateurs d'Apache Ignite.