لماذا يستخدم الجميع الخدمات المصغرة؟ هل هو حقا مفيد؟

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

ما هي المشكلة؟

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

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

ما الفرق الذي تجلبه الخدمات الصغيرة؟

الجذب الأول: الاستقلال.

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

الميزة الثانية: التحجيم المرن.

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

السحر الثالث: الحرية التكنولوجية.

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

فهل هناك أي صداع في ذلك؟

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

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

ما الذي يهتم به الناس حقًا عندما يختارون؟

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

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

كيف يشبه هذا بشكل غريب تصميم الأجهزة؟

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

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

إذًا، في أي المشاهد يتألق حقًا؟

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

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

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

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