الخدمات المصغرة

الموسوعة الحرة

في هندسة البرمجيات ، تُعدّ بنية الخدمات المصغّرة نمطًا معماريًا يُنظّم التطبيق في مجموعة من الخدمات الدقيقة ذات الترابط الضعيف، والتي تتواصل فيما بينها عبر بروتوكولات خفيفة الوزن. يُمكّن هذا النمط فرق العمل من تطوير الخدمات ونشرها وتوسيع نطاقها بشكل مستقل، مما يُحسّن من نمطية النظام وقابليته للتوسع والتكيّف. مع ذلك، يُضيف هذا النمط تعقيدًا إضافيًا، لا سيما في إدارة الأنظمة الموزّعة والتواصل بين الخدمات، مما يجعل التنفيذ الأولي أكثر صعوبة مقارنةً بالبنية المتجانسة . [ 1 ]

تعريف

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

الاستخدام

يشيع اعتماد بنية الخدمات المصغرة في تطبيقات الحوسبة السحابية الأصلية ، والحوسبة بلا خوادم ، والتطبيقات التي تستخدم نشر الحاويات الخفيف عبر المحاكاة الافتراضية على مستوى نظام التشغيل . ووفقًا لفولر ، نظرًا للعدد الكبير من الخدمات (مقارنةً بتطبيقات البرمجيات المتجانسة)، فإن التسليم المستمر اللامركزي ومنهجية DevOps مع مراقبة شاملة للخدمات ضروريان لتطوير هذه التطبيقات وصيانتها وتشغيلها بكفاءة. [ 5 ] ومن نتائج (وأسباب) اتباع هذا النهج إمكانية توسيع نطاق كل خدمة مصغرة على حدة. ففي النهج المتجانس، يجب توسيع نطاق تطبيق يدعم ثلاث وظائف بالكامل حتى لو كانت إحدى هذه الوظائف فقط تعاني من قيود على الموارد. [ 6 ] أما مع الخدمات المصغرة، فلا يلزم توسيع نطاق سوى الخدمة المصغرة التي تدعم الوظيفة التي تعاني من قيود على الموارد، مما يوفر مزايا في تحسين استخدام الموارد وخفض التكاليف. [ 7 ] وعلى الرغم من مزاياها، فإن بنية الخدمات المصغرة تُثير تحديات مثل زيادة التعقيد التشغيلي، وزمن استجابة الشبكة، والحاجة إلى آليات مراقبة قوية وتحمل للأعطال.

بنية قائمة على الخلايا في الخدمات المصغرة

تُعدّ بنية الخلايا تصميمًا للحوسبة الموزعة ، حيث تُنظّم الموارد الحاسوبية في وحدات مستقلة تُسمى الخلايا. تعمل كل خلية بشكل مستقل، وتتعامل مع مجموعة فرعية من الطلبات مع الحفاظ على قابلية التوسع، وعزل الأعطال، والتوافر. [ 2 ] [ 8 ] [ 9 ]

تتألف الخلية عادةً من عدة خدمات مصغرة وتعمل كوحدة مستقلة. في بعض التطبيقات، تُنسخ مجموعات كاملة من الخدمات المصغرة عبر خلايا متعددة، مما يسمح بإعادة توجيه الطلبات إلى خلية تشغيلية أخرى في حال تعطل إحداها. يهدف هذا النهج إلى تحسين مرونة النظام ككل من خلال الحد من تأثير الأعطال الموضعية. [ 2 ] [ 8 ] [ 9 ]

تتضمن بعض التطبيقات قواطع دوائر داخل الخلايا وفيما بينها. داخل الخلية الواحدة، يمكن استخدام قواطع الدوائر للحد من حالات الفشل المتتالية بين الخدمات المصغرة، بينما يمكن لقواطع الدوائر بين الخلايا عزل الخلايا المعطلة وإعادة توجيه حركة البيانات إلى الخلايا التي لا تزال تعمل. [ 2 ] [ 8 ] [ 9 ]

تم اعتماد بنية الخلايا في بعض الأنظمة الموزعة واسعة النطاق حيث يُعد عزل الأعطال والتكرار من أولويات التصميم. ويختلف تطبيقها بناءً على متطلبات النظام، وقيود البنية التحتية، والأهداف التشغيلية المحددة. [ 2 ] [ 8 ] [ 9 ]

تاريخ

