jakiro
著者：Arweaveoasis、出典：Permadao
この記事では、マイクロサービスアーキテクチャ（またはアクターモデル）を採用することの利点について説明し、アプリケーション開発にもたらす論理的な複雑さを分析します。
@AotheComputerのリリースは、間違いなく、@Arweaveecoエコシステム全体、さらにはWeb3業界全体に新しい種類の思考と実践をもたらしました。これは、大多数の投資家の注意だけでなく、多数の高品質の開発者を集めて詳細な研究を開始することにも反映されています。
Web3の大規模な採用を妨げるものは何ですか？
分散型アプリケーションを使用する価値が少なすぎるため、非常に簡単です。
Web3インフラストラクチャ、開発ツール、ソフトウェアエンジニアリングプラクティスなどの現在の状況に基づいて、現在達成することはほとんど不可能です。
インフラストラクチャの観点から、AOの出現はいくつかの主要なギャップを埋めると思います。ただし、大規模な分散アプリケーションを構築するプロジェクトの複雑さは依然として困難です。これにより、リソースがより多様で、より大きく、より機能的なアプリケーションを開発するために、より多様で、より大きく、しばしばより良い分散化を開発することができません。
「スマートコントラクト/オンチェーンプログラムは非常に簡単なはずです。それらを複雑すぎる必要はありません」などのナンセンスな言葉を信じないでください！
本当の問題は「欲しくない」のではなく、「そうではない」 – 私はそれをすることができません。
AOは、Arweaveで実行されているコンピューターシステムで、検証可能な無制限のコンピューティングパワーを実現するように設計されています。それは俳優志向の短い名前です。名前が示すように、これはAOで実行されている分散型アプリケーションには、アクターモデルに基づいて設計およびプログラミング方法が必要であることを意味します。
実際、AOはブロックチェーンにアクターモデルを使用した最初ではありませんでした（または「分散型インフラストラクチャ」）。たとえば、TonのスマートコントラクトはActor Modelを使用して構築されています。トンといえば、個人的にはAOといくつかの点で類似点があると思います。
まだWeb3を深く理解していないWeb2開発者の場合、他の「モノリシックブロックチェーン」と比較してAOまたはTONの最大の機能を迅速に理解したい場合は、スマートコントラクトを実行する便利な方法（チェーン）（チェーン）（チェーン）（パート1）は「マイクロサービス」と見なされています。AOまたはTONは、Kafka、Kubernetesなどのこれらのマイクロサービスの動作をサポートするインフラストラクチャです。
20年以上にわたってアプリケーション開発に焦点を当ててきたシニアクラッドの少年として、私は個人的にAOやTonなどの非独占ブロックチェーンの出現を見てとてもうれしく、彼らの開発への期待に満ちています。以下では、アプリケーション開発者の観点からAOに関する私の見解について話したいと思います。おそらく、一部のアプリケーション開発者はresしていると感じるでしょう、それで十分です。
アクターモデルをブロックチェーンに適用する必要がありますか？
答えはイエスです。「大規模な採用」を達成したWeb2アプリケーションを見てください。
Microservice Architecture（MSA）、イベント駆動型アーキテクチャ（EDA）、メッセージ通信メカニズム、最終的な一貫性モデル、シャーディング…彼らが何を呼んでいても、常に共存しています。俳優モデル。これらの概念のいくつかは、物事の異なる側面であるとさえ言えます。したがって、次のテキストでは、「マイクロサービス」と俳優を区別しません。それらを同義語と考えることができます。
今日のインターネットの繁栄は、これらの建築家の知恵と切り離せないものです。彼らは絶えず探求し、実践し、要約し、最終的に完全なエンジニアリング練習システムを形成しました。
Web3インフラストラクチャとして、AOは素晴らしい仕事をしています。少なくとも、AOは、現在のWeb3フィールド（私の目に）で最高の分散化されたメッセージングブローカーとして大きな可能性を示しています。従来のWeb2アプリケーションの開発者は、これの重要性をすぐに理解できると思います。KafkaまたはKafkaのようなメッセージブローカーが利用できない場合、現在「プログラムの書き方」を持っている大規模なインターネットアプリケーションがいくつあるか想像できますか？
アクターモデルには、アクターモデルであろうとマイクロサービスアーキテクチャであろうと、多くの面で理論的な利点がありますが、私の意見では、特定のアプリケーションを開発するために開発者が特定のアプリケーション（特に大規模アプリケーション）を開発しなければならない問題です。 （特に大規模なアプリケーション）。
簡単な例を使用して、これを非技術的な読者に説明しましょう。「世界のコンピューター」に基づいて世界のすべての銀行が行動すると仮定し、この世界コンピューターはモノリシックシステムです。その後、ICBCの顧客「Zhang San」が中国商人銀行にアカウントを開設する「Li Si」に100元を送金すると、開発者はこのような転送プログラムのコードを書くことができます。
1。トランザクション（または「トランザクション」を開始します。これは英語で同じ単語です）。
2.チャンサンのアカウントから100元を差し引きます。
3. Li Siのアカウントに100元を追加します。
4.トランザクションを送信します。
たとえば、上記のステップに問題があります。たとえば、Li Siのアカウントの金額を増やします。ちなみに、このようなプログラムを書くときは、「強力な一貫性」モデルを使用して呼び出します。
この世界のコンピューターがマイクロサービスアーキテクチャ（MSA）を採用するシステムである場合はどうなりますか？
次に、ICBCアカウントを管理するマイクロサービス（またはアクター）は、中国商人の銀行口座を管理するマイクロサービスと同じである可能性はほとんどありません。まず、彼らが実際に同じではないと仮定しましょう。現時点では、開発者は次のように転送コードを書く必要がある場合があります。
1。俳優ICBCは、最初に次の情報を記録します。 ;
2。俳優CMBはメッセージを受け取り、Li Siのアカウントに100元を追加し、俳優ICBCにメッセージを送信しました。
3。俳優ICBCはメッセージを受け取り、「Zhang Sanが100元をLi Siに移したが、成功している」と録音した。
上記は、「すべてが大丈夫」のプロセスにすぎません。しかし、2番目のステップ「Li Siのアカウントに100元を追加」などの特定のステップが問題がある場合はどうでしょうか。
開発者は、この可能な問題のためにそのような処理ロジックを書く必要があります。
-
俳優CMBは俳優ICBCにメッセージを送信しました：「Zhang Sanは100元をLi Siに移しましたが、処理は失敗しました。」
-
俳優のICBCは、100元をZhang Sanのアカウントに追加して記録したというメッセージを受け取り、「Zhang Sanは100元をLi Siに移しましたが、失敗しました。」
これがプログラムの書き方であり、最終的な一貫性モデルと呼びます。
上記のように、非技術的な読者は、モノリシック建築の発展とMSAの開発の適用との間のワークロードの大きな違いを直感的に感じることができるはずですよね？上記の転送例は、機能ではなくアプリケーションと呼ばれる場合、非常に単純なアプリケーションであることを知っておく必要があります。大規模なアプリケーションの機能は、多くの場合、そのような例よりもはるかに複雑です。
このマイクロサービスはどれくらいの大きさですか？
言い換えれば、「このマイクロサービスは大きすぎて、2つに分割する必要がありますか？」
残念ながら、この質問に対する標準的な答えはありません。それは芸術です。マイクロサービスが小さいほど、新しいインスタンスを作成してオンデマンドで移動することにより、システムを最適化しやすくなります。ただし、マイクロサービスが小さいほど、上記のように、開発者が複雑なプロセスを実装するのは難しくなります。
ちなみに、データベース設計の観点から、アプリケーションを複数のマイクロサービスに分割し、いわゆる「シャード」です。マイクロサービスアーキテクチャのベストプラクティスの1つは、各マイクロサービスが独自のローカルデータベースを1つだけ使用していることです。簡単に言えば、シャードは水平方向の拡張を可能にします。データセットが従来の方法で処理できないほど大きくなりすぎると、小さなフラグメントに分割することを除いて（スケールアップするために）他に何もありません。
マイクロサービスの分割問題に戻ります。このアートをより適切に実践するには、いくつかの思考ツールの使用を習得する必要があります。DDD（ドメイン駆動型デザイン）の「集計」は、あなたが持っている必要がある「大きな殺人者」です。つまり、ソフトウェア設計の「コアの複雑さ」を破壊するのに役立ちます。
集約は、戦術レベルでのDDDの最も重要な概念だと思います。
集約とは何ですか？集約は、オブジェクト、特にエンティティ間の境界を引き出します。集合体には、1つの集計ルートエンティティのみが含まれている必要があり、不確実な数の集約内部エンティティ（または凝集していないルートエンティティ）が含まれている場合があります。
集約の概念を使用して、アプリケーションが提供するフィールドを分析およびモデル化することができます。最も簡単な方法は、各集約をマイクロサービスに実装することです。
しかし、あなたがどんなに熟練していても、あなたが初めて正しいことをすることを保証することはできません。現時点では、モデリングの結果をできるだけ早く検証できるツールであり、機能しない場合は貴重です。
大規模なWeb2アプリケーションをAOエコシステムに移行するための障壁を構成する他のものは何ですか？
言語とプログラムのランタイムの問題についてお話したいと思います。
AOはデータプロトコルです。AOネットワーク内の各「ユニット」がコラボレーションを実装する方法を定義するインターフェイス仕様のセットと考えることができます。現在、AOの公式実装には、AOプロセスの開発を簡素化することを目的としたWASMベースの仮想マシン環境とLUAランタイム環境（AO-LIB）がWASMに編集されたLUAランタイム環境（AO-LIB）が含まれています。
ルアは小さくて美しい言語です。LUAは一般に、他の言語に軽量で簡単な埋め込みの利点があると考えられているため、ゲーム開発などの特定のシナリオで特に役立ちます。ただし、LUA言語は、大規模なインターネットアプリケーションを開発するための主流の選択ではありません。大規模なインターネットアプリケーション開発は、Java、C＃、PHP、Python、JavaScript、Rubyなどの言語を使用する傾向があることがよくあります。これらの言語は、より包括的なエコシステムとツールチェーン、およびより広範なコミュニティサポートを提供するため。
一部の人々は、これらの言語をWASMバイトコードにコンパイルし、WASM仮想マシンで実行できると主張する場合があります。しかし、実際には、Webフロントエンド開発の分野でWASMは強く機能していますが、インターネットアプリケーションのバックエンド動作環境としてのWASMの現在の使用は、主流の選択ではありません。スマートコントラクト（オンチェーンプログラム）は、Web3時代の「新しいバックエンド」であることに注意してください。
要約します
要約すると、マイクロサービスアーキテクチャ（またはアクターモデル）を採用することの利点と、アプリケーション開発にもたらす複雑さについて説明しました。いくつかの複雑さは避けられません。たとえば、より成熟したエンジニアリングWeb2環境であっても、メッセージ通信に基づいて「最終的な一貫性」を達成することは、多くの開発者にとってすでに大きな課題です。課題は、新入生のAOプラットフォームでDAPPを開発するときにさらに明白であるように思われます – もちろん、それは完全に理解できます。次のリンク記事の先頭に例が示されています。
https://github.com/ddddappp/a-a-ao-demo?tab = readme-ov-file#an-ao-dapp-development-demo-with-a-low-code-approach
私たちは皆、公共チェーン間の戦いが実際にアプリケーション開発者にとっての戦争であることを知っています。それでは、この場合、AOはどのようにして開発者を獲得できますか？
すでに「大規模な採用」を受けているWeb2から学習を続ける必要があると思います。これには、インフラストラクチャを学習するだけでなく、開発方法論、開発ツール、ソフトウェアエンジニアリングの実践などのすべての側面も含まれます。次の記事では、私が固く信じているソリューションの1つである低コード開発を紹介します。
