نظرة عامة على البدء

تقدم هذه النظرة العامة السرد والنموذج العقلي الأدنى اللازم للبدء بثقة. إنها تحدد كيف يبدو “النجاح الأول” وتظهر كيف توفر المكونات الأساسية الحتمية وإعادة التشغيل.

لمن هذا

أي شخص جديد على Asset Core ويريد فهم المكونات الأساسية المطلوبة لتشغيل النظام وإرسال أول معاملة. إذا كنت تقيم ما إذا كان النموذج يناسب مجالك، فهذه هي أسرع طريقة لتوجيه نفسك قبل أن تتعمق في التفاصيل.

ما ستتعلمه

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

المكونات الأساسية (خادم الكتابة، خادم القراءة، سجل الالتزام، كتالوج المساحة الاسمية، والعملاء مع رموز المصادقة) وما هو مسؤول عنه كل منها
كيف تتدفق البيانات من الالتزام إلى التوقعات المقروءة ولماذا تبقى تلك التدفقات حتمية
كيف يبدو “النجاح” في التفاعل الأول وكيفية التعرف عليه في الردود

متى تستخدم هذا

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

الهيكل عالي المستوى

يستخدم Asset Core بنية فصل بين الكتابة والقراءة مع مصدر الأحداث كمصدر للحقيقة. هذا الفصل أساسي: يقوم خادم الكتابة بتحسين الدقة والحتمية، بينما يقوم خادم القراءة بتحسين أداء الاستعلام ورؤية الحداثة. معًا، يشكلان نظامًا مترابطًا حيث يعد سجل الالتزام الجسر بين الكتابات والقراءات.

┌──────────────┐        ┌──────────────┐
│ Write Daemon │        │ Read Daemon  │
└──────┬───────┘        └──────▲───────┘
       │                       │
       │ Events                │ Tail + Apply
       ▼                       │
   ┌───────────────────────────┴──┐
   │      Commit Log (Events)     │
   │   (sealed batches, ordered)  │
   └──────────────────────────────┘

اكتب daemon

يقبل خادم الكتابة طلبات HTTP POST إلى /v1/write/namespaces/{namespace_id}/commit. إنه المكون الوحيد الذي يغير الحالة، لذا يتم تسلسل كل عملية التزام ويظل النظام حتميًا تحت التزامن.

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

خدمة الكتابة:

يتحقق من صحة المعاملات الواردة (يتحقق من هيكل العملية، الشروط المسبقة)
ينفذ العمليات ضد وقت التشغيل (يطبق منطق الأعمال عبر طبقات L2/L3)
يقوم بتجميع الأحداث في دفعات (يجمع الأحداث مع أرقام تسلسلية)
يحتفظ بالدفعات في سجل الالتزام الخلفي قبل الإقرار (تعتمد المتانة على اختيار الخلفية)

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

اقرأ daemon

يقدم خادم القراءة استعلامات HTTP GET. يقوم بتجسيد الإسقاطات من سجل الالتزام بحيث تكون القراءة سريعة ومتسقة وقابلة للتفسير. الإسقاطات هي بيانات مشتقة - إذا فقدت، يمكن إعادة بنائها من سجل الالتزام (انظر Freshness and Replay).

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

خدمة القراءة:

يتتبع سجل الالتزام للدفعات الجديدة (يستعلم عن الأحداث منذ آخر نقطة تفتيش)
تطبق الأحداث عبر إعادة التشغيل الحتمية (تستخدم إعدادات L1، انظر نموذج التشغيل)
ينشر لقطات بدون نسخ (تبادل ذري، لا تحديثات جزئية مرئية)
تقارير بيانات الانتعاش (الفارق بين الأحداث الملتزمة وحالة الاستعلام)

تُعيد الاستعلامات توقعات في نقطة زمنية معينة مع معلومات عن الحداثة (world_seq، التأخير في الالتزامات والميلي ثانية)، بحيث يمكنك التفكير في القدم بشكل صريح. يمكن للعملاء حظر القراءة حتى تصبح حديثة بما فيه الكفاية عن طريق تمرير x-assetcore-min-world-seq.

ما تكسبه: أداء الاستعلامات مستقل عن حمل الكتابة، حالة قراءة قابلة للتخلص (إعادة بناء من السجل)، رؤية في القدم (لا تأخير مخفي). ما تتخلى عنه: القراءات ليست جديدة على الفور - هناك دائمًا بعض التأخير (عادةً بالمللي ثانية).

سجل الالتزام

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

سجل الالتزام هو:

الإضافة فقط: يتم إضافة الأحداث في النهاية، ولا يتم تعديلها أو حذفها
غير قابلة للتغيير: بمجرد كتابتها، لا يمكن تغيير الدفعات أو إعادة ترتيبها
متسلسل: كل دفعة لها رقم تسلسل أحادي (ترتيب كامل)
دائم (اختياري): عندما يتم دعمها بواسطة تخزين الملفات أو التخزين المجزأ، يتم الاحتفاظ بالدفعات قبل الإقرار

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

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

العميل

يمكن لأي عميل HTTP التفاعل مع Asset Core. تعتبر SDKs طبقات رقيقة فوق نفس عقد HTTP، لذا لديك دائمًا مسار احتياطي عندما تحتاج إلى تصحيح الأخطاء على مستوى البروتوكول.

العملاء:

إرسال المعاملات إلى عملية الكتابة (POST /v1/write/namespaces/{id}/commit)
استعلام الحالة من عملية القراءة (GET /v1/read/namespaces/{id}/query)
استخدم مفاتيح التكرار الآمن لإعادة المحاولة (يمنع الالتزامات المكررة من إعادة المحاولة عبر الشبكة)

يوفر SDK بايثون مساعدات محددة وملفات تغليف مريحة، لكن HTTP الخام يعمل مع أي لغة. هذا يعني أنك لن تكون مقيدًا بـ SDK معين—عندما تحتاج إلى استكشاف الأخطاء على مستوى البروتوكول، يمكنك استخدام curl أو أي عميل HTTP.

الهدف

بدء الاستخدام يعني:

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

هذا يؤكد أن بيئتك تعمل ويعطيك أساسًا لتجارب وتكاملات أكثر تعقيدًا.

الخطوات التالية

الالتزام الأول والقراءة - دليل خطوة بخطوة مع أمثلة HTTP، ثم التعمق في HTTP API و المعاملات
استخدام SDK بايثون - نفس سير العمل مع مساعدات بايثون المخصصة لتسريع التكرار
سيناريو الذراع الروبوتية المستمر - جولة كاملة في العالم الحقيقي مع تفاصيل السجلات وإعادة التشغيل الحتمية