في عام ١٩٩٩، كان مطور البرمجيات بيتر رودجرز يعمل على مشروع ديكستر البحثي في ​​مختبرات هيوليت باكارد ، والذي كان يهدف إلى جعل الشيفرة البرمجية أقل هشاشة، وجعل أنظمة البرمجيات المعقدة واسعة النطاق قادرة على التكيف مع التغييرات. [ ١٠ ] أدى هذا المسار البحثي في ​​نهاية المطاف إلى تطوير الحوسبة الموجهة نحو الموارد (ROC)، وهي تجريد حسابي معمّم، حيث تُعدّ REST مجموعة فرعية خاصة منه. في عام ٢٠٠٥، وخلال عرض تقديمي في مؤتمر Web Services Edge، دافع رودجرز عن " خدمات REST "، وذكر أن " مكونات البرمجيات هي خدمات ويب مصغّرة... تُركّب الخدمات المصغّرة باستخدام مسارات شبيهة بنظام يونكس (الويب يلتقي يونكس = ترابط مرن حقيقي ). يمكن للخدمات استدعاء خدمات أخرى (بالإضافة إلى بيئات تشغيل بلغات متعددة). تُجرّد تجميعات الخدمات المعقدة خلف واجهات URI بسيطة . يمكن عرض أي خدمة، بأي مستوى من التفصيل." وصف كيف أن منصة الخدمات المصغرة المصممة جيدًا "تطبق المبادئ المعمارية الأساسية للويب وخدمات REST جنبًا إلى جنب مع جدولة وخطوط أنابيب تشبه نظام Unix لتوفير مرونة جذرية وبساطة محسنة في البنى الموجهة نحو الخدمات. [ 11 ]

في عام ٢٠٠٥ أيضاً، كتب أليستير كوكبيرن عن البنية السداسية، وهي نمط تصميم برمجي يُستخدم مع الخدمات المصغرة. يُتيح هذا النمط تصميم الخدمات المصغرة، إذ يعزل منطق الأعمال في طبقات عن الخدمات المساعدة اللازمة لنشر وتشغيل الخدمة المصغرة بشكل مستقل تماماً عن غيرها.

دقة الخدمات المصغرة

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

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

ربط الخدمات المصغرة بالسياقات المحددة

يُعرّف السياق المحدود، وهو مفهوم أساسي في تصميم المجال الموجه (DDD)، منطقةً محددةً يكون فيها نموذج المجال متسقًا وصحيحًا، مما يضمن الوضوح وفصل الاهتمامات. [ 12 ] في بنية الخدمات المصغرة، غالبًا ما يُربط السياق المحدود بخدمة مصغرة، ولكن هذه العلاقة قد تختلف باختلاف منهجية التصميم. تُعدّ العلاقة من نوع واحد إلى واحد، حيث يُنفّذ كل سياق محدود كخدمة مصغرة واحدة، مثاليةً عادةً لأنها تحافظ على حدود واضحة، وتقلل من الترابط، وتُمكّن من النشر والتوسع بشكل مستقل. مع ذلك، قد تكون هناك روابط أخرى مناسبة أيضًا: قد تنشأ علاقة من نوع واحد إلى متعدد عندما يُقسّم السياق المحدود إلى خدمات مصغرة متعددة لتلبية احتياجات التوسع المختلفة أو الاحتياجات التشغيلية الأخرى، بينما قد تُدمج علاقة من نوع متعدد إلى واحد سياقات محدودة متعددة في خدمة مصغرة واحدة لتبسيط العملية أو لتقليل النفقات التشغيلية. يجب أن يوازن اختيار العلاقة بين مبادئ تصميم المجال الموجه (DDD) وأهداف العمل والقيود التقنية والمتطلبات التشغيلية للنظام. [ 14 ]

فوائد

