عندما يبدو مشروع الخدمات المصغرة الخاص بك وكأنه مجموعة من الأجزاء المتناثرة

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

ما الذي يحدد بالضبط "بنية" الخدمات المصغرة؟

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

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

إنها حدود الخدمة، ولا تتعلق برسمها أينما تريد.

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

ثم هناك آلية الاتصال، وليس مجرد إرسال الرسائل

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

استقلالية البيانات - يجب أن يكون لكل خدمة مستودع صغير خاص بها

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

هناك أيضًا "أجزاء الدعم" غير الواضحة ولكنها حاسمة

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

لذا يصبح السؤال: كيف يمكن تجميع هذه المكونات في نظام منسق؟

في هذا الوقت، قد تفكر: "أنا أفهم المبدأ، ولكن كيف أفعل ذلك على وجه التحديد؟" دعونا نتحدث عن بعض النقاط التي يجب الانتباه إليها أثناء التجميع الفعلي.

عليك أن تختار بروتوكول الاتصال الصحيح. مثل اختيار إشارة التحكم للمؤازرة أو PWM أو الأمر التسلسلي؟ تتطلب المشاهد المختلفة إيقاعات مختلفة. قد تكون مكالمات الخدمة الداخلية أسرع مع gRPC، بينما يكون REST أكثر تنوعًا لواجهات برمجة التطبيقات الخارجية. ليس هناك خير مطلق أو شر مطلق، فقط ملاءمة أو عدم ملاءمة.

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

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

من الأجزاء إلى الكل: تجربة تجميع أسهل

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

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

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

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

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