عندما يتم تصور منتج كبير أو عندما يبدأ البرنامج الصغير في النمو إلى ليفيتان ، ما هو مسار التطوير الذي يجب علي اختياره؟ هل ينبغي علي إعادة كتابة كل شيء من الصفر أو متابعة التقاليد "التاريخية"؟ على أي حال ، هل يستحق مراجعة مفهوم العمارة ذاته؟
مرحباً يا خبروفيتيس! اسمي كونستانتين ، وأنا المطور الرئيسي لنظام واحد كبير إلى حد ما بدأ مرة واحدة كتجربة. تم إنشاء موقع PHP صغير حرفيًا "على الركبة" ، وبطبيعة الحال ، متراصة. مع مرور الوقت ، نما الموقع وواجه العديد من المشكلات ، التي طرح حلها السؤال "ثم كيف؟".
متراصة أو الخدمات الدقيقة؟ ماذا تختار؟ الفرق الأساسي بين النهج ، في رأيي ، هو أن المتراصة تنطوي على دورة مركزية لمعالجة طلب المستخدم ، والخدمات الميكروية - دورة لا مركزية. والمزايا والعيوب الشائعة لكلا النهجين معروفة على نطاق واسع ويتم سردها أكثر من مرة (على سبيل المثال ،
هنا ،
هنا أو
هنا ). ومع ذلك ، لا توجد عوامل واضحة وواضحة للغاية تؤثر على اختيار الهندسة المعمارية.
- تحميل الموظفين بدوام كامل . مع التطور السريع للمنتج ، تتراكم مجموعة من المهام ، والتي لا يمكن حلها في إطار زمني مقبول - الجميع مشغولون. وإذا كان مثل هذا "الحصار" منفردًا ، فليس من المنطقي توسيع موظفي المطورين. الحل الواضح هو المقاولين الخارجيين (الشركات أو المستقلين). ولكن كيف نعطيهم قطعة من المنتج للعمل دون المخاطرة بتحويلها إلى مصدر مفتوح ، بشكل تقريبي؟ في حالة استخدام خدمات microservices ، فإن حل هذه المهمة أسهل بكثير.
- صعوبة الغوص . كلما زاد حجم المنتج ، زاد الوقت الذي يستغرقه الموظف الجديد للراحة فيه. خاصةً إذا كان هناك الكثير من الإعدادات الافتراضية المختلفة في التعليمات البرمجية (نعم ، فإن التوثيق الجيد يجعل العملية أسهل كثيرًا ، لكن إذا لم يحدث ذلك؟) والتخصيصات للحالات الخاصة الفردية. من وجهة النظر هذه ، فإن التعامل مع جزء صغير مستقل أسهل بكثير من التعامل مع المنتج بالكامل على الفور.
- الموارد في ذروة الأحمال . في ممارستي ، كانت هناك حالة عندما زاد الحمل على الخوادم في بعض الأحيان إلى قيم غير مقبولة (وإذا تم تحديدًا - تم استنفاد ذاكرة الوصول العشوائي (RAM) ، تم تنشيط المبادلة وتحول الخادم إلى خضروات لفترة من الوقت) ، أثناء العمل المجاني طوال الوقت (لم يتجاوز التحميل 30٪ من حيث ذاكرة الوصول العشوائي ). ومثل هذه القمم حدثت بشكل غير منتظم مع توقف طويل. في حالة المتراصة (نعتقد أنه لا يوجد مكان لتحسين الكود) ، يتم حفظ اتصال الخوادم الجديدة فقط بنسخة من النظام بأكمله لموازنة التحميل. وفي حالة الخدمات المصغرة ، يمكنك تنظيم قائمة انتظار معالجة (بالطبع ، هذا ينطبق فقط على العمليات الحساسة للوقت سريعة وغير متوقعة ، مثل تفريغ جدول Excel).
- أداء المهام في الخلفية . الطريقة التي يعتمد عليها هذا العامل "يهز القارب" تعتمد على حجمه وتعقيده. كقاعدة عامة ، متراصة وجهاز توقيت (كرون) كافية. ولكن إذا بدأت المهام تتراكم في مجموعات كبيرة ، فستظهر المشكلات أيضًا. من الضروري موازنة مهام cron بالفعل. Microservices تسهيل هذا الموقف إلى حد كبير.
- تعقيد التتبع . في حالة الخدمات المصغرة ، يتم زيادة متطلبات صيانة الحديد - أين ، وماذا وكيف يجب تكوينها. متراصة - بمعنى تقريبًا ، تعتمد بعض الإعدادات الخاصة بجميع العقد ، والخدمات المجهرية - الإعدادات على متطلبات خدمات ميكروية محددة تعمل على العقدة.
- متطلبات التأهيل . كلما زاد عدد التقنيات التي تمارسها حديقة الحيوان (وعادة ما تنمو إذا كان النظام عبارة عن خدمة مجهرية) ، كلما زادت متطلبات مهارات ومعارف الموظفين العاديين. بعد كل شيء ، إذا كان هناك تحسينات أو مشاكل ، يجب عليهم التعامل. أو هناك حاجة إلى المزيد من المهنيين لتغطية المكدس بأكمله.
هل هناك أي حاجة للاختيار؟ هل اللعبة تستحق كل هذا العناء؟ أعتقد بالتأكيد يستحق كل هذا العناء. ولكن يجب على المرء أن يتعامل مع القضية برأس بارد. خلاف ذلك ، سيتم استبدال بعض المشاكل ببساطة من قبل الآخرين.
في حالتي ، جاءت نقطة تحول عندما توقف الموقع عن "ملاءمة" موارد خادم واحد. ثم تقرر إعادة كتابة النظام وفقًا لأفضل خيار في رأيي - هجين. هناك
توصيات عامة لتطوير المنتج في "الحالة المختلطة". ولكني أود أن أكملها ببعض التوصيات.
عند تصميم متراصة بداية ، يجب وضع إمكانيات اتصال الخدمات الخارجية على الفور. بناء الاتصالات بين المكونات على الفور كما لو أن هذه المكونات بالفعل (أو بالفعل تقريبا) "خدمات خارجية". خاصة إذا كانت كثيفة الاستخدام للموارد.
فكر فورًا في سياسة للتعامل مع ذاكرات التخزين المؤقت ومخازن البيانات (قواعد البيانات والملفات). على سبيل المثال ، قم بمشاركة جلسة المستخدم.
والشيء الأكثر أهمية هو عدم التسرع في التطرف. بنفسي ، استنتجت الصيغة التالية لمشروع جيد: "النظام الفعال هو نظام متوازن". على وجه الخصوص ، يتم التعبير عن ذلك في حقيقة أنه في الخدمات المجهرية لا أخرج سوى شظايا كبيرة ومعزولة منطقياً من النواة. وبعد ذلك ، فقط إذا تم استيفاء واحد على الأقل من الشروط:
- مطلوب الحد من الحمل والتنبؤ ، تأخير الوقت بسبب تنفيذ المهمة ليست حاسمة بدوره
- سوف العزلة تعطي زيادة كبيرة في الإنتاجية.
نتيجة لهذا النهج ، حصلنا على نظام ، و 95 ٪ من الوظائف الموجودة في النواة ، و 5 ٪ في الخدمات الصغيرة. ولكن في الوقت نفسه ، يمثل الحساب الأساسي 60٪ فقط من إجمالي الحمل. وفي الوقت نفسه ، يمكنك ضمان ألا يتجاوز الحمل على الخوادم الفردية القيم الحرجة.
لذا ، تعد الخدمات المصغرة (من حجم معين للمنتج) جيدة إذا كنت تستخدمها فقط إذا كان ذلك ضروريًا للغاية ، وليس بسبب الموضة أو "لأنها باردة". هناك
منتجات كبيرة تعيش بنجاح كمتراصة. ولكن في بعض الأحيان لا يمكن أن يحل متراصة المشكلة ...
شكرا لك