تتعدد فوائد تقسيم التطبيق إلى خدمات أصغر مختلفة:

  • النمطية : تجعل هذه الميزة التطبيق أسهل في الفهم والتطوير والاختبار، وأكثر مقاومة لتآكل البنية. [ 15 ] غالبًا ما تُناقش هذه الميزة مقارنةً بتعقيد البنى المتجانسة. [ 16 ]
  • قابلية التوسع : بما أن الخدمات المصغرة يتم تنفيذها ونشرها بشكل مستقل عن بعضها البعض، أي أنها تعمل ضمن عمليات مستقلة، فإنه يمكن مراقبتها وتوسيع نطاقها بشكل مستقل. [ 17 ]
  • تكامل الأنظمة غير المتجانسة والقديمة : تُعتبر الخدمات المصغرة وسيلة فعّالة لتحديث تطبيقات البرمجيات المتجانسة القائمة. [ 18 ] [ 19 ] وتوجد تقارير تجارب من عدة شركات نجحت في استبدال أجزاء من برامجها الحالية بالخدمات المصغرة، أو هي بصدد القيام بذلك. [ 20 ] ويتم تحديث البرامج القديمة باستخدام منهجية تدريجية. [ 21 ]
  • التطوير الموزع: يُتيح هذا الأسلوب التطوير المتوازي من خلال تمكين فرق صغيرة مستقلة من تطوير خدماتها ونشرها وتوسيع نطاقها بشكل مستقل. [ 22 ] كما يسمح بظهور بنية الخدمة الفردية من خلال إعادة هيكلة مستمرة . [ 23 ] وتُسهّل البنى القائمة على الخدمات المصغرة التكامل والتسليم والنشر المستمر . [ 24 ]

الانتقادات والمخاوف

يتعرض نهج الخدمات المصغرة للنقد بسبب عدد من المشكلات:

  • تشكل الخدمات حواجز معلوماتية. [ 25 ]
  • تتسم المكالمات بين الخدمات عبر الشبكة بتكلفة أعلى من حيث زمن استجابة الشبكة ووقت معالجة الرسائل مقارنةً بالمكالمات داخل عملية خدمة متجانسة . [ 26 ]
  • قد يكون الاختبار والنشر معقدين . [ 27 ]
  • يُعدّ نقل المسؤوليات بين الخدمات أكثر صعوبة. [ 15 ] وقد يتطلب ذلك التواصل بين فرق مختلفة، أو إعادة كتابة الوظائف بلغة برمجة أخرى، أو دمجها في بنية تحتية مختلفة. [ 26 ] مع ذلك، يمكن نشر الخدمات المصغّرة بشكل مستقل عن بقية التطبيق، بينما تحتاج الفرق العاملة على التطبيقات المتكاملة إلى التنسيق لنشرها معًا. [ 21 ]
  • قد يؤدي اعتبار حجم الخدمات آلية الهيكلة الأساسية إلى عدد كبير جدًا من الخدمات، في حين أن البديل المتمثل في التجزئة الداخلية قد يؤدي إلى تصميم أبسط. ويتطلب ذلك فهم البنية العامة للتطبيقات والترابطات بين مكوناتها. [ 28 ]
  • تُعتبر عمليات الالتزام على مرحلتين نمطًا سيئًا في البنى القائمة على الخدمات المصغرة، مما يؤدي إلى ترابط أوثق بين جميع المشاركين في المعاملة. ومع ذلك، فإن غياب هذه التقنية يتسبب في إجراءات معقدة يتعين على جميع المشاركين في المعاملة تنفيذها للحفاظ على اتساق البيانات. [ 29 ]
  • يصبح تطوير ودعم العديد من الخدمات أكثر صعوبة إذا تم بناؤها باستخدام أدوات وتقنيات مختلفة - وتُعد هذه مشكلة خاصة إذا كان المهندسون ينتقلون بين المشاريع بشكل متكرر. [ 30 ]
  • تم تصميم البروتوكول المستخدم عادةً مع الخدمات المصغرة (HTTP) للخدمات العامة، وبالتالي فهو غير مناسب للخدمات المصغرة الداخلية التي غالباً ما يجب أن تكون موثوقة بشكل لا تشوبه شائبة. [ 31 ]
  • على الرغم من أن منهجية التفكيك ليست خاصة بالخدمات المصغرة، إلا أنها غالباً ما تستخدم التفكيك الوظيفي، الذي لا يتعامل مع التغييرات في المتطلبات مع استمراره في إضافة تعقيد الخدمات. [ 31 ]
  • إن مفهوم الخدمات المصغرة بحد ذاته مُضلل، إذ لا يوجد سوى خدمات. ولا يوجد تعريف دقيق يحدد متى تبدأ الخدمة أو تتوقف عن كونها خدمة مصغرة. [ 31 ]
  • تجميع البيانات. للحصول على رؤية شاملة لنظام العمل، يلزم استخراج مجموعات البيانات من مستودعات الخدمات المصغرة وتجميعها في مخطط واحد. على سبيل المثال، لإنشاء تقارير تشغيلية لا يمكن إعدادها باستخدام مستودع خدمة مصغرة واحد.

