بنية الخدمات المصغرة: إيجابيات وسلبيات

الخدمات الصغيرة هي وسيلة لتقسيم تطبيق كبير إلى وحدات مترابطة بشكل غير محكم تتواصل مع بعضها البعض من خلال واجهة برمجة تطبيقات بسيطة. في الآونة الأخيرة، الأشخاص الأغبياء فقط هم الذين لم يتحدثوا عن الخدمات الصغيرة. لقد أصبح هذا أكثر وأكثر شعبية. يبدو النمط المعماري المعياري مناسبًا بشكل خاص للبيئات السحابية ويتزايد شعبيته. قبل أن ندخل في التفاصيل، دعونا نلقي نظرة شاملة على كل شيء . لذلك: الخدمات المصغرة هي وسيلة لتقسيم مشروع كبير إلى وحدات صغيرة ومستقلة ومترابطة بشكل غير محكم. الوحدات المستقلة مسؤولة عن مهام محددة ومنفصلة بوضوح وتتواصل مع بعضها البعض من خلال واجهة برمجة تطبيقات بسيطة ويمكن الوصول إليها. بمعنى آخر، الخدمات المصغرة هي ببساطة نمط معماري مختلف لتصميم تطبيقات الويب المعقدة في الغالب. ولكن ما هو السيء جدًا في الحلول المعمارية الحالية مثل SOA (الهندسة الموجهة نحو الخدمة)؟ يبدو أن معظم حلول المؤسسات الحديثة المكتوبة باستخدام SOA تعمل بشكل جيد. قد يكون هذا وقتًا رائعًا للحديث عن بعض التحديات التي تواجهها الصناعة هذه الأيام... فلنبدأ بمثال بسيط. لنفترض أنني بحاجة إلى تشغيل تطبيق كلاسيكي مكتوب بلغة Java. أولاً سأقوم بتطوير واجهة المستخدم، ثم طبقة منطق الأعمال، مع العديد من المكونات التي ستتفاعل مع واجهة المستخدم، وأخيرًا طبقة قاعدة البيانات، والتي ستكون في متناول قاعدة البيانات المستمرة. الآن وفقًا لحقيقة أنني أريد تشغيل التطبيق، سأقوم بإنشاء WAR/EAR/JAR وتثبيته على خادم (مثل JBoss أو Tomcat أو WebLogic). وبما أن هذا يتم في مكان واحد، أحصل على تطبيق متجانس، مما يعني أن جميع المكونات موجودة في مكان واحد... المثال في الصورة: على الأرجح، أنت بالفعل على دراية بهذا النهج واستخدمته، ولكن الفكرة تكمن في استخدام هذا المثال لإظهار التحديات التي سيتعين على المطورين مواجهتها باستخدام هذا الحل المعماري. تطبيق متآلف: التحديات التحديات

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

وفي الوقت نفسه، نحن على استعداد للنظر في وفهم معنى الخدمات الصغيرة، أي كيف يمكن استخدامها لاستعادة المرونة التي فقدتها مع أسلوب SOA. خدمات God Microservices للإنقاذ إحدى أهم الخصائص في أي حل معماري هي قابلية التوسع. بينما كنت أتعلم الخدمات المصغرة لأول مرة، رأيت أن كل شيء كان مشابهًا جدًا للاقتباسات من كتاب "فن قابلية التوسع". هذه بداية رائعة ومكان للمناقشة. يحدد هذا الكتاب ما يسمى بنموذج "مكعب قابلية التوسع"، والذي يصف نظام قابلية التوسع ثلاثي الأبعاد: كما ترون، يصف المحور X "القياس الأفقي" (والذي رأيناه متاحًا أيضًا للبنيات المتجانسة)، ويمثل المحور Y القياس بمعنى فصل مكونات الخدمة المختلفة . يتم فهم فكرة المحور Z عندما يتم تقسيم البيانات ويقوم التطبيق بإرسال الطلبات إلى المكان الذي توجد فيه البيانات بالضبط. أي أنهم ليسوا جميعا في مكان واحد. فكرة المحور Y هي التي سنركز عليها بمزيد من التفصيل. ويمثل هذا المحور التحلل الوظيفي . في هذه الاستراتيجية، يمكن اعتبار الوظائف المختلفة بمثابة خدمات مستقلة. لذلك، من خلال تثبيت التطبيق بأكمله فقط عند الانتهاء من كل شيء، يمكن للمطورين تحميل الخدمات الفردية بشكل مستقل عن بعضهم البعض وعدم انتظار الآخرين لإنهاء العمل على وحداتهم. لن يؤدي هذا إلى تحسين وقت التطوير فحسب، بل سيوفر أيضًا المرونة للتغيير والتجديد دون الحاجة إلى القلق بشأن بقية مكونات التطبيق. دعونا نقارن هذا المخطط بالمخطط المتجانس السابق: الخدمات الصغيرة: الفوائد يبدو أن فوائد الخدمات الصغيرة كافية لإقناع مطوري المؤسسات مثل Amazon وNetflix وEbay بالبدء في استخدام هذا النهج. على عكس التطبيقات المعمارية المتجانسة، فإن الخدمات الصغيرة:

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

الخدمات الصغيرة: ميزات التثبيت والمحاكاة الافتراضية الآن نحن نفهم ما هي الخدمات الصغيرة. والميزة الكبرى هي أنه مثبت بأكثر من أرشيف WAR/EAR/JAR. ولكن كيف يتم تثبيته؟ أفضل طريقة لتركيب الخدمات الصغيرة داخل الحاويات. الحاوية عبارة عن نظام تشغيل ظاهري تم تكوينه بالكامل مع تكوين البيئة اللازمة، مما يساعد على عزل الوصول إلى موارد نظام الأجهزة الذي تم تثبيت الحاوية عليه. الحل الأكثر شهرة في السوق هو بالطبع Docker . يمكن أيضًا للأجهزة الافتراضية من IaaS (البنية التحتية كخدمة) مثل AWS أن تعمل بشكل جيد لتركيب الخدمات الصغيرة، ولكن الخدمات الصغيرة خفيفة الوزن نسبيًا قد لا تستخدم جميع الموارد الموجودة في الجهاز الظاهري، مما قد يقلل من ربحية الاستخدام. يمكنك أيضًا تركيب خدماتك الصغيرة باستخدام حزمة OSGI (مبادرة بوابة الخدمة المفتوحة). في هذه الحالة، سيتم تشغيل جميع الخدمات الصغيرة في JVM واحد، ولكن هذا يتضمن مشكلات المفاضلة بين التحكم والعزل. الخدمات الصغيرة: العيوب إن مجرد كون "كل هذا رائع" و"لم نر هذا من قبل" لا يعني عدم وجود عيوب. فيما يلي قائمة بمجالات الألم المحتملة التي تجلبها بنية الخدمات الصغيرة معها:

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

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