Der Schlüssel zum Sieg des AO -Ökosystems: die Microservice -Architektur in der Web3 -Ära

Autor: Arweaveaasis, Quelle: Permadao

In diesem Artikel werden die Vorteile der Einführung einer Microservice -Architektur (oder eines Akteurmodells) erörtert und die logische Komplexität analysiert, die sie für die Anwendungsentwicklung mit sich bringt.

Die Veröffentlichung von @Aothecomputer hat zweifellos eine neue Art von Denken und Praxis in das gesamte @Arweaveco -Ökosystem und sogar die gesamte Web3 -Branche gebracht.Dies spiegelt sich nicht nur in der Aufmerksamkeit der Mehrheit der Investoren wider, sondern auch darin, eine große Anzahl hochwertiger Entwickler für eingehende Forschung zu gewinnen.

Was behindert die massive Einführung von Web3?

Es ist sehr einfach, da es zu wenige dezentrale Anwendungen gibt, die es wert sind, verwendet zu werden.

Basierend auf der aktuellen Situation von Web3 -Infrastruktur, Entwicklungstools, Software -Engineering -Praktiken usw. sind derzeit viele Arten dezentraler Anwendungen zu erreichen.

In Bezug auf die Infrastruktur denke ich, dass die Entstehung von AO einige der wichtigsten Lücken füllt.Die Komplexität des Projekts zum Aufbau großer dezentraler Anwendungen ist jedoch immer noch entmutigend.Dies macht es uns unmöglich, vielfältige, größere und oft bessere, funktionale Dezentralisierung zu entwickeln, wenn die Ressourcen in den Anfangsphasen der Entwicklung eingeschränkt werden, um vielfältiger, größer und funktionaler zu entwickeln.

Glauben Sie nicht an diese Unsinnswörter wie „Smart Contracts/On-Chain-Programme sollten sehr einfach sein, es besteht keine Notwendigkeit, sie zu kompliziert zu machen“!

Das eigentliche Problem ist nicht „nicht“, sondern „nicht“ – ich kann es nicht tun.

AO ist ein Computersystem, das auf Arweave ausgeführt wird und die nachweisbare unbegrenzte Rechenleistung erreicht hat.Es ist der kurze Name für Schauspielerorientierung.Wie der Name schon sagt, bedeutet dies, dass dezentrale Anwendungen, die auf AO ausgeführt werden, Design- und Programmiermethoden erfordern, die auf dem Akteurmodell basieren.

Tatsächlich war AO nicht der erste, der das Schauspielermodell für Blockchain (oder „dezentrale Infrastruktur“) verwendete.Zum Beispiel wird der intelligente Vertrag von Ton mit dem Schauspielermodell erstellt.Apropos Ton, ich persönlich denke, dass es in gewisser Weise Ähnlichkeiten mit AO hat.

Für Web2 -Entwickler, die noch kein tiefes Verständnis von Web3 hatten, wenn Sie im Vergleich zu anderen „monolithischen Blockchains“ schnell die größte Funktion von AO oder Tonne verstehen möchten, ist dies eine bequeme Möglichkeit, die intelligenten Verträge (Kette) (Kette) zum Laufen zu bringen (Kette) (Kette) (Kette) Teil 1) wird als „Microservice“ angesehen.AO oder Tonne ist die Infrastruktur, die den Betrieb dieser Mikrodienste wie Kafka, Kubernetes usw. unterstützt.

Als Senior Crud Boy, der sich seit mehr als 20 Jahren auf die Anwendungsentwicklung konzentriert, bin ich persönlich sehr froh, dass die Entstehung von nicht-monopolischen Blockchains wie AO und Tonne und voller Erwartungen an ihre Entwicklung sind.Im Folgenden möchte ich aus der Perspektive eines Anwendungsentwicklers über meine Ansichten zu AO sprechen.Vielleicht fühlen sich einige Anwendungsentwickler ärgerlich, das reicht aus.