التعقيدات

تُضيف هذه البنية تعقيدًا إضافيًا ومشاكل جديدة، مثل زمن الاستجابة ، وتصميم تنسيق الرسائل ، [ 32 ] والنسخ الاحتياطي /التوافر/الاتساق (BAC)، [ 33 ] وموازنة الأحمال وتحمل الأعطال . [ 34 ] يجب معالجة جميع هذه المشاكل على نطاق واسع. لا يختفي تعقيد التطبيق المتجانس عند إعادة تنفيذه كمجموعة من الخدمات المصغرة، بل يتحول جزء منه إلى تعقيد تشغيلي. [ 35 ] ومن مظاهر هذا التعقيد أيضًا زيادة حركة مرور الشبكة وبطء الأداء. كما أن أي تطبيق يتكون من عدد من الخدمات المصغرة يحتوي على عدد أكبر من نقاط الربط للوصول إلى نظامه البيئي ، مما يزيد من تعقيد البنية. [ 36 ] وقد طُبقت مبادئ تنظيمية متنوعة (مثل استخدام الوسائط المتعددة كمحرك لحالة التطبيق (HATEOAS)، وتوثيق واجهة المستخدم ونموذج البيانات باستخدام Swagger ، وغيرها) للحد من تأثير هذا التعقيد الإضافي.

الأنماط المضادة

  • يُسلّط مصطلح "نمط الهجرة المُوجّه بالبيانات" (الذي صاغه مارك ريتشاردز) الضوء على تحديات تحديد أولويات هجرة البيانات أثناء الانتقال من بنية متجانسة إلى بنية الخدمات المصغّرة. ولمعالجة هذا النمط، يُمكن اتباع نهج تكراري، حيث يتم هجرة كود التطبيق أولًا، مع اعتماد الخدمات المصغّرة الجديدة مؤقتًا على قاعدة البيانات المتجانسة الحالية. ومع مرور الوقت، ومع تحسّن فهم النظام، يُمكن فصل البيانات وإعادة هيكلتها، مما يُمكّن كل خدمة مصغّرة من العمل بقواعد بياناتها الخاصة. تُسهم هذه الاستراتيجية في تبسيط عملية الهجرة وتقليل أخطاء هجرة البيانات. [ 13 ]
  • يصف مصطلح "نمط المهلة الزمنية" (Meatout Antipattern)، الذي صاغه مارك ريتشاردز، التحديات التي تواجه تحديد قيم المهلة الزمنية في الأنظمة الموزعة. قد تؤدي المهلات الزمنية القصيرة إلى فشل الطلبات المشروعة قبل الأوان، مما يستدعي حلولًا معقدة، بينما قد تؤدي المهلات الزمنية الطويلة إلى بطء الاستجابة للأخطاء وتجربة مستخدم سيئة. يمكن لنمط قاطع الدائرة معالجة هذه المشكلات من خلال مراقبة حالة الخدمة عبر آليات مثل نبضات القلب، أو "المعاملات الاصطناعية"، أو مراقبة الاستخدام في الوقت الفعلي. يُمكّن هذا النهج من اكتشاف الأعطال بشكل أسرع، ويُحسّن تجربة المستخدم بشكل عام في البنى الموزعة. [ 13 ]
  • يُمثل إعداد التقارير عن بيانات الخدمات المصغرة تحديات، إذ قد يؤدي استرجاع البيانات لخدمة إعداد التقارير إلى كسر نطاق الخدمات المصغرة، أو تقليل دقة توقيت البيانات، أو كليهما. وينطبق هذا بغض النظر عن طريقة سحب البيانات، سواءً من قواعد البيانات مباشرةً، أو عبر بروتوكول HTTP، أو على دفعات. ويُشير مارك ريتشاردز إلى هذا النمط بـ"نمط الإبلاغ المُتعمّد". [ 13 ] يتمثل أحد البدائل الممكنة لهذا النهج في قيام قواعد البيانات بدفع البيانات اللازمة إلى خدمة إعداد التقارير بشكل غير متزامن، بدلاً من قيام خدمة إعداد التقارير بسحبها. ورغم أن هذه الطريقة تتطلب عقدًا منفصلاً بين الخدمات المصغرة وخدمة إعداد التقارير، وقد يكون تنفيذها معقدًا، إلا أنها تُساعد في الحفاظ على نطاق الخدمات المصغرة مع ضمان دقة توقيت البيانات. [ 13 ]

