يمكن لعقد DuskVM أن ينجو من فشل العقدة بينما ينسى تطبيقي فجأة كيفية التحدث إليه.
السبب يكمن خارج السلسلة. يقوم Forge ببناء مخرَجين من WASM من نفس المصدر: العقدة التي تعمل داخل DuskVM، وسائق بيانات يتولى التعامل مع JSON القابل للقراءة لتحويله إلى rkyv وفك ترميزه. لا يتم نشر هذا السائق كجزء من عقد السلسلة على-الربط.
إذا أردت لمسارات عقد JSON الخاصة بـ Rusk أن تنفّذ ذلك التحويل، يقوم مالك العقد بتسجيل السائق لدى تلك العقدة.
وبالتالي يمكنني النشر مرة واحدة، والاختبار مقابل Node A، ورؤية استدعاءات قابلة للقراءة وواضحة، ثم إجراء failover إلى Node B والاصطدام بحالة غريبة. العقد موجودة. السلسلة سليمة. لكن driver_available قد يكون false، فيفقد التطبيق سطح فك الترميز الذي بُني حوله.
هذه هي فخّ الإنتاج بالنسبة لي. لم تفشل آلية الإجماع. لم تفشل العقدة. لقد غيّر failover الخاص بي اعتمادًا خارج السلسلة كنت اعتبره أنه ينتقل مع العقد.
سأجعل توفر السائق جزءًا من جاهزية العقدة وأتحقق منه في كل نقطة نهاية من نقاط Rusk قبل وصول حركة المرور إليها.
على DuskVM، يمكن للعقد أن تنجو من failover بينما يختل المترجم الخاص بها.
#dusk $DUSK @Dusk
السبب يكمن خارج السلسلة. يقوم Forge ببناء مخرَجين من WASM من نفس المصدر: العقدة التي تعمل داخل DuskVM، وسائق بيانات يتولى التعامل مع JSON القابل للقراءة لتحويله إلى rkyv وفك ترميزه. لا يتم نشر هذا السائق كجزء من عقد السلسلة على-الربط.
إذا أردت لمسارات عقد JSON الخاصة بـ Rusk أن تنفّذ ذلك التحويل، يقوم مالك العقد بتسجيل السائق لدى تلك العقدة.
وبالتالي يمكنني النشر مرة واحدة، والاختبار مقابل Node A، ورؤية استدعاءات قابلة للقراءة وواضحة، ثم إجراء failover إلى Node B والاصطدام بحالة غريبة. العقد موجودة. السلسلة سليمة. لكن driver_available قد يكون false، فيفقد التطبيق سطح فك الترميز الذي بُني حوله.
هذه هي فخّ الإنتاج بالنسبة لي. لم تفشل آلية الإجماع. لم تفشل العقدة. لقد غيّر failover الخاص بي اعتمادًا خارج السلسلة كنت اعتبره أنه ينتقل مع العقد.
سأجعل توفر السائق جزءًا من جاهزية العقدة وأتحقق منه في كل نقطة نهاية من نقاط Rusk قبل وصول حركة المرور إليها.
على DuskVM، يمكن للعقد أن تنجو من failover بينما يختل المترجم الخاص بها.
#dusk $DUSK @Dusk
