Nanosai est un ensemble d'outils Java open source axé sur la création de systèmes distribués hautes performances, haute fiabilité et à faible latence. Il fournit des modules tels que Stream Ops (moteur de traitement de flux intégré), Mem Ops (gestionnaire de mémoire zéro GC), RION Ops (format de données binaires compact), Net Ops (boîte à outils réseau non bloquante) et convient aux scénarios d'infrastructure tels que les pipelines d'inférence d'IA, le traitement de données en temps réel, l'informatique de pointe IoT et la communication de microservices.

Nanosaï

Paramètres et statistiques de base de Nanosai

Nanosai n'est pas un produit unique, mais un ensemble d'outils de création de systèmes distribués composé de plusieurs modules Java. Sa conception principale s'articule autour des trois objectifs d'ingénierie suivants : "zéro pause GC, latence déterministe et déploiement intégré". Chaque module est orienté vers un domaine vertical des systèmes distribués : gestion de la mémoire, traitement des flux, communication réseau, sérialisation des données et contrôle de la concurrence.

Module	Positionnement fonctionnel	Version actuelle	Dépendances principales	Contrat de licence
Opérations de flux	Moteur de traitement de flux de données intégré	0.7.0	Opérations mémoire + Opérations RION	Apache2.0
Opérations mémoire	Gestionnaire de mémoire et pool d'objets Zero GC	0.7.1	Aucun	Apache2.0
Opérations RION	Encodage et décodage au format de données binaires compact	0.1.0 (non entièrement divulgué)	Opérations mémoire	Apache2.0
Opérations Internet	Boîte à outils d'E/S réseau non bloquante	0.1.0	Aucun	Apache2.0
Opérations de discussion	Gestion des threads et primitives de concurrence	0.1.0	Aucun	Apache2.0
Opérations de grille	Cadre de grille de calcul distribué	0.1.0	Tous les modules de couche supérieure	Apache2.0
Opérations V	Outils d'exécution du langage virtuel	0.1.0	Aucun	Apache2.0
Modrun	Chargeur de classe d'exécution Maven	0.1.0	Aucun	Apache2.0

Implications techniques du positionnement de la conception : les modules Nanosai ne sont pas des middlewares volumineux et complets (tels que Kafka, Redis), mais une « infrastructure Lego » qui peut être intégrée dans l'application. Stream Ops est intégré au processus JVM en tant que bibliothèque et ne s'appuie pas sur des agents externes ou des clusters indépendants, ce qui présente un attrait direct pour les nœuds périphériques aux ressources limitées et les systèmes financiers qui nécessitent une isolation de sécurité stricte. Mais cela signifie également qu'il n'est pas livré avec une interface d'exploitation et de maintenance, des alarmes de surveillance ou un stockage persistant, et que les utilisateurs doivent créer eux-mêmes des installations d'exploitation et de maintenance de support.

Aperçu de l'indicateur de performance : Nanosai affirme officiellement que l'objectif de Stream Ops est d'atteindre 1 milliard de capacités de traitement d'enregistrement par seconde (défi 1BRS), mais il n'existe actuellement aucun test de référence public tiers pour vérifier cet indicateur. Dans les microbenchmarks, Mem Ops réduit considérablement la pression du GC en pré-attribuant de grands tableaux d'octets et en gérant manuellement les allocations/libérations - avec des milliers d'allocations de petits objets par seconde, la distribution de latence converge de la gigue à longue traîne en mode GC (des dizaines de millisecondes de pauses STW) aux opérations déterministes de l'ordre de la microseconde. Net Ops est implémenté sur la base de sélecteurs Java NIO et peut gérer des dizaines de milliers de connexions simultanées dans le cadre d'un modèle de boucle d'événements à thread unique.

Utilisateurs de Nanosai et reconnaissance du marché

Nanosai s'adresse aux architectes back-end Java et aux ingénieurs informatiques hautes performances, et non aux utilisateurs grand public. La dimension de mesure de son impact sur le marché est complètement différente de celle des applications de l’IA grand public.

Couverture de la communauté open source : à la mi-2026, les 11 entrepôts de Nanosai sur GitHub avaient accumulé environ 340+ étoiles, parmi lesquelles Modrun (102 étoiles) et Stream Ops (50 étoiles) retiennent le plus l'attention. Les adeptes sont principalement des développeurs de middleware Java, des ingénieurs de systèmes de transactions à faible latence et des chercheurs en traitement de flux intégré. À en juger par les données GitHub, le projet n'a reçu aucune nouvelle soumission depuis la mi-2020 et est actuellement en statut de « maintenance stable » plutôt que de « développement actif ».

Positionnement du benchmarking industriel : Chaque module de Nanosai chevauche les projets suivants au niveau fonctionnel, mais le positionnement est évidemment différent :

Dimensions comparatives	Nanosaï	Apache Kafka	File d'attente des chroniques	Aéron
Mode de déploiement	Bibliothèque intégrée	Cluster autonome	Bibliothèque intégrée	Bibliothèque intégrée
Langages de programmation	Java 8+	Java/Scala	Java	Java/C
Contrôle GC	Gestion explicite de la mémoire	Dépend de JVM GC	Mémoire hors tas	Mémoire hors tas
Objectif de performance	1 milliard d'enregistrements/seconde (réclamé)	Millions de messages/seconde	Des dizaines de millions de messages/seconde	Millions de messages/seconde
Complexité opérationnelle	Faible (pas de dépendances externes)	Élevé (nécessite la gestion du cluster)	Faible	Moyen
Maturité écologique	Phase expérimentale/maintenance	Niveau de production/déploiement à grande échelle	Niveau de production	Niveau de production

Citations techniques et applications de recherche : les articles de blog et les didacticiels de Nanosai (principalement publiés sur les sites de didacticiels HackerNoon et jenkov.com) sont largement lus dans la communauté des développeurs de systèmes distribués Java, mais les cas de déploiement de production à grande échelle de chaque composant lui-même dans l'industrie n'ont pas été divulgués publiquement. Ses idées techniques, en particulier la gestion explicite de la mémoire et le traitement de flux intégré, ont fourni des références de validation de principe pour des projets similaires tels que Chronicle Software et Aeron.

