ما هو الحجم المناسب للخدمات المصغرة؟ غالباً ما تسمع شيئاً يؤثر على "ليس كبيراً للغاية وليس صغيراً للغاية" - وعلى الرغم من أن هذا صحيح بالتأكيد، فإنه ليس مفيداً جداً في الممارسة العملية. ولكن إذا بدأت من نموذج مجال مصمم بعناية، فمن الأسهل بكثير التفكير في الخدمات المصغرة.
تستخدم هذه المقالة خدمة تسليم الطائرات بدون طيار كمثال على التشغيل. يمكنك قراءة المزيد حول السيناريو وتنفيذ المرجع المقابل هنا.
من نموذج المجال إلى الخدمات المصغرة
في المقالة السابقة، حددنا مجموعة من السياقات المحددة لتطبيق تسليم الطائرات بدون طيار. ثم بحثنا عن كثب في أحد هذه السياقات المحدودة، وهو سياق الشحن المرتبط، وحددنا مجموعة من الكيانات والمجموعات وخدمات المجال لهذا السياق المحدد.
الآن نحن على استعداد للانتقال من نموذج المجال إلى تصميم التطبيق. إليك طريقة يمكنك استخدامها لاشتقاق خدمات مصغرة من نموذج المجال.
ابدأ بسياق محدد. بشكل عام، يجب ألا تمتد الوظيفة في الخدمة المصغرة لأكثر من سياق واحد محدد. حسب التحديد، يضع السياق المحدد علامة على حدود نموذج مجال معين. إذا وجدت أن خدمة مصغرة تمزج نماذج مجال مختلفة معاً، وهذا هو علامة على أنك قد تحتاج إلى العودة وتحسين تحليل مجالك.
بعد ذلك، انظر المجموعات في نموذج المجال. وغالبًا ما تكون المجموعات مرشحين جيدين للخدمات المصغرة. تعرض المجموعة المصممة بشكل جيد العديد من خصائص الخدمة المصغرة المصممة تصميماً جيداً:
- وتعتمد المجموعة على متطلبات العمل وليس الاهتمامات الفنية، مثل الوصول إلى البيانات أو الرسائل.
- وينبغي أن يكون للمجموعة تماسك وظيفي عالٍ.
- المجموعة هو حد استمرار.
- وينبغي أن تكون المجموعات مقرونة بشكل فضفاض.
خدمات المجال هي أيضًا مرشح جيد للخدمات المصغرة. خدمات المجال هي عمليات عديمة الحالة عبر مجموعات متعددة. مثال نموذجي هو سير عمل يتضمن العديد من الخدمات المصغرة. سنرى مثالاً على ذلك في تطبيق توصيل الطائرات بدون طيار.
وأخيرًا، ضع في الاعتبار المتطلبات غير الوظيفية. انظر إلى عوامل مثل حجم الفريق وأنواع البيانات والتقنيات ومتطلبات قابلية التوسع ومتطلبات التوفر ومتطلبات الأمان. قد تقودك هذه العوامل إلى مزيد من تجزئة الخدمة المصغرة إلى اثنين من الخدمات الصغيرة أو أكثر، أو القيام بالعكس ودمج العديد من الخدمات المصغرة في واحدة.
بعد تحديد الخدمات المصغرة في تطبيقك، تحقق من صحة تصميمك وفقاً للمعايير التالية:
- تمثل الخدمة مسؤولية واحدة.
- لا توجد مكالمات دردشة بين الخدمات. إذا تسبب تقسيم الوظائف إلى خدمتين في إجراء دردشة زائدة، فقد يكون من الأعراض أن هذه الدالات تنتمي إلى نفس الخدمة.
- كل خدمة صغيرة بالدرجة الكافية بحيث يمكن إنشاؤها من قبل فريق صغير يعمل بشكل مستقل.
- لا توجد تبعيات مشتركة تتطلب خدمتين أو أكثر ليتم نشرها في خطوة التأمين. يجب أن يكون من الممكن دائماً نشر خدمة دون إعادة توزيع أي خدمات أخرى.
- الخدمات ليست مقترنة بإحكام، ويمكن أن تتطور بشكل مستقل.
- لن تتسبب حدود الخدمة في مشاكل بتناسق البيانات أو تكاملها. في بعض الأحيان، يكون من المهم الحفاظ على تناسق البيانات عن طريق وضع الوظائف في خدمة مصغرة واحدة. مع ذلك، ضع في اعتبارك ما إذا كنت بحاجة حقاً إلى اتساق قوي. هناك استراتيجيات لمعالجة الاتساق النهائي في نظام موزع، وغالباً ما تفوق فوائد تحليل الخدمات تحديات إدارة الاتساق النهائي.
من المهم أن تكون عملياً وتذكر أن التصميم المعتمد على المجال هو عملية متكررة. في حالة الشك، ابدأ بخدمات مصغرة مشوشة. من الأسهل تقسيم خدمة مصغرة إلى خدمتين أصغر مما هو عليه الحال في وظائف إعادة بناء التعليمات البرمجية عبر العديد من الخدمات المصغرة الحالية.
مثال: تحديد الخدمات المصغرة لتطبيق تسليم الطائرات بدون طيار
تذكر أن فريق التطوير قد حدد المجموعات الأربعة - التسليم والحزمة والطائرات بدون طيار والحساب - واثنين من خدمات المجال، المجدول والمشرف.
التسليم والحزمة مرشحان واضحان للخدمات المصغرة. ينسق المجدول والمشرف الأنشطة التي تقوم بها الخدمات المصغرة الأخرى، لذلك من المنطقي تنفيذ خدمات المجال هذه كخدمات مصغرة.
الطائرات بدون طيار والحساب مثيران للاهتمام لأنهما ينتميان إلى سياقات محددة أخرى. أحد الخيارات هو أن يتصل المجدول بالسياقين المقيدين بالطائرة بدون طيار والحساب مباشرة. خيار آخر هو إنشاء خدمات مصغرة لطائرات بدون طيار والحساب داخل سياق الشحن المحدد. ستتوسط هذه الخدمات المصغرة بين السياقات المحددة، عن طريق الكشف عن واجهات برمجة التطبيقات أو مخططات البيانات الأكثر ملاءمة لسياق الشحن.
تفاصيل السياقات المقيدة بطائرات بدون طيار والحساب خارج نطاق هذه التوجيهات، لذلك أنشأنا خدمات وهمية لهم في التنفيذ المرجعي. ولكن فيما يلي بعض العوامل التي يجب مراعاتها في هذه الحالة:
ما هو حمل الشبكة للاتصال مباشرة بالسياق الآخر المرتبط؟
هل مخطط البيانات للسياق الآخر المرتبط مناسب لهذا السياق، أم أنه من الأفضل أن يكون لديك مخطط مصمم خصيصاً لهذا السياق المحدد؟
هل السياق الآخر المرتبط نظام قديم؟ إذا كان الأمر كذلك، يمكنك إنشاء خدمة تعمل كطبقة لمكافحة الفساد للترجمة بين النظام القديم والتطبيق الحديث.
ما هي بنية الفريق؟ هل من السهل التواصل مع الفريق المسؤول عن السياق الآخر المرتبط؟ إذا لم يكن الأمر كما هو، فإن إنشاء خدمة تتوسط بين السياقين يمكن أن يساعد في التخفيف من تكلفة الاتصال عبر الفريق.
حتى الآن، لم ندرس أي متطلبات غير وظيفية. بالتفكير في متطلبات معدل نقل التطبيق، قرر فريق التطوير إنشاء خدمة مصغرة منفصلة للاستيعاب تكون مسؤولة عن استيعاب طلبات العميل. ستنفذ هذه الخدمة المصغرة تسوية التحميل عن طريق وضع الطلبات الواردة في مخزن مؤقت للمعالجة. سيقرأ المجدول الطلبات من المخزن المؤقت وينفذ سير العمل.
أدت المتطلبات غير الوظيفية إلى إنشاء الفريق خدمة إضافية واحدة. جميع الخدمات حتى الآن كانت حول عملية جدولة وتقديم الحزم في الوقت الحقيقي. ولكن النظام يحتاج أيضاً إلى تخزين تاريخ كل تسليم في التخزين طويل الأجل لتحليل البيانات. ونظر الفريق في جعل هذه مسؤولية خدمة التسليم. ومع ذلك، تختلف متطلبات تخزين البيانات اختلافاً كبيراً للتحليل التاريخي مقابل العمليات أثناء الطيران (راجع اعتبارات البيانات). لذلك، قرر الفريق إنشاء خدمة Delivery History منفصلة، والتي ستنصت لأحداث DeliveryTracking من خدمة التسليم وكتابة الأحداث في موقع تخزين طويل الأجل.
يوضح الرسم التخطيطي التالي التصميم في هذه المرحلة:
قم بتنزيل ملف Visio لهذه البنية.
الخطوات التالية
في هذه المرحلة، يجب أن يكون لديك فهم واضح للغرض من كل خدمة مصغرة ووظائفها في تصميمك. الآن يمكنك تصميم النظام.