كيف تختلف الخدمات المصغرة عن API

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

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

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

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

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

لماذا يجب أن تهتم بهذا التمييز؟

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

تخيل أنك تقوم بتصميم منصة ميكانيكية معقدة:

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

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

دعونا نتحدث عن بعض الخرافات الشائعة:

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

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

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

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

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

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