مشاكل جديدة في أنظمة المؤازرة والحل السحابي

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

هل سبق لك أن واجهت موقفا مماثلا؟ الأجهزة ممتازة بما فيه الكفاية، لكن "عقل" التحكم الذي يقف خلفها واجه عنق الزجاجة.

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

عندما تجتمع الآلات مع الخدمات الصغيرة

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

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

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

لماذا أزور؟

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

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

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

من المفهوم إلى ورشة العمل

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

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

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

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

ليس فقط التكنولوجيا، بل الأفكار أيضًا

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

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

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

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

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