أين يجب تشديد الرخاوة؟ دعونا نتحدث عن الصداع في الخدمات الصغيرة

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

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

لماذا خدماتك الصغيرة "تقاتل" دائمًا؟

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

هذه ليست مجرد مشكلة فنية، ولكنها أشبه بـ "مرض" التصميم. الحدود بين الخدمات غير واضحة، والمسؤوليات متداخلة، وتتدفق البيانات في كل مكان... من الواضح أننا نريد استخدام الخدمات الصغيرة لتحسين المرونة، ولكن النتيجة هي شبكة غير واضحة.

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

في الواقع، الجواب ليس "كبيرًا أم صغيرًا"، بل "كيفية الاتصال".

الاتصال الجيد يشبه نظام نقل سلس

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

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

كيف؟ بدلاً من الاعتماد على القواعد الصارمة والسريعة، دعنا نعود إلى مصدر المشكلة: من يجب أن يكون مسؤولاً عن إجراءات عملك؟

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

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

من "كيفية القيام" إلى "كيفية الاختيار"

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

• للتواصل بين الخدمات، هل يجب أن نستخدم المكالمات المتزامنة أم الرسائل غير المتزامنة؟
• هل يجب مشاركة البيانات أم الاحتفاظ بها بشكل منفصل؟
• أين هو الحد المناسب لرسم وظيفة؟

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

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

عندما نتحدث عن الخدمات المصغرة، ما الذي نتحدث عنه؟

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

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

تسعى بنية الخدمات الصغيرة الجيدة إلى تحقيق هذه الحالة بالضبط - مستقلة ولكنها ليست معادية؛ متصلة ولكن غير المجمعة.

لذا، قبل إلغاء تثبيت الخدمة في المرة القادمة، اسأل نفسك:

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

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

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

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

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