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

ما الفرق بين الخدمات المصغرة وREST API؟ دعونا نتحدث

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

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

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

اكتشف ذلك أولاً: من هم؟

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

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

ببساطة، الخدمات المصغرة عبارة عن هيكل فريق "فرق تسد"، وREST API هي "لغة الاتصال" الشائعة داخل الفريق. يمكنك استخدام REST API لتوصيل الخدمات الصغيرة، ولكن يمكن أيضًا استخدام REST API في بنيات أخرى. لا يقتصر الأمر على الخدمات الصغيرة.

فلماذا الانفصال؟ ما الفائدة؟

قد ترغب في التساؤل، أليس من الجيد أن يكون لديك تطبيق "متجانس كبير" يجمع كل التعليمات البرمجية معًا؟ لماذا نتكبد عناء تقسيمها؟

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

"ولكن،" سوف يتمتم شخص ما، "إذا تم تقسيم الخدمات، فكيف يمكنهم التحدث مع بعضهم البعض بشكل موثوق؟" وهذا يعود إلى ما نسميه "لغة التواصل". السبب وراء شهرة REST API هو أنها بسيطة وعالمية، مثل لغة الماندرين في عالم الإنترنت. يستخدم الإجراءات الشائعة لبروتوكول HTTP - GET (get)، POST (إنشاء)، PUT (تحديث)، DELETE (حذف) لنقل النوايا. عندما تحتاج الخدمة "أ" إلى بيانات، فإنها ترسل طلب HTTP منسق بشكل واضح إلى الخدمة "ب"، وترجع الخدمة "ب" حزمة بيانات بتنسيق قياسي (عادةً JSON). واضحة وصديقة للمطورين.

كيف نستخدمها؟

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

وفي وقت لاحق، قمت بالتبديل إلى هندسة الخدمات الصغيرة. قمنا بتقسيم وظائف التحكم في المحركات ومراقبة الحالة وتشخيص الأخطاء وتسجيل الدخول إلى خدمات صغيرة مستقلة. تركز كل خدمة على القيام بشيء واحد بشكل جيد. كيف يتحدثون مع بعضهم البعض؟ ويتم ذلك من خلال واجهة REST API المصممة جيدًا والموثقة بوضوح. على سبيل المثال، إذا كانت خدمة مراقبة الحالة تريد معرفة عزم الدوران في الوقت الحقيقي للمحرك رقم 3، فإنها ترسل طلب GET /api/motors/3/torque إلى خدمة التحكم في المحرك، وتحصل على الفور على سلسلة واضحة من البيانات. ترقية التشخيص؟ وطالما تم تمكين خدمة التشخيص، سيتم تشغيل كل شيء آخر كالمعتاد.

هذا النموذج يجعل التكرارات سريعة ويقلل الاقتران بين الفرق. يستطيع الزميل المسؤول عن التحكم الحركي التركيز على عمله. وطالما أنه يلتزم بـ "عقد الاتصال" الخاص بواجهة برمجة التطبيقات (API) المتفق عليه مسبقًا، فهو لا يخشى التأثير على الوحدات الأخرى.

ما الذي يجب الانتباه إليه عند الاختيار؟

لذا، إذا كنت تفكر في هيكلة مشروعك الخاص، فلا تنظر فقط إلى الكلمات الطنانة. اسأل نفسك:

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

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

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

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