التحديات

تُعدّ الخدمات المصغّرة عرضةً لمغالطات الحوسبة الموزّعة – وهي سلسلة من المفاهيم الخاطئة التي يمكن أن تؤدي إلى مشاكل كبيرة في تطوير البرمجيات ونشرها. [ 12 ]

تحديات مشاركة التعليمات البرمجية

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

أفضل الممارسات

يقترح ريتشاردز وفورد في كتابهما "أساسيات هندسة البرمجيات " (2020) أن يكون لكل خدمة مصغرة خصائصها المعمارية الخاصة (المعروفة أيضًا بالمتطلبات غير الوظيفية )، وأنه لا ينبغي للمهندسين المعماريين تحديد خصائص موحدة للنظام الموزع بأكمله . [ 12 ]

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

التقنيات

يمكن تنفيذ الخدمات المصغرة الحاسوبية بلغات برمجة مختلفة، وقد تستخدم بنى تحتية متباينة. لذا، فإن أهم الخيارات التقنية هي طريقة تواصل الخدمات المصغرة فيما بينها (متزامنة، غير متزامنة، تكامل واجهة المستخدم) والبروتوكولات المستخدمة في هذا التواصل (مثل RESTful HTTP، المراسلة، GraphQL ). في الأنظمة التقليدية، تؤثر معظم الخيارات التقنية، كلغة البرمجة، على النظام بأكمله. لذلك، يختلف منهج اختيار التقنيات اختلافًا كبيرًا. [ 37 ]

نشرت مؤسسة Eclipse مواصفات لتطوير الخدمات المصغرة، وهي Eclipse MicroProfile . [ 38 ] [ 39 ]

شبكة الخدمة

في شبكة الخدمات، يُقرن كل مثيل خدمة بمثيل خادم وكيل عكسي، يُسمى وكيل الخدمة أو وكيل الحاوية الجانبية. يتشارك مثيل الخدمة ووكيل الحاوية الجانبية حاويةً واحدة، وتُدار هذه الحاويات بواسطة أداة تنسيق حاويات مثل Kubernetes أو Docker Swarm أو DC/OS . تتولى وكلاء الخدمة مسؤولية التواصل مع مثيلات الخدمات الأخرى، ويمكنها دعم وظائف مثل اكتشاف الخدمات (المثيلات)، وموازنة الأحمال، والمصادقة والترخيص، والاتصالات الآمنة، وغيرها.

انظر أيضاً

