jakiro
Autor: Arweageasis, Fuente: Permadao
Este artículo analiza las ventajas de adoptar una arquitectura de microservicio (o modelo de actor) y analiza la complejidad lógica que aporta al desarrollo de aplicaciones.
El lanzamiento de @aothecomputer, sin duda, ha traído un nuevo tipo de pensamiento y práctica a todo el ecosistema @Arweaveeco e incluso a toda la industria Web3.Esto no solo se refleja en la atención de la mayoría de los inversores, sino también en atraer una gran cantidad de desarrolladores de alta calidad para comenzar una investigación en profundidad.
¿Qué dificulta la adopción masiva de Web3?
Es muy simple, porque hay muy pocas aplicaciones descentralizadas que vale la pena usar.
Según la situación actual de la infraestructura de Web3, las herramientas de desarrollo, las prácticas de ingeniería de software, etc., muchos tipos de aplicaciones descentralizadas son casi imposibles de lograr en la actualidad.
En términos de infraestructura, creo que la aparición de AO llena algunos de los mayores vacíos.Sin embargo, la complejidad del proyecto para construir aplicaciones descentralizadas a gran escala sigue siendo desalentadora.Esto nos hace imposible desarrollar una descentralización más diversa, más grande y a menudo mejor y más funcional cuando los recursos están limitados, generalmente en las etapas iniciales del desarrollo de las cosas, para desarrollar una aplicación más diversa, más grande y más funcional.
No creas en esas palabras sin sentido como «los contratos inteligentes/programas en la cadena deberían ser muy simples, ¡no hay necesidad de hacerlas demasiado complicadas»!
El verdadero problema no es «no querer», sino «no», no puedo hacerlo.
AO es un sistema informático que se ejecuta en Arweave, diseñado para lograr una potencia informática ilimitada verificable.Es el nombre corto para el actor orientado.Como su nombre indica, esto significa que las aplicaciones descentralizadas que se ejecutan en AO requieren métodos de diseño y programación basados en el modelo de actor.
De hecho, AO no fue el primero en usar el modelo de actor para blockchain (o «infraestructura descentralizada»).Por ejemplo, el contrato inteligente de TON se crea utilizando el modelo de actor.Hablando de toneladas, personalmente creo que tiene similitudes con AO de alguna manera.
Para los desarrolladores de Web2 que aún no han tenido una comprensión profunda de Web3, si desea comprender rápidamente la característica más importante de AO o TON en comparación con otras «blockchains monolíticas», una forma conveniente de hacer que los contratos inteligentes se ejecuten en ellos (cadena) ((cadena) ( La Parte 1) se considera como un «microservicio».AO o TON es la infraestructura que admite el funcionamiento de estos microservicios, como Kafka, Kubernetes, etc.
Como un niño crud senior que se ha centrado en el desarrollo de aplicaciones durante más de 20 años, personalmente estoy muy feliz de ver la aparición de blockchains no monopolio como AO y TON, y estoy lleno de expectativas para su desarrollo.A continuación, me gustaría hablar sobre mis puntos de vista sobre AO desde la perspectiva de un desarrollador de aplicaciones.Quizás algunos desarrolladores de aplicaciones se sientan resentidos, eso es suficiente.
¿Es realmente necesario aplicar el modelo de actor a blockchain?
La respuesta es sí.Mire las aplicaciones Web2 que han logrado una «adopción masiva» y verá.
Demasiados arquitectos ya saben cómo «hacer grandes» aplicaciones Web2: Arquitectura de microservicio (MSA), arquitectura impulsada por eventos (EDA), mecanismo de comunicación de mensajes, modelo de consistencia final, fragmentos … no importa lo que se llamen, siempre coexisten con El modelo de actor.Incluso se puede decir que algunos de estos conceptos son solo aspectos diferentes de una cosa.Entonces, en el siguiente texto, no distinguimos entre «microservicios» y actor, puede pensar en ellos como sinónimos.
La prosperidad de Internet hoy es inseparable de la sabiduría de estos arquitectos.Exploran, practican y resumen constantemente, y finalmente formaron un sistema de práctica de ingeniería completo.
Como infraestructura Web3, AO hace un gran trabajo.Al menos, AO ha mostrado un gran potencial como el mejor corredor de mensajería descentralizado en el campo Web3 actual (a mis ojos).Creo que los desarrolladores de aplicaciones Web2 tradicionales pueden comprender inmediatamente la importancia de esto: si Kafka o Kafka Menss Broker no está disponible, ¿te imaginas cuántas aplicaciones de Internet grandes ahora tienen «cómo escribir programas»?
Aunque el modelo de actor tiene ventajas teóricas en muchos aspectos, ya sea el modelo de actor o la arquitectura de microservicio, en mi opinión, es más un problema que los desarrolladores tienen que desarrollar ciertas aplicaciones (especialmente aplicaciones grandes) para desarrollar ciertas aplicaciones (especialmente aplicaciones grandes).
Usemos un ejemplo simple para ilustrar esto a los lectores no técnicos.Supongamos que todos los bancos del mundo realizan negocios basados en una «computadora mundial», y esta computadora mundial es un sistema de estructura única.Luego, cuando el cliente de ICBC «Zhang San» remita a 100 yuanes a «Li Si» que abre una cuenta en China Merchants Bank, el desarrollador puede escribir el código para el programa de transferencia como este:
1. Comience una transacción (o «transacciones», que son la misma palabra en inglés);
2. Deducir 100 yuanes de la cuenta de Zhang San;
3. Agregue 100 yuanes a la cuenta de Li Si;
4. Enviar transacciones.
No importa qué paso hay un problema con los pasos anteriores, por ejemplo, el tercer paso, que aumenta la cantidad en la cuenta de Li Si.Por cierto, al escribir programas como este, llamamos usar el modelo de «fuerte consistencia».
¿Qué pasa si las computadoras en este mundo son sistemas que adoptan la arquitectura de microservicio (MSA)?
Luego, el microservicio (o actor) que administra la cuenta ICBC es casi poco probable que sea el mismo que el microservicio que administra la cuenta bancaria de comerciantes de China.Primero supongamos que de hecho no son lo mismo.En este momento, el desarrollador puede necesitar escribir el código de transferencia de la misma manera:
1. El actor ICBC primero registra la siguiente información: «Zhang San Transfiere 100 yuanes a Li Si»; ;
2. El actor CMB recibió un mensaje, agregó 100 yuanes a la cuenta de Li Si, y luego envió un mensaje al actor ICBC, «Li Si ha recibido 100 yuanes transferidos por Zhang San»;
3. El actor ICBC recibió el mensaje y lo grabó: «Zhang San transfirió 100 yuanes a Li Si, y ha tenido éxito».
Lo anterior es solo un proceso de «todo está bien».Pero, ¿qué pasa si un cierto paso, como el segundo paso, «agregue 100 yuanes a la cuenta de Li Si», y hay un problema?
Los desarrolladores deben escribir dicha lógica de procesamiento para este posible problema:
-
El actor CMB envió un mensaje al actor ICBC: «Zhang San transfirió 100 yuanes a Li Si, pero el procesamiento falló».
-
El actor ICBC recibió un mensaje de que agregó 100 yuanes a la cuenta de Zhang San y registró: «Zhang San transfirió 100 yuanes a Li Si, pero ha fallado».
Así es como se escribe el programa, lo llamamos el modelo de consistencia final.
Como se mencionó anteriormente, los lectores no técnicos deberían poder sentir intuitivamente la gran diferencia en la carga de trabajo entre la aplicación del desarrollo de la arquitectura monolítica y la aplicación del desarrollo de MSA, ¿verdad?Debe saber que el ejemplo de transferencia mencionado anteriormente es solo una aplicación muy simple, si lo llamamos una aplicación, no una función.Las funciones en aplicaciones grandes a menudo son mucho más complicadas que tales ejemplos.
¿Qué tan grande debe ser este microservicio?
En otras palabras, «¿Es este microservicio demasiado grande y debe dividirse en dos?»
Desafortunadamente, no hay una respuesta estándar a esta pregunta, es un arte.Cuanto más pequeño sea los microservicios, más fácil es optimizar el sistema creando nuevas instancias y moviéndolos a pedido.Sin embargo, cuanto más pequeño sea el microservicio, más difícil es para los desarrolladores implementar procesos complejos, como se muestra arriba.
Por cierto, divide una aplicación en múltiples microservicios, desde la perspectiva del diseño de la base de datos, es el llamado «fragmentación».Una de las mejores prácticas para la arquitectura de microservicio es que cada microservicio usa solo una base de datos local propia.En pocas palabras, el fragmento permite la expansión horizontal.Cuando el conjunto de datos se vuelve demasiado grande para ser procesado de la manera tradicional, no hay nada más (para escalarlo) excepto dividirlos en fragmentos más pequeños.
Vuelve al problema de división de los microservicios.Para practicar mejor este arte, necesitamos dominar el uso de algunas herramientas de pensamiento.El «agregado» del DDD (diseño impulsado por el dominio) es un «gran asesino» que debes tener.Quiero decir, te ayuda a destruir la «complejidad central» en el diseño de software.
Creo que la agregación es el concepto más importante de DDD a nivel táctico.
¿Qué es la agregación?La agregación atrae un límite entre objetos, especialmente entidades y entidades.Un agregado debe contener y solo una entidad de raíz agregada, y puede contener un número incierto de entidades internas agregadas (o entidades raíz no agregadas).
Podemos usar el concepto de agregación para analizar y modelar los campos que sirve la aplicación;La forma más fácil es implementar cada agregación en un microservicio.
Sin embargo, no importa cuán hábil sea, no puede garantizar que hará lo correcto la primera vez.En este momento, una herramienta que le permite verificar los resultados de modelado lo antes posible y si no funciona, será precioso para usted.
¿Qué más podría constituir una barrera para la migración de grandes aplicaciones Web2 al ecosistema AO?
Quiero hablar sobre los problemas de tiempo de ejecución del idioma y el programa.
AO es un protocolo de datos.Puede pensar en ello como un conjunto de especificaciones de interfaz que definen cómo cada «unidad» en una red AO implementa la colaboración.Actualmente, la implementación oficial de AO incluye un entorno de máquina virtual basado en WASM y un entorno de tiempo de ejecución LUA (AO-LIB) compilado en WASM, con el objetivo de simplificar el desarrollo de los procesos AO.
Lua es un idioma pequeño y hermoso.En general, se cree que Lua tiene la ventaja de su incrustación ligera y fácil en otros idiomas, lo que lo hace particularmente útil en escenarios específicos, como el desarrollo de juegos.Sin embargo, el idioma LUA no es la opción convencional para desarrollar grandes aplicaciones de Internet.El desarrollo de aplicaciones de Internet a gran escala a menudo tiende a usar idiomas como Java, C#, PHP, Python, JavaScript, Ruby, etc., porque estos idiomas proporcionan un ecosistema y una cadena de herramientas más integral, así como un apoyo comunitario más amplio .
Algunas personas pueden argumentar que estos idiomas pueden compilarse en WASM Bytecode y ejecutar en una máquina virtual WASM.Pero, de hecho, aunque WASM se ha desempeñado fuertemente en el campo del desarrollo del front-end web, el uso actual de WASM como entorno operativo de fondo para aplicaciones de Internet no es una opción convencional.Tenga en cuenta que los contratos inteligentes (programas en la cadena) son el «nuevo backend» de la era Web3.
Resumir
En resumen, hemos discutido las ventajas de adoptar una arquitectura de microservicio (o el modelo de actor) y la complejidad que aporta al desarrollo de aplicaciones.Algunas complejidades son inevitables.Por ejemplo, incluso en entornos de ingeniería más maduros de Web2, lograr la «consistencia final» basada en la comunicación de mensajes ya es un gran desafío para muchos desarrolladores.El desafío parece ser aún más obvio al desarrollar DAPPS en la plataforma AO de primer año, por supuesto, es completamente comprensible.Se muestra un ejemplo al comienzo del siguiente artículo de enlace.
https://github.com/dddappp/a-ao-demo?tab=readme-ov-file#an-ao-dapp-develovelopment-demo-with-a-low-code-parrroach
Todos sabemos que la batalla entre las cadenas públicas es en realidad una guerra para los desarrolladores de aplicaciones.Entonces, ¿cómo puede AO ganar a los desarrolladores en este caso?
Creo que es necesario continuar aprendiendo de Web2 que ya ha recibido «adopción masiva».Esto incluye no solo aprender su infraestructura, sino también todos los aspectos, como la metodología de desarrollo, las herramientas de desarrollo y las prácticas de ingeniería de software.En el próximo artículo, le mostraré una de las soluciones en las que creo firmemente: desarrollo de bajo código.