Ist es wirklich notwendig, das Schauspielermodell auf Blockchain anzuwenden?

Die Antwort lautet ja.Schauen Sie sich die Web2 -Anwendungen an, die „massive Adoption“ erreicht haben, und Sie werden sehen.

Zu viele Architekten wissen bereits, wie man große Web2-Anwendungen „erstellen“: Microservice Architecture (MSA), ereignisgesteuerte Architektur (EDA), Nachrichtenkommunikationsmechanismus, endgültiges Konsistenzmodell, Sharding … unabhängig davon, wie sie genannt werden, immer koexistieren das Schauspielermodell.Einige dieser Konzepte können sogar als nur unterschiedliche Aspekte einer Sache sein.Im folgenden Text unterscheiden wir also nicht zwischen „Microservices“ und dem Schauspieler, Sie können sie als Synonyme betrachten.

Der Wohlstand des Internets ist heute untrennbar mit der Weisheit dieser Architekten verbunden.Sie erforschen, üben und fassen ständig zusammen und bildeten schließlich ein vollständiges Ingenieurpraxissystem.

Als Web3 -Infrastruktur macht AO einen tollen Job.Zumindest hat AO ein großes Potenzial als der beste dezentrale Messaging -Broker im aktuellen Web3 -Feld (in meinen Augen) gezeigt.Ich glaube, dass Entwickler herkömmlicher Web2-Anwendungen die Bedeutung dieser Bedeutung sofort verstehen können: Wenn Kafka- oder Kafka-ähnliche Message Broker nicht verfügbar ist, können Sie sich vorstellen, wie viele große Internetanwendungen jetzt „Wie man Programme schreibt“?

Obwohl das Akteurmodell in vielen Aspekten theoretische Vorteile hat, sei es meiner Meinung nach das Schauspielermodell oder die Microservice -Architektur, ist es eher ein Problem, dass Entwickler bestimmte Anwendungen (insbesondere große Anwendungen) entwickeln müssen, um bestimmte Anwendungen zu entwickeln, um bestimmte Anwendungen zu entwickeln (insbesondere große Anwendungen).

Lassen Sie uns ein einfaches Beispiel verwenden, um dies nicht-technischen Lesern zu veranschaulichen.Angenommen, alle Banken der Welt verarbeiten Geschäfte auf der Grundlage eines „Weltcomputers“, und dieser Weltcomputer ist ein Einzelstruktursystem.Wenn der ICBC -Kunde „Zhang San“ dann 100 Yuan an „Li Si“ überweist, der ein Konto bei der China Merchants Bank eröffnet, kann der Entwickler den Code für das Übertragungsprogramm wie diese schreiben:

1. Starten Sie eine Transaktion (oder „Transaktionen“, die das gleiche Wort in Englisch sind);

2. Abziehen 100 Yuan von Zhang San’s Account;

3. Fügen Sie 100 Yuan zu Li Sis Konto hinzu;

4. Senden Sie Transaktionen.

Unabhängig davon, welcher Schritt ein Problem mit den obigen Schritten gibt, beispielsweise der dritte Schritt, der den Betrag auf dem Konto von Li Si erhöht.Übrigens, wenn wir solche Programme schreiben, rufen wir übrigens das Modell „starker Konsistenz“ an.

Was ist, wenn Computer in dieser Welt Systeme sind, die Microservice Architecture (MSA) übernehmen?

Anschließend ist es fast unwahrscheinlich, dass der Microservice (oder der Schauspieler), der das ICBC -Konto verwaltet, dem Microservice, der das China Merchants Bankkonto verwaltet, übereinstimmt.Nehmen wir zunächst an, dass sie in der Tat nicht gleich sind.Zu diesem Zeitpunkt muss der Entwickler möglicherweise den Überweisungscode wie diesen schreiben:

1. Schauspieler ICBC erfasst zuerst die folgenden Informationen: „Zhang San überträgt 100 Yuan an Li Si“; ;

