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

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

في بنية الخدمات المتناهية الصغر، تمتلك كل خدمة متناهية الصغر مهمة بسيطة، وتتواصل مع العملاء أو مع الخدمات المتناهية الصغر الأخرى باستخدام آليات اتصال خفيفة الوزن مثل طلبات واجهة برمجة تطبيقات REST.

يوضح الشكل التالي بنية تطبيق يتكون من خدمات صغيرة متعددة.

وصف الشكل التوضيحي microservice_Archtecture.png

تمكنك Microservices من تصميم التطبيق كمجموعة من الخدمات المزدوجة للغاية. وتتبع الخدمات المتناهية الصغر نموذج المشاركة - لا شيء، وتعمل كعمليات عديمة الجنسية. ويسهل هذا النهج توسيع نطاق التطبيق وصيانته.

• طبقة API هي نقطة الإدخال لكل طلبات العميل إلى خدمة صغيرة. كما تتيح طبقة واجهة برمجة التطبيقات للخدمات المتناهية الصغر الاتصال فيما بينها عبر HTTP وgRPC وTCP/UDP.
• وتركز الطبقة المنطقية على مهمة أعمال واحدة، مما يقلل إلى أدنى حد من التبعيات على الخدمات الصغرى الأخرى. يمكن كتابة هذه الطبقة بلغة مختلفة لكل خدمة صغيرة.
• توفر طبقة مخزن البيانات آلية ثبات، مثل محرك تخزين قاعدة البيانات وملفات الأرشيف وما إلى ذلك. فكر في استخدام مخزن بيانات دائم منفصل لكل خدمة صغيرة. يوفر Oracle حاويات قاعدة بيانات ذات قواعد بيانات متعددة قابلة للتركيب تجعل من السهل على الخدمات المتناهية الصغر عزل البيانات للتأمين وHA والتوسع. بالإضافة إلى ذلك، يمكن لتطبيقات SaaS الاستفادة من تعدد العملاء بطريقة آمنة. كما أن قاعدة البيانات المتقاربة تجلب مجموعة متنوعة من البيانات تحت سقف واحد للحصول على رؤى أكثر ثراء من البيانات.

وعادة ما تعمل كل خدمة صغيرة في حاوية توفر بيئة وقت تشغيل خفيفة الوزن.

الفروق بين الخدمات المتناهية الصغر والهندسة المعمارية الأحادية

قبل البدء في تصميم التطبيقات باستخدام بنية الخدمات المتناهية الصغر، يجب أن تفهم كيف تختلف هذه البنية عن البنية الأحادية التقليدية.

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

يوضح الشكل التوضيحي التالي هياكل الخدمات الأحادية والجزئية.

وصف الشكل التوضيحي monolithic_vs_microservice.png

ويوجز الجدول التالي الفروق بين الخدمات المتناهية الصغر والهياكل الأحادية.

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

لمزيد من التفاصيل حول هذه الخصائص، انظر Microservices: تعريف لهذا المصطلح المعماري الجديد (Martin Fowler and James Lewis, 2014).

اعتبارات اعتماد بنية الخدمات المتناهية الصغر

عند تصميم تطبيق جديد، ضع في اعتبارك بنية الخدمات المتناهية الصغر للتطبيقات التي تتطلب مستويات عالية من قابلية التوسع والمرونة والموثوقية. يمكنك استخدام لغة وإطار عمل برمجيين مختلفين لتطوير كل مكون.

فكر في ترحيل تطبيق أحادي الجانب إلى الخدمات المتناهية الصغر إذا كان بإمكانك تقسيم وظيفة التطبيق إلى خدمات مركزة، ولكل منها مجال محدود. بالنسبة للتطبيقات الأحادية المعقدة التي لا يمكن ترحيلها إلى بنية الخدمات المتناهية الصغر، يجب مراعاة تطوير الوظيفة الجديدة فقط كخدمات متناهية الصغر.

