دع مشاريع المحرك المؤازر ومعدات التوجيه تتحرك: بناء الخدمات الصغيرة .NET Core

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

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

لماذا الخدمات المصغرة؟ إنه مثل إضافة "مفاصل معيارية" إلى مشروعك الميكانيكي

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

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

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

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

أنشئ أول خدمة صغيرة لك في .NET Core

كيف تفعل هذا؟ دعونا نتخطى النظرية المجردة وننتقل مباشرة إلى بعض الخطوات العملية.

أنت بحاجة إلى "ترسيم حدود واضح". لنفترض أنك تعمل في مشروع ذراع آلية، والذي يمكن تقسيمه إلى: خدمات تخطيط الحركة، وخدمات محرك السيارات، وخدمات مراقبة الحالة. تتوافق كل خدمة مع مشروع .NET Core مستقل.

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

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

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

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

من المفهوم إلى الواقع: دع الكود يقود الآلات

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

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

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

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

مكتوب في

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

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

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