إن اختيار البنية يشبه تجميعها: الخدمات الصغيرة، أو المونوليث، أو SOA، أي منها يجعل مشروعك الميكانيكي أكثر مرونة؟

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

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

دعونا نتحدث عن تلك "الكتلة الحديدية الكبيرة" أولاً: العمارة المتجانسة

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

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

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

ورشة العمل المعيارية: SOA (الهندسة الموجهة نحو الخدمة)

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

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

التجميع على طراز Lego: الخدمات المصغرة

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

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

يبدو رائعا، أليس كذلك؟ لكنه ليس سحراً أيضاً. Microservices bring new challenges: How to coordinate so many small services? هل ستصبح الاتصالات عبر الشبكة عنق الزجاجة الجديد؟ كيفية تعقب المشكلة؟ يبدو الأمر كما لو كنت تدير مجموعة من الروبوتات الصغيرة التي يمكنها التصرف بشكل مستقل. أنت بحاجة إلى أدوات مراقبة واستراتيجيات نشر أفضل للتأكد من عدم اصطدامها ببعضها البعض أو ضياعها.

إذن، كيف تختار؟

في الواقع، لا توجد هندسة معمارية "الأفضل". 、看精度、看响应速度——软件架构也得匹配你的具体场景。

بعض النصائح قد تساعدك على تنظيم أفكارك:

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

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

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

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