يمكن أن يؤثر الترابط بين الخدمات على مقدار عدم توفر التطبيق أثناء إعادة توزيع الخدمة. حل أية مشكلات تبعية من هذا القبيل أثناء تصميم التطبيق.

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

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

كن مستعداً للتعقيد التشغيلي الذي ينطوي عليه هيكل الخدمات المتناهية الصغر. وفقًا لما ذكره مارتن فولر، يجب استيفاء المتطلبات المسبقة التالية قبل نقل تطبيق أحادي الجانب إلى بنية الخدمات الصغيرة:

• تزويد سريع: القدرة على تزويد الخوادم بسرعة
• الرصد الأساسي: القدرة على اكتشاف مشكلات الخدمات وقضايا الأعمال. تتضمن مشكلات الخدمة توفر الخدمة والأخطاء الوظيفية ومشاكل الأداء
• النشر السريع للتطبيقات: القدرة على نشر أي خدمة بسرعة في بيئتي الاختبار والإنتاج

تأكد من أن فوائد بنية الخدمات المتناهية الصغر تفوق التكلفة.

لمزيد من المعلومات، انظر المتطلبات الأساسية للخدمات المتناهية الصغر (مارتن فولر، 2014).

حول آلية الاتصال في بنية الخدمات المتناهية الصغر

في بنية الخدمات المتناهية الصغر، تعمل الخدمات على خوادم متعددة. ويحدث الاتصال بين هذه الخدمات من خلال بروتوكولات مثل HTTP وAMQP وTCP. بروتوكول HTTP /REST والمراسلة غير المتزامنة هما البروتوكولان الأكثر استخدامًا.

تستخدم واجهة برمجة تطبيقات REST لخدمات الويب بروتوكول HTTP بشكل عام. باستخدام أساليب HTTP (مثل GET وPOST وPUT وDELETE) يمكن للعملاء الوصول إلى موارد التطبيق ومعالجتها باستخدام محدد مواقع موارد موحد (URL).

يرسل العملاء طلبًا إلى خدمة من خلال واجهة برمجة تطبيقات REST التي تمثل نقطة إدخال لوظيفة التطبيق. يمكن للعملاء الاتصال بالخدمات المتناهية الصغر إما مباشرةً أو من خلال جيت واي API.

يحدد نمط جيت واي API نقطة إدخال واحدة لكل الطلبات إلى الخدمات. عند وصول طلب عميل، تقوم جيت واي API بتوجيه الطلب إلى الخدمة المناسبة.

متغير نمط جيت واي API هو الخلفية لنمط الواجهة الأمامية، الذي يحدد جيت واي API منفصلة لكل نوع من العملاء (على سبيل المثال جيت واي واحدة للعملاء المتنقلين وجيت واي آخر لتطبيقات الويب).

ومن الممارسات الموصى بها تقليل الاتصال بين الدوائر إلى أدنى حد. وعندما يكون الاتصال ضروريا، يفضل الاتصال غير المتزامن. يمكن أن تستمر الخدمة التي ترسل الطلب في العمل دون انتظار استجابة.

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

حول الخدمات والأدوار المطلوبة

يتطلب هذا الحل الخدمات التالية:

• Oracle Cloud Infrastructure Database
• Oracle Cloud Infrastructure Container Engine for Kubernetes

حدد السياسات التي تسمح ، كحد أدنى ، لمجموعة المستخدمين بإدارة أنواع موارد الطبعات والأسرة والحجم والشبكات الافتراضية - الأسرة والمجموعات - الأسرة والكائنات - الأسرة وقاعدة البيانات - الأسرة في القسم الخاص بك. بالإضافة إلى ذلك، منح حق الوصول إلى نوع المورد repos في الاستئجار.

يرجى الاطلاع على كيفية الحصول على خدمات Oracle Cloud لـ Oracle Solutions للحصول على الخدمات السحابية التي تحتاجها.