jakiro
Auteur: Arweaveoasis, Source: Permadao
Cet article examine les avantages de l’adoption d’une architecture de microservice (ou modèle d’acteur) et analyse la complexité logique qu’il apporte au développement d’applications.
La sortie de @AotheComputer a sans aucun doute apporté un nouveau type de réflexion et de pratique à l’ensemble de l’écosystème @arweaveco et même à toute l’industrie Web3.Cela se reflète non seulement dans l’attention de la majorité des investisseurs, mais aussi pour attirer un grand nombre de développeurs de haute qualité pour commencer des recherches approfondies.
Qu’est-ce qui entrave l’adoption massive de Web3?
C’est très simple, car il y a trop peu d’applications décentralisées à utiliser.
Sur la base de la situation actuelle de l’infrastructure Web3, des outils de développement, des pratiques d’ingénierie logicielle, etc., de nombreux types d’applications décentralisées sont presque impossibles à réaliser.
En termes d’infrastructures, je pense que l’émergence de l’AO comble certaines des grandes lacunes.Cependant, la complexité du projet pour construire des applications décentralisées à grande échelle est toujours intimidante.Cela nous rend impossible de développer une décentralisation plus diversifiée, plus grande et souvent meilleure, plus fonctionnelle lorsque les ressources sont limitées – généralement dans les étapes initiales du développement des choses – pour développer une application plus diversifiée, plus grande et plus fonctionnelle.
Ne croyez pas en ces mots absurdes comme «les contrats intelligents / programmes sur la chaîne devraient être très simples, il n’est pas nécessaire de les rendre trop compliqués»!
Le vrai problème n’est pas de « ne pas vouloir », mais « pas » – je ne peux pas le faire.
AO est un système informatique fonctionnant sur Arweave, conçu pour obtenir une puissance de calcul illimitée vérifiable.C’est le nom court pour les acteurs orientés.Comme son nom l’indique, cela signifie que les applications décentralisées exécutées sur AO nécessitent des méthodes de conception et de programmation basées sur le modèle d’acteur.
En fait, AO n’a pas été le premier à utiliser le modèle d’acteur pour la blockchain (ou « infrastructure décentralisée »).Par exemple, le contrat intelligent de Ton est construit à l’aide du modèle d’acteur.En parlant de tonne, je pense personnellement qu’il a des similitudes avec AO à certains égards.
Pour les développeurs Web2 qui n’ont pas encore eu une compréhension approfondie de Web3, si vous voulez comprendre rapidement la plus grande fonctionnalité d’AO ou TON par rapport à d’autres « blockchains monolithiques », un moyen pratique de faire fonctionner les contrats intelligents sur eux (chaîne) ( La partie 1) est considérée comme un « microservice ».AO ou TON est l’infrastructure qui prend en charge le fonctionnement de ces microservices, tels que Kafka, Kubernetes, etc.
En tant que Crud Boy senior qui s’est concentré sur le développement des applications depuis plus de 20 ans, je suis personnellement très heureux de voir l’émergence de blockchains non monopole tels que AO et TON, et sont pleins d’attentes pour leur développement.Ci-dessous, je voudrais parler de mes opinions sur AO du point de vue d’un développeur d’applications.Peut-être que certains développeurs d’applications ressentiront du ressentiment, cela suffit.
Est-il vraiment nécessaire d’appliquer le modèle d’acteur à la blockchain?
La réponse est oui.Regardez les applications Web2 qui ont obtenu une « adoption massive » et vous verrez.
Trop d’architectes savent déjà comment «faire de grandes» applications Web2: architecture microservice (MSA), architecture axée sur les événements (EDA), mécanisme de communication de message, modèle de cohérence finale, rupture … peu importe comment ils sont appelés, coexistent toujours avec le modèle d’acteur.Certains de ces concepts peuvent même être considérés comme des aspects différents d’une chose.Ainsi, dans le texte suivant, nous ne faisons pas de distinction entre les «microservices» et l’acteur, vous pouvez les considérer comme des synonymes.
La prospérité d’Internet aujourd’hui est inséparable de la sagesse de ces architectes.Ils explorent, pratiquent et résument constamment et ont finalement formé un système de pratique d’ingénierie complet.
En tant qu’infrastructure Web3, AO fait un excellent travail.Au moins, AO a montré un grand potentiel en tant que meilleur courtier de messagerie décentralisé dans le champ Web3 actuel (à mes yeux).Je crois que les développeurs d’applications Web2 traditionnelles peuvent immédiatement comprendre l’importance de ceci: si le courtier de messages de type Kafka ou Kafka n’est pas disponible, pouvez-vous imaginer combien de grandes applications Internet ont maintenant « comment écrire des programmes »?
Bien que le modèle d’acteur ait des avantages théoriques à de nombreux aspects, qu’il s’agisse du modèle d’acteur ou de l’architecture de microservice, à mon avis, c’est plus un problème que les développeurs doivent développer certaines applications (en particulier les grandes applications) afin de développer certaines applications (en particulier les grandes applications).
Utilisons un exemple simple pour illustrer cela aux lecteurs non techniques.Supposons que toutes les banques du monde mènent des affaires en fonction d’un « ordinateur mondial », et cet ordinateur mondial est un système monolithique.Ensuite, lorsque le client ICBC « Zhang San » se retire de 100 yuans à « Li si » qui ouvre un compte à la China Merchants Bank, le développeur peut écrire le code du programme de transfert comme celui-ci:
1. Démarrer une transaction (ou des «transactions», qui sont le même mot en anglais);
2. Déduire 100 yuans du compte de Zhang San;
3. Ajoutez 100 yuans au compte de Li si;
4. Soumettre les transactions.
Quelle que soit la mesure où il y a un problème avec les étapes ci-dessus, par exemple, la troisième étape, qui augmente le montant du compte de Li si.Soit dit en passant, lors de la rédaction de programmes comme celui-ci, nous appelons l’utilisation du modèle « cohérence solide ».
Et si les ordinateurs de ce monde sont des systèmes qui adoptent l’architecture microservice (MSA)?
Ensuite, le microservice (ou acteur) qui gère le compte ICBC est presque peu susceptible d’être le même que le microservice qui gère le compte bancaire China Merchants.Supposons d’abord qu’ils ne sont en effet pas les mêmes.Pour le moment, le développeur peut avoir besoin d’écrire le code de transfert comme ceci:
1. L’acteur ICBC enregistre d’abord les informations suivantes: « Zhang San transfère 100 yuan à li si »; l’acteur ICBC déduit 100 yuan du compte de Zhang San et envoie un message à l’acteur CMB: « Zhang San transfère 100 yuan à Li si. Yuan » ;
2. L’acteur CMB a reçu un message, ajoutant 100 yuans au compte de Li si, puis a envoyé un message à l’acteur ICBC, «Li si a reçu 100 yuans transférés par Zhang San»;
3. L’acteur ICBC a reçu le message et l’a enregistré: « Zhang San a transféré 100 yuan à Li SI, et il a réussi. »
Ce qui précède n’est qu’un processus de « tout va bien ».Mais que se passe-t-il si une certaine étape, comme la deuxième étape, « ajouter 100 yuan au compte de Li si », et il y a un problème?
Les développeurs doivent écrire une telle logique de traitement pour ce problème possible:
-
L’acteur CMB a envoyé un message à l’acteur ICBC: « Zhang San a transféré 100 yuan à Li SI, mais le traitement a échoué. »
-
L’acteur ICBC a reçu un message selon lequel il a ajouté 100 yuans au compte de Zhang San et a enregistré: « Zhang San a transféré 100 yuans à Li si, mais il a échoué. »
C’est ainsi que le programme est écrit, nous l’appelons le modèle de cohérence finale.
Comme mentionné ci-dessus, les lecteurs non techniques devraient être en mesure de ressentir intuitivement l’énorme différence de charge de travail entre l’application de l’architecture monolithique en développement et l’application du développement de MSA, non?Vous devez savoir que l’exemple de transfert mentionné ci-dessus n’est qu’une application très simple, si nous l’appelons une application, pas une fonction.Les fonctions dans les grandes applications sont souvent beaucoup plus compliquées que de tels exemples.
Quelle est la taille de ce microservice?
En d’autres termes, « Ce microservice est-il trop grand et devrait-il être divisé en deux? »
Malheureusement, il n’y a pas de réponse standard à cette question, c’est un art.Plus les microservices sont petits, plus il est facile d’optimiser le système en créant de nouvelles instances et en les déplaçant à la demande.Cependant, plus le microservice est petit, plus il est difficile pour les développeurs de mettre en œuvre des processus complexes, comme indiqué ci-dessus.
Soit dit en passant, divisez une application en plusieurs microservices, du point de vue de la conception de la base de données, il s’agit du soi-disant « rayonnage ».L’une des meilleures pratiques pour l’architecture de microservice est que chaque microservice utilise une seule base de données locale qui lui est propre.En termes simples, Sharding permet une expansion horizontale.Lorsque l’ensemble de données devient trop grand pour être traité de la manière traditionnelle, il n’y a rien d’autre (pour le faire évoluer), sauf les diviser en fragments plus petits.
Revenez au problème de division des microservices.Afin de mieux pratiquer cet art, nous devons maîtriser l’utilisation de certains outils de réflexion.Le « agrégat » de DDD (conception axée sur le domaine) est un « gros tueur » que vous devez avoir.Je veux dire, cela vous aide à détruire la « complexité de base » dans la conception des logiciels.
Je pense que l’agrégation est le concept le plus important de DDD au niveau tactique.
Qu’est-ce que l’agrégation?L’agrégation établit une frontière entre les objets, en particulier les entités.Un agrégat doit contenir et une seule entité racine agrégée et peut contenir un nombre incertain d’entités internes agrégées (ou entités racines non agrégées).
Nous pouvons utiliser le concept d’agrégation pour analyser et modéliser les champs que l’application sert; puis lors du codage, nous pouvons diviser les microservices en fonction de l’agrégation.Le moyen le plus simple est de mettre en œuvre chaque agrégation en microservice.
Cependant, peu importe à quel point vous êtes qualifié, vous ne pouvez pas garantir que vous ferez la bonne chose la première fois.Pour le moment, un outil qui vous permet de vérifier les résultats de la modélisation dès que possible et si cela ne fonctionne pas, il vous sera précieux.
Qu’est-ce qui pourrait constituer une barrière à la migration des grandes applications Web2 vers l’écosystème AO?
Je veux parler des problèmes d’exécution de la langue et du programme.
AO est un protocole de données.Vous pouvez le considérer comme un ensemble de spécifications d’interface qui définissent comment chaque « unité » dans un réseau AO implémente la collaboration.Actuellement, la mise en œuvre officielle d’AO comprend un environnement de machine virtuelle basée sur WASM et un environnement d’exécution LUA (AO-LIB) compilé en WASM, visant à simplifier le développement des processus AO.
Lua est une petite et belle langue.Lua est généralement censé avoir l’avantage de son intégration légère et facile dans d’autres langues, ce qui le rend particulièrement utile dans des scénarios spécifiques, tels que le développement de jeux.Cependant, la langue LUA n’est pas le choix grand public pour développer de grandes applications Internet.Le développement d’applications Internet à grande échelle a souvent tendance à utiliser des langues telles que Java, C #, PHP, Python, JavaScript, Ruby, etc., car ces langues fournissent un écosystème et une chaîne d’outils plus complets, ainsi qu’un support communautaire plus large .
Certaines personnes peuvent affirmer que ces langues peuvent être compilées en bytecode WasM et s’exécuter dans une machine virtuelle WASM.Mais en fait, bien que WASM ait fortement fonctionné dans le domaine du développement du Web, l’utilisation actuelle de WASM comme environnement d’exploitation back-end pour les applications Internet n’est pas un choix grand public.Notez que les contrats intelligents (programmes sur chaîne) sont le « nouveau backend » de l’ère Web3.
Résumer
En résumé, nous avons discuté des avantages de l’adoption d’une architecture de microservice (ou du modèle d’acteur) et de la complexité qu’elle apporte au développement d’applications.Certaines complexités sont inévitables.Par exemple, même dans des environnements WEB2 d’ingénierie plus matures, la réalisation de la « cohérence finale » basée sur la communication de messages est déjà un grand défi pour de nombreux développeurs.Le défi semble être encore plus évident lors du développement de DAPP sur la plate-forme AO de première année – bien sûr, il est tout à fait compréhensible.Un exemple est montré au début de l’article de lien suivant.
https://github.com/dddappp/ao-demo?tab=readme-ov-file#an-ao-dapp-development-demo-with-a-low-code-approach
Nous savons tous que la bataille entre les chaînes publiques est en fait une guerre pour les développeurs d’applications.Alors, comment AO peut-il gagner des développeurs dans ce cas?
Je pense qu’il est nécessaire de continuer à apprendre de Web2 qui a déjà reçu une «adoption massive».Cela comprend non seulement l’apprentissage de son infrastructure, mais aussi tous les aspects tels que la méthodologie de développement, les outils de développement et les pratiques d’ingénierie logicielle.Dans le prochain article, je vais vous montrer l’une des solutions auxquelles je crois fermement: le développement à faible code.
