مرحبا بالجميع!
مؤخرًا ، في أحد مؤتمرات PGConf في موسكو ، أظهر أحد المتحدثين بنية "خدمات microservice" ، موضحًا أن جميع خدمات microses ترث من فئة أساسية واحدة مشتركة. على الرغم من عدم وجود تفسيرات للتنفيذ ، فقد بدا في هذه الشركة أن مصطلح "microservices" لم يتم فهمه بالطريقة نفسها التي يبدو أن الكلاسيكيات تعلمنا بها. اليوم سوف نتعامل مع واحدة من المشاكل المثيرة للاهتمام - ما يمكن أن يكون الرمز المشترك في الخدمات الصغيرة وما إذا كان يمكن أن يكون على الإطلاق.
ما هي خدمة microservice؟ هذا هو تطبيق قائم بذاته. ليس وحدة نمطية ، وليس عملية ، وليس شيئًا يتم نشره بشكل منفصل فقط ، ولكن تطبيقًا حقيقيًا ومتكاملًا. لديها وظيفتها الرئيسية الخاصة بها ، ومستودعها الخاص في البوابة ، واختباراتها الخاصة ، وواجهة برمجة التطبيقات الخاصة بها ، وخادم الويب الخاص بها ، وملف README الخاص بها ، وقاعدة بياناتها الخاصة ، وإصدارها الخاص ، ومطوريها.
مثل الحاويات ، بدأت استخدام الخدمات المصغرة عندما وصلت طاقة الحوسبة للـ HW وموثوقية الشبكات إلى هذا المستوى بحيث يمكنك تحمل مكالمة وظيفية تدوم أطول 100 مرة من ذي قبل ، ويمكنك تحمل استهلاك الذاكرة أعلى 100 مرة ، يمكنك شراء الكماليات لتسوية كل "جدة" ليس فقط في "شقة" منفصلة ، ولكن في "منزل" منفصل. مثل أي حل معماري ، تضحي بنية الخدمات الصغيرة مرة أخرى بالأداء ، وتربح في الحفاظ على رمز المطورين. ولكن نظرًا لأن الشخص وسرعة رد فعله ظلت كما هي ، فإن الأنظمة تواصل تلبية المتطلبات.
لماذا الانقسام إلى تطبيقات منفصلة؟ لأننا نوزع جزءًا من تعقيد النظام بالفعل على مستوى بنية النظام. تتحدث عملية البرمجة عمومًا عن "قطع" على مراحل من "التعقيد" الأولي الكبير ، والتحلل (في الفصول ، الوحدات النمطية ، الوظائف ، وفي حالتنا ، التطبيقات بأكملها) هو تنفيذ جزء من هذا التعقيد في شكل هيكل. عندما قسمنا النظام إلى خدمات ميكروية ، اتخذنا قرارًا معماريًا (ناجحًا أم لا) ، لم يعد المطورون بحاجة إلى اتخاذه في المستقبل عند تنفيذ أجزاء محددة من الوظيفة. من المعروف أن هذه الخدمة المجهرية المعينة هي المسؤولة عن إرسال رسائل البريد الإلكتروني ، وقد تم بالفعل إنشاء هذه الرسالة - للحصول على إذن ، وبالتالي فإن جميع ميزاتي الجديدة "تسقط" على هذا النمط دون مناقشة.
أحد الجوانب الرئيسية لخدمات micros هو ضعف الاتصال. يجب أن تكون Microservices مستقلة عن كلمة "بالكامل". ليس لديهم هياكل بيانات مشتركة ، وقد يكون / ينبغي أن يكون لكل خدمة ميكروية بنية خاصة بها ، وطريقة تجميعها (وما إلى ذلك). بحكم التعريف. لأنه تطبيق مستقل. يجب ألا تؤثر التغييرات في رمز إحدى خدمات microservice على الآخرين بأي طريقة ، ما لم تتأثر API. إذا كان لدي N microservices مكتوب بلغة Java ، فلا ينبغي أن يكون هناك أي عوامل مقيدة لعدم كتابة N + 1st microservice في Python ، إذا كانت مربحة فجأة لسبب ما. يتم اقترانها بشكل فضفاض ، وبالتالي المطور الذي يبدأ العمل مع microservice معين:
أ) يراقب API بحساسية شديدة ، لأنه المكون الوحيد المرئي من الخارج ؛
ب) يشعر بالحرية الكاملة في إعادة البناء.
ج) فهم الغرض من الخدمة المجهرية (هنا نتذكر حول SRP) وتنفذ وظيفة جديدة وفقًا لذلك ؛
د) يختار طريقة الثبات الأكثر ملاءمة ؛
إلخ
كل هذا جيد ويبدو منطقيا ومتناسقا ، مثل العديد من الأيديولوجيات والنظريات (وهنا يضع المنظر الإيديولوجي حدا ويذهب لتناول العشاء) ، لكننا نمارس. لا يلزم كتابة
الكود على
martinfowler.com . عاجلاً أم آجلاً ، نواجه حقيقة أن جميع الخدمات المصغرة:
- تسجيل المعلومات ؛
- تحتوي على إذن ؛
- وسطاء رسالة الوصول
- إرجاع رسائل الخطأ الصحيحة ؛
- يجب فهم الكيانات العامة في النظام بطريقة ما ، إن وجدت ؛
- يجب أن تعمل بتنسيق رسالة مشترك (وبروتوكول) ؛
وتفعل ذلك بطريقة مماثلة.
وفي مرحلة ما ، يأتي المهندس الإيديولوجي للعمل في الصباح ويكتشف أنه في الليل ظهرت "مكتبة" في النظام - مستودع جديد برمز مشترك يستخدم في العديد من الخدمات المجهرية. هل يجب أن يصاب المهندس المعماري بالرعب؟
ذلك يعتمد.
لتقييم الموقف بشكل صحيح ، يجب أن نعود إلى الفكرة الرئيسية: الخدمات المصغرة هي مجموعة من التطبيقات المستقلة التي تتفاعل مع بعضها البعض من خلال واجهة برمجة تطبيقات (شبكة). في هذا نرى الميزة الرئيسية والبساطة للهندسة المعمارية. ونحن لا نريد أن نفقد هذه الميزة تحت أي ظرف من الظروف. هل تتداخل الكود العام الذي تم وضعه في "المكتبة" مع هذا؟ لنلقي نظرة على بعض الأمثلة.
1. تعيش فئة المستخدم (أو بعض الكيانات التجارية الأخرى) في المكتبة.
- أي لا يتم تغليف الكيان التجاري في خدمة microservice واحدة ، ولكن يتم نشره بشكل مختلف (وإلا فلماذا يتم وضعه في مكتبة الرموز المشتركة؟) ؛
- أي تصبح الخدمات الصغيرة متصلة من خلال هذا الكيان التجاري ؛ وسيؤثر تغيير منطق العمل مع كيان على العديد من الخدمات الصغيرة ؛
- إنه أمر سيء ، سيء للغاية ، إنه ليس خدمات ميكروية على الإطلاق ، على الرغم من أنها ليست "كرة كبيرة من الوحل" ، ولكن نظرتنا إلى العالم ستؤدي سريعًا إلى "كرة كبيرة من الطين الموزع" ؛
- لكن الخدمات الميكروية في النظام تعمل مع نفس المفاهيم ، وغالبًا ما تكون المفاهيم كيانات ، أو مجرد هياكل مع حقول ، ماذا علي أن أفعل؟ قراءة DDD ، إنه يتعلق بالضبط بكيفية تغليف الكيانات داخل الخدمات الصغيرة بحيث لا "تطير" عبر واجهة برمجة التطبيقات.
لسوء الحظ ، فإن أي منطق عمل يوضع في مكتبة مشتركة سيكون له مثل هذا التأثير. تميل مكتبات الأكواد العامة إلى النمو ، مما يؤدي في منتصف النظام إلى تكوين "ورم" منطقي لا ينتمي إلى أي خدمات ميكروية معينة ، وتعطل الهيكل. يبدأ "مركز الثقل المنطقي" للنظام في الانتقال إلى repo برمز مشترك ، ونحصل على مزيج جهنمي من الخدمات المتجانسة والخدمات الصغيرة ، ونحن لسنا بحاجة للذهاب إلى هناك على الإطلاق.
2. يتم وضع رمز تحليل تنسيق الرسالة في المكتبة.
- من المرجح أن تكون الشفرة في Java إذا كانت جميع الخدمات المصغرة مكتوبة بلغة Java ؛
- إذا كتبت غداً خدمة في Python ، فلن أكون قادرًا على استخدام المحلل اللغوي ، لكن يبدو أنها ليست مشكلة على الإطلاق ، سأكتب نسخة Python ؛
- النقطة الأساسية: إذا كنت أكتب خدمة microservice جديدة في Java ، فهل يتعين علي استخدام هذا المحلل اللغوي؟ نعم ، ربما لا. ربما لست ملتزمًا ، على الرغم من أنه ، كمطور لخدمات microservice ، يمكن أن يكون مفيدًا للغاية. حسنًا ، كما لو أنني وجدت شيئًا مفيدًا في مستودع مافن.
محلل الرسائل ، أو مسجل محسن ، أو عميل ملفوف لإرسال البيانات إلى RabbitMQ - إنه نوع من المساعدين ، والمكونات الإضافية. فهي على قدم المساواة مع المكتبات القياسية من NuGet ، Maven أو NPM. يعد مطور خدمات microservice دائمًا هو الملك ؛ فهو يقرر ما إذا كان سيتم استخدام المكتبة القياسية أو إنشاء الكود الجديد الخاص به أو استخدام الكود من مكتبة المساعد المشتركة. كيف سيكون أكثر ملاءمة له ، لأنه يكتب تطبيق منفصل ومستقل. يمكن أن تتطور مساعد معين؟ ربما سيكون لديه الإصدارات. اسمح للمطور بالرجوع إلى إصدار محدد في خدمته ، لا أحد يجبره على تحديث الخدمة ، عند تحديث المساعدين ، هذا سؤال عن من يدعم الخدمة.
3. واجهة جافا ، فئة قاعدة مجردة ، سمة.
- أو قطعة أخرى من فئة "قطعة ممزقة من الكود" ؛
- أي أنا هنا ، مستقل ومستقل ، وتقع قطعة من كبدنا في مكان آخر ؛
- يظهر هنا تماسك الخدمات الميكروية على مستوى الشفرة ، لذلك لن نوصي بها ؛
- في المراحل الأولية ، ربما لن يجلب هذا أي مشاكل ملموسة ، ولكن جوهر التصميم المعماري هو ضمان الراحة (أو عدم الراحة) لسنوات قادمة.
يضع الفريق الذي بدأ العمل على منتج جديد الأساس للهندسة المعمارية وله تأثير كبير على الاتجاهات التي سيكون عليها المنتج. إذا تم دمج مبادئ SRP ، والتحلل الناجح ، والاتصال المنخفض ، وما إلى ذلك في البداية في النظام ، عندها فرصة لمواصلة التطوير بشكل صحيح. إذا لم يكن الأمر كذلك ، فإن التسارع بالطرد المركزي "لعوامل الوقت" (فريق آخر ، وقت قليل ، تصحيحات عاجلة ، عدم وجود وثائق) سوف يؤدي إلى جعل هذا النظام على الهامش أسرع مما يبدو.
تظل مسألة وجود كود شائع في الخدمات المصغرة صعبة لأنها مرتبطة بنوع من المقايضة: سنزن ما سيكون أكثر ربحية في المستقبل - درجة استقلالية الخدمات الصغيرة ، وتكرار أقل في الكود ، ومؤهلات المهندسين ، وبساطة النظام ، إلخ. في كل مرة تكون هذه هي الأفكار والمناقشات ، والتي يمكن أن تؤدي إلى قرارات معمارية محددة مختلفة. ومع ذلك ، دعونا نلخص بعض التوصيات:
التوصية 0: لا تستدعي خدمات microservices أي شيء ينقسم إلى أجزاء موجودة بشكل مستقل. ليس كل جدول يحتوي على أعمدة مصفوفة ، فلنستخدم المصطلحات بشكل صحيح.
التوصية 1: من المرغوب فيه للغاية أن الخدمات الميكروية ليس لها كود مشترك على الإطلاق.
التوصية 2: إذا كان لا يزال هناك كود مشترك ، فليكن مجموعة (مكتبة) من "المساعدين" الاختياريين. يقرر مطور الخدمة ما إذا كان سيتم استخدامها أو كتابة التعليمات البرمجية الخاصة به.
التوصية 3: تحت أي ظرف من الظروف يجب أن يكون هناك منطق الأعمال في الكود الموحد. يتم تغليف كل منطق الأعمال في الخدمات الصغيرة.
التوصية 4: دع مكتبة الشفرات العامة مصممة كحزمة قياسية (NuGet ، Maven ، NPM ، إلخ) ، مع خيار الإصدار (أو ، أفضل ، عدة حزم منفصلة).
التوصية 5: يجب أن يظل "مركز الثقل المنطقي" للنظام دائمًا في الخدمات الصغيرة نفسها ، وليس في الكود الموحد.
التوصية 6: إذا كنت تخطط للكتابة بتنسيق microservices ، فعليك التوفيق مقدماً في بعض الأحيان أن تتكرر الشفرة بينهما. إلى حد ما ، يجب قمع "غريزة التجفيف" الطبيعية لدينا.
شكرا لك على اهتمامك و microservices الناجحة.