Fermer

mai 7, 2020

De nombreuses mains font travailler la lumière – Architecture du connecteur de recherche de poignée de main


Dans notre premier article nous avons discuté de la nécessité de s'éloigner de l'approche de solution d'application autonome pour rechercher des connecteurs. Dans cet article, nous décrirons l'architecture Handshake à un niveau élevé. Nous avons choisi de évoluer vers une architecture de microservices pour plusieurs raisons :

  • Moins de ressources
  • Planification, réutilisation des composants et maintenance
  • Paysage technologique plus récent et en pleine croissance
  • Cloud et gestion locale sont presque interchangeables
  • Plus facile à gérer pour les utilisateurs (point de contact unique et gestion pour de nombreux threads)
  • Beaucoup plus de flexibilité pour le déploiement et les flux de travail dynamiques
  • Meilleure gestion des protocoles REST et SOAP

Récupération des composants Parlez entre vous

La prise de contact peut être exécutée en tant que conteneur autonome ou déployée sur un serveur Wildfly existant. Il implémente un cadre de composants enfichables utilisant Quartz, ActiveMQ Artemis, Mongo DB et Derby. Le package est fourni avec des interfaces source et cible, des classes de transformation (classes java configurables qui manipulent du contenu ou des métadonnées) et un moteur de licence. Toutes les interfaces peuvent être étendues, mais disposent des fonctionnalités les plus élémentaires nécessaires pour générer des objets standard à traiter, se connecter aux systèmes requis et afficher dans l'interface utilisateur.

L'application frontale Angular est déployée séparément (généralement dans le même domaine / pare-feu). L'interface utilisateur elle-même peut communiquer avec n'importe quel nombre de serveurs et processeurs Wildfly. C'est un choix qui maximise notre capacité à faire évoluer et à étendre le cadre.

Des processeurs supplémentaires peuvent vivre sur du matériel source partagé sans aucune perte de performances. L'objectif final ici est de diffuser n'importe quel contenu sur les moteurs de recherche. Notre solution devait être suffisamment flexible pour s'interfacer avec une multitude de protocoles de stockage et de communication, sans impact sur les performances. En règle générale, nous déployons un serveur d'exécution Wildfly par serveur source, mais celui-ci est flexible et est défini par l'architecture du client.

L'application peut être mise en package et déployée en tant que .war géré localement ou en tant que conteneur docké (actuellement ECS uniquement, EKS est sur la feuille de route.)

Architecture des microservices

Connecteurs en tant que microservices

Exemple de deux instances de connecteur: le connecteur 1 a de nombreuses files d'attente, le connecteur 2 n'en a que 2, envoyant du contenu directement au moteur de recherche [19659015] Platforms & Technology – A Business Leaders Guide to Key Trends in Cloud  » width= »300″ height= »232″ class= »alignnone size-medium wp-image-273762″ data-recalc-dims= »1″/>

Handshake lit et envoie des données via des files d'attente JMS (ActiveMQ) pour échelonner le traitement et suivre le contenu. Les files d'attente, les travaux et les planifications sont des instances de configuration. Ils sont créés et gérés dynamiquement par un service de processeur global (un par processeur). Le processeur planifie les travaux Quartz, envoie des statistiques et des réponses à l'interface utilisateur et achemine le contenu via une instance de connecteur. Il gère également les points de contrôle de traversée, le hachage et la vérification de suppression.

Chaque instance de connecteur est un seul thread, bien que la prise en charge des déploiements multi-nœuds et du threading simultané pour une instance soit sur la feuille de route. Le nombre d'instances de connecteur (et de threads) n'est limité que par le matériel mis à disposition. Dans de futurs articles, nous discuterons des exigences de performances et du dimensionnement des instances de prise de contact.

Conception et développement d'interfaces

Lorsque nous concevons une nouvelle source (application pour extraire le contenu) ou cible (application envoyer du contenu à), nous identifions le protocole de connexion (généralement une API REST ou une connexion à une base de données), qu'il s'agisse de PUSH ou PULL, des méthodes de spécification de sous-ensembles de données et des détails de la jonction de contenu, de métadonnées et d'autorisations. Le travail devient alors la mise en correspondance de ces protocoles avec notre API et les transformations de base nécessaires pour normaliser le contenu pour la consommation ou la transmission.

Une fois que ces détails ont été codifiés et testés, ils sont emballés et ajoutés au projet ou téléchargé via l'interface de gestion. Ils peuvent être appelés en tant que composants dans les instances de connecteur, utilisés autant de fois que le cas d'utilisation l'exige.

Une configuration mineure pour l'instance de connecteur fournit à Handshake tout ce dont il a besoin pour faire tourner un thread, lire et standardiser le contenu et l'écrire. à une file d'attente JMS. Puisque Handshake a standardisé l'objet, la source et les cibles peuvent être facilement échangées ou modifiées.

Et ensuite

Nos prochains articles parleront de certains des composants sous-jacents de notre produit, des considérations de conception qui nous ont amenés

À propos de l'auteur

Zach est analyste technique et chef de projet chez Perficient depuis 9 ans, spécialisé dans la recherche, la gestion de contenu d'entreprise, et technologies de gouvernance du cycle de vie de l'information. Au cours des dernières années, il est devenu chef de produit pour les technologies Poignée de main, NERO et recherche de base de Perficient.

Plus de contenu de cet auteur

Le meilleur outil 2023 pour ta croissance Instagram !



Source link

Revenir vers le haut