عيوب بنية الخدمات الصغيرة

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

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

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

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

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

"هل نحن عالقون هنا؟ هل نتعايش مع هذه التعقيدات؟"

بالطبع لا. المشاكل موجودة ليتم حلها.

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

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

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

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

ما الفرق الذي يمكن أن يحدثه هذا؟

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

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

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

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

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

لذا، عندما تفكر في الهندسة المعمارية، اسأل نفسك بعض الأسئلة البسيطة:

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

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

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

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