الخدمات المصغرة، أو بنية الخدمات المصغرة، هي نهج بنائي قائم السحابة الأصلية حيث يتكون التطبيق الواحد من العديد من العناصر أو الخدمات المصغرة المرتبطة بشكل ضعيف والتي يمكن نشرها بشكل مستقل.
تتميز الخدمات المصغرة عادةً بما يلي:
بينما ركَّزت الكثير من النقاشات حول الخدمات المصغرة على التعريفات البنائية وخصائصها، يمكن فهم قيمتها بشكل أكثر وضوحًا من خلال الفوائد التجارية والتنظيمية البسيطة نسبيًا:
يمكن أيضًا فهم الخدمات المصغرة بالمقارنة مع نوعين من البنى التطبيقية السابقة: البنية الأحادية والبنية الموجَّهة نحو الخدمة (SOA).
الفرق بين الخدمات المصغرة والبنية الأحادية هو أن الخدمات المصغرة تكوِّن تطبيقًا واحدًا من العديد من الخدمات الصغيرة المرتبطة بشكل ضعيف، على عكس النهج الأحادي الذي يعتمد على تطبيق كبير ومترابط بإحكام.
قد تكون الفروقات بين الخدمات المصغرة وبنية SOA أقل وضوحًا بعض الشيء. بينما يمكن رسم فروقات تقنية بين الخدمات المصغرة وSOA، خاصةً فيما يتعلق بدور ناقل الخدمات المؤسسية (ESP)، من الأسهل النظر إلى الفرق باعتباره مسألة نطاق. كانت بنية SOA جهدًا على مستوى المؤسسة لتوحيد طريقة تواصل جميع خدمات الويب داخل المؤسسة وتكاملها مع بعضها، في حين أن بنية الخدمات المصغرة مخصصة لتطبيق معين.
النشرة الإخبارية الخاصة بالمجال
ابقَ على اطلاع دائم على أبرز الاتجاهات في مجالات الذكاء الاصطناعي، والأتمتة، والبيانات، وغيرها الكثير من خلال رسالة Think الإخبارية. راجع بيان الخصوصية لشركة IBM.
سيصلك محتوى الاشتراك باللغة الإنجليزية. ستجد رابط إلغاء الاشتراك في كل رسالة إخبارية. يمكنك إدارة اشتراكاتك أو إلغاء اشتراكك من هنا. لمزيد من المعلومات، راجع بيان خصوصية IBM.
من المرجح أن تحظى الخدمات المصغرة بشعبية لدى المديرين التنفيذيين وقادة المشاريع بقدر ما هي لدى المطورين. هذه واحدة من الخصائص الأكثر تميزًا للخدمات المصغرة، إذ عادةً ما يقتصر الحماس البنائي على فِرق تطوير البرمجيات. السبب في ذلك هو أن الخدمات المصغرة تعكس بشكل أفضل الطريقة التي يرغب بها العديد من قادة الأعمال في تنظيم فِرقهم وإدارة عمليات التطوير.
بعبارة أخرى، تُعَد الخدمات المصغرة نموذجًا بنائيًا يسهِّل بشكل أفضل تحقيق نموذج تشغيلي مرغوب فيه. في استطلاع IBM لعام 2021 الذي شمل أكثر من 1,200 مطوِّر ومدير تنفيذي في تكنولوجيا المعلومات، وافق 87% من مستخدمي الخدمات المصغرة على أن اعتمادها يستحق التكلفة والجهد.
فيما يلي بعض الفوائد التي تقدِّمها الخدمات المصغرة:
ربما تكون أهم خاصية للخدمات المصغرة هي أنه نظرًا لصغر حجم الخدمات وإمكانية نشرها بشكل مستقل، لم يَعُد من الضروري القيام بإجراءات معقدة لتغيير سطر برمجي أو إضافة ميزة جديدة في التطبيق.
تَعِد الخدمات المصغرة المؤسسات بحل لمشاعر الإحباط الناتجة عن استغراق تغييرات بسيطة لوقت طويل جدًا. ليس من الضروري أن تكون حائزًا على دكتوراة في علوم الكمبيوتر لتدرك قيمة نهج يسهِّل تحقيق السرعة والمرونة بشكل أفضل.
لكن السرعة ليست القيمة الوحيدة لتصميم الخدمات بهذه الطريقة. أحد النماذج التنظيمية الشائعة والناشئة هو جمع فِرق متعددة التخصصات حول مشكلة أعمال أو خدمة أو منتج. يتوافق نموذج الخدمات المصغرة بشكل مثالي مع هذا التوجه. يُتيح هذا النموذج للمؤسسة تكوين فِرق صغيرة متعددة التخصصات حول خدمة واحدة أو مجموعة من الخدمات، والعمل بها بأسلوب مرن وسريع الاستجابة.
يساهم الترابط الضعيف في الخدمات المصغرة أيضًا في توفير مستوى من عزل الأخطاء وزيادة مرونة التطبيقات. كما أن صغر حجم الخدمات، مع حدودها الواضحة وأنماط تواصلها، يسهِّل على أعضاء الفريق الجُدُد فهم قاعدة الكود والمساهمة فيها بسرعة - وهو فائدة واضحة من حيث السرعة ومعنويات الموظفين.
في أنماط البنية متعددة الطبقات التقليدية، عادةً ما يشترك التطبيق في بنية أساسية واحدة، مع قاعدة بيانات علائقية كبيرة تدعم التطبيق بأكمله. لهذا النهج عدة عيوب واضحة، أبرزها أن كل عنصر من عناصر التطبيق يجب أن يشارك في نفس البنية الأساسية ونموذج البيانات وقاعدة البيانات، حتى لو كانت هناك أداة أفضل لكل عنصر على حدة. يؤدي ذلك إلى بنية سيئة، ويسبِّب إحباطًا للمطورين الذين يدركون دائمًا أن هناك طريقة أفضل وأكثر كفاءة لبناء هذه العناصر.
على النقيض من ذلك، في نموذج الخدمات المصغرة، يتم نشر العناصر بشكل مستقل وتتواصل عبر مزيج من واجهات REST وبث الأحداث ووسطاء الرسائل، ما يُتيح تحسين بنية كل خدمة بشكل يناسبها. تتغير التكنولوجيا باستمرار، والتطبيق المكوَّن من عدة خدمات صغيرة يكون أسهل وأقل تكلفة في التطور لمواكبة التكنولوجيا الأكثر ملاءمة عند توفُّرها.
مع الخدمات المصغرة، يمكن نشر كل خدمة بشكل مستقل - كما يمكن توسيع كل خدمة بشكل مستقل أيضًا. الفائدة الناتجة واضحة: عند تنفيذ الخدمة المصغرة بشكل صحيح، تحتاج إلى بنية تحتية أقل من التطبيقات الأحادية، لأنها تُتيح توسيع العناصر التي تحتاج فقط إلى التوسع، بدلًا من توسيع التطبيق بأكمله كما في التطبيقات الأحادية.
تأتي الفوائد الكبيرة للخدمات المصغرة مصحوبة بتحديات كبيرة أيضًا. الانتقال من البنية الأحادية إلى الخدمات المصغرة يعني زيادة كبيرة في تعقيد الإدارة - المزيد من الخدمات، التي تنشئها فِرق أكثر، ويتم نشرها في أماكن أكثر. قد تتسبب المشكلات في خدمة واحدة في ظهور مشكلات في خدمات أخرى، أو قد تنتج عنها مشكلات. تكون بيانات التسجيل (المستخدمة للمراقبة وحل المشكلات) أكثر حجمًا، وقد تكون غير متسقة بين الخدمات المختلفة. قد تتسبب الإصدارات الجديدة في مشكلات تتعلق بالتوافق مع الإصدارات السابقة. تشمل التطبيقات المزيد من الاتصالات الشبكية، ما يزيد من احتمالات حدوث تأخير ومشكلات في الاتصال. يمكن لمنهجية عمليات التطوير معالجة العديد من هذه المشكلات، لكن تبنّي نهج عمليات التطوير له تحدياته الخاصة أيضًا.
ومع ذلك، لا تمنع هذه التحديات غير المتبنّين لها من تبنّي الخدمات المصغرة، ولا تمنع المتبنِّين من تعزيز التزامهم بها. تكشف بيانات استطلاع IBM المذكور أعلاه أن 56% من المستخدمين غير الحاليين من المحتمل أو المرجح جدًا أن يتبنّوا الخدمات المصغرة خلال العامين القادمين. ونتيجةً لذلك، من المرجح أن يزيد 78% من مستخدمي الخدمات المصغرة الحاليين الوقت والمال والجهد الذي استثمروه في فيها.
غالبًا ما يُوصف نموذج الخدمات المصغرة بأنه مُهيأ لمنهجية عمليات التطوير والتكامل المستمر (CI) أو التسليم المستمر (CD)، وفي سياق الخدمات الصغيرة التي يمكن نشرها بشكل متكرر، يصبح السبب واضحًا.
ولكن هناك طريقة أخرى للنظر إلى العلاقة بين الخدمة المصغرة وعمليات التطوير وهي أن بنية الخدمة المصغرة تتطلب عمليات التطوير لكي تنجح. على الرغم من أن التطبيقات الأحادية لها مجموعة من العيوب التي تمت مناقشتها سابقًا في هذه المقالة، فإنها تتمتع بميزة عدم كونها نظامًا موزعًا معقدًا مع أجزاء متحركة متعددة وبنى تقنية مستقلة. بالمقابل، نظرًا للزيادة الكبيرة في التعقيد وعدد الأجزاء والتبعيات المصاحبة للخدمات المصغرة، سيكون من غير الحكمة التعامل معها دون استثمارات كبيرة في النشر والمراقبة وأتمتة دورة الحياة.
تقدِّم Rosalind Radcliffe شرحًا أعمق حول عمليات التطوير في الفيديو:
بينما يمكن استخدام أي أداة أو لغة حديثة تقريبًا في بنية الخدمات المصغرة، هناك مجموعة محدودة من الأدوات الأساسية التي أصبحت ضرورية وشبه تعريفية للخدمات المصغرة:
أحد العناصر الأساسية للخدمة المصغرة هو أنها صغيرة. لا يوجد مقدار محدد من الكود يحدِّد ما إذا كان شيء ما يُعَد خدمة مصغرة أم لا، لكن كلمة "مصغرة" موجودة بالفعل في الاسم.
عندما بدأت Docker عصر الحاويات الحديث في عام 2013، قدَّمت أيضًا نموذج الحوسبة الذي أصبح مرتبطًا بشكل وثيق بالخدمات المصغرة. بما أن كل حاوية لا تحتاج إلى نظام تشغيل خاص بها، فهي أصغر وأخف من الأجهزة الافتراضية التقليدية، ويمكن تشغيلها وإيقافها بسرعة أكبر، ما يجعلها مناسبة تمامًا للخدمات الصغيرة والخفيفة الموجودة في بنية الخدمات المصغرة.
ومع تزايد أعداد الخدمات والحاويات، أصبح تنسيق وإدارة المجموعات الكبيرة من الحاويات أحد التحديات الأساسية بسرعة. لقد أصبح Kubernetes، وهو منصة مفتوحة المصدر لتنسيق الحاويات، واحدًا من أكثر حلول التنسيق انتشارًا لأنه يؤدي هذا الدور بكفاءة عالية.
غالبًا ما تتواصل الخدمات المصغرة عبر واجهات برمجة التطبيقات، خاصةً عند تهيئة حالتها لأول مرة. صحيح أن العملاء والخدمات يمكنهم التواصل مباشرة، إلا إن بوابات واجهة برمجة التطبيقات غالبًا ما تكون طبقة وسيطة مفيدة، خاصةً مع ازدياد عدد الخدمات داخل التطبيق بمرور الوقت. تعمل بوابة واجهة برمجة التطبيقات (بوابات API) كوكيل عكسي للعملاء من خلال توجيه الطلبات، وتوزيعها عبر خدمات متعددة، وتوفير طبقات إضافية من الحماية والمصادقة.
توجد عدة تقنيات يمكن استخدامها لتنفيذ بوابات API. من بين هذه التقنيات منصات إدارة واجهات برمجة التطبيقات، ولكن إذا كان يتم تنفيذ بنية الخدمات المصغرة باستخدام الحاويات وKubernetes، فعادةً ما يتم تنفيذ البوابة عبر Ingress أو، مؤخرًا، عبر Istio.
وعلى الرغم من أن أفضل الممارسات تقتضي تصميم خدمات بلا حالة، فإن الحالة تظل موجودة ويجب على الخدمات الإحاطة بها. وعلى الرغم من أن استدعاء واجهة برمجة التطبيقات غالبًا ما يكون وسيلة فعَّالة لتأسيس الحالة في البداية لخدمة معينة، فإنه ليس وسيلة فعَّالة للبقاء محدَّثًا. لا يُعَد الاعتماد على أسلوب الاستطلاع المستمر بسؤال "هل وصلنا بعد؟" للحفاظ على تحديث الخدمات أمرًا عمليًا.
بدلًا من ذلك، من الضروري دمج استدعاءات واجهات برمجة التطبيقات التي تؤسِّس الحالة مع الرسائل أو بث الأحداث، بحيث تتمكن الخدمات من نشر التغييرات في حالتها. بهذه الطريقة، يمكن للأطراف المهتمة الأخرى الاستماع لتلك التغييرات والتكيف معها حسب الحاجة. من المرجح أن يكون هذا الدور مناسبًا أكثر لوسيط رسائل عام، لكن هناك حالات قد تكون فيها منصة بث الأحداث، مثل Apache Kafka، خيارًا مناسبًا. وبالدمج بين الخدمات المصغرة والبنية القائمة على الأحداث، يمكن للمطورين بناء أنظمة موزعة وذات قابلية توسُّع عالية ومقاومة للأخطاء وقابلة للتوسيع تستطيع استهلاك ومعالجة كميات كبيرة من الأحداث أو المعلومات في الوقت الفعلي.
تأخذ البنى الخالية من الخوادم بعض الأنماط الأساسية للحوسبة السحابية والخدمات المصغرة إلى أقصى حدودها المنطقية. في حالة البنى الخالية من الخوادم، لا تُعَد وحدة التنفيذ مجرد خدمة صغيرة، بل هي وظيفة، والتي غالبًا ما تكون مجرد بضعة أسطر من الكود. الخط الفاصل بين وظيفة خالية من الخوادم وخدمة مصغرة ليس واضحًا تمامًا، لكن عادةً ما يُفهم أن الوظائف أصغر حجمًا من الخدمة المصغرة.
النقطة المشتركة بين البنى الخالية من الخوادم ومنصات الوظائف كخدمة (FaaS) والخدمات المصغرة هي اهتمامها بإنشاء وحدات نشر أصغر وقابلة للتوسع بدقة حسب الطلب.
لا تقتصر الخدمات المصغرة بالضرورة على الحوسبة السحابية فقط. ومع ذلك، هناك بعض الأسباب المهمة التي تجعلهما غالبًا ما يُستخدمان معًا - أسباب تتجاوز كون الخدمات المصغرة أسلوبًا بنائيًا شائعًا للتطبيقات الجديدة، وأن الحوسبة السحابية وجهة استضافة شائعة لهذه التطبيقات.
من أبرز فوائد بنية الخدمات المصغرة هي الفوائد المتعلقة بالاستخدام والتكلفة الناتجة عن نشر وتوسيع كل عنصر من العناصر بشكل فردي. بينما ستظل هذه الفوائد موجودة إلى حد ما عند استخدام البنية التحتية المحلية، فإن الجمع بين العناصر الصغيرة القابلة للتوسع بشكل مستقل والبنية التحتية حسب الطلب والدفع مقابل الاستخدام هو المكان الذي يمكن تحقيق فيه تحسينات فعلية في التكلفة.
ثانيًا، وربما الأهم، من الفوائد الرئيسية الأخرى للخدمات المصغرة هو أن كل عنصر فردي يمكنه اعتماد المجموعة الأنسب لمهامه المحددة. قد يؤدي انتشار المجموعات إلى تعقيد كبير وأعباء إضافية عند إدارته داخليًا، لكن استخدام المجموعات الداعمة كخدمات سحابية يمكن أن يقلل بشكل كبير من تحديات الإدارة. بمعنى آخر، رغم أن بناء بنية تحتية للخدمات المصغرة بنفسك ليس مستحيلًا، فإنه غير مستحسن، خاصًة عند البدء لأول مرة.
في بنية الخدمات المصغرة، هناك العديد من أنماط التصميم والتواصل والتكامل الشائعة والمفيدة، التي تساعد على معالجة بعض التحديات والفرص الأكثر شيوعًا، بما في ذلك:
يعمل هذا النمط على إدراج طبقة بين تجربة المستخدم والموارد التي تعتمد عليها هذه التجربة. على سبيل المثال، التطبيق المستخدم على سطح المكتب سيواجه حدودًا مختلفة للشاشة والعرض والأداء مقارنةً بالجهاز المحمول. يسمح نمط BFF للمطورين بإنشاء ودعم نوع واحد من الخلفية لكل واجهة مستخدم باستخدام أفضل الخيارات لتلك الواجهة، بدلًا من محاولة دعم خلفية عامة تعمل مع أي واجهة ولكن قد تؤثِّر سلبًا في أداء الواجهة الأمامية.
الكيان هو كائن يتميز بهويته. على سبيل المثال، على موقع التجارة الإلكترونية، قد يتم تمييز كائن المنتج حسب اسم المنتج ونوعه وسعره. التجميع عبارة عن مجموعة من الكيانات ذات الصلة التي يجب التعامل معها كوحدة واحدة. على سبيل المثال، بالنسبة لموقع التجارة الإلكترونية، فإن الطلب سيكون مجموعة (تجميعة) من المنتجات (الكيانات) التي يطلبها المشتري. يتم استخدام هذه الأنماط لتصنيف البيانات بطرق مفيدة.
تساعد هذه التطبيقات والخدمات في العثور على بعضها. في بنية الخدمات المصغرة، تتغير مثيلات الخدمة ديناميكيًا بسبب التوسع والترقيات وفشل الخدمة وحتى إنهاء الخدمة. وتوفِّر هذه الأنماط آليات اكتشاف للتعامل مع هذا الانتقال. يمكن لموازنة التحميل استخدام أنماط اكتشاف الخدمات من خلال الاعتماد على فحوصات الصحة وفشل الخدمات كمحفِّزات لإعادة توزيع الحركة.
فكِّر في أنماط المحوِّلات كما تفكر في محوِّلات المقابس التي تستخدمها عند السفر إلى دولة أخرى. الغرض من أنماط المحوِّلات هو المساعدة على ترجمة العلاقات بين الفئات أو الكائنات التي لا تتوافق مع بعضها بشكل طبيعي. قد يحتاج التطبيق الذي يعتمد على واجهات برمجة تطبيقات خارجية إلى استخدام نمط المحوِّل لضمان تواصل التطبيق مع هذه الواجهات بشكل صحيح.
تساعد هذه الأنماط على إدارة إعادة هيكلة تطبيق أحادي إلى تطبيقات خدمات مصغرة. يشير الاسم الملون إلى الطريقة التي تتسلق بها الكرمة (الخدمات المصغرة) تدريجيًا وتخنق الشجرة (التطبيق الأحادي).
رغم وجود العديد من الأنماط التي تساعد على تطبيق الخدمات المصغرة بشكل جيد، هناك عدد مماثل من الأنماط التي يمكن أن تضع أي فريق تطوير في المشكلات بسرعة. بعض هذه الأنماط -المُعاد صياغتها على أنها "ما لا يجب فعله في الخدمات المصغرة"- تتمثل فيما يلي:
بعبارة أكثر دقة، لا تبدأ بالخدمات المصغرة. الخدمات المصغرة هي طريقة لإدارة التعقيد عندما تصبح التطبيقات كبيرة جدًا وغير عملية بحيث لا يمكن تحديثها وصيانتها بسهولة. لا يُستحسن التفكير في تحويل التطبيق إلى خدمات أصغر إلا عندما تشعر بوضوح بوجود المشكلات والتعقيدات التي يسببها التطبيق الأحادي. وما لم تشعر بصعوبة وتعقيد التطبيق، فلا يمكن اعتبار أن التطبيق الأحادي يحتاج إلى إعادة التصميم.
بناء الخدمات المصغرة يعني إنشاء أنظمة موزعة، وهذه الأنظمة صعبة - وخاصةً إذا اتخذت قرارات تجعلها أكثر تعقيدًا. ومحاولة تطبيق الخدمات المصغرة دون أتمتة مناسبة للنشر والمراقبة، أو دون خدمات سحابة مُدارة لدعم بنيتك التحتية الموزعة والمتنوعة، يعرِّضك للكثير من المشكلات غير الضرورية. تجنَّب عناء ذلك لتتمكن من التركيز على إدارة الحالة.
إذا بالغت في صِغر حجم الخدمات المصغرة، فقد ينتهي بك المطاف إلى أعباء وتعقيدات تفوق المكاسب الإجمالية لبنية الخدمات المصغرة. من الأفضل الاعتماد على خدمات أكبر في البداية، ثم تفكيكها فقط عندما تبدأ بتطوير خصائص تعمل الخدمات المصغرة على حلها - مثل صعوبة وبطء نشر التغييرات، وتعقيد نموذج البيانات المشترك، أو اختلاف متطلبات الحمل/التوسع بين أجزاء الخدمة.
غالبًا ما يتم الخلط بين الخدمات المصغرة وبنية SOA، نظرًا لأنه في أبسط مستوياتهما، يهتم كلاهما ببناء عناصر قابلة لإعادة الاستخدام يمكن استهلاكها من قِبل تطبيقات أخرى. يتمثَّل الفرق بين الخدمات المصغرة وSOA هو أن مشروعات الخدمات المصغرة عادةً ما تتضمن إعادة هيكلة التطبيق لجعله أسهل في الإدارة، بينما تهتم بنية SOA بتغيير طريقة عمل خدمات تكنولوجيا المعلومات على مستوى المؤسسة بالكامل. من المرجح أن ينهار مشروع الخدمات المصغرة الذي يتحول إلى مشروع SOA بسبب تعقيده المتزايد.
كانت Netflix من الرواد الأوائل في بنية الخدمات المصغرة عند بناء وإدارة تطبيق يمثِّل ثلث حركة الإنترنت - وهو موقف استثنائي تطلَّب منهم تطوير الكثير من الأكواد والخدمات المخصصة التي لا يحتاجها التطبيق العادي. من الأفضل أن تبدأ بوتيرة يمكنك التحكم بها وتتجنَّب التعقيد وتستفيد بأقصى قدر من الأدوات الجاهزة.
إذا كنت مستعدًا لمعرفة المزيد حول كيفية استخدام الخدمات المصغرة، أو إذا كنت بحاجة إلى تطوير مهاراتك في الخدمات المصغرة، فجرِّب أحد هذه البرامج التعليمية:
خدمة مُدارة بالكامل ومستأجر واحد لتطوير تطبيقات Java وتسليمها.
استخدم أدوات وبرمجيات عمليات التطوير لإنشاء تطبيقات السحابة الأصلية ونشرها وإدارتها عبر أجهزة وبيئات متعددة.
إن تطوير تطبيقات السحابة يعني البناء مرة واحدة، والتكرار بسرعة، والنشر في أي مكان.