يتطلب بناء الأنظمة الموزعة التعامل مع موازنات معقدة بين حدود الخدمات وأنماط الاتصال واتساق البيانات. توفر هذه المهارة أنماطًا مثبتة وأمثلة برمجية لتفكيك الأحادية الأجزاء (monoliths)، وتنفيذ اتصال مرن بين الخدمات، وإدارة المعاملات الموزعة بشكل فعال.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "microservices-patterns". قم بتحليل هذا أحادي الأجزاء للتجارة الإلكترونية مع وحدات للطلبات والدفعات والمخزون والشحن وحسابات المستخدمين. اقترح حدود الخدمات المصغرة.
النتيجة المتوقعة:
بناءً على مبادئ التصميم القائم على المجال، إليك حدود الخدمات الموصى بها: 1) خدمة الطلبات - تملك دورة حياة الطلب وحالة الطلب؛ 2) خدمة الدفع - تعالج معالجة الدفع والمبالغ المستردة؛ 3) خدمة المخزون - تدير مستويات المخزون والحجوزات؛ 4) خدمة الكتالوج - معلومات المنتج والتسعير؛ 5) خدمة الشحن - التنفيذ وتتبع التسليم. يجب أن تظل حسابات المستخدمين جزءًا من خدمة هوية مشتركة عبر النظام. يجب أن تملك كل خدمة قاعدة بياناتها وتنشر أحداث المجال للحصول على الاتساق النهائي.
استخدام "microservices-patterns". صمم اتصالًا قائمًا على الأحداث لتلبية الطلبات. متى يجب أن أستخدم الأحداث مقابل مكالمات الخدمة المباشرة؟
النتيجة المتوقعة:
استخدم الأحداث عندما: 1) تحتاج خدمات متعددة إلى التفاعل مع نفس الحدث (OrderCreated يؤدي إلى حجز المخزون وإنشاء تسمية الشحن وإشعار العميل)؛ 2) ق��ول الفصل الزمني (يمكن حجز المخزون بعد ثوانٍ)؛ 3) تريد فصلًا فضفاضًا بين الخدمات. استخدم المكالمات المتزامنة المباشرة عندما: 1) تحتاج إلى استجابة فورية (التحقق من المخزون قبل وضع الطلب)؛ 2) لا يمكن للمتصل المتابعة بدون الاستجابة؛ 3) مطلوب اتساق قوي. لتلبية الطلبات، انشر حدث OrderCreated بشكل غير متزامن للمخزون والشحن، ولكن استخدم مكالمة متزامنة للتحقق من توفر المخزون أثناء وضع الطلب.
استخدام "microservices-patterns". أظهر لي نمط saga لدفع الطلب مع منطق التعويض.
النتيجة المتوقعة:
خطوات OrderPaymentSaga: 1) ReserveOrder - ينشئ طلبًا معلقًا؛ التعويض: CancelOrder. 2) ProcessPayment - يفرض رسومًا على العميل؛ التعويض: RefundPayment. 3) ConfirmInventory - يحجز العناصر؛ التعويض: ReleaseInventory. 4) CompleteOrder - يحدد الطلب مؤكدًا؛ التعويض: MarkOrderFailed. التنفيذ: إذا فشلت الخطوة 2 (الدفع)، نفذ الإجراءات التعويضية بالعكس: ReleaseInventory (تعويض الخطوة 3)، CancelOrder (تعويض الخطوة 1). هذا يضمن عودة النظام إلى حالة متسقة بعد أي فشل.
التدقيق الأمني
آمنAll 29 static analysis findings are false positives from markdown code examples in educational documentation. The skill contains only documentation files (SKILL.md and implementation-playbook.md) with Python code samples demonstrating microservices patterns. No executable code, scripts, or actual security risks present. The 'external_commands' and 'network' patterns detected are from code block delimiters and example URLs in instructional content.
درجة الجودة
ماذا يمكنك بناءه
تفكيك تطبيق أحادي الأجزاء
مخطط برمجي يخطط لتفكيك تطبيق Rails أحادي ضخم إلى خدمات مركزة. استخدم هذه المهارة لتحديد السياقات المحددة وتعريف حدود الخدمة وتخطيط استراتيجية هجرة من نوع fig التدريجي.
تصميم الاتصال القائم على الأحداث
مهندس خلفي ينفذ مراسلة غير متزامنة بين الخدمات. استخدم هذه المهارة للاختيار بين Kafka و RabbitMQ أو المراسلة السحابية الأصلية، وتصميم مخططات الأحداث، وتنفيذ معالجات الأحداث مع معالجة الأخطاء الصحيحة.
تنفيذ أنماط المرونة
مهندس منصة يبني الموثوقية في الاتصال من خدمة إلى خدمة. استخدم هذه المهارة لتطبيق قواطع الدائرة وتنفيذ منطق إعادة المحاولة مع التراجع الأسي ومنع الفشل المتتالي في نظامك الموزع.
جرّب هذه الموجهات
قم بتحليل هذا التطبيق الأحادي الأجزاء [صف المجال والوحدات] واقترح حدود الخدمات المصغرة. قم بتجمي�� الوظائف ذات الصلة حسب القدرة التجارية والنطاقات الفرعية لـ DDD. اشرح السبب لكل حد خدمة مقترحة.
أحتاج إلى [الخدمة A] للاتصال بـ [الخدمة B] لـ [حالة استخدام محددة]. قارن بين REST المتزامن والنهج القائم على الأحداث غير المتزامن. أوصي بأفضل نمط مع مرا��اة وقت الاستجابة ومتطلبات الاتساق ومعالجة الفشل.
صمم تنسيق saga لـ [العملية التجارية التي تتضمن خدمات متعددة]. حدد كل خطوة معاملة، وعرف الإجراءات التعويضية للفشل، وأظهر تدفق التنفيذ مع معالجة الأخطاء.
تستدعي خدمتي [خدمة خارجية/تبعية] وتعاني من فشل مت��طع. صمم تنفيذ قاطع دائرة مع عتبة فشل مناسبة ومدة انتهاء مهلة الاسترداد وسلوك الاحتياطي. أظهر الكود في [لغتك المفضلة].
أفضل الممارسات
- ابدأ بـ monolith معياري واستخرج الخدمات فقط عندما يكون لديك حد تجاري واضح وحاجة تشغيلية
- صمم الخدمات حول القدرات التجارية والسياقات المحدودة من التصميم القائم على المجال، وليس الطبقات التقنية
- فضل الاتصال القائم على الأحداث غير المتزامن على REST المتزامن للحصول على فصل فضفاض ومرونة أفضل
- نفذ قواطع الدوائر وإعادة المحاولات مع التراجع الأسي ومدد انتهاء المهام لجميع مكالمات الخدمة البينية
- طبق نمط قاعدة بيانات لكل خدمة لتجنب اقتران قاعدة البيانات المشتركة وتمكين عمليات النشر المستقلة
- استخدم التتبع الموزع والتسجيل المنظم لمراقبة الطلبات عبر حدود الخدمة
تجنب
- النظام الموزع أحادي الأجزاء - خدمات يجب نشرها معًا ومشاركة قواعد البيانات، مما يهزم فوائد الخدمات المصغرة
- الخدمات الحديثة بشكل مفرط - مكالمات متزامنة مفرطة بين الخدمات تنشئ اقترانًا وثيقًا ووقت استجابة
- قواعد البيانات المشتركة - خدمات متعددة تصل إلى نفس قاعدة البيانات تنشئ تزامن المخطط وتبعيات النشر
- تجاهل أوضاع الفشل - افتراض أن الشبكات موثوقة أو الخدمات متاحة دائمًا أو ضمان توصيل الرسائل
- الخدمات المصغرة المبكرة - بدء مشروع جديد بالخدمات المصغرة قبل فهم المجال وعبء التشغيل
الأسئلة المتكررة
متى يجب أن أستخدم الخدمات المصغرة بدلاً من monolith؟
كيف أتعامل مع المعاملات عبر خدمات متعددة؟
هل يجب أن أستخدم REST أو المراسلة لاتصال الخدمة؟
كيف أمنع الفشل المتتالي في الخدمات المصغرة؟
ما هو أكبر خطأ ترتكبه الفرق مع الخدمات المصغرة؟
كيف أصحح المشكلات عبر خدمات متعددة؟
تفاصيل المطور
المؤلف
sickn33الترخيص
MIT
المستودع
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/microservices-patternsمرجع
main
بنية الملفات