L'avantage de coût de Nanosai

La licence open source de Nanosai (Apache 2.0) rend le coût de sa licence logicielle cohérent pour tous les utilisateurs : aucun frais de licence. Cependant, en tant que composante d'infrastructure, son coût réel se reflète dans les trois niveaux d'intégration, d'exploitation et de maintenance, et de seuil de compétence.

Développeurs côté C/individuels : aucun coût d'utilisation. Les développeurs individuels peuvent introduire directement des dépendances via Maven Central, sans inscription, sans clé API et sans restrictions de quota d'utilisation. En prenant Mem Ops comme exemple, ajoutez les dépendances suivantes dans « pom.xml » pour commencer à l'utiliser :

<dépendance>
    <groupId>com.nanosai</groupId>
    <artifactId>opérations mémoire</artifactId>
    <version>0.7.1</version>
</dépendance>

Point de vue API/développeur : aucune couche de service géré. Nanosai ne propose pas de version hébergée dans le cloud ni de service de passerelle API. Les développeurs doivent compiler, intégrer et déployer eux-mêmes tous les composants. Cela signifie qu'en plus du coût nul de la dépendance du code elle-même, il existe également les coûts cachés suivants :

• Coût d'intégration : la documentation du module Nanosai est principalement composée de JavaDoc et de README, manquant d'exemples d'utilisation complets de bout en bout et de guides de bonnes pratiques. L'équipe a besoin d'au moins un ingénieur senior familier avec Java NIO, la gestion de la mémoire et la programmation concurrente pour contrôler la qualité de l'intégration.
• Coût de débogage : bien que la gestion explicite de la mémoire entraîne des retards déterministes, elle introduit également un risque de fuites de mémoire similaire à celui du C/C++ : oublier de libérer les blocs d'octets alloués peut conduire à des "trous noirs de mémoire". Les outils standard JVM (tels que VisualVM, JProfiler) ont une visibilité limitée sur la mémoire hors tas et la mémoire gérée manuellement, ce qui rend le dépannage plus difficile que pour les applications Java ordinaires.
• Coût d'exploitation et de maintenance : aucune interface utilisateur intégrée de surveillance, d'alerte ou de gestion. Le déploiement en production doit intégrer des rapports de métriques (comme la connexion à Prometheus + Grafana) et un suivi des liens de journalisation pour compenser le manque d'observabilité.

Déploiements en entreprise/privés : déduction du coût total de possession (TCO). Le TCO d'une entreprise adoptant Nanosai est principalement composé des facteurs suivants :