مراجع

  1. ↑ فاولر، مارتن (2002). أنماط هندسة تطبيقات المؤسسات . أديسون-ويسلي بروفيشنال. ISBN 978-0321127426.
  2. 1 2 3 4 5 6 نيومان، سام (2015-02-20). بناء الخدمات المصغرة . دار نشر أورايلي ميديا. رقم ISBN 978-1491950357.
  3. ↑ وولف، إيبرهارد (12 أكتوبر 2016). الخدمات المصغرة: بنى برمجية مرنة . أديسون-ويسلي. ISBN 978-0134602417.
  4. ↑ ناداريشفيلي، آي.، ميترا، آر.، ماكلارتي، إم.، أموندسن، إم.، هندسة الخدمات المصغرة: مواءمة المبادئ والممارسات والثقافة، أورايلي 2016
  5. ↑ مارتن فاولر (28 أغسطس 2014). "متطلبات الخدمات المصغرة" . مؤرشف من الأصل في 3 أكتوبر 2023.
  6. ↑ ريتشاردسون، كريس (نوفمبر 2018). أنماط الخدمات المصغرة . منشورات مانينغ. 1.4.1 مكعب التوسع والخدمات المصغرة. ISBN 9781617294549.
  7. ↑ ميندونكا، نابور سي؛ جمشيدي، بويان؛ جارلان، ديفيد؛ باهل، كلاوس (16 أكتوبر 2019). "تطوير أنظمة الخدمات المصغرة ذاتية التكيف: التحديات والاتجاهات". مجلة IEEE للبرمجيات . 38 (2): 70-79 . arXiv : 1910.07660 . doi : 10.1109/MS.2019.2955937 . S2CID 204744007 . 
  8. 1 2 3 4 ريتشاردسون، كريس (2019). أنماط الخدمات المصغرة: مع أمثلة بلغة جافا . شيلتر آيلاند، نيويورك: منشورات مانينغ. ISBN 978-1-61729-454-9.
  9. 1 2 3 4 كريستوداس، بينيلداس (2019). أنماط معمارية عملية للخدمات المصغرة: خدمات جافا المصغرة القائمة على الأحداث مع Spring Boot و Spring Cloud . بيركلي، كاليفورنيا: Apress LP ISBN 978-1-4842-4501-9.
  10. ↑ راسل، بيري؛ رودجرز، بيتر؛ سيلمان، رويستون (2004). "هندسة وتصميم منصة تطبيقات XML" . تقارير HP الفنية . ص 62. تاريخ الاسترجاع: 20 أغسطس 2015 . 
  11. ↑ رودجرز، بيتر (15 فبراير 2005). "التطوير الموجه نحو الخدمات على NetKernel - أنماط وعمليات ومنتجات لتقليل تعقيد النظام" . CloudComputingExpo . SYS-CON Media. مؤرشف من الأصل في 20 مايو 2018. تم الاطلاع عليه في 19 أغسطس 2015 .
  12. 1 2 3 4 ريتشاردز، مارك؛ فورد، نيل (2020). أساسيات هندسة البرمجيات: منهج هندسي ( الطبعة الأولى). أورايلي. ISBN  9781492043454.
  13. 1 2 3 4 5 6 7 8 ريتشاردز، مارك. أنماط ومزالق الخدمات المصغرة . أورايلي.
  14. ↑ بناء الخدمات المصغرة، تأليف سام نيومان . رقم ISBN 978-1492034025.
  15. 1 2 تشين، ليان بينغ (2018). الخدمات المصغرة: تصميم البنية للتسليم المستمر و DevOps . المؤتمر الدولي لهندسة البرمجيات (ICSA 2018) . IEEE.
  16. ↑ يوسف، مازن (2016). "الخدمات المصغرة". الحوسبة السحابية IEEE . 3 (5): 4-5 . doi : 10.1109/MCC.2016.101 .
  17. ↑ دراغوني، نيكولا؛ لانسي، إيفان؛ لارسن، ستيفان ثوردال؛ مازارا، مانويل؛ مصطفى، روسلان؛ سافينا، لاريسا (2017). "الخدمات المصغرة: كيفية توسيع نطاق تطبيقك" (ملف PDF) . منظورات معلوماتية النظم . سلسلة محاضرات في علوم الحاسوب. المجلد 10742. الصفحات 95-104 . arXiv : 1702.07149 . Bibcode : 2017arXiv170207149D . doi : 10.1007/978-3-319-74313-4_8 . ISBN   978-3-319-74312-7. S2CID 1643730 . 
  18. ↑ نيومان، سام (2015). بناء الخدمات المصغرة . أورايلي. ISBN 978-1491950357.
  19. ↑ وولف، إيبرهارد (2016). الخدمات المصغرة: بنية برمجية مرنة . أديسون ويسلي. ISBN 978-0134602417.
  20. ↑ كنوخ، هولجر؛ هاسلبرينغ، فيلهلم (2019). "دوافع ومعوقات تبني الخدمات المصغرة - دراسة استقصائية بين المهنيين في ألمانيا" . نمذجة المؤسسات وهياكل نظم المعلومات . 14 : 1:1–35. doi : 10.18417/ emisa.14.1
  21. 1 2 تايبي، دافيد؛ ليناردوزي، فالنتينا؛ باهل، كلاوس؛ جانيس، أندريا (2017). "الخدمات المصغرة في تطوير البرمجيات الرشيقة: دراسة قائمة على ورش العمل حول المشكلات والمزايا والعيوب" . وقائع ورش العمل العلمية لمؤتمر XP2017 . الصفحات 1-5 . doi : 10.1145/3120459.3120483 . ISBN  978-1-4503-5264-2. S2CID 28134110 . 
  22. ↑ ريتشاردسون، كريس. "نمط بنية الخدمات المصغرة" . microservices.io . تم ​​الاسترجاع في 19-03-2017 .
  23. ↑ تشين، ليان بينغ؛ علي بابار، محمد (2014). "نحو فهم قائم على الأدلة لظهور بنية البرمجيات من خلال إعادة البناء المستمر في تطوير البرمجيات الرشيقة". وقائع مؤتمر IEEE/IFIP الحادي عشر حول هندسة البرمجيات (WICSA 2014) . IEEE. doi : 10.1109/WICSA.2014.45 .
  24. ↑ بالالاي، أرمين؛ حيدرنوري، عباس؛ جمشيدي، بويان (مايو 2016). "بنية الخدمات المصغرة تُمكّن DevOps: الانتقال إلى بنية سحابية أصلية" (ملف PDF) . مجلة IEEE للبرمجيات . 33 (3): 42-52 . doi : 10.1109/ms.2016.64 . hdl : 10044/1/40557 . ISSN 0740-7459 . S2CID 18802650 .  
  25. ↑ ستينبيرج، جان (11 أغسطس 2014). "تجارب من الفشل مع الخدمات المصغرة" .
  26. 1 2 مارتن فاولر. "الخدمات المصغرة" . مؤرشف من الأصل في 14 فبراير 2018.
  27. ↑ كالاندرا، ماريانو (7 أبريل 2021). "لماذا لا يكفي اختبار الوحدة عندما يتعلق الأمر بالخدمات المصغرة" .
  28. ↑ لانزا، ميشيل؛ دوكاس، ستيفان (2002). "فهم تطور البرمجيات باستخدام مزيج من تصور البرمجيات ومقاييسها" (ملف PDF) . وقائع مؤتمر LMO 2002 (اللغات والنماذج الكائنية) : 135-149 . مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 27 فبراير 2021.
  29. ↑ ريتشاردسون، كريس (نوفمبر 2018). "الفصل 4. إدارة المعاملات باستخدام ساغا". أنماط الخدمات المصغرة . منشورات مانينغ. ISBN 978-1-61729454-9.
  30. ↑ ديفوكس (30 أغسطس 2017). "10 نصائح للفشل الذريع في تصميم الخدمات المصغرة بقلم ديفيد شميتز" . يوتيوب . مؤرشف من الأصل في 22 أبريل 2021.
  31. 1 2 3 لوي، جوفال (2019). كتابة البرمجيات، الطبعة الأولى . أديسون-ويسلي بروفيشنال. الصفحات 73-75 . ISBN  978-0136524038.
  32. ↑ باوتاسو، سيزار (2017). "الخدمات المصغرة في الممارسة العملية، الجزء 2: تكامل الخدمات واستدامتها". مجلة IEEE للبرمجيات . 34 (2): 97-104 . doi : 10.1109/MS.2017.56 . S2CID 30256045 . 
  33. ↑ باوتاسو، سيزار (2018). "التعافي المتسق من الكوارث للخدمات المصغرة: نظرية BAC". الحوسبة السحابية IEEE . 5 (1): 49-59 . doi : 10.1109/MCC.2018.011791714 . S2CID 4560021 . 
  34. ↑ "تطوير الخدمات المصغرة لمنصة PaaS باستخدام Spring و Cloud Foundry" .
  35. ↑ فاولر، مارتن . "المفاضلات في الخدمات المصغرة" .
  36. ↑ "أنظمة برمجيات BRASS التكيفية لموارد البناء". حكومة الولايات المتحدة. داربا. 7 أبريل 2015.مع ذلك، يتم الوصول إلى مكونات النظام والواجهات بين العملاء وتطبيقاتهم عبر عدد من الآليات غير المترابطة في كثير من الأحيان، بما في ذلك واجهات برمجة التطبيقات (APIs) الموثقة بشكل غير رسمي، وواجهات الوظائف الخارجية الخاصة، وتعريفات النماذج المعقدة وغير المفهومة جيدًا، أو تنسيقات البيانات المخصصة . وعادةً ما توفر هذه الآليات فهمًا جزئيًا وغير مكتمل لدلالات المكونات نفسها. في ظل هذا التعقيد، ليس من المستغرب أن تتضمن التطبيقات عادةً العديد من الافتراضات حول السلوك المتوقع للنظام البيئي الذي تتفاعل معه.
  37. ↑ وولف، إيبرهارد (15 أبريل 2018). الخدمات المصغرة - دليل عملي . منصة النشر المستقلة كريت سبيس. رقم ISBN 978-1717075901.
  38. ↑ سوارت، ستيفاني (14 ديسمبر 2016). "Eclipse MicroProfile" . projects.eclipse.org .
  39. ↑ "الملف التعريفي المصغر" . الملف التعريفي المصغر . تم الاسترجاع في 11 أبريل 2021 .

للمزيد من القراءة