عندما تجتمع Java مع الخدمات الصغيرة: لا تدع التعقيد يلتهم مشروعك

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

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

لماذا يحتاج مشروع Java الخاص بك إلى إعادة التفكير؟

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

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

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

كيف تبدو الخدمات المصغرة حقًا في Java

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

على سبيل المثال: في الماضي، ربما كان تطبيق Java الخاص بك يحتوي على فئة "UserService" ضخمة تتعامل مع تسجيل الدخول والتسجيل وتحديثات الملف الشخصي وإعادة تعيين كلمة المرور وكل شيء. في بنية الخدمات الصغيرة، يمكن تقسيمها إلى أربع خدمات مستقلة. The login service only verifies credentials; تعالج خدمة التسجيل بيانات المستخدم الجديدة؛ تدير خدمة الملف الشخصي عرض المعلومات وتحريرها؛ وتركز خدمة كلمة المرور على عملية إعادة تعيين الأمان.

ما هي فوائد القيام بذلك؟

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

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

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

لكن الانقسام ليس حلا سحريا

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

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

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

من النظرية إلى التطبيق: بعض الأفكار الواقعية

ما الذي يفعله مطور Java بالضبط؟

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

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

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

تجنب المزالق الشائعة

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

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

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

مكتوب في: ابحث عن إيقاعك الخاص

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

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

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

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

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

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