التصميم والخدمات الدقيقة المدفوعة بالمجال

عندما يبدأ نظام الخادم الخاص بك في "الغضب": فلنتحدث عن برامج تشغيل المجال والخدمات الصغيرة

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

المشكلة في كثير من الأحيان ليست مع الأجهزة

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

التصميم المستند إلى المجال: امنح كل أداة صندوق أدوات مخصصًا

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

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

ما الفرق الحقيقي الذي يمكن أن يحققه هذا المزيج؟

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

"ولكن هل سيكون من الصعب إدارتها إذا تم تقسيمها بشكل دقيق للغاية؟" سأل شخص ما.

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

عدة نقاط للملاحظة عند اختيار الخطة

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

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

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

الحكمة التقدمية عند الهبوط

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

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

التحديات والاستجابات التي لا مفر منها

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

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

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

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