2. Schauspieler CMB erhielt eine Nachricht, die Li SIs Konto yuan hinzufügte und dann eine Nachricht an den Schauspieler ICBC gesendet hat.

3. Schauspieler ICBC erhielt die Nachricht und zeichnete sie auf: „Zhang San übertrieb 100 Yuan nach Li Si, und es war erfolgreich.“

Das obige ist nur ein Prozess von „Alles ist in Ordnung“.Aber was ist, wenn ein bestimmter Schritt, wie der zweite Schritt, „100 Yuan zu Li Si’s Konto hinzufügen“, und es gibt ein Problem?

Entwickler müssen eine solche Verarbeitungslogik für dieses mögliche Problem schreiben:

• Der Schauspieler CMB sandte eine Nachricht an den Schauspieler ICBC: „Zhang San hat 100 Yuan an Li Si übertragen, aber die Verarbeitung ist fehlgeschlagen.“

• Der Schauspieler ICBC erhielt eine Nachricht, dass es 100 Yuan zu Zhang San’s Konto hinzugefügt und aufgezeichnet wurde: „Zhang San hat 100 Yuan an Li Si übertragen, aber es ist gescheitert.“

So wird das Programm geschrieben, wir nennen es das endgültige Konsistenzmodell.

Wie oben erwähnt, sollten nicht-technische Leser intuitiv intuitiv den enormen Unterschied in der Arbeitsbelastung zwischen der Anwendung der Entwicklung monolithischer Architektur und der Anwendung der Entwicklung von MSA spüren können, oder?Sie sollten wissen, dass das oben genannte Übertragungsbeispiel nur eine sehr einfache Anwendung ist, wenn wir es eine Anwendung, keine Funktion nennen.Die Funktionen in großen Anwendungen sind oft viel komplizierter als solche Beispiele.

Wie groß sollte dieser Microservice sein?

Mit anderen Worten: „Ist dieser Microservice zu groß und sollte in zwei unterteilt werden?“

Leider gibt es keine Standardantwort auf diese Frage, es ist eine Kunst.Je kleiner die Microservices, desto einfacher ist es, das System zu optimieren, indem neue Instanzen erstellt und auf Anfrage verschoben werden.Je kleiner der Microservice ist, desto schwieriger ist es für Entwickler, komplexe Prozesse zu implementieren, wie oben gezeigt.

Teilen Sie übrigens eine Anwendung aus der Perspektive des Datenbankdesigns in mehrere Microservices auf, und ist die sogenannte „Sharding“.Eine der besten Praktiken für die Microservice -Architektur ist, dass jeder Microservice nur eine eigene lokale Datenbank verwendet.Einfach ausgedrückt, ermöglicht Sharding die horizontale Expansion.Wenn der Datensatz zu groß wird, um auf traditionelle Weise verarbeitet zu werden, gibt es nichts anderes (um ihn zu skalieren), außer sie in kleinere Fragmente aufzuteilen.

Kehren Sie zum Aufteilungsproblem von Microservices zurück.Um diese Kunst besser zu praktizieren, müssen wir die Verwendung einiger Denkwerkzeuge beherrschen.Das „Aggregat“ von DDD (domänengesteuertes Design) ist ein so „großer Killer“, den Sie haben müssen.Ich meine, es hilft Ihnen, die „Kernkomplexität“ im Softwaredesign zu zerstören.

Ich denke, Aggregation ist das wichtigste Konzept der DDD auf taktischer Ebene.

Was ist Aggregation?Die Aggregation zieht eine Grenze zwischen Objekten, insbesondere Entitäten und Unternehmen.Ein Aggregat muss und nur eine aggregierte Wurzeleinheit enthalten und kann eine unsichere Anzahl von internationalen Entitäten (oder nicht-aggregierte Wurzeleinheiten) enthalten.

Wir können das Konzept der Aggregation verwenden, um die Felder, die die Anwendung dient, zu analysieren und zu modellieren.Am einfachsten besteht die Umsetzung jeder Aggregation in einen Microservice.

