عندما تجتمع الخدمات المصغرة مع Java: هل لا يزال مشروعك عالقًا على المستوى الميكانيكي؟

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

يبدو الأمر وكأنه تجميع أداة دقيقة. كل ترس مصقول بسلاسة، ولكن عند تجميعه معًا فإنه لن يتحول.

لماذا الأجهزة جاهزة والبرمجيات متخلفة؟

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

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

"ماذا يجب أن نفعل؟" سألني أحد الطلاب قبل بضع سنوات، "هل نحتاج إلى تفكيك البرنامج وكتابته؟"

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

الخدمات المصغرة + Java: إنها ليست مصادفة، إنها أمر لا مفر منه

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

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

فكر في الأمر، إنه يشبه إلى حد كبير صيانة قطعة معقدة من الآلات - ليس عليك تمزيقها برمتها في كل مرة.

ولكن لا تتسرع في القيام بذلك، فهناك بعض المزالق التي تحتاج إلى معرفتها أولاً

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

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

"كيفية فهم هذه الدرجة؟" هذا سؤال جيد. قاعدتي الأساسية هي: البدء بالوحدات التي من المرجح أن تتغير بشكل مستقل. على سبيل المثال، يجب أن تكون وحدة مراقبة درجة الحرارة ووحدة التحكم في الحركة قادرين على العمل بشكل مستقل.

من الرسومات إلى الواقع: كيفية تنفيذ هذا المزيج؟

لنفترض أنك تريد أن تبدأ الآن. لا تتعجل في كتابة التعليمات البرمجية، ارسم مخطط حدود الخدمة أولاً، تمامًا مثل رسم مخطط التجميع الميكانيكي. تحديد مسؤوليات كل خدمة، ما هي البيانات التي تتعامل معها؟ ما هو الناتج؟ مع من تتواصل؟

ثم اختر الأداة . يعد Spring Boot الآن تقريبًا نقطة البداية الافتراضية لخدمات Java الصغيرة، وهو يتعامل مع الكثير من الأمور التافهة نيابةً عنك. تتيح حاويات Docker تشغيل خدماتك باستمرار في بيئات مختلفة، تمامًا مثل المكونات القياسية.

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

كن صادقا

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

فهو يسمح للبرامج بمواكبة تطور الأجهزة.

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

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

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