العمارة المتجانسة

• إذا قمنا بتطوير جميع الوظائف في مشروع واحد، فسيتم تسميته كتطبيق قائم على بنية Monolith.

• سنقوم بتجميع تطبيقنا كجرة/حرب للنشر في الخادم.

• نظرًا لأن التطبيق المترابط يحتوي على جميع الوظائف، فإنه سيصبح جرة/حربًا سمينة.

المزايا
1) سهولة التطوير والإدارة.
2) كل شيء متوفر في مكان واحد.
3) التكوين مطلوب مرة واحدة فقط.

المزايا
1) صعوبة الصيانة
2) نقطة فشل واحدة
3) إذا قمنا بإجراء أي تغييرات، فسيتم إعادة نشر المشروع بالكامل واختباره.
4) قد لا يكون المطور على دراية بالوحدات النمطية بأكملها، لذا من الصعب البدء في حل المشكلة.
5) إذا تم تحميل بعض الوحدات بشكل كبير، فإننا نحتاج إلى إنشاء مثيلات متعددة للتطبيق الكامل بحيث يستغرق ذلك مساحة كبيرة لأن كل وحدة مقترنة بإحكام مع بعضها البعض.

للتغلب على مشاكل Monolithic، ظهرت بنية الخدمات المصغرة في السوق

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

• الخدمات المصغرة ليست لغة برمجة أو إطار عمل أو واجهة برمجة تطبيقات. الخدمات المصغرة هي نمط التصميم المعماري.

• الخدمات المصغرة التي تقترح تطوير وظائف التطبيق من خلال الاقتران غير المحكم.

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

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

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

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

المزايا

• استقلال التكنولوجيا (يمكننا تطوير واجهات برمجة التطبيقات الخلفية باستخدام تقنيات متعددة مثل python وGo وما إلى ذلك)

• استقلال قاعدة البيانات.

• كل خدمة مستقلة عن بعضها البعض (اقتران فضفاض) حتى نتمكن من نشر كل خدمة بشكل مستقل.

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

• لا يتطلب عمل التطوير على خدمة واحدة معرفة التطبيق بأكمله.

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

• قواعد التعليمات البرمجية الأصغر والفصل بين الاهتمامات يجعل الصيانة وتصحيح الأخطاء أكثر قابلية للإدارة.

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

• يمكن اختبار كل خدمة بشكل مختلف.

العيوب

• إذا أردنا إجراء التغييرات في تكوين خدمة واحد، فإننا نحتاج إلى إجراء التغييرات على كل تكوين خدمة على سبيل المثال، هناك خاصية مشتركة موجودة في كل ملف application.properties في جميع مشاريعي.

company.name=tier3Hub

لذلك إذا أردنا تغيير اسم الشركة من جميع الخدمات التي نحتاجها لتغيير الاسم.

• يمكن أن يكون اختبار التطبيق القائم على الخدمات الصغيرة أكثر تعقيدًا بسبب الترابط والتفاعلات بين الخدمات.

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

لماذا جافا للخدمات الصغيرة

توفر Java إطار العمل المسمى Spring-Boot لتطوير Rest API's ويوفر Spring-Boot الكثير من الميزات مثل التكوين التلقائي والخادم المضمن، إذا كنا نقوم بتطوير الخدمة، فهناك حاجة لنشر خدمة sec على الخادم ويوفر Spring-Boot خادم Tomcat، بحيث تعمل كل خدمة على منافذ Tomcat المختلفة. على سبيل المثال، يتم تشغيل خدمة الموظفين على المنفذ 8080، ويتم تشغيل خدمة الدورة التدريبية على المنفذ 8081 ولكل خدمة خادم خاص بها.

بمساعدة Spring-Boot يوفر ميزات للتطوير السريع، وتكوين أقل، وتطبيق جاهز للإنتاج ومشروع الحالة

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

تركز Spring Cloud على توفير تجربة جيدة خارج الصندوق لحالات الاستخدام النموذجية وآلية التوسعة لتغطية الحالات الأخرى

• التكوين الموزع/الإصدار
• تسجيل الخدمة واكتشافها
• التوجيه
• المكالمات من خدمة إلى خدمة
• موازنة التحميل
• قواطع الدائرة
• الرسائل الموزعة
• الخدمات الصغيرة (المهام) قصيرة العمر
• اختبار العقود التي يحركها المستهلك والمنتج.

هندسة الخدمات المصغرة

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

1) سجل الخدمة (خادم يوريكا)

2) الخدمات (REST APIs)

3) الاتصالات بين الخدمات (FeginClient)

4) بوابة واجهة برمجة التطبيقات

5) خادم المشرف

6) زيبكين

خاتمة

لقد غيرت الخدمات الصغيرة في Java الطريقة التي نتعامل بها مع تطوير البرمجيات، مما يوفر مستوى جديدًا من المرونة وقابلية التوسع والمرونة. إن نظام Java البيئي الغني، جنبًا إلى جنب مع أطر عمل مثل Spring Boot وMicronaut، يجعلها خيارًا ممتازًا لبناء خدمات صغيرة يمكنها تلبية متطلبات التطبيقات الحديثة.

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

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

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