Egal wie qualifiziert Sie sind, Sie können nicht garantieren, dass Sie beim ersten Mal das Richtige tun werden.Zu diesem Zeitpunkt können Sie ein Tool so schnell wie möglich überprüfen, mit dem Sie die Modellierungsergebnisse überprüfen können. Wenn es nicht funktioniert, ist es für Sie wertvoll.

Was könnte sonst noch eine Barriere für die Migration großer Web2 -Anwendungen auf das AO -Ökosystem darstellen?

Ich möchte über Sprach- und Programm -Laufzeitprobleme sprechen.

AO ist ein Datenprotokoll.Sie können es als eine Reihe von Schnittstellenspezifikationen betrachten, die definieren, wie jede „Einheit“ in einem AO -Netzwerk die Zusammenarbeit implementiert.Derzeit umfasst die offizielle Implementierung von AO eine WASM-basierte virtuelle Maschinenumgebung und eine in WASM zusammengestellte LUA-Laufzeitumgebung (AO-LIB), die darauf abzielt, die Entwicklung von AO-Prozessen zu vereinfachen.

Lua ist eine kleine und schöne Sprache.Es wird allgemein angenommen, dass Lua den Vorteil seines leichten und einfachen Einbettens in andere Sprachen hat, was es in bestimmten Szenarien wie Spieleentwicklung besonders nützlich macht.Die LUA -Sprache ist jedoch nicht die Mainstream -Wahl für die Entwicklung großer Internetanwendungen.Die Entwicklung großer Internetanwendungen nutzt häufig Sprachen wie Java, C#, PHP, Python, JavaScript, Ruby usw., da diese Sprachen ein umfassenderes Ökosystem und ToolChain sowie eine breitere Unterstützung der Gemeinschaft bieten .

Einige Leute mögen argumentieren, dass diese Sprachen in WASM -Bytecode zusammengestellt werden und in einer WASM -Virtual -Maschine ausgeführt werden können.Obwohl WASM im Bereich der Web-Front-End-Entwicklung stark gespielt hat, ist die derzeitige Verwendung von WASM als Back-End-Betriebsumgebung für Internetanwendungen keine Mainstream-Wahl.Beachten Sie, dass Smart Contracts (On-Chain-Programme) das „neue Backend“ der Web3-Ära sind.

Zusammenfassen

Zusammenfassend haben wir die Vorteile einer Microservice -Architektur (oder des Akteurmodells) und der Komplexität der Anwendungsentwicklung erörtert.Einige Komplexitäten sind unvermeidlich.Zum Beispiel ist es für viele Entwickler bereits eine große Herausforderung, „endgültige Konsistenz“ basierend auf der Nachrichtenkommunikation „endgültige Konsistenz“ zu erreichen.Die Herausforderung scheint noch offensichtlicher zu sein, wenn es um die Entwicklung von Dapps auf der AO -Plattform von Freshman ist – natürlich ist es völlig verständlich.Am Anfang des folgenden Linkartikels wird ein Beispiel angezeigt.

https://github.com/dddappp/a-ao-demo?tab=readme-ove#an-ao-dapp-development-demo-with-a-low-code-approach

Wir alle wissen, dass der Kampf zwischen öffentlichen Ketten tatsächlich ein Krieg für Anwendungsentwickler ist.Wie kann AO in diesem Fall Entwickler gewinnen?

Ich denke, es besteht die Notwendigkeit, von Web2 weiter zu lernen, das bereits „massive Adoption“ erhalten hat.Dies beinhaltet nicht nur das Erlernen seiner Infrastruktur, sondern auch alle Aspekte wie Entwicklungsmethoden, Entwicklungswerkzeuge und Software -Engineering -Praktiken.Im nächsten Artikel werde ich Ihnen eine der Lösungen zeigen, an die ich fest davon überzeugt bin: Low-Code-Entwicklung.