FR3069669A1 - Un systeme de communication et un procede d'acces et de deploiement des microservices ephemeres sur une plateforme heterogene - Google Patents
Un systeme de communication et un procede d'acces et de deploiement des microservices ephemeres sur une plateforme heterogene Download PDFInfo
- Publication number
- FR3069669A1 FR3069669A1 FR1757040A FR1757040A FR3069669A1 FR 3069669 A1 FR3069669 A1 FR 3069669A1 FR 1757040 A FR1757040 A FR 1757040A FR 1757040 A FR1757040 A FR 1757040A FR 3069669 A1 FR3069669 A1 FR 3069669A1
- Authority
- FR
- France
- Prior art keywords
- execution
- microservices
- microservice
- node
- host server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 74
- 238000000034 method Methods 0.000 title claims description 39
- 230000009471 action Effects 0.000 claims description 11
- 238000004422 calculation algorithm Methods 0.000 claims description 10
- 238000011161 development Methods 0.000 claims description 5
- 238000000151 deposition Methods 0.000 claims description 4
- 230000008859 change Effects 0.000 claims description 3
- 230000004807 localization Effects 0.000 claims 2
- 230000003213 activating effect Effects 0.000 claims 1
- 238000004590 computer program Methods 0.000 abstract description 4
- 230000008901 benefit Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- XEEYBQQBJWHFJM-UHFFFAOYSA-N Iron Chemical compound [Fe] XEEYBQQBJWHFJM-UHFFFAOYSA-N 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000008021 deposition Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 229910052742 iron Inorganic materials 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/32—Operator till task planning
- G05B2219/32136—Web service oriented architecture for manufacturing and automation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
Abstract
La présente invention concerne un système (1) de communication comprenant un ou plusieurs nœuds (2) d'exécution apte à exécuter un ou plusieurs microservices (5), un dispositif informatique, dit « serveur hôte » (3), comportant plusieurs routeurs (30) constituant une interface intermédiaire de communication entre chaque nœud (2) d'exécution et l'extérieur du système (1) de communication, une plateforme (4) informatique hétérogène, constituée d'un ensemble (40) de matériel et logiciel ou code exécutable pour l'accès et le déploiement des microservices (5) sur le système dans un environnement (J) d'exécution Java (runtime java) sur le serveur hôte (3) et les nœuds (2) d'exécution permettant l'exécution des programmes informatiques basés sur le langage Java; le système (1) de communication permet la création de microservices (5) éphémères par l'utilisation d'un système (6) clef/valeur mémorisé dans un cache (8) mémoire distribué à chaque création en référenciant chaque microservices (5) par des noms de fichier déposés dans le système par un développeur (10) et utilisant un protocole (T) d'échange TCP asynchrone échangeant des notifications contenant des métadatas (M) entre le serveur hôte (3) et chaque nœud (2) d'exécution ; et en ce que chaque nœud (2) mémorise des fichiers (50) d'exécution du ou des microservices (5) comportant l'accès au système (1) par au moins un des deux point d'entrée soit au serveur hôte (3) soit au nœud (2) d'exécution et au moins un chargeur de classe (7) assurant le déploiement des services associés aux microservices (5) qui sont intégrés dans le nœud (2) d'exécution.
Description
La présente invention concerne un système (1) de communication comprenant un ou plusieurs nœuds (2) d'exécution apte à exécuter un ou plusieurs microservices (5), un dispositif informatique, dit « serveur hôte » (3), comportant plusieurs routeurs (30) constituant une interface intermédiaire de communication entre chaque nœud (2) d'exécution et l'extérieur du système (1) de communication, une plateforme (4) informatique hétérogène, constituée d'un ensemble (40) de matériel et logiciel ou code exécutable pour l'accès et le déploiement des microservices (5) sur le système dans un environnement (J) d'exécution Java (runtime java) sur le serveur hôte (3) et les nœuds (2) d'exécution permettant l'exécution des programmes informatiques basés sur le langage Java; le système (1) de communication permet la création de microservices (5) éphémères par l'utilisation d'un système (6) clef/valeur mémorisé dans un cache (8) mémoire distribué à chaque création en référenciant chaque microservices (5) par des noms de fichier déposés dans le système par un développeur (10) et utilisant un protocole (T) d'échange TC P asynchrone échangeant des notifications contenant des métadatas (M) entre le serveur hôte (3) et chaque nœud (2) d'exécution; et en ce que chaque nœud (2) mémorise des fichiers (50) d'exécution du ou des microservices (5) comportant l'accès au système (1) par au moins un des deux point d'entrée soit au serveur hôte (3) soit au nœud (2) d'exécution et au moins un chargeur de classe (7) assurant le déploiement des services associés aux microservices (5) qui sont intégrés dans le nœud (2) d'exécution.
Un système de communication et un procédé d’accès et de déploiement des microservices éphémères sur une plateforme hétérogène
DOMAINE TECHNIQUE DE L’INVENTION
La présente invention concerne le domaine des systèmes de communication et plus particulièrement l’amélioration de l’accès et du déploiement des microservices, basés sur le langage Java, sur une plateforme hétérogène. La présente invention concerne également un procédé d’accès et de déploiement des microservices sur une plateforme hétérogène par ce système de communication.
ARRIERE-PLAN TECHNOLOGIQUE DE L’INVENTION
Un problème dans le domaine des systèmes de communication concerne la fiabilité du système sur l’accès et le déploiement des microservices éphémères sur une plateforme informatique hétérogène.
Au début de l'informatique, la communication entre machines informatiques nécessitait une connaissance approfondie des protocoles réseau et du matériel réseau. La programmation orientée objet (POO consistant à la définition et l’interaction de briques logicielles ou d’application informatique appelées objets) a permis le développement des architectures d’un environnement informatique ou des réseaux, dites distribuées, en fournissant des bibliothèques (ou des collections de routines encapsulant des séquences d’instructions) de haut-niveau pour faire communiquer, entre eux, des objets répartis sur des machines différentes de sorte à alléger le travail des programmeurs et d’optimiser la disponibilité des ressources sur les machines d’un réseau. Les microservices peuvent être définis comme des bibliothèques ou modules de code et peuvent constituer une unité fonctionnelle comprenant un point d’entrée connu et formant un assemblage, par exemple, avec un système d’exploitation, une plateforme informatique, un framework (terme anglophone désignant une structure logicielle) ou un environnement d’exécution. Chaque microservice est un processus autonome et indépendant qui peut ne pas dépendre d’autres microservices. Avec l’évolution de l’internet des objets (loT) et de la communication machine-à-machine (M2M), l’utilisation des microservices permet aux développeurs ou programmeurs et opérateurs de développer, de déployer et de gérer des applications auto-adaptatives, par exemple, sur une plateforme de calcul qui répond aux besoins de nombreux scénarios d’application, en utilisant un langage (par exemple du Java) pris en charge par la plateforme de calcul et en utilisant l’environnement d’exécution standard et les ressources fournies par cette plateforme de calcul. Ainsi, au lieu de lancer plusieurs instances du serveur d’application, on peut faire monter en charge un microservice donné à la demande. Ceci valorise mieux l’infrastructure sous-jacente d’un service informatique qui ne nécessite désormais plus de provisionner de nouvelles machines virtuelles, il suffit de provisionner de nouvelles instances de microservices sur les machines existantes.
Il est connu de l’art antérieur, des plateformes de calcul commerciales généralement payantes (telles qu’Amazon Lambda, Azuré functions, Google Functions ou Iron.io) ou une seule solution gratuite (OpenWhisk). Par exemple, Amazon Lambda est un service informatique qui permet d’exécuter un code sans nécessiter le provisionnement ou la gestion des serveurs. Il exécute le code uniquement lorsque cela est nécessaire et s’adapte automatiquement. Le temps de calcul requis pour exécuter le code et les requêtes distribuées sont facturés à l’usage par ce service et l’utilisateur ne peut se connecter aux instances de calcul ni personnaliser le système d’exploitation ou l’environnement d’exécution, car ce service informatique effectue les activités opérationnelles et administratives à la place de l’utilisateur (notamment le déploiement du code, l’adaptation de la capacité, la vérification de l’état des instances ou l’application des correctifs de sécurité). Ces solutions sont généralement payantes, ou nécessitent une plateforme de base qui est complexe à mettre en œuvre avec des composants non interchangeables. De plus, les protocoles d’accès depuis internet sont peu diversifiés.
Il également connu de l’art antérieur un système et un procédé de communication améliorant l’accès aux services électroniques disponibles via un réseau de télécommunication, comme par exemple décrit dans le document US2003154265. Ce document qui traite du déploiement de services temporaires sur une plateforme de télécommunication fait mention de l’utilisation d’un système cache dans lequel les services sont archivés sous un format de fichier Jar puis chargé par un chargeur de fichier Jar. Le procédé comprend la construction d’un paquet électronique, sous le format Jar, comportant le code et les données nécessaires à l’exécution du service et les informations de contrôle du cache ; ainsi que la transmission du paquet à un dispositif de mise en cache pour mettre en cache le service par rapport à l’information de contrôle de cache. Cependant, ce système de communication ne permet pas de référencier les services temporaires de façon à faciliter l’identification et le déploiement des services sur demande d’une requête. De plus, ce système ne peut être adapté ou mis en place pour développer et déployer des microservices éphémères, notamment du fait que les microservices ne peuvent être chargés ou rechargés sans interruption de service et sans provoquer d’impact sur les ressources utilisés.
Dans ce contexte, il est intéressant de proposer une solution permettant de pallier certains inconvénients de l’art antérieur en facilitant et améliorant l’accès et le déploiement des microservices éphémères sur une plateforme informatique hétérogène.
DESCRIPTION GENERALE DE L’INVENTION
La présente invention a pour but de pallier certains inconvénients de l'art antérieur en proposant un nouveau système de communication, facilitant et fiabilisant l’accès et le déploiement de microservices éphémères sur une plateforme informatique hétérogène.
A cet effet, la présente invention concerne un système de communication comprenant un ou plusieurs nœuds d’exécution apte à exécuter un ou plusieurs microservices, un dispositif informatique, dit « serveur hôte » (ou « hub >> en terme anglophone), comportant plusieurs routeurs constituant une interface intermédiaire de communication entre chaque nœud d’exécution et l’extérieur du système de communication, une plateforme informatique hétérogène, constituée d’un ensemble de matériel et logiciel ou code exécutable pour l’accès et le déploiement des microservices sur le système dans un environnement d’exécution Java (ou « runtime java >> en terme anglophone) sur le serveur hôte et les nœuds d’exécution permettant l’exécution des programmes informatiques basés sur le langage Java ; le système de communication permet la création de microservices éphémères par l’utilisation d’un système clef/valeur mémorisé dans un cache mémoire distribué à chaque création en référenciant chaque microservices par des noms de fichier déposés dans le système par le développeur et utilisant un protocole d’échange TCP (désignant un « protocole de contrôle de transmissions ») asynchrone échangeant des notifications contenant des métadatas entre le serveur hôte et chaque nœud d’exécution ; et en ce que chaque nœud mémorise des fichiers d’exécution du ou des microservices comportant l’accès au système par au moins un des deux point d’entrée soit au serveur hôte soit au nœud d’exécution et au moins un chargeur de classe assurant le déploiement des services associés aux microservices qui sont intégrés dans le nœud d’exécution.
Selon une autre particularité, les échanges d’information entre le serveur hôte et les nœuds d’exécution utilisent des données de type métadatas comprenant un ou plusieurs des éléments suivants : un alias du microservice (appelé clé), un chemin de localisation d’une méthode particulière dans le microservice, une action associée au chemin de localisation, un code retour d’exécution du microservice et un type de contenu d’exécution du microservice.
Selon une autre particularité, un outil de développement de microservices constitue une interface développeur et un outil d’envoi dans le protocole utilisé entre le microservice et le serveur hôte.
Selon une autre particularité, chaque nœud d’exécution comprend en outre des moyens informatiques de gestion des microservices, des moyens informatiques de lecture et d’écriture des fichiers d’exécution disposés dans une unité distribuée de stockage du système, et un système de publication et souscription de message lorsqu’un microservice est déposé ou un alias est modifié par le développeur sur le système.
Selon une autre particularité, chaque nœud d’exécution est apte à exécuter un algorithme prédéterminé dédié à la sélection d’un ou plusieurs nœuds d’exécution du microservice en déterminant un score (ou valeur) puis en mémorisant l’adresse ou l’alias du microservice et ce score (pouvant être défini par le système clé/valeur) dans le cache mémoire distribué si le score est plus pertinent que le précédent.
Selon une autre particularité, l’algorithme prédéterminé est prévu pour lancer un timeout d’inactivité (terme anglophone désignant un délai d’inactivité de charge) à chaque détermination de score pour que le serveur hôte puisse réutiliser le même nœud d’exécution tant que le microservice est inexploité ou qu’un timeout d’inactivité est levé.
Selon une autre particularité, une fois le nœud d’exécution choisi, le nœud appelé par le système charge le microservice dans un nouveau chargeur de classe (ou en terme anglophone « classloader »), le système référencie ce chargeur de classe dans une HashMap (terme anglophone d’un exemple de système clef/valeur, c'est-à-dire qu’il s’agit d’une collection ou un dictionnaire associant une clé à une valeur) du cache mémoire distribué en fonction de l’alias utilisé dans le message d’échange standardisé.
Selon une autre particularité, chaque nœud d’exécution sélectionné est apte à remonter des données sous forme de score et d’attribution d’adresse dans un cache mémoire distribué du système de communication attribué à chaque microservices pour que le serveur hôte puisse lire et exploiter ces données.
Selon une autre particularité, les routeurs du serveur hôte utilisent des applications basées sur Java et Netty pour assurer des communications multiprotocoles vers l’extérieur du système et des échanges asynchrone en protocole TCP vers les noeuds d’exécution du système.
Selon une autre particularité, le système mémorise les microservices au format Jar ou Javascript et le système désarchive les fichiers au format Jar en classes d’utilisation ou d’exécution pour les rendre accessible au chargeur de classe de l’environnement d’exécution Java du nœud d’exécution qui charge ces microservices depuis l’unité de stockage distribué en fonction de la demande du serveur hôte (définie par l’alias de service qui permet d’identifier le microservice à charger), le chemin de la requête entrante permettant d’identifier la méthode (java ou javascript) à appeler dans le microservice chargé, et les autres formats de fichier sont mémorisés unitairement sur le système clef/valeur pour que l’environnement d’exécution Java puisse lire ou exploiter selon le besoin.
Selon une autre particularité, le système est apte à sélectionner un nœud d’exécution pour qu’il charge un microservice dans un chargeur de classe qui est référencié dans l’unité distribuée de stockage en fonction de l’alias utilisé dans le métadatas d’échange.
Selon une autre particularité, l’utilisation d’un microservice est activée par au moins un code d’accès disposé soit au niveau du service permettant l’accès à toutes les ressources du service, soit au niveau d’une ressource du service permettant l’accès à cette unique ressource, ou par au moins une méthode d’accès prédéfinie par un gestionnaire de sécurité du système de communication.
Selon une autre particularité, le serveur hôte utilise et réutilise le même nœud d’exécution tant que le microservice est inexploité ou qu’un délai d’inactivité de charge du microservice est levé.
Selon une autre particularité, le système clef/valeur et le système de notification sont des systèmes externes au système de communication qui sont intégrés dans un code exécutable du système de communication, ou injectés au moment de l’exécution du système.
La présente invention a également pour autre objet un procédé d’accès et de déploiement fiable, de microservices éphémères sur une plateforme informatique hétérogène.
Ce but est atteint par le procédé d’accès et de déploiement de microservices éphémères sur une plateforme hétérogène, par un système de communication selon une des particularités de la présente invention, comprenant les étapes suivantes :
- dépôt d’un ou plusieurs microservices par le développeur sur un ou plusieurs nœuds d’exécution ;
- référencement des microservices par le nom de fichier déposé sans son extension dans le système clef/valeur ;
- mémorisation des microservices, sous forme de fichier d’exécution de type Jar ou Javascript, par le système clef/valeur dans l’unité distribuée de stockage ;
- désarchivage en classes d’utilisation ou d’exécution des fichiers d’exécution au format Jar par le système clef/valeur pour les rendre accessibles au chargeur de classe de l’environnement d’exécution Java du nœud d’exécution, et le format JavaScript des fichiers d’exécution sont mémorisés unitairement sur le système clef/valeur pour que l’environnement d’exécution Java puisse lire ou exploiter selon le besoin ;
- chargement des classes associées aux microservices par les chargeurs de classe des nœuds d’exécution à charger ;
- déchargement des microservices par les nœuds d’exécution lorsque les microservices sont inexploités ou que le délai d’inactivité de charge du ou des microservices est levé.
Selon une autre particularité, l’étape de déchargement des microservices comprend une sélection par le serveur hôte des nœuds d’exécution du microservice à charger et chaque nœud d’exécution remonte des données sous forme de score et d’adresse d’attribution du microservice dans un cache mémoire distribué du système de communication pour que le serveur hôte puisse lire et exploiter ces données.
Selon une autre particularité, le procédé comprend en outre une étape de création des alias aux microservices par le développeur pour que le système puisse localiser le ou les microservices à déployer.
Selon une autre particularité, lorsque le microservice n’est pas chargé, le système de communication choisit le nœud d’exécution qui charge le microservice dans un nouveau chargeur de classe et le référencie dans l’unité distribuée de stockage du système.
Selon une autre particularité, le rechargement de microservice se fait soit par le dépôt d’un nouveau microservice avec le même nom de fichier d’exécution, soit par changement d’alias.
Selon une autre particularité, le rechargement de microservice entraîne un envoi de message par le système de publication et souscription pour actualiser l’ensemble des actions des nœuds d’exécution du système de communication.
D’autres particularités et avantage de la présente invention sont détaillés dans la description qui suit.
DESCRIPTION DES FIGURES ILLUSTRATIVES
D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels :
- la figure 1 représente un schéma global d’un système de communication selon un mode de réalisation;
- la figure 2 représente un schéma le système de communication avec les différents composants pouvant intervenir à l’accès et au déploiement de microservices éphémères selon un mode de réalisation.
DESCRIPTION DES MODES DE REALISATION PREFERES DE L’INVENTION
L’invention, en référence aux figures 1 et 2, va être maintenant décrite.
La présente invention concerne un système de communication permettant l’accès et le déploiement facile, élastique (c'est-à-dire modulable en fonction des besoins en applications et le plus rapidement possible), automatique et auto-régulable de microservices éphémères, basés sur le langage Java, sur une plateforme informatique hétérogène.
Par exemple comme représenté sur la figure 1, le système (1) de communication comprend :
- au moins un nœud d’exécution (2) supportant l’environnement d’exécution des microservices (5) ;
- au moins un dispositif informatique, dit « serveur hôte >> (3), comprenant un point ou périphérie d’entrée public externe servant à commander le système de communication ou à y envoyer ou récupérer des informations du système de communication par un utilisateur externe ;
- une plateforme (4) informatique hétérogène comprenant un ensemble (40) de matériel et logiciel ou code exécutable pour l’accès et le déploiement des microservices (5) sur le système (1) dans un environnement (J) d’exécution Java disposé à la fois sur le serveur hôte (3) et les nœuds d’exécution (2) pour pouvoir exécuter des programmes informatiques basés sur le langage Java.
Dans certains modes de réalisation, le serveur hôte (3) comprend plusieurs routeurs (30) constituant une interface intermédiaire de communication entre chaque nœud d’exécution (2) et l’extérieur du système (1) de communication, comme représenté par exemple sur les figures 1 et 2. Dans certains modes de réalisation, les routeurs (30) du serveur hôte (3) utilisent des applications basées sur Java et Netty pour assurer des communications multiprotocoles vers l’extérieur du système et des échanges asynchrone en protocole TCP vers les nœuds d’exécution (2) du système (1). Ainsi, plusieurs protocoles d’accès externe (c'est-à-dire via internet) peuvent être gérés par le système (1) grâce à l’utilisation du framework Netty, tels que HTTP(S) (désignant des protocoles de transfert sur internet), MQTT (désignant un protocole de messagerie de la transmission des données télémétrie), Websocket, TCP ou FTP (désignant un protocole de transfert de fichier).
Dans certains modes de réalisation, le système (1) de communication permet la création de microservices (5) éphémères par l’utilisation d’un système clef/valeur (6) mémorisé dans au moins un cache (8) mémoire distribué (par exemple et non limitativement les bases Redis ou Hazelcast) à chaque création en référenciant chaque microservices (5) par des noms de fichier déposés dans le système (1) par un développeur (10) et utilisant un protocole (T) d’échange TCP asynchrone échangeant des notifications contenant des métadatas (M) entre le serveur hôte (3) et chaque nœud d’exécution (2). La communication via le protocole TCP asynchrone permet un gain en performance et en mémoire puisqu’elle limite le nombre de tâche ou fil d’exécution/instruction nécessaire entre le serveur hôte et les nœuds.
Dans certains modes de réalisation, lorsque le développeur (10) dépose un microservice (5) sur le système (1), une sélection d’un ou plusieurs nœuds (2) d’exécution du microservice se fait par un algorithme spécifique qui utilise, par exemple, NativeMemory, MetaSpace, TotalHeap ou CPU (désignant une unité centrale de calcul). L’algorithme, pour chaque nœud (2), détermine ainsi un score (ou une valeur) et mémorise ce score et une adresse d’attribution (clef) ou un alias du microservice dans le cache (8). Cette information (clef, valeur) est mémorisée dans le cache (8) mémoire distribué si le score est plus pertinent que le précédent et le serveur hôte pourra lire cette information et choisir le nœud (2) d’exécution. Le cache mémoire distribué (8) peut être exploité par le serveur hôte (par exemple pour identifier le nœud le moins chargé) et mis à jour par les nœuds d’exécution (par exemple pour pouvoir répartir la charge entre les nœuds faite par l’algorithme).
Dans certains modes de réalisation, les données en entrée du système (1) peuvent être reformatées en un message standard qui est échangeable et modifiable par l’ensemble des microservices (5) et de leurs fonctions exportées mise en œuvre. Ce message contient des métadatas (M) intégré par le serveur hôte (3), tel que par exemple un alias ou identifiant ou clé du microservice pour que le système puisse identifier quel microservice utiliser, un chemin de localisation d’une méthode particulière dans le microservice et une action associée au chemin de localisation ; et/ou par les nœuds d’exécution (2), tels que par exemple un code retour d’exécution du microservice et un type de contenu d’exécution du microservice. Dans le cas du chemin de localisation, par exemple, une méthode « manageUser() » peut être recherché par le chemin « /user ». Dans le cas d’une action associée au chemin de localisation, par exemple, une action peut être précisée (comme par exemple création ou suppression) : méthode « createUser() » par le chemin « /user » et une action « POST » ou méthode « deleteUser() » par le chemin « /user » et une action « DELETE ».
Dans certains modes de réalisation, chaque nœud (2) mémorise des fichiers d’exécution (50) du ou des microservices (5), pouvant être déposés par le développeur (10) et comportant l’accès au système (1) par au moins un des deux point d’entrée soit au serveur hôte (3) soit au nœud d’exécution (2). Par exemple, ces fichiers d’exécution peuvent contenir un nom d’un chemin ou une méthode de localisation dans le microservice. Dans le cas des fichiers sous format Jar, par exemple, une nomenclature similaire au Jax-rs (terme anglophone pour Java API for RESTfui Wab Services et désignant une interface de programmation Java pour créer des services web avec une architecture REST) peut être utilisée: utilisation du chemin de l’url (ou adresse sur le web) pour localiser la méthode à utiliser (« @Path »), réécriture des sous éléments du chemin de l’url (« @PathParam »), utilisation de verbes ou vocabulaires d’accès aux ressources (« @GET», « @POST», « @DELETE », « @PUT»).
Dans certains modes de réalisation, chaque nœud (2) comprend au moins un chargeur de classe (7) assurant le déploiement des services associés aux microservices (5) qui sont intégrés dans le nœud d’exécution (2), comme représenté par exemple sur les figures 1 et 2. Dans certains modes de réalisation, le système (1) est apte à sélectionner un nœud (2) d’exécution pour qu’il charge un microservice (5) dans le chargeur de classe (7) qui est référencié dans une unité distribuée de stockage (9) en fonction de l’alias utilisé dans la métadata (M) d’échange. Ainsi, la gestion par le chargeur de classe de Java peut permettre de charger et recharger sans interruption de service, de sorte à obtenir un rollback (terme anglophone désignant une méthode permettant d’annuler l’ensemble des requêtes réalisées) rapide. Dans certains modes de réalisation, le développeur (10) peut également créer des alias aux microservices (5).
Dans certains modes de réalisation, le système clef/valeur (6) est mémorisé dans le cache mémoire distribué (8) et l’unité de stockage distribué (9), par exemple et non limitativement les bases de données Redis, Cassandra, Aerospike, etc. Le système (6) clef/valeur permet de mémoriser les microservices (5) ou les fichiers d’exécution (50) des microservices sous format Jar ou sous forme de fichier simple Javascript. Dans certains modes de réalisation, le système (1) désarchive les fichiers au format Jar en classes d’utilisation ou d’exécution pour les rendre accessible au chargeur de classe (7) de l’environnement (J) d’exécution Java du nœud (2) d’exécution. Les autres fichiers (Javascript) sont mémorisés unitairement en se basant sur le système (6) clef/valeur pour que l’environnement (J) d’exécution Java puisse lire ou exploiter selon le besoin. Le chargeur de classe (7) peut charger les microservices (5) depuis l’unité de stockage distribué (9) en fonction de la demande ou requête du serveur hôte (3), définie par l’alias de service qui permet d’identifier le microservice à charger et le chemin de la requête entrante permet d’identifier la méthode (Java ou Javascript) à appeler dans le microservice chargé.
Dans certains modes de réalisation, l’algorithme des nœuds (2) d’exécution est apte à lancer un timeout d’inactivité à chaque détermination de score. Ceci permet au serveur hôte (3) d’utiliser et réutiliser le même nœud (2) d’exécution, grâce à l’algorithme spécifique du nœud d’exécution, tant que le microservice est inexploité ou qu’un timeout d’inactivité est levé. En effet, chaque appel de microservice peut entraîner des appels à d’autres microservices qu’il soit sur le même nœud d’exécution ou sur un autre nœud du système. De ce fait, le microservice peut comprendre une méthode particulière pour associer l’ensemble de ces réponses en une seule, pour pouvoir ainsi récupérer chacun de ces appels pour ne générer qu’une réponse à l’appelant.
Dans certains modes de réalisation, si le microservice (5) n’est pas chargé, le système (1) choisit le nœud (2) d’exécution. Le nœud (2) appelé par le serveur hôte (3) du système (1) charge le microservice dans un nouveau chargeur de classe (7) qui est référencié par le système dans une HashMap du cache mémoire distribué (8) en fonction de l’alias utilisé dans le message d’échange standardisé.
Dans certains modes de réalisation, l’appel au microservice (5) se fait par un nom ou alias de référencement unique. Par exemple, cet alias peutêtre un nom de domaine web et dans le cas d’une requête HTTP sur le serveur hôte (3), c’est le nom de « host » (en-tête du fichier informatique dans le protocole HTTP1.1) qui pourra être utilisé pour retrouver le microservice associé.
Dans certains modes de réalisation, le serveur hôte (3) et les nœuds d’exécution (2) sont multipliables, sans aucune configuration particulière, par un ou des gestionnaires du système (1). Cette configuration permet à l’administrateur ou développeur de la plateforme, de limiter les modifications ou réglages spécifiques des paramètres par serveur ou par architecture informatique pour la mise en œuvre du système.
Dans certains modes de réalisation, le système (1) peut comprendre un outil de développement de microservices pour constituer une interface de développement (par exemple, via une interface de programmation applicative) pour le développeur (10) et/ou un outil d’envoi dans le protocole utilisé entre le microservice et le serveur hôte.
Dans certains modes de réalisation, chaque nœud (2) d’exécution peut comprendre en outre des moyens informatiques (21) de gestion des microservices, des moyens informatiques de lecture et d’écriture des fichiers d’exécution disposés dans une unité distribuée de stockage (9) du système (1), et un système (22) de publication et souscription de message (pouvant être un système de notification) lorsqu’un microservice (5) est déposé ou un alias est modifié par le développeur (10) sur le système (1). Dans certains modes de réalisation, le rechargement de service se fait soit par changement d’alias, soit par le dépôt dans le système d’un nouveau microservice avec le même nom. Le dépôt du microservice ou la modification d’alias provoque donc un envoi de message via le système de publication/souscription qui entraîne une action sur l’ensemble des nœuds du système de communication.
Dans certains modes de réalisation, le système (6) clef/valeur et le système de notification peuvent être des systèmes externes au système (1) de communication qui peuvent être intégrés dans un code exécutable du système de communication, ou injectés au moment de l’exécution du système par un gestionnaire du système. Cette configuration présente l’avantage de rendre le système de communication de la présente invention, à la fois indépendant et évolutif par rapport aux systèmes externes. Ainsi, l’administrateur du système n’est pas lié vis-à-vis du système externe choisi, par exemple l’administrateur pourra de préférence utiliser et facilement contrôler l’unité de stockage distribué par une base de données de type Cassandra plutôt que Redis. L’administrateur peut également, d’une part, changer facilement les composants externes en fonction de l’instanciation de la plateforme souhaitée, et d’autre part, optimiser le système de communication en ajoutant sans contrainte, par exemple sans modifier l’architecture ou les codes exécutables du système, de nouveau système de notification ou de système clef/valeur plus performant.
Dans certains modes de réalisation, le système peut supprimer les entrées dans la HashMap du cache mémoire distribué (8), lorsque le délai d’inactivité de charge est levé ou lors du rechargement du microservice. Ce qui les permettra d’être éliminé par le Garbage Collector Java (terme anglophone désignant un « ramasse-miettes » ou un « récupérateur » de mémoire qui détermine les objets ne pouvant être utilisé par le programme pour récupérer l’espace utilisé par ces objets). En cas de rechargement du microservice, les fichiers déployés ou chargés provenant du Jar seront aussi supprimés du système clef/valeur. Dans certains modes de réalisation, s’il n’y a plus de lien entre les microservices chargés par le chargeur de classe et l’environnement d’exécution Java, le chargeur de classe peut être supprimé automatiquement par le Garbage Collector Java, de sorte que le rechargement multiple d’un microservice ne provoque pas d’impact sur les ressources utilisées.
Dans certains modes de réalisation, l’utilisation d’un microservice (5) peut être activée par au moins un code d’accès disposé soit au niveau du service (par exemple par une annotation «@DisableSecurity») permettant l’accès à toutes les ressources du service (par exemple «@DisableSecurity({7.*})>>), soit au niveau d’une ressource (par exemple «(a)Authentification(false)») du service permettant l’accès à cette unique ressource, ou par au moins une méthode d’accès prédéfinie par un gestionnaire de sécurité du système de communication. En effet, initialement l’appel d’un microservice non autorisé entraîne un code retour d’erreur au serveur hôte. Au niveau des nœuds d’exécution, chaque appel d’un microservice devra ainsi être autorisé pour pouvoir déployer le microservice sur la plateforme. Ceci permet un accès au microservice sécurisé dans le système de communication.
La présente invention concerne également un procédé d’accès et de déploiement de microservices (5) éphémères sur une plateforme (4) informatique hétérogène, par le système (1) de communication selon une des modes de réalisation de la présente invention.
Dans certains modes de réalisation, comme représenté par exemple sur la figure 2, le procédé comprend les étapes suivantes :
- dépôt d’un ou plusieurs microservices (5) par le développeur (10) sur un ou plusieurs nœuds (2) d’exécution ;
- référencement des microservices (5) par le nom de fichier déposé sans son extension dans le système (6) clef/valeur ;
- mémorisation des microservices (5), sous forme de fichier d’exécution (50) de type Jar ou Javascript, par le système (6) clef/valeur dans l’unité (9) distribuée de stockage ;
- désarchivage en classes d’utilisation ou d’exécution des fichiers d’exécution (50) au format Jar par le système (6) clef/valeur pour les rendre accessibles au chargeur de classe (7) de l’environnement (J) d’exécution Java du nœud (2) d’exécution, et le format JavaScript des fichiers d’exécution (50) sont mémorisés unitairement sur le système (6) clef/valeur pour que l’environnement (J) d’exécution Java puisse lire ou exploiter selon le besoin ;
- chargement des classes associées aux microservices (5) par les chargeurs de classe (7) des nœuds(2) d’exécution à charger ;
- déchargement ou déploiement des microservices (5) par les nœuds (2) d’exécution lorsque les microservices (5) sont inexploités ou que le délai d’inactivité de charge du ou des microservices (5) est levé.
Dans certains modes de réalisation, l’étape de déchargement des microservices (5) comprend une sélection par le serveur hôte (3) des nœuds (2) d’exécution du microservice à charger et chaque nœud (2) d’exécution remonte des données sous forme de score et d’adresse d’attribution du microservice dans un cache (8) mémoire distribué du système (1) de communication pour que le serveur hôte (3) puisse lire et exploiter ces données.
Dans certains modes de réalisation, le serveur hôte (3) choisi le nœud (2) d’exécution par trois processus différents :
- dans le cas où, le serveur hôte ne comprend pas d’information sur un nœud d’exécution pour un microservice donné, le serveur hôte s’adresse au cache mémoire distribué pour récupérer l’information du nœud le plus pertinent, puis s’adresse à ce nœud pour que ce dernier charge le microservice.
- dans le cas où, le serveur hôte comprend déjà une information sur un nœud d’exécution pour un microservice donné, et que le microservice n’est pas utilisé (c'est-à-dire que la communication entre le serveur hôte et le microservice n’est pas utilisée), le serveur hôte réutilise ce microservice ;
- dans le cas où, le serveur hôte comprend déjà une information sur un nœud d’exécution pour un microservice donné, et que le microservice est utilisé par ce serveur hôte (c'est-à-dire que la communication entre ce serveur hôte et ce microservice est utilisé ou qu’une requête est en cours), le serveur hôte instancie un nouveau microservice pour communiquer avec le nœud d’exécution (tel que dans le cas du premier processus décris cidessus).
Dans certains modes de réalisation, le procédé comprend en outre une étape de création des alias aux microservices (5) par le développeur (10) pour que le système puisse localiser le ou les microservices (5) à déployer.
Dans certains modes de réalisation, lorsque le microservice (5) n’est pas chargé, le système (1) de communication choisit (par exemple via le serveur hôte) le nœud (2) d’exécution qui charge le microservice (5) dans un nouveau chargeur de classe (7) et le référencie dans l’unité (9) distribuée de stockage du système.
Dans certains modes de réalisation, le rechargement de microservice (5) se fait soit par le dépôt d’un nouveau microservice avec le même nom de fichier d’exécution, soit par changement d’alias.
Dans certains modes de réalisation, le rechargement de microservice (5) entraîne un envoi de message par le système (22) de publication et souscription pour actualiser l’ensemble des actions des nœuds (2) d’exécution du système (1) de communication.
Dans certains modes de réalisation, le déploiement ou l’actualisation d’un microservice est réalisé par le développeur qui dépose le microservice (par exemple, par une interface homme machine (IHM) ou une interface de programmation applicative (API) pouvant être intégré dans le nœud d’exécution) dans l’unité de stockage distribué, afin que le système de publication/souscription informe du déploiement ou de l’actualisation des microservices sur l’ensemble des nœuds d’exécution.
Le système de communication et le procédé d’accès et de déploiement de microservices éphémères sur une plateforme hétérogène utilisant ce système de communication, selon un des modes de réalisation de la présente invention, permettent au développeur de n’a pas avoir à appréhender les problématiques d’infrastructures techniques sous-jacentes masquées. En effet, le développeur peut simplement déposer le microservice (par exemple un fichier Jar pour du Java ou un fichier simple pour du Javascript) dans un des nœuds d’exécution du système (par exemple par une simple requête HTTP). Le développeur peut ainsi instancier et déployer de façon dynamique l’accès et le déploiement des microservices. Le système de communication permet également de pouvoir déployer sur tout type environnement technique (de la carte ARM avec des architectures matérielles RISC (désignant un processeur à jeu d’instructions réduit) aux serveurs de calcul) supportant un environnement d’exécution Java. Par ailleurs, ce système de communication peut être utilisé dans le domaine de l’internet des objets en limitant les coûts d’investissement (par exemple en investissant sur des composants modulables et réutilisables) et en évoluant de manière sélective. Enfin, le procédé selon l’invention permet un accès et un déploiement sécurisé des microservices sur la plateforme hétérogène de façon entièrement agnostique du média et/ou du réseau d’accès utilisés par le développeur ou l’utilisateur.
La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. L’homme de métier comprendra que les caractéristiques techniques d’un mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d’un autre mode de réalisation à moins que l’inverse ne soit explicitement mentionné ou qu’il ne soit évident que ces caractéristiques sont incompatibles ou que la combinaison ne fournisse pas une solution à au moins un des problèmes techniques mentionnés dans la présente demande. De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l’inverse ne soit explicitement mentionné.
II doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la protection demandée, et l'invention ne doit pas être limitée aux détails donnés ci-dessus.
Claims (20)
- REVENDICATIONS1. Système (1) de communication comprenant un ou plusieurs nœuds (2) d’exécution apte à exécuter un ou plusieurs microservices (5), un dispositif informatique, dit « serveur hôte » (3), comportant plusieurs routeurs (30) constituant une interface intermédiaire de communication entre chaque nœud (2) d’exécution et l’extérieur du système (1) de communication, une plateforme (4) informatique hétérogène, constituée d’un ensemble (40) de matériel et logiciel ou code exécutable pour l’accès et le déploiement des microservices (5) sur le système dans un environnement (J) d’exécution Java (runtime java) sur le serveur hôte (3) et les nœuds (2) d’exécution permettant l’exécution des programmes informatiques basés sur le langage Java, le système (1) de communication étant caractérisé en ce qu’il permet la création de microservices (5) éphémères par l’utilisation d’un système (6) clef/valeur mémorisé dans un cache (8) mémoire distribué à chaque création en référenciant chaque microservices (5) par des noms de fichier déposés dans le système par un développeur (10) et utilisant un protocole (T) d'échange TCP asynchrone échangeant des notifications contenant des métadatas (M) entre le serveur hôte (3) et chaque nœud (2) d’exécution ; et en ce que chaque nœud (2) mémorise des fichiers (50) d’exécution du ou des microservices (5) comportant l’accès au système (1) par au moins un des deux point d’entrée soit au serveur hôte (3) soit au nœud (2) d’exécution et au moins un chargeur de classe (7) assurant le déploiement des services associés aux microservices (5) qui sont intégrés dans le nœud (2) d’exécution.
- 2. Système selon la revendication 1, caractérisé en ce que le serveur hôte (3) et les nœuds (2) d’exécution du système, échangent des données de type métadatas (M) comprenant un ou plusieurs des éléments suivants : un alias du microservice (appelé clé), un chemin de localisation d’une méthode particulière dans le microservice, une action associée au chemin de localisation, un code retour d’exécution du microservice et un type de contenu d’exécution du microservice.
- 3. Système selon la revendication 1 ou 2, caractérisé en ce qu’un outil de développement de microservices constitue une interface développeur et un outil d’envoi dans le protocole utilisé entre le microservice (5) et le serveur hôte (3).
- 4. Système selon une des revendications 1 à 3, caractérisé en ce que chaque nœud (2) d’exécution comprend en outre des moyens informatiques (21) de gestion des microservices, des moyens informatiques de lecture et d’écriture des fichiers d’exécution disposés dans une unité (9) distribuée de stockage du système (1), et un système (22) de publication et souscription de message lorsqu’un microservice (5) est déposé ou un alias est modifié par le développeur (10) sur le système (1).
- 5. Système selon une des revendications 1 à 4, caractérisé en ce que chaque nœud (2) d’exécution est apte à exécuter un algorithme prédéterminé dédié à la sélection d’un ou plusieurs nœuds (2) d’exécution du microservice (5) en déterminant un score (valeur) puis en mémorisant l’adresse ou l’alias du microservice (5) et ce score (système clé/valeur) dans le cache (8) mémoire distribué si le score est plus pertinent que le précédent.
- 6. Système selon la revendication 5, caractérisé en ce que l’algorithme prédéterminé exécuté par le nœud (2) d’exécution lance un timeout d’inactivité à chaque détermination de score pour que le serveur hôte (3) réutilise le même nœud (2) d’exécution tant que le microservice (5) est inexploité ou qu’un timeout d’inactivité est levé.
- 7. Système selon une des revendications 1 à 6, caractérisé en ce que le nœud (2) d’exécution choisit par le serveur hôte (3) appelé par le système (1), charge le microservice (5) dans un nouveau chargeur de classe (7) référencé au sein du système (1), dans une HashMap du cache (8) mémoire distribué en fonction de l’alias utilisé dans le message d’échange standardisé.
- 8. Système selon une des revendications 5 à 7, caractérisé en ce que chaque nœud (2) d’exécution sélectionné est apte à remonter des données sous forme de score et d’attribution d’adresse dans le cache (8) mémoire distribué du système (1) de communication attribué à chaque microservices (5) pour que le serveur hôte (3) puisse lire et exploiter ces données.
- 9. Système selon une des revendications 1 à 8, caractérisé en ce que les routeurs (30) du serveur hôte (3) intègrent des applications basées sur Java et Netty pour assurer des communications multiprotocoles vers l’extérieur du système (1) et des échanges asynchrones en protocole (T) TCP vers les nœuds (2) d’exécution du système (1).
- 10. Système selon une des revendications 1 à 9, caractérisé en ce que les microservices (5) sont mémorisés au format Jar ou Javascript par le système (1) dans le cache (8) mémoire distribué ; tandis que les fichiers au format Jar sont désarchivés en classes d’utilisation ou d’exécution par le système (1) pour les rendre accessible au chargeur de classe (7) de l’environnement (J) d’exécution Java du nœud (2) d’exécution ; de sorte que ces microservices (5) soit chargés depuis l’unité (9) de stockage distribué en fonction de la demande du serveur hôte (définie par l’alias de service qui permet d’identifier le microservice à charger et le chemin de la requête entrante permettant d’identifier la méthode (java ou javascript) à appeler dans le microservice chargé) ; et les autres formats de fichier sont mémorisés unitairement sur le système clef/valeur (6) pour que l’environnement (J) d’exécution Java puisse lire ou exploiter selon le besoin.
- 11.Système selon une des revendications 4 à 10, caractérisé en ce que le système (1) est apte à sélectionner un nœud (2) d’exécution pour qu’il charge un microservice (5) dans un chargeur de classe (6) qui est référencié dans l’unité (9) distribuée de stockage en fonction de l’alias utilisé dans le métadatas (M) d’échange.
- 12.Système selon une des revendications 1 à 11, caractérisé en ce qu’il comporte au moins un code d’accès pour une activation d’appel d’un microservice (5) pour son déploiement sur la plateforme (4), ledit code d’accès est disposé soit au niveau du service permettant l’accès à toutes les ressources du service, soit au niveau d’une ressource du service permettant l’accès à cette unique ressource, ou par au moins une méthode d’accès prédéfinie par un gestionnaire de sécurité du système (1) de communication.
- 13. Système selon une des revendications 5 à 12, caractérisé en ce que le serveur hôte (3) est configuré à utiliser et réutiliser le même nœud (2) d’exécution, au moyen de l’algorithme spécifique du nœud (2), tant que le microservice (5) est inexploité ou qu’un délai d’inactivité de charge du microservice (5) est levé.
- 14. Système selon une des revendications 1 à 13, caractérisé en ce que le système clef/valeur (6) et le système de notification sont des systèmes externes au système de communication qui sont intégrés dans un code exécutable du système de communication, ou injectés au moment de l’exécution du système (1).
- 15. Procédé d’accès et de déploiement de microservices (5) éphémères sur une plateforme (4) informatique hétérogène, par un système (1) de communication selon une des revendications 1 à 14, caractérisé en ce que le procédé comprend les étapes suivantes :- dépôt d’un ou plusieurs microservices (5) par le développeur (10) sur un ou plusieurs nœuds (2) d’exécution ;- référencement des microservices (5) par le nom de fichier déposé sans son extension dans le système clef/valeur (6) ;- mémorisation des microservices (5), sous forme de fichier (50) d’exécution de type Jar ou Javascript, par le système clef/valeur (6) dans l’unité (9) distribuée de stockage ;- désarchivage en classes d’utilisation ou d’exécution des fichiers d’exécution au format Jar par le système clef/valeur (6) pour les rendre accessibles au chargeur de classe (7) de l’environnement (J) d’exécution Java du nœud d’exécution, et le format JavaScript des fichiers d’exécution sont mémorisés unitairement sur le système clef/valeur (6) pour que l’environnement (J) d’exécution Java puisse lire ou exploiter selon le besoin ;- chargement des classes associées aux microservices (5) par les chargeurs de classe (7) des noeuds (2) d’exécution à charger ;- déchargement des microservices (5) par les nœuds (2) d’exécution lorsque les microservices (5) sont inexploités ou que le délai d’inactivité de charge du ou des microservices (5) est levé.
- 16. Procédé selon la revendication 15, caractérisé en ce que l’étape de déchargement des microservices (5) comprend une sélection par le serveur hôte (3) des nœuds (2) d’exécution du microservice (5) à charger et chaque nœud (2) d’exécution remonte des données sous forme de score et d’adresse d’attribution du microservice (5) dans le cache (8) mémoire distribué du système (1) de communication pour que le serveur hôte (3) puisse lire et exploiter ces données.
- 17. Procédé selon la revendication 15 ou 16, caractérisé en ce qu’il comprend en outre une étape de création des alias aux microservices (5) par le développeur (10) pour que le système (1) puisse localiser le ou les microservices (5) à déployer.
- 18. Procédé selon une des revendications 15 à 17, caractérisé en ce que lorsque le microservice (5) n’est pas chargé, le système (1) de communication choisit le nœud (2) d’exécution qui charge le microservice (5) dans un nouveau chargeur de classe (7) et le référencie dans l’unité (9) distribuée de stockage du système (1).
- 19. Procédé selon la revendication 17 ou 18, caractérisé en ce que le rechargement de microservice (5) se fait soit par le dépôt d’un nouveau microservice (5) avec le même nom de fichier d’exécution, soit par changement d’alias.
- 20. Procédé selon une des revendications 15 à 19, caractérisé en ce que le rechargement de microservice (5) entraîne un envoi de message par le , Γ système (22) de publication et souscription pour actualiser l’ensemble des actions des noeuds (2) d’exécution du système (1) de communication.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1757040A FR3069669B1 (fr) | 2017-07-25 | 2017-07-25 | Un systeme de communication et un procede d'acces et de deploiement des microservices ephemeres sur une plateforme heterogene |
| US16/633,984 US10866841B2 (en) | 2017-07-25 | 2018-07-24 | Communication system and method for accessing and deploying temporary microservices on a heterogeneous platform |
| PCT/EP2018/070077 WO2019020651A2 (fr) | 2017-07-25 | 2018-07-24 | Un système de communication et un procédé d'accès et de déploiement des microservices éphémères sur une plateforme hétérogène |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1757040 | 2017-07-25 | ||
| FR1757040A FR3069669B1 (fr) | 2017-07-25 | 2017-07-25 | Un systeme de communication et un procede d'acces et de deploiement des microservices ephemeres sur une plateforme heterogene |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3069669A1 true FR3069669A1 (fr) | 2019-02-01 |
| FR3069669B1 FR3069669B1 (fr) | 2019-10-18 |
Family
ID=61187360
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1757040A Active FR3069669B1 (fr) | 2017-07-25 | 2017-07-25 | Un systeme de communication et un procede d'acces et de deploiement des microservices ephemeres sur une plateforme heterogene |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US10866841B2 (fr) |
| FR (1) | FR3069669B1 (fr) |
| WO (1) | WO2019020651A2 (fr) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112104617B (zh) * | 2020-08-27 | 2023-07-21 | 中国平安财产保险股份有限公司 | 微服务的权限管理方法、装置、设备及存储介质 |
| CN112685052B (zh) * | 2020-12-30 | 2024-01-23 | 浪潮通用软件有限公司 | 一种基于.NET Core的支持不同部署方式的微服务实现方法 |
| CN112835559B (zh) * | 2021-01-28 | 2023-08-11 | 北银金融科技有限责任公司 | 微前端在北银金融场景建设中的设计与实现方法 |
| CN113268251A (zh) * | 2021-05-25 | 2021-08-17 | 中国联合网络通信集团有限公司 | 微服务的部署方法及其设备、计算机存储介质 |
| CN114185695A (zh) * | 2021-11-26 | 2022-03-15 | 中国汽车技术研究中心有限公司 | 基于工业app微服务的松耦合数据处理方法和系统 |
| CN114201314B (zh) * | 2021-12-10 | 2022-10-04 | 优维科技(深圳)有限公司 | 一种基于契约的实现服务依赖发现和服务访问的路由方法 |
| CN116069519B (zh) * | 2022-04-21 | 2024-01-30 | 中国石油天然气集团有限公司 | 一种录井方法、装置、设备及存储介质 |
| CN115756771B (zh) * | 2022-10-19 | 2023-09-29 | 中电金信软件有限公司 | 微服务化的前置系统、工作流调度方法及装置 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140304810A1 (en) * | 2013-04-06 | 2014-10-09 | Citrix Systems, Inc. | Systems and methods for protecting cluster systems from tcp syn attack |
| US20160127199A1 (en) * | 2014-11-04 | 2016-05-05 | Futurewei Technologies, Inc. | Adaptive Allocation of Server Resources |
| US20160344846A1 (en) * | 2014-03-12 | 2016-11-24 | Shenzhen Chuangwei-Rgb Electronic Co., Ltd | Inter-process communication method based on application layer of android and basic application communication system |
| WO2017109435A1 (fr) * | 2015-12-24 | 2017-06-29 | Bull Sas | Procede de configuration d'un systeme d'exploitation |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1324217A1 (fr) | 2001-12-18 | 2003-07-02 | Hewlett-Packard Company, A Delaware Corporation | Procédé et système de cache pour fournir un service électronique dans un réseau de télécommunication |
| US10255061B2 (en) * | 2016-08-05 | 2019-04-09 | Oracle International Corporation | Zero down time upgrade for a multi-tenant identity and data security management cloud service |
-
2017
- 2017-07-25 FR FR1757040A patent/FR3069669B1/fr active Active
-
2018
- 2018-07-24 US US16/633,984 patent/US10866841B2/en active Active
- 2018-07-24 WO PCT/EP2018/070077 patent/WO2019020651A2/fr active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140304810A1 (en) * | 2013-04-06 | 2014-10-09 | Citrix Systems, Inc. | Systems and methods for protecting cluster systems from tcp syn attack |
| US20160344846A1 (en) * | 2014-03-12 | 2016-11-24 | Shenzhen Chuangwei-Rgb Electronic Co., Ltd | Inter-process communication method based on application layer of android and basic application communication system |
| US20160127199A1 (en) * | 2014-11-04 | 2016-05-05 | Futurewei Technologies, Inc. | Adaptive Allocation of Server Resources |
| WO2017109435A1 (fr) * | 2015-12-24 | 2017-06-29 | Bull Sas | Procede de configuration d'un systeme d'exploitation |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2019020651A2 (fr) | 2019-01-31 |
| US20200218581A1 (en) | 2020-07-09 |
| US10866841B2 (en) | 2020-12-15 |
| WO2019020651A3 (fr) | 2019-04-25 |
| FR3069669B1 (fr) | 2019-10-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR3069669B1 (fr) | Un systeme de communication et un procede d'acces et de deploiement des microservices ephemeres sur une plateforme heterogene | |
| US11750456B2 (en) | Secure configuration of cloud computing nodes | |
| US10564946B1 (en) | Dependency handling in an on-demand network code execution system | |
| US7124289B1 (en) | Automated provisioning framework for internet site servers | |
| US11507672B1 (en) | Runtime filtering of computer system vulnerabilities | |
| US10853196B2 (en) | Prioritizing microservices on a container platform for a restore operation | |
| CN109688222A (zh) | 共享计算资源的调度方法、共享计算系统、服务器及存储介质 | |
| US10104187B2 (en) | System, computer program, and method for dividing services into subsets based on interdependencies | |
| CN113055492A (zh) | 服务灰度链路的控制方法、装置、计算机设备和存储介质 | |
| US20070168554A1 (en) | System and method for providing trickle resource discovery | |
| EP2190160A1 (fr) | Système et procédé pour le déploiement dynamique de traitements distribués | |
| US20110295922A1 (en) | Aspect oriented programming for an enterprise service bus | |
| US20220214931A1 (en) | System and method for exposing features of integration platform adapters as first-class actions in an orchestration template | |
| EP3931694A1 (fr) | Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée | |
| JP5052126B2 (ja) | Ｊｍｓトピック名でワイルドカードを使用するための方法、装置、およびコンピュータで使用可能な媒体（公開に関する加入の動的発見） | |
| CN114640610B (zh) | 基于云原生的服务治理方法、装置及存储介质 | |
| EP1872256B1 (fr) | Systeme et procede de gestion des dechets | |
| US8224933B2 (en) | Method and apparatus for case-based service composition | |
| US20230019920A1 (en) | Detecting layered bottlenecks in microservices | |
| US20220173963A1 (en) | Heterogeneous cross-cloud service interoperability | |
| FR2995425A1 (fr) | Procede et systeme de mise en oeuvre d'une infrastructure informatique en nuage agregeant des ressources isolees mises a disposition a travers un reseau | |
| US7933880B2 (en) | System and method of application persistence | |
| FR3067832A1 (fr) | Fourniture de services inter-groupements | |
| US12135793B2 (en) | Runtime filtering of computer system vulnerabilities | |
| FR3099258A1 (fr) | Adaptation dynamique d’un environnement d’exécution d’élément sécurisé à des profils |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLSC | Publication of the preliminary search report |
Effective date: 20190201 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |