مفتاح النصر لنظام AO البيئي: بنية الخدمات الصغيرة في عصر Web3

المؤلف: ArweaveOasis، المصدر: PermaDAO

تناقش هذه المقالة مزايا اعتماد بنية الخدمات الصغيرة (أو نموذج الممثل) وتحلل التعقيد المنطقي الذي يجلبه لتطوير التطبيقات إلى حد ما.

يجلب إصدار @aoTheComputer بلا شك نوعًا جديدًا من التفكير والممارسة للنظام البيئي @ArweaveEco بأكمله وحتى صناعة Web3 بأكملها. ولا ينعكس هذا في اهتمام غالبية المستثمرين فحسب، بل ينعكس أيضًا في جذب عدد كبير من المطورين ذوي الجودة العالية لبدء البحث المتعمق.

ما الذي يعيق التبني الجماعي لـ Web3؟

ببساطة، هناك عدد قليل جدًا من التطبيقات اللامركزية التي تستحق الاستخدام.

استنادًا إلى الوضع الحالي للبنية التحتية لـ Web3 وأدوات التطوير وممارسات هندسة البرمجيات وما إلى ذلك، يكاد يكون من المستحيل حاليًا تنفيذ العديد من أنواع التطبيقات اللامركزية.

فيما يتعلق بالبنية التحتية، أعتقد أن ظهور AO يسد بعض الفجوات الرئيسية. ومع ذلك، فإن التعقيد الهندسي الحالي لبناء تطبيقات لامركزية واسعة النطاق لا يزال أمرًا شاقًا. وهذا يمنعنا من تطوير لامركزية أكثر تنوعًا وواسعة النطاق، وغالبًا ما تكون أفضل وغنية بالميزات وبموارد محدودة - وهو ما يحدث عادةً في المراحل الأولى من تطوير الأشياء.

لا تصدق تلك الكلمات الهراء مثل "يجب أن تكون العقود الذكية/البرامج عبر السلسلة بسيطة للغاية، وليست هناك حاجة لجعلها معقدة للغاية"!

المشكلة الحقيقية ليست "لا أريد ذلك"، ولكن "لا أستطيع" - لا أستطيع فعل ذلك.

AO هو نظام كمبيوتر يعمل على Arweave، وهو مصمم لتحقيق قوة حوسبة غير محدودة. إنه اختصار لـ "الممثل الموجه". كما يوحي الاسم، هذا يعني أن التطبيقات اللامركزية التي تعمل على AO تحتاج إلى اعتماد طريقة تصميم وبرمجة تعتمد على نموذج الممثل.

في الواقع، AO ليس أول من استخدم نموذج الممثل لـ blockchain (أو "البنية التحتية اللامركزية"). على سبيل المثال، تم إنشاء عقود TON الذكية باستخدام نموذج الممثل. عند الحديث عن TON، أشعر شخصيًا أنها تشبه إلى حد كبير AO في بعض الجوانب.

بالنسبة لمطوري Web2 الذين لم يفهموا بعد Web3 بشكل عميق، إذا كانوا يريدون فهم أكبر ميزات AO أو TON بسرعة مقارنة بـ "سلاسل الكتل المنفردة" الأخرى، فإن نقطة البداية المناسبة هي: العقود الذكية (البرامج الموجودة على السلسلة) التي تعمل عليها تعتبر "خدمات صغيرة". AO أو TON هي البنية التحتية التي تدعم تشغيل هذه الخدمات الصغيرة، مثل Kafka وKubernetes وما إلى ذلك.

باعتباري أحد كبار طلاب CRUD الذي ركز بشكل أساسي على تطوير التطبيقات لأكثر من 20 عامًا، أنا شخصيًا سعيد جدًا برؤية ظهور سلاسل الكتل غير المتجانسة مثل AO وTON، وأنا أنا قلق للغاية بشأن تطورهم المليء بالتوقعات. الآن أود أن أتحدث عن آرائي حول AO من وجهة نظر مطور التطبيقات، وقد لا تكون العديد من آرائي ناضجة بعد. ربما سيشعر بعض مطوري التطبيقات بالحزن، وهذا يكفي.

هل من الضروري حقًا تطبيق نموذج الممثل على blockchain؟

الإجابة هي نعم. ما عليك سوى إلقاء نظرة على تطبيقات Web2 التي حققت "الاعتماد الشامل" وسوف تفهم ذلك.

يعرف عدد كبير جدًا من المهندسين المعماريين بالفعل كيفية "توسيع نطاق" تطبيقات Web2: بنية الخدمات الصغيرة (MSA)، والهندسة المستندة إلى الحدث (EDA)، وآلية توصيل الرسائل، ونموذج الاتساق النهائي، والتقسيم... ...هذه الأشياء، بغض النظر عن تسميتها، فهي موجودة دائمًا بشكل تكافلي مع نموذج الممثل. بل يمكن القول أن بعض هذه المفاهيم هي مجرد جوانب مختلفة لنفس الشيء. لذلك، في النص التالي، لن نفرق بين "الخدمة المصغرة" و"الممثل"، ويمكنك اعتبارهما مترادفين.

إن ازدهار الإنترنت اليوم لا يمكن فصله عن حكمة هؤلاء المهندسين المعماريين. واستمروا في الاستكشاف والممارسة والتلخيص، وشكلوا في النهاية نظامًا كاملاً لممارسة الهندسة.

كبنية أساسية لـ Web3، يقوم AO بعمل رائع. على الأقل، أظهر AO إمكانات كبيرة باعتباره (في نظري) أفضل وسيط رسائل لامركزي في مجال Web3 الحالي. أعتقد أن مطوري تطبيقات Web2 التقليدية يمكنهم فهم أهمية هذا على الفور: إذا لم يكن هناك وسيط رسائل كافكا أو شبيه بكافكا، فهل يمكنك تخيل "كيفية كتابة البرامج" للعديد من تطبيقات الإنترنت واسعة النطاق اليوم؟

على الرغم من أن نموذج Actor يتمتع بمزايا نظرية في العديد من الجوانب، سواء كان نموذج Actor أو بنية الخدمات الصغيرة، إلا أنه في رأيي، يكون الأمر أكثر للمطورين لتطوير تطبيقات معينة (خصوصًا إنه "الألم" تلك التطبيقات الكبيرة) يجب أن تتحملها.

دعونا نوضح ذلك للقراء غير التقنيين بمثال بسيط. لنفترض أن جميع البنوك في العالم تعمل على أساس "كمبيوتر عالمي"، وهذا الكمبيوتر العالمي هو نظام معماري متجانس. بعد ذلك، عندما يقوم "Zhang San"، أحد عملاء ICBC، بتحويل 100 يوان إلى "Li Si" الذي لديه حساب في China Merchants Bank، يمكن للمطور كتابة رمز برنامج التحويل مثل هذا:

1. ابدأ معاملة (أو "معاملة"، فهي نفس الكلمة باللغة الإنجليزية)؛

2. اخصم 100 يوان من حساب Zhang San؛

3. اخصم 100 يوان من حساب Li Si أضف 100 يوان إلى الحساب؛

4.

بغض النظر عن أي خطوة من الخطوات المذكورة أعلاه بها مشكلة، على سبيل المثال، الخطوة الثالثة، فشل إضافة المبلغ إلى حساب Li Si لسبب ما، ثم سيتم التراجع عن العملية بأكملها، كما لو كان هناك لم يحدث شيء. بالمناسبة، عندما يتم كتابة البرنامج بهذه الطريقة، فإننا نسميه باستخدام نموذج "التناسق القوي".

ماذا لو كان الكمبيوتر في هذا العالم عبارة عن نظام يستخدم بنية الخدمات الدقيقة (MSA)؟

ثم، من غير المحتمل تقريبًا أن تكون الخدمة الصغيرة (أو الممثل) التي تدير حساب ICBC والخدمة الصغيرة التي تدير حساب China Merchants Bank هي نفسها. لنفترض أولاً أنهما ليسا متماثلين بالفعل. الأول يسمى Actor ICBC والأخير يسمى Actor CMB. في هذا الوقت، قد يحتاج المطور إلى كتابة رمز النقل مثل هذا:

1. يقوم الممثل ICBC أولاً بتسجيل المعلومات التالية: "يقوم Zhang San بتحويل 100 يوان إلى Li Si"؛ اطرح 100 يوان وأرسل رسالة إلى الممثل CMB: "Zhang San ينقل 100 يوان إلى Li Si"؛

2. يتلقى الممثل CMB الرسالة ويضيف 100 يوان إلى حساب Li Si، ثم يرسل 100 يوان. إلى حساب Li Si. يرسل الممثل ICBC رسالة "لقد تلقى Li Si مبلغ 100 يوان الذي حوله Zhang San"؛

3. يتلقى الممثل ICBC الرسالة ويسجلها: "لقد قام Zhang San بتحويل 100 يوان إلى Li سي بنجاح".

ما ورد أعلاه هو مجرد عملية "كل شيء على ما يرام". ومع ذلك، ماذا يجب أن نفعل إذا كانت هناك مشكلة في خطوة معينة، مثل الخطوة الثانية، "إضافة 100 يوان إلى حساب John Doe"؟

يحتاج المطورون إلى كتابة منطق المعالجة التالي لهذه المشكلة المحتملة:

• يقدم الممثل CMB تقاريره إلى الممثل ICBC أرسل رسالة الرسالة: "حوّل Zhang San 100 يوان إلى Li Si، وفشلت المعالجة."

• استلم الممثل ICBC الرسالة، وأضاف 100 يوان إلى حساب Zhang San، وسجل: " Zhang San's لقد فشل تحويل 100 يوان إلى Li Si."

تسمى كتابة البرنامج بهذه الطريقة باستخدام نموذج الاتساق النهائي.

أعلاه، يجب أن يكون القراء غير التقنيين قادرين على الشعور بشكل حدسي بالفرق الكبير في عبء العمل بين تطوير تطبيقات الهندسة المعمارية المتجانسة وتطوير تطبيقات MSA، أليس كذلك؟ كما تعلمون، مثال النقل المذكور أعلاه هو مجرد تطبيق بسيط جدًا، إذا أسميناه تطبيقًا وليس وظيفة. غالبًا ما تكون الوظائف في التطبيقات الكبيرة أكثر تعقيدًا من الأمثلة المشابهة لهذه.

ما هو حجم هذه الخدمة الصغيرة؟

بمعنى آخر، "هل هذه الخدمة الصغيرة كبيرة جدًا ويجب تقسيمها إلى قسمين؟"

لسوء الحظ، لا توجد إجابة قياسية لهذا السؤال؛ كلما كانت الخدمات الصغيرة أصغر، كان من الأسهل تحسين النظام عن طريق إنشاء مثيلات جديدة وتحريكها حسب الحاجة. ومع ذلك، كلما كانت الخدمة الصغيرة أصغر، أصبح من الصعب على المطورين تنفيذ العمليات المعقدة، كما هو موضح أعلاه.

بالمناسبة، يُطلق على تقسيم التطبيق إلى خدمات صغيرة متعددة اسم "التقسيم" من منظور تصميم قاعدة البيانات. إحدى أفضل ممارسات هندسة الخدمات الصغيرة هي أن كل خدمة صغيرة تستخدم قاعدة البيانات المحلية الخاصة بها فقط. ببساطة، يسمح التقسيم بالتحجيم الأفقي. عندما تصبح مجموعات البيانات كبيرة جدًا بحيث لا يمكن معالجتها بالوسائل التقليدية، فلا توجد طريقة أخرى سوى تقسيمها إلى أجزاء أصغر.

العودة إلى مسألة تقسيم الخدمات الصغيرة. ولكي نمارس هذا الفن بشكل أفضل، علينا أن نتقن استخدام بعض أدوات التفكير. "التجميع" لـ DDD (التصميم المعتمد على المجال) هو "القاتل الكبير" الذي يجب أن تمتلكه. ما أعنيه هو أنه يساعدك على تدمير "التعقيد الأساسي" في تصميم البرامج.

أعتقد أن التجميع هو أهم مفهوم لـ DDD على المستوى التكتيكي.

ما هو التجميع؟ التجميع يرسم الحدود بين الكائنات، وخاصة الكيانات. يجب أن يحتوي التجميع على كيان جذر تجميعي واحد فقط، وقد يحتوي على عدد غير محدد من الكيانات الداخلية المجمعة (أو الكيانات الجذرية غير المجمعة).

يمكننا استخدام مفهوم التجميع لتحليل ونمذجة الحقول التي يخدمها التطبيق، ثم عند البرمجة، يمكننا تقسيم الخدمات الصغيرة وفقًا للتجميع. إن أبسط طريقة هي تنفيذ كل تجميع كخدمة صغيرة.

ومع ذلك، بغض النظر عن مدى مهارتك، لا يمكنك ضمان أنك ستفعل هذا النوع من الأشياء بشكل صحيح في المرة الأولى. في الوقت الحالي، تعد الأداة التي تسمح لك بالتحقق من نتائج النمذجة في أسرع وقت ممكن والبدء من جديد في حالة الفشل أمرًا ذا قيمة كبيرة بالنسبة لك.

ما هي الأشياء الأخرى التي قد تشكل عائقًا أمام ترحيل تطبيقات Web2 الكبيرة إلى نظام AO البيئي؟

أريد أن أتحدث عن مشكلات اللغة ووقت تشغيل البرنامج.

AO هو بروتوكول بيانات. يمكنك اعتبارها مجموعة من مواصفات الواجهة التي تحدد كيفية تعاون كل "وحدة" في شبكة AO. حاليًا، يتضمن التنفيذ الرسمي لـ AO بيئة آلة افتراضية تعتمد على WASM وبيئة تشغيل Lua (ao-lib) مجمعة في WASM، بهدف تبسيط تطوير عملية AO.

اللوا لغة صغيرة ولكنها جميلة. من المعتقد عمومًا أن نقاط قوة Lua تكمن في خفة وزنها وسهولة دمجها في لغات أخرى، مما يجعلها مفيدة بشكل خاص في سيناريوهات محددة مثل تطوير الألعاب. ومع ذلك، فإن لغة Lua ليست خيارًا رئيسيًا لتطوير تطبيقات الإنترنت واسعة النطاق. يميل تطوير تطبيقات الإنترنت على نطاق واسع عادةً إلى استخدام لغات مثل Java وC# وPHP وPython وJavaScript وRuby وما إلى ذلك، لأن هذه اللغات توفر أنظمة بيئية وسلاسل أدوات أكثر شمولاً، فضلاً عن مجتمع أوسع. يدعم.

قد يجادل بعض الأشخاص بأن هذه اللغات يمكن تجميعها في رمز بايت WASM وتشغيلها في الجهاز الظاهري WASM. ولكن في الواقع، على الرغم من أن WASM يتمتع بأداء قوي في مجال تطوير الواجهة الأمامية للويب، إلا أنه في الوقت الحالي ليس الخيار السائد لتطبيقات الإنترنت هو استخدام WASM كبيئة تشغيل خلفية. لاحظ أن العقود الذكية (البرامج الموجودة على السلسلة) هي "الواجهة الخلفية الجديدة" في عصر Web3.

الملخص

باختصار، ناقشنا مزايا اعتماد بنية الخدمات الصغيرة (أو نموذج الممثل) والفوائد التي يجلبها لتطوير التطبيقات . بعض التعقيد أمر لا مفر منه. على سبيل المثال، حتى في بيئة Web2 الأكثر نضجًا، يمثل تحقيق "الاتساق النهائي" استنادًا إلى اتصالات الرسائل تحديًا كبيرًا للعديد من المطورين. عند تطوير Dapps على منصة AO الناشئة، يبدو هذا التحدي أكثر وضوحًا - بالطبع هذا أمر مفهوم تمامًا.  يظهر المثال في بداية المقال الرابط أدناه.

https://github.com/dddappp/A-AO-Demo?tab=readme-ov-file#an-ao-dapp-development-demo -with-a-low-code-approach

نعلم جميعًا أن المعركة من أجل السلاسل العامة هي في الواقع حرب لمطوري التطبيقات. إذًا، كيف يجذب AO المطورين في هذه الحالة؟

أعتقد أننا بحاجة إلى مواصلة التعلم من "الاعتماد الشامل" لـ Web2. وهذا لا يشمل تعلم بنيتها التحتية فحسب، بل يشمل أيضًا جوانب مثل منهجيات التطوير وأدوات التطوير وممارسات هندسة البرمجيات. في المقالة التالية، سأعرض لك الحل الذي أؤمن به بشدة: تطوير التعليمات البرمجية المنخفضة.