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