• Skill Premium : la prime salariale pour les ingénieurs Java de haut niveau maîtrisant la gestion explicite de la mémoire + le mode réacteur Java NIO est d'environ 30 à 50 % sur le marché, et l'offre de talents est rare.
• Main d'œuvre de maintenance : sur la base d'une équipe de taille moyenne (3 à 5 personnes), le coût de maintenance annuel est estimé à environ 1,5 à 3 millions de yuans (y compris le salaire et la chaîne d'outils), ce qui est bien plus élevé que l'utilisation de solutions matures telles que Kafka (la main d'œuvre d'exploitation et de maintenance est concentrée sur la gestion du cluster plutôt que sur le débogage du framework sous-jacent).
• Risk Buffer : Le projet n'a pas de mises à jour actives depuis longtemps. Si elle rencontre des problèmes de compatibilité de version JVM (tels que les versions ultérieures de Java LTS supprimant ou modifiant des API internes telles que sun.misc.Unsafe), l'équipe doit le créer et le réparer elle-même.

Dans l'ensemble, l'avantage de coût nul de Nanosai en matière de licences logicielles peut être compensé par les risques d'intégration et les coûts de maintenance lors de la mise en œuvre réelle. Il est recommandé de le positionner comme un « choix léger pour les étapes de vérification technologique et de prototype de concept » plutôt que de l'utiliser directement dans l'infrastructure de production du système commercial de base.

Principales fonctionnalités de Nanosai

La conception fonctionnelle de chaque module de Nanosai suit le principe « interface minimaliste + performances ultimes ». Chaque module ne fait qu'une seule chose, mais celle-ci est suffisamment faible pour prendre en charge les diverses utilisations de la couche supérieure.

Stream Ops : moteur de traitement de flux intégré

Stream Ops est un moteur de traitement de flux Java entièrement intégrable conçu avec des objectifs de conception similaires à ceux d'Apache Kafka, mais avec un ensemble différent de compromis architecturaux.

• Déploiement intégré : le moteur de streaming est directement intégré au processus d'application en tant que bibliothèque et ne repose pas sur des clusters Broker externes. Bien que cela élimine les délais de saut de réseau (aucun aller-retour sur le réseau), cela signifie également que les données ne circulent qu'au sein d'un seul processus, et que la distribution des données entre processus et entre machines nécessite la coopération de Net Ops ou d'un middleware de messagerie externe.
• API Stream Processing : fournit une interface de traitement en chaîne similaire à l'API Java Stream, prenant en charge les opérateurs d'opération tels que le filtre, la carte, le flatMap et l'agrégation. La différence avec Java Stream standard est que les opérations Stream Ops sont effectuées en interne sur la base d'un pool de mémoire pré-alloué et ne génèrent pas de pression GC en raison de résultats intermédiaires.
• Persistance et lecture : Stream Ops utilise Mem Ops et RION Ops pour conserver les données de flux sur le système de fichiers local, prenant en charge la lecture des données et la reprise des points d'arrêt. Cependant, la couche de persistance ne prend actuellement en charge que le stockage de fichiers local et ne dispose pas de mécanismes intégrés de réplication distribuée ou de copie multiple.

Vue d'expert : La vraie valeur de Stream Ops n'est pas "un autre moteur de traitement de flux", mais le fait qu'il compresse les capacités de traitement de flux selon la granularité de la bibliothèque, afin qu'il puisse s'exécuter dans les passerelles IoT des appareils Android ou dans les fonctions sans serveur. Dans un pipeline d'inférence d'IA typique, Stream Ops peut servir de ciment de pipeline local pour « le prétraitement des entrées du modèle -> la mise en file d'attente des demandes d'inférence -> le post-traitement des résultats », en orchestrant plusieurs étapes de traitement à effectuer dans le même processus, évitant ainsi la sérialisation répétée et la transmission réseau des données entre Kafka/Redis et le service d'inférence.

Mem Ops : gestionnaire de mémoire zéro GC

Mem Ops est le module le plus techniquement approfondi de l'écosystème Nanosai. Il contourne les mécanismes d'allocation de mémoire et GC standard de Java et fournit des capacités de contrôle de mémoire « de type C » pour les scénarios nécessitant une latence déterministe en pré-attribuant un très grand tableau d'octets et en implémentant un pool de mémoire manuel dessus.

• Pool d'octets pré-alloués (ByteAllocator) : pré-allouer un tableau d'octets de taille fixe (par exemple, 1 Go) sur le tas JVM, et toutes les allocations de petits objets sont renvoyées à partir de ce pool en coupant des sous-plages. Le marquage de la plage est disponible dès la sortie plutôt que d'être renvoyé à la JVM, éliminant ainsi la source de pression du GC.
• Stratégie de défragmentation enfichable : propose deux modes : défragmentation instantanée (compression immédiate à la sortie) et défragmentation retardée (défragmentation par lots lorsque le système est inactif). Les développeurs peuvent choisir une stratégie appropriée en fonction de la sensibilité à la latence du scénario. Dans les scénarios à haut débit, le temps de pause peut être modifié de la « pause incontrôlable » du GC à une « défragmentation contrôlable au niveau de la microseconde ».
• Object Pool (ObjectPool) : en conjonction avec la capacité de pooling d'objets de Byte Pool, il prend en charge la réutilisation de n'importe quel objet Java, réduisant ainsi davantage le coût de création et de recyclage d'objets.

Point de vue d'expert : La contradiction fondamentale résolue par Mem Ops est le conflit classique entre « la facilité d'utilisation de Java et la latence déterministe ». Dans le service d'inférence AI, l'utilisation du GPU dépend fortement de la vitesse de prétraitement des requêtes côté CPU - si le côté CPU provoque des retards de mise en file d'attente dans les demandes d'inférence en raison de pauses GC, le GPU sera "affamé" (baisse d'utilisation allant de 10 à 30 %). Mem Ops améliore directement l'utilisation du GPU et le débit d'inférence en éliminant les pauses GC et en modifiant la répartition de la latence côté CPU de « longue traîne occasionnelle » à « faible latence stable ». Mais le prix est une complexité accrue du code : les développeurs doivent gérer explicitement le cycle de vie de la mémoire, et oublier « free() » entraînera des fuites de mémoire imperceptibles.

RION Ops : format de données binaires compact

RION (Reduced I/O Notation) est un format de données binaires compact conçu par Nanosai, similaire à MessagePack ou BSON, mais spécialement optimisé pour les scénarios à faible latence.

• Navigabilité : les données codées RION peuvent être parcourues sous forme binaire et des champs spécifiques peuvent être extraits sans désérialisation complète. Cela peut réduire considérablement la surcharge du processeur pour les scénarios nécessitant une lecture partielle de structures de données volumineuses (comme la lecture uniquement du champ d'horodatage à partir de données de streaming persistantes).
• Encodage compact : par rapport à JSON, le volume de données codées RION est généralement 40 à 60 % plus petit et comparable aux tampons de protocole. Toutes les balises de type utilisent un codage entier de longueur variable et les champs avec de petites valeurs économisent de l'espace supplémentaire.
• Convivial pour le mappage direct de la mémoire : la conception de RION permet des opérations directes sur les fichiers mappés en mémoire, éliminant ainsi le besoin de copier les données du disque vers la mémoire tas pour terminer l'analyse.

Vue d'expert : la fonctionnalité « binaire navigable » de RION a une valeur unique dans le scénario AI ​​Feature Store (Feature Store). Lorsque le modèle n'a besoin de lire que quelques fonctionnalités parmi un grand nombre de vecteurs de fonctionnalités persistants, RION peut « désérialiser uniquement les champs requis, pas la structure entière ». Dans les scénarios de recommandation où le nombre de fonctionnalités atteint des milliers de dimensions, cette fonctionnalité peut réduire la latence de lecture des fonctionnalités de quelques millisecondes à quelques microsecondes.

Net Ops : boîte à outils réseau non bloquante

Net Ops fournit un cadre de base pour les clients et serveurs TCP/UDP non bloquants basés sur des sélecteurs Java NIO (Selector).

• Implémentation du mode Reactor : une boucle d'événements à thread unique pilote plusieurs canaux et prend en charge la détection de préparation et la distribution des événements OP_ACCEPT, OP_READ et OP_WRITE.
• Codec de message extensible : fournit une interface de codec entre le canal et le message, prenant en charge l'intégration de codec natif du format RION.
• Prise en charge de la contre-pression : combiné à la capacité de vérification de la mémoire de Mem Ops, un mécanisme de contre-pression basé sur la mémoire restante peut être implémenté au niveau de la couche application - suspendant automatiquement la lecture des données entrantes lorsque l'utilisation du pool de mémoire dépasse le seuil pour empêcher le MOO.

Vue d'expert : le concept de conception de Net Ops au niveau du réseau est similaire à celui de Netty, mais grâce à une intégration approfondie avec Mem Ops, il fournit une « contre-pression tenant compte de la mémoire » difficile à réaliser avec la mise en œuvre traditionnelle de Netty. Lors de la création d'une passerelle d'inférence IA, cette fonctionnalité évite les débordements de mémoire provoqués par un trafic en rafale et permet une limitation fluide du débit au niveau de l'équilibreur de charge en amont.

Thread Ops et Grid Ops : bases de la concurrence et de la distribution

Thread Ops fournit une encapsulation de haut niveau des pools de threads et des interfaces simplifiées pour les tâches Fork-Join, tandis que Grid Ops construit un cadre de grille de calcul distribué au-dessus de tous les modules sous-jacents pour prendre en charge la distribution des tâches et la fusion des résultats entre les JVM.

Modrun : chargeur de classes d'exécution

Modrun peut résoudre les dépendances directement à partir des référentiels Maven et charger des classes au moment de l'exécution sans avoir besoin de pré-construire fat-jar. Cela réduit la complexité du déploiement dans les scénarios qui nécessitent une expansion dynamique des modules fonctionnels, tels que le chargement de modèles de plug-ins pour les pipelines d'inférence d'IA.

Evolution du modèle et de la version de Nanosai

L'évolution de la version de Nanosai n'est pas un modèle typique de « feuille de route produit », mais un projet open source « axé sur l'enseignement » produit à la demande par le fondateur Jakob Jenkov alors qu'il continue d'écrire des didacticiels sur les systèmes distribués. Son historique de versions reflète le chemin de construction progressif depuis les composants de base sous-jacents jusqu'au cadre d'application supérieur.

Première étape de la fondation : Grid Ops vs Net Ops (2017)

• Grid Ops 0.1.0 (~2017-04) : le premier projet Nanosai, fournissant le cadre de base d'une grille informatique distribuée, y compris la découverte de nœuds, la distribution des tâches et la collecte des résultats. Ce module est conceptuellement similaire à Hadoop MapReduce, mais est conçu pour être plus léger.
• Net Ops 0.1.0 (~2017-06) : première version de la boîte à outils réseau non bloquante, offrant des capacités de communication TCP/UDP basées sur Java NIO. Thread Ops, publié en même temps, prend en charge la gestion des threads et les primitives de concurrence.
• V Ops 0.1.0 (~2017-07) : outil d'exécution de langage virtuel pour implémenter des langages spécifiques à un domaine exécutés sur des machines virtuelles virtuelles.

Étape de maturité des composants de base : Mem Ops et RION Ops (2018-2019)

• Mem Ops 0.5.1 (~2018-03) : première version publique, présentant l'API de base du gestionnaire de mémoire zéro-GC.
• Mem Ops 0.6.0 (~2018-09) : fonctionnalités améliorées du pool d'objets, ajout du paramètre ObjectPool à l'interface IObjectFactory.
• Mem Ops 0.6.2 (~2019-03) : introduction de l'interface IBytesAllocator pour prendre en charge l'implémentation de l'allocateur d'octets enfichable.
• Mem Ops 0.6.4 (~2019-06) : corrigez le problème de réinitialisation d'index de Bytes.allocate() et améliorez la stabilité.

Implémentation des capacités de traitement de flux : première version de Stream Ops (2019-2020)

• Stream Ops 0.7.0 (~2019-10) : la première version publique, vérifiant la faisabilité conceptuelle d'un moteur de traitement de flux intégré. Parallèlement, RION Ops a été intégré en tant que module de formatage de données de base.
• Mem Ops 0.7.1 (~2020-06) : La dernière version, ajoutant la prise en charge du module Java JPMS. Le projet est depuis entré dans une période calme de maintenance.
• Modrun Final (~2017-11) : le projet le plus populaire de Nanosai atteignant 102 étoiles, démontrant le besoin des développeurs Java d'un chargeur de classes d'exécution léger.

État actuel et stratégie de maintenance

Depuis 2026, tous les référentiels Nanosai n'ont eu aucun nouveau commit sur GitHub au cours des 3 dernières années. Les activités publiques de Jakob Jenkov ont évolué dans d'autres directions (telles que la création de contenus didactiques liés à l'IA). Le projet n'a pas été déclaré officiellement obsolète, mais est en fait en « mode à faible maintenance » - acceptant les commentaires sur les problèmes mais ne s'engageant pas sur un calendrier de réparation et ne traitant pas la fusion des demandes d'extraction.

Phases	Temps	Changements clés	Maturité des modules
Pose précoce des fondations	2017	Première version de Grid Ops, Net Ops et Thread Ops	Niveau de preuve de concept
Maturité de base	2018-2019	Mem Ops itéré jusqu'à 0.6.4, l'API devient stable	Niveau de production prototype/lumière
Implémentation du traitement de flux	2019-2020	Première version de Stream Ops, version finale de Mem Ops 0.7.1	Niveau prototype
Période de silence de maintenance	2020-présent	Aucune nouvelle fonctionnalité publiée, seuls les commentaires sur les problèmes sont acceptés	Mode maintenance

Les avantages techniques de Nanosai

L'avantage technique de Nanosai ne réside pas dans la fourniture d'une solution de système distribué prête à l'emploi, mais dans une série de compromis techniques incorporés dans sa conception sous-jacente - des compromis qui peuvent se traduire par des gains de performances mesurables dans des scénarios spécifiques.

Latence déterministe pour la gestion explicite de la mémoire

L'écosystème Java a depuis longtemps accepté les pauses incontrôlables provoquées par GC, et la plupart des développeurs Java n'attribueront pas la « distribution longue traîne » des retards des microservices au GC. Cependant, dans les scénarios sensibles à la latence (tels que le trading à haute fréquence, l'inférence d'IA en temps réel), des dizaines de millisecondes de gigue de latence causée par les pauses GC sont inacceptables.

Mem Ops de Nanosai atteint une latence déterministe grâce aux mécanismes suivants :

• Pré-allocation + allocation manuelle/gratuit : remplace le standard new byte[n] de Java pour diviser les sous-plages d'un grand tableau d'octets partagé. La marque est disponible lors de la sortie plutôt que renvoyée à la JVM, éliminant complètement le besoin d'intervention du thread GC.
• Temporisation de défragmentation contrôlable : les développeurs peuvent choisir d'effectuer une défragmentation pendant les périodes de faible charge du système, transformant ainsi le « caractère aléatoire » des pauses GC en pauses « planifiées ». Pour les services d’inférence IA, la défragmentation peut être programmée pour se produire dans une fenêtre d’intervalle pour l’inférence par lots.
• Pré-vérification de la capacité avant allocation : vérifiez la capacité restante du pool avant l'allocation, et si elle est insuffisante, renvoyez une erreur au lieu de lancer le MOO. Ceci est crucial pour créer un mécanisme de contre-pression robuste : Net Ops peut « suspendre automatiquement les lectures de connexions entrantes lorsque l'utilisation du pool de mémoire Mem Ops dépasse 80 % ».

Mécanisme -> Effet -> Chaîne causale du scénario : Élimine les pauses GC → La latence côté CPU est stable au niveau de la microseconde → La latence de la file d'attente des demandes d'inférence GPU est prévisible → L'utilisation du GPU augmente de 10 à 30 % (en fonction de la taille du lot d'inférence et de la complexité du prétraitement du CPU). Scénarios applicables de base : raisonnement en ligne à haut débit (plus de milliers de requêtes par seconde), calcul de fonctionnalités en temps réel et prétraitement des données en streaming.

Zéro surcharge réseau pour l'architecture embarquée

Stream Ops choisit des bibliothèques intégrées au lieu d'une architecture de cluster indépendante, ce qui élimine fondamentalement le coût des « données circulant dans les deux sens sur le réseau ».

• Zéro sérialisation/désérialisation : les données circulent au sein du même processus JVM. Il n'est pas nécessaire de le sérialiser au format binaire, puis de le transmettre au courtier externe via le réseau, puis de le désérialiser à la réception. Pour les scénarios sensibles à la latence en microsecondes, la surcharge de ce saut est énorme.
• Aucun mode de défaillance du réseau : il n'y a aucune complexité des protocoles de consensus distribués tels que les interruptions de connexion, les tentatives d'expiration de délai, les élections du chef de partition, etc. La communication de pipeline interne de Stream Ops est une combinaison d'appels de méthodes locales + de tampons de mémoire partagée, et le mode de défaillance est simplifié en "exceptions en cours".
• Domaine de défaillance au niveau du processus : la limite de fiabilité de Stream Ops est cohérente avec le processus hôte. Les données de flux sont perdues si un processus tombe en panne (à moins qu'elles ne soient explicitement conservées dans le système de fichiers) et qu'aucune réplication inter-processus ou garantie de basculement n'est fournie.

Mécanisme -> Effet -> Chaîne causale du scénario : Architecture intégrée → Élimine les allers-retours du réseau et les frais de sérialisation → La latence d'un seul saut est réduite de millisecondes à microsecondes. Scénarios applicables de base : scénarios qui nécessitent des pipelines de données à haut débit et à faible latence au sein d'un seul processus, tels que les chaînes de prétraitement d'inférence d'IA et les moteurs de décision de transactions financières. Scénarios inappropriés : scénarios dans lesquels les flux de données doivent être partagés entre machines/équipes (à l'heure actuelle, le modèle de publication-abonnement de Kafka est toujours irremplaçable).

Navigabilité des formats de données binaires

La valeur technique la plus unique de RION est la « navigabilité binaire » : sauter les champs non pertinents et localiser directement le décalage d'octets du champ cible sans avoir à décoder complètement la structure de données entière.

• Gain de performances : dans un scénario typique de lecture de vecteur de fonctionnalités, si la structure de données contient 1 000 champs mais que seulement 5 d'entre eux doivent être lus, RION peut réduire le temps de lecture à 0,5-1 % de la désérialisation complète, économisant ainsi le coût d'analyse de la définition de proto par rapport à l'index du numéro de champ des tampons de protocole.
• Zéro copie conviviale : RION fonctionne particulièrement efficacement avec les fichiers mappés en mémoire (mmap) - une fois les données mappées du disque vers la mémoire, l'emplacement des champs et la lecture peuvent être effectués sans copie de mémoire supplémentaire.

Limites architecturales globales et coûts d'ingénierie

Les avantages techniques ci-dessus ne sont pas sans coût. Les compromis techniques de Nanosai imposent les limitations suivantes :

• Goulot d'étranglement lié à un seul processus : l'architecture intégrée signifie que toutes les capacités de traitement sont limitées aux ressources CPU/mémoire d'une seule machine, et qu'une expansion horizontale ne peut pas être réalisée en ajoutant des nœuds comme Kafka ou Spark.
• Persistence Primitive : la persistance Stream Ops prend uniquement en charge les systèmes de fichiers locaux, sans réplication, partitionnement ou basculement intégrés. Toute stratégie de haute disponibilité pour les données persistantes doit être mise en œuvre par l'utilisateur au niveau de la couche application.
• Communauté et écologie faibles : aucun écosystème de contributeurs actif, aucun support commercial et aucune vérification de cas de production mature. La sélection technologique est entrée dans la gamme de risques consistant à « parier sur les travaux de développeurs individuels ».
• Java 8 Baseline : Le composant utilise Java 8 comme cible de compilation et ne profite pas des nouvelles fonctionnalités telles que les threads virtuels (Project Loom) et l'accès à la mémoire externe (Project Panama) dans les versions LTS ultérieures (telles que Java 17/21). Il peut y avoir des risques de compatibilité avec les futures migrations.

Comment utiliser Nanosai

Nanosai n'est pas disponible en tant que service SaaS ou cloud, tous les modules sont distribués sous forme de bibliothèques Java via Maven Central. Le processus d'utilisation est divisé en trois étapes : "Introduire les dépendances -> Intégration du codage -> Créer et déployer".

Premiers pas : introduction aux dépendances Maven

En prenant le noyau Mem Ops comme exemple, ajoutez pom.xml :

<dépendance>
    <groupId>com.nanosai</groupId>
    <artifactId>opérations mémoire</artifactId>
    <version>0.7.1</version>
</dépendance>

L'introduction de Stream Ops nécessite d'ajouter ses dépendances en même temps :

<dépendance>
    <groupId>com.nanosai</groupId>
    <artifactId>opérations de flux</artifactId>
    <version>0.7.0</version>
</dépendance>
<!-- Stream Ops dépend automatiquement des mem-ops et des rion-ops -->

Étapes d'utilisation typiques

Étape 1 : Configurer le pool de mémoire

//Créer un allocateur d'octets de 100 Mo
Allocateur ByteAllocator = nouveau ByteAllocator (100 * 1024 * 1024);

// Alloue des blocs d'octets de 1 Ko à partir du pool
Octets octets = allocator.allocate(1024);

// Libération une fois l'utilisation terminée
octets.free();

Étape 2 : Définir le pipeline de traitement de flux (Stream Ops)

//Créer un processeur de flux
Processeur StreamProcessor = new StreamProcessor();

//Définir le pipeline de traitement
processeur
    .source(rawDataStream) //Source d'entrée
    .filter(enregistrement -> record.isValid()) // Filtre
    .map(Record::transform) // Transformation
    .sink(outputStream); // sortie

// Commencer le traitement
processeur.start();

Étape 3 : Intégrer les communications réseau (Net Ops)

//Créer un serveur non bloquant
Serveur NetServer = nouveau NetServer (port) ;
server.setMessageProcessor(message -> {
    // Traiter les messages dans la boucle d'événements, pas de compétition de verrouillage
});
serveur.start();

Entrée à chaque module

Module	Méthode d'accès	Classe de base	Entrée typique
Opérations mémoire	Dépendances Maven	ByteAllocator, octets, ObjectPool	nouveau ByteAllocator(taille)
Opérations de flux	Dépendances Maven	StreamProcessor, StreamSource, StreamSink	nouveau StreamProcessor()
Opérations Internet	Dépendances Maven	NetServer, NetClient, MessageProcessor	nouveau NetServer(port)
Opérations RION	Dépendances Maven	RionReader, RionWriter	RionReader.readFrom(octets)
Opérations de discussion	Dépendances Maven	ThreadManager, Planificateur de tâches	nouveau ThreadManager(poolSize)
Modrun	Dépendances Maven/CLI	ModrunLanceur	java -jar modrun.jar
Opérations de grille	Dépendances Maven	GridNode, GridTask, GridResult	nouveau GridNode(config)

Créer et déployer

Le projet Nanosai est construit à l'aide d'Apache Ant (certains modules fournissent Maven POM) et le produit final est un fichier JAR standard. Lors du déploiement, placez simplement le JAR dépendant sur le chemin de classe. Tous les modules ne reposent pas sur des fichiers de configuration externes et tous les paramètres sont définis via des API de programmation.

Remarque :

• La taille du pool d'octets pour Mem Ops est pré-calculée en fonction du budget mémoire et de la charge maximale de l'application. Une valeur trop petite entraînera des échecs d'allocation fréquents, et une valeur trop élevée gaspillera de la mémoire.
• Le modèle de boucle d'événements à thread unique de Stream Ops est sensible aux opérations de blocage lors de la gestion des rappels - n'effectuez pas d'attentes d'E/S ou d'appels à distance dans les rappels, sinon l'ensemble du pipeline sera bloqué.
• En mode de gestion explicite de la mémoire, assurez-vous d'associer free() à chaque appel alloc(). Il est recommandé d'utiliser try-finally ou une classe wrapper encapsulée comme AutoCloseable pour éviter les fuites de mémoire sous des chemins anormaux.

Prix des produits Nanosai

Le modèle de tarification de Nanosai est extrêmement simple – gratuit dans tous les scénarios. En tant que projet open source sous licence Apache 2.0, Nanosai ne propose aucune version payante, licence d'entreprise ou service de support commercial.

Implications financières des licences open source

• Frais de licence du logiciel : zéro. Les particuliers, les entreprises et les intégrations commerciales peuvent tous être utilisés gratuitement, sans limite sur le nombre d'utilisateurs, sans émasculation fonctionnelle et sans exigences d'audit.
• Support commercial : non disponible. Pas d'équipe de support technique officielle, pas de SLA, pas de canal de contrat de conseil. Si une entreprise a besoin de garanties au niveau de la production, elle doit développer ses propres capacités de support interne ou trouver une société tierce de conseil en performances Java.
• Version hébergée dans le cloud : n'existe pas. Nanosai n'a jamais lancé de produit SaaS ou PaaS. Toute utilisation nécessite un auto-déploiement et une gestion.

Comparaison des coûts avec des solutions similaires

Dimension du coût	Nanosaï	Apache Kafka	Rédis	File d'attente des chroniques (édition professionnelle)
Frais de licence logicielle	0	0 (Apache 2.0)	0 (SSPL)	Payé annuellement
Frais d'hébergement	Version non gérée	Confluent Cloud, paiement à l'utilisation	Redis Enterprise avec paiement à l'utilisation	Auto-déploiement
Effectif d'exploitation et de maintenance (estimé)	Moyen-élevé (compétences de faible niveau requises)	Moyen (exploitation et maintenance du cluster)	Faible-moyen	Faible (soutien commercial)
Courbe d'apprentissage	Raide	Moyen	Faible	Moyen
Assistance commerciale	Aucun	Fourni par Confluent	Fourni par Redis Inc.	Fourni par le fournisseur

Suggestions d'achat pour les entreprises

Le caractère « gratuit » de Nanosai doit être recompris du point de vue du coût total de possession. Pour les systèmes Java en temps réel qui recherchent une latence déterministe, la solution technique de Nanosai présente des caractéristiques uniques, mais le manque de support commercial signifie que les entreprises doivent supporter tous les risques techniques. Il est recommandé que les conditions suivantes soient prises en compte pour être incluses dans le système de production :

• Avoir au moins 1 à 2 ingénieurs seniors au sein de l'équipe avec une expérience en Java NIO, en gestion de mémoire et en programmation sans GC.
• Effectuer des tests indépendants de performance et de stabilité des modules de base de Nanosai (en particulier Mem Ops) pour vérifier leurs performances dans des conditions d'échelle et de charge de données réelles.
• Établir la préparation pour la maintenance interne du fork - si le projet n'a pas été mis à jour depuis longtemps et provoque des problèmes de compatibilité des versions JVM, l'équipe doit être capable de le résoudre elle-même.

Scénarios d'application de Nanosai

Les scénarios d'application de Nanosai sont concentrés dans des domaines techniques qui « nécessitent une latence déterministe, un déploiement intégré et zéro pause GC », couvrant les trois directions principales de l'infrastructure de l'IA, de la technologie financière et de l'informatique de pointe IoT.

Pipeline de prétraitement d'inférence d'IA (scénario d'attaque par réduction de dimensionnalité)

Le délai de bout en bout du service d'inférence d'IA en ligne est composé de quatre sections : « transmission réseau + prétraitement des demandes + inférence GPU + post-traitement des résultats ». Lorsque l'inférence GPU elle-même a été optimisée (par exemple en utilisant TensorRT, vLLM et d'autres technologies), le prétraitement côté CPU devient souvent un goulot d'étranglement.

Point d'intervention de Nanosai :

• Mem Ops : gérez les tampons d'entrée et de sortie pour les demandes d'inférence, éliminant ainsi les retards de file d'attente côté CPU causés par les pauses du GC. Dans des scénarios à haut débit traitant plus de 10 000 requêtes par seconde, la gestion explicite de la mémoire de Mem Ops réduit la latence P99 côté CPU de 50 ms à moins de 1 ms.
• Stream Ops : organisez « Demande de désérialisation -> Tokenisation -> Extraction de fonctionnalités -> Assemblage d'entrée de modèle » dans un pipeline de traitement de flux en cours de processus et transférez les données via un tampon de mémoire partagé entre chaque étape pour éviter les frais généraux de sérialisation et de désérialisation.
• RION Ops : codez les vecteurs de fonctionnalités et les métadonnées du modèle, en tirant parti de la navigabilité binaire pour permettre un accès aléatoire sans copie aux champs de fonctionnalités.

Schéma d'architecture :

Demande d'inférence → Net Ops (réception HTTP/TCP)
         → Pipeline Stream Ops : Désérialisation → Tokenisation → Calcul de fonctionnalités → Assemblage de requêtes d'inférence
         → Moteur d'inférence (GPU)
         → Pipeline Stream Ops : désérialisation des résultats → Post-traitement → Encodage
         → Net Ops (retour HTTP/TCP)

Transactions financières à haute fréquence (référence de sélection technologique)

Les systèmes de trading financier sont peut-être les plus sensibles à la latence de tous les secteurs : les différences de latence en microsecondes ont un impact direct sur la rentabilité d'une stratégie de trading.

• Mem Ops + Net Ops : Créez une passerelle d'ordres en ligne pour compléter la réception, le décodage et l'inspection du contrôle des risques des données de marché dans une mémoire tampon pré-allouée, sans qu'aucune pause GC n'intervienne dans le chemin critique des transactions.
• Stream Ops : en tant que bus d'événements interne du moteur de stratégie de trading, il connecte les sources de marché, les modules de calcul de stratégie et d'ordres via des pipelines de flux en cours de processus, éliminant ainsi les retards de saut du middleware.

⚠️Avertissement de risque : Nanosai n'a jamais divulgué ses cas de déploiement dans la production de trading haute fréquence dans aucune information publique. Les applications ci-dessus sont des analyses déductives de faisabilité technique et ne représentent pas les meilleures pratiques éprouvées. Les systèmes de trading financier ont des exigences extrêmement élevées en matière de stabilité. Il est recommandé de choisir Chronicle Queue ou Aeron, qui ont des mentions claires en matière de production, et d'utiliser Nanosai comme référence de recherche technique.

Edge computing IoT et systèmes embarqués

Les appareils périphériques aux ressources limitées (passerelles Raspberry Pi ARM, appareils mobiles) ne peuvent pas exécuter un cluster Kafka complet ou une instance Redis, mais ont toujours des besoins en matière de traitement de données en streaming.

• Avantages de l'architecture intégrée : Stream Ops et Mem Ops sont intégrés dans des applications Edge sous la forme de centaines de packages KB JAR, sans dépendances externes, sans démons et sans occupation de port.
• Mise en cache et synchronisation hors ligne : les appareils Edge peuvent conserver les données des capteurs localement (persistance des fichiers Stream Ops) lorsque le réseau est déconnecté, et se synchroniser avec le cloud par lots après la restauration du réseau.

Ne convient pas à la scène

Nanosai ne convient pas aux scénarios suivants :

• Partage de données entre équipes/services : architecture de microservices nécessitant un modèle de publication-abonnement, plusieurs groupes de consommateurs et des files d'attente de messages persistantes. Kafka ou RabbitMQ sont de loin supérieurs à Nanosai dans de tels scénarios.
• Traitement de données à grande échelle nécessitant une expansion horizontale : les moteurs informatiques distribués tels que Spark et Flink présentent des avantages architecturaux évidents lors du traitement de données dépassant le niveau du téraoctet.
• Exigences de prototypage rapide et de faibles seuils de compétences : si l'équipe se concentre sur le développement commercial et n'a pas la capacité d'optimiser les performances Java sous-jacentes, le coût d'apprentissage et la charge de maintenance de Nanosai dépasseront ses avantages en termes de performances.
• Entreprises recherchant une assistance commerciale : tout système de production nécessitant des garanties SLA, une assistance technique du fournisseur ou une certification de conformité.

Groupes applicables de Nanosai

La valeur du Nanosai varie considérablement entre les mains de différentes personnes. Il s’agit d’un « outil haut de gamme » typique – puissant mais avec un seuil élevé, adapté à des rôles et des tâches spécifiques.

Rôles applicables

• Ingénieur d'infrastructure Java : l'équipe technique intermédiaire chargée de créer le middleware interne, le cadre de communication ou la plate-forme de calcul haute performance de l'entreprise. Chaque module de Nanosai peut être utilisé comme élément de base sur lequel est encapsulé le cadre de service interne haute performance de l'entreprise. Ce type d'équipe dispose de suffisamment de profondeur technique pour compenser le manque de documentation et de soutien de la communauté de Nanosai.

• Ingénieur d'optimisation du système d'inférence IA : équipe MLOps ou moteur d'inférence responsable du déploiement de modèles formés en tant que services d'inférence en ligne et de l'optimisation de la latence et du débit d'inférence. Les capacités zéro GC de Mem Ops et le pipeline intégré de Stream Ops peuvent être intégrées directement dans des backends personnalisés de cadres d'inférence tels que Triton Inference Server ou vLLM pour optimiser les flux de pré- et post-traitement côté CPU.

• Chercheur/éducateur en systèmes distribués Java : les didacticiels Nanosai de Jakob Jenkov (hébergés sur jenkov.com et HackerNoon) sont des ressources pédagogiques de haute qualité dans les domaines de Java NIO, de la gestion de la mémoire et du traitement des flux. Pour les développeurs qui apprennent la programmation Java haute performance, la lecture du code source de Nanosai (en particulier l'allocateur d'octets de Mem Ops et la boucle d'événements de sélection de Net Ops) est un excellent chemin d'apprentissage.

• Développeur de systèmes de trading à faible latence : équipe de trading quantitatif explorant la mise en œuvre de Java à haut déterminisme. Notez cependant que ce groupe devrait donner la priorité à l’évaluation d’alternatives éprouvées en production telles que Chronicle Queue, Aeron et OpenHFT.

Ne convient pas à la foule

• Business Backend Development Engineer : une équipe qui utilise Spring Boot pour créer l'API CRUD. Le modèle de gestion explicite de la mémoire et de programmation de boucles d'événements de Nanosai est trop éloigné du paradigme du développement commercial. Les introduire de force augmentera la complexité inutile.

• Développeurs d'applications IA (direction non infrarouge) : développeurs qui appellent l'API OpenAI/DeepSeek pour créer des applications IA. Le problème que Nanosai résout n'existe pas dans le modèle d'appel d'API (la latence de bout en bout de l'API est déterminée par le réseau et le modèle), et il n'existe aucun scénario d'utilisation.

• Utilisateurs recherchant un produit SaaS prêt à l'emploi : Utilisateurs ayant besoin d'une API REST d'interface web et d'une configuration sans code. Nanosai est une bibliothèque de code pure sans aucun composant visuel.

Résumé et Outlook

Nanosai est un projet open source plutôt "idéaliste" - il a personnellement construit une chaîne d'outils complète depuis la gestion de la mémoire jusqu'au traitement des flux, de la communication réseau à l'informatique distribuée, et montre des choix d'ingénierie clairs et radicaux dans la conception technique (zéro GC, déploiement embarqué, navigabilité binaire). Pour les scénarios spécifiques de l'écosystème Java qui sont perturbés par les pauses GC et la surcharge de communication des microservices, Nanosai propose une voie technique qui mérite d'être explorée.

Compétences de base : La gestion explicite de la mémoire de Mem Ops est la partie la plus différenciée de Nanosai. Il offre une capacité de « latence déterministe » rare dans l'écosystème Java, qui correspond naturellement aux exigences d'optimisation du prétraitement du processeur des scénarios d'inférence d'IA. L'architecture intégrée de Stream Ops occupe une position unique dans les scénarios d'IoT et d'informatique sans serveur. La navigabilité binaire de RION Ops offre des possibilités d'ingénierie pour le stockage de fonctionnalités et l'optimisation partielle de la lecture.

Limites actuelles : la plus grande incertitude actuelle de Nanosai ne concerne pas ses capacités techniques, mais son activité de projet. Aucune nouvelle fonctionnalité n'a été publiée depuis mi-2020, les fondateurs ont évolué vers d'autres directions et les contributions de la communauté sont proches de zéro. Le risque technique de placer un projet sur le chemin de production critique est élevé jusqu'à ce qu'il soit réactivé ou au moins qu'il ait un engagement clair de maintenance à long terme. En outre, le manque de références de performances tierces et de cas de déploiement de qualité industrielle constitue également un obstacle à l’information difficile à surmonter pour les évaluateurs.

Écologie et avenir : les idées techniques de Nanosai (en particulier la gestion explicite de la mémoire et le traitement des flux intégré) sont réimplémentées de différentes manières par de nouveaux projets. Project Loom (threads virtuels Java) réduit la complexité de la programmation simultanée, Project Panama fournit une API d'accès à la mémoire externe plus sûre et des projets actifs tels que Chronicle Queue et Aeron ont accumulé plus d'expérience de production dans la même direction. Nanosai est plus susceptible de rester dans l'histoire comme une « preuve de concept technologique » que comme une norme industrielle largement adoptée.

Évaluation des risques d'approvisionnement et d'adoption : Pour les équipes envisageant d'adopter Nanosai, il est recommandé de suivre le principe de « vérification en trois étapes » : Tout d'abord, créez une preuve de concept (PoC) dans un environnement hors production pour vérifier si l'amélioration réelle des performances de Nanosai dans le scénario cible répond aux attentes (par exemple, si le retard de convergence provoqué par l'élimination du GC est significatif). La deuxième étape consiste à comparer et évaluer les alternatives en cours de développement actif (Aeron, Chronicle Queue, Java 21 Virtual Threads + LMAX Disruptor) et à faire des compromis entre performances, coûts de maintenance et support communautaire. La troisième étape, si vous décidez toujours d'utiliser Nanosai, vous devez vous préparer à la maintenance de Fork - copiez le code source dans l'entrepôt interne, établissez un pipeline CI/CD et affectez une personne dédiée pour suivre l'impact de compatibilité des mises à jour de version JVM. Pour les entreprises qui ne peuvent accepter les risques ci-dessus, il est recommandé de choisir des produits du même type avec un soutien commercial et des communautés actives.

Informations de version

• Opérations mémoire 0.7.1 ：Mem Ops ajoute la prise en charge de la création de modules Java JPMS, aucun changement fonctionnel. Stream Ops 0.7.0 est la première version rendue publique. L'ensemble du projet est en phase de maintenance et il n'y a pas de développement actif. （~2020-06）
• Opérations de flux 0.7.0 ：La première version publique de Stream Ops, fournissant les fonctionnalités de base du moteur de traitement de flux intégré. （~2019-10）
• Opérations mémoire 0.6.4 ：Correction d'un bug dans Bytes.allocate() où les index n'étaient pas réinitialisés correctement. （~2019-06）
• Opérations mémoire 0.6.2 ：Présentation de l'interface IBytesAllocator pour prendre en charge l'implémentation d'un allocateur enfichable. （~2019-03）
• Opérations mémoire 0.6.0 ：La méthode d'instance d'interface IObjectFactory ajoute le paramètre ObjectPool. （~2018-09）
• Opérations mémoire 0.5.1 ：La première version publique de Mem Ops, offrant des fonctionnalités de base d'allocation d'octets et de pooling de mémoire. （~2018-03）
• Opérations réseau 0.1.0 ：Net Ops et Thread Ops sont lancés pour la première fois, offrant des fonctionnalités de base d'E/S réseau non bloquantes et de gestion des threads. （~2017-06）
• Opérations de grille 0.1.0 ：Grid Ops est lancé, fournissant un cadre de base pour les grilles informatiques distribuées. （~2017-04）