في 19 سبتمبر ، تم
عقد أول metap مواضيعية HUG (مجموعة مستخدمي Highload ++) في موسكو ، والتي تم تخصيصها للخدمات الدقيقة. تم تسليم تقرير "تشغيل الخدمات الصغيرة: الحجم مهم حتى إذا كان لديك Kubernetes" والذي شاركنا فيه خبرة Flant الواسعة في تشغيل المشاريع باستخدام بنية الخدمات الصغيرة. بادئ ذي بدء ، سيكون مفيدًا لجميع المطورين الذين يفكرون في تطبيق هذا النهج في مشروعهم الحالي أو المستقبلي.
نقدم
الفيديو مع التقرير (50 دقيقة ، أكثر إفادة من المقالة) ، بالإضافة إلى المقتطف الرئيسي منه في شكل نص.
ملاحظة: يتوفر الفيديو والعرض التقديمي أيضًا في نهاية هذا المنشور. مقدمة
عادة ما تحتوي القصة الجيدة على مؤامرة ومؤامرة رئيسية وخاتمة. هذا التقرير أشبه بمؤامرة ومأساة. من المهم أيضًا ملاحظة أنه يوفر نظرة على
تشغيل الخدمات الدقيقة.
سأبدأ بمثل هذا الجدول الزمني ، مؤلفه (في عام 2015)
كان مارتن فاولر:
يوضح كيف أنه في حالة تطبيق متجانسة وصل إلى قيمة معينة ، تبدأ إنتاجية العمل في الانخفاض. تختلف الخدمات الصغيرة في أن الإنتاجية الأولية معها أقل ، ولكن مع تزايد التعقيد ، فإن تدهور الكفاءة بالنسبة لها ليس ملحوظًا.
سأكمل هذا الرسم البياني لحالة استخدام Kubernetes:
لماذا تحسن تطبيق الخدمات الصغيرة؟ لأن مثل هذه الهندسة المعمارية تطرح متطلبات معمارية خطيرة ، والتي بدورها مغطاة تمامًا بقدرات Kubernetes. من ناحية أخرى ، سيكون جزءًا من هذه الوظيفة مفيدًا أيضًا للمونوليث ، خاصة لسبب أن المونوليث النموذجي اليوم ليس بالضبط مترابطًا (ستكون التفاصيل أكثر في التقرير).
كما ترى ، الجدول الزمني النهائي (عندما لا يكون كل من تطبيقات الخدمات المتجانسة والخدمات الصغيرة في البنية التحتية مع Kubernetes) مختلفًا تمامًا عن الجدول الأصلي. بعد ذلك ، سنتحدث عن التطبيقات التي تعمل باستخدام Kubernetes.
خدمة دقيقة مفيدة وضارة
وهنا الفكرة الرئيسية:
ما هي بنية الخدمات الصغيرة
العادية ؟ يجب أن يجلب لك فوائد حقيقية ، وزيادة كفاءة العمل. إذا عدت إلى الرسم البياني ، فهذا هو:
إذا وصفته بأنه
مفيد ، فسيكون على الجانب الآخر من الرسم البياني خدمة مايكروسيف
ضارة (تتداخل مع العمل):
العودة إلى "الفكرة الرئيسية": هل تستحق الثقة بتجربتي على الإطلاق؟ منذ بداية هذا العام ، نظرت في
85 مشروعًا . لم تكن جميعهم من الخدمات الصغيرة (ما يقرب من ثلث إلى نصفهم يمتلكون مثل هذه العمارة) ، لكن هذا لا يزال عددًا كبيرًا. تمكنا نحن (شركات Flant) كمتعاقدين خارجيين من رؤية مجموعة واسعة من التطبيقات المطورة في الشركات الصغيرة (مع 5 مطورين) وكبيرة (~ 500 مطور). إضافة إضافية هي أننا نرى كيف تعيش هذه التطبيقات وتتطور على مر السنين.
لماذا الخدمات الدقيقة؟
بالنسبة للسؤال حول فوائد الخدمات الدقيقة ، فإن مارتن فاولر المذكور بالفعل لديه
إجابة محددة للغاية :
- حدود وحدانية واضحة ؛
- نشر مستقل ؛
- حرية اختيار التكنولوجيا.
تحدثت كثيرًا مع المهندسين المعماريين ومطوري البرامج وسألت لماذا يحتاجون إلى خدمات دقيقة. وجمع قائمته توقعاتهم. إليك ما حدث:
إذا كنت تصف "في الأحاسيس" بعض النقاط ، فعندئذٍ:
- حدود واضحة للوحدات: هنا لدينا متراصة رهيبة ، والآن سيتم وضع كل شيء بدقة في مستودعات Git ، حيث يكون كل شيء "على الرفوف" ، وليس ممزوجًا بالدفء والنعومة ؛
- استقلالية النشر: سنكون قادرين على طرح الخدمات بشكل مستقل ، بحيث يتم التطوير بشكل أسرع (نشر ميزات جديدة بالتوازي) ؛
- استقلالية التنمية: يمكننا تقديم هذه الخدمة الصغيرة إلى ذلك الفريق / المطور ، والآخر ، حتى نتمكن من التطور بشكل أسرع ؛
- موثوقية أكبر: في حالة حدوث انحطاط جزئي (واحد من أصل 20 خدمة صغيرة) ، سيتوقف زر واحد فقط عن العمل ، وسيستمر النظام ككل في العمل.
بنية الخدمات الصغيرة النموذجية (الضارة)
لشرح لماذا كل شيء في الواقع ليس كما نتوقع ، سأقدم صورة
جماعية لهندسة الخدمات الصغيرة على أساس الخبرة من العديد من المشاريع المختلفة.
على سبيل المثال ، متجر تجريدي عبر الإنترنت على وشك التنافس مع Amazon أو على الأقل OZON. تبدو هندسة الخدمات الصغيرة على النحو التالي:
لمجموعة من الأسباب ، تتم كتابة هذه الخدمات الدقيقة على منصات مختلفة:
نظرًا لأن كل خدمة صغيرة يجب أن تتمتع بالاستقلالية ، فإن العديد منها يحتاج إلى قاعدة بيانات وذاكرة تخزين مؤقت خاصة به. العمارة النهائية هي كما يلي:
ما هي عواقبه؟
لدى فاولر
مقال حول هذا الموضوع - حول "الاسترداد" لاستخدام الخدمات الصغيرة:
وسنرى ما إذا تم تحقيق توقعاتنا.
مسح حدود الوحدات ...
ولكن
كم عدد الخدمات الصغيرة التي نحتاج إلى إصلاحها بالفعل لإطلاق التغيير؟ هل يمكننا حتى معرفة كيف يعمل كل شيء بدون أداة تتبع موزعة (بعد كل شيء ، تتم معالجة أي طلب بواسطة نصف الخدمات الدقيقة)؟
هناك نمط "
كتلة كبيرة من الطين " ، لكن هنا نحصل على كتلة موزعة من الطين. لدعم ذلك ، إليك مثال توضيحي لكيفية عمل الاستعلامات:
استقلالية النشر ...
من الناحية الفنية ، تم تحقيق ذلك: يمكننا تدوير كل خدمة صغيرة على حدة. ولكن في الممارسة العملية ، يجب أن
تضع في اعتبارك أن
العديد من الخدمات الدقيقة يتم طرحها دائمًا ، وعلينا أن نأخذ في الاعتبار
ترتيب طرحها . بطريقة جيدة ، نحتاج عمومًا إلى اختبار في دائرة منفصلة ما إذا كنا نطرح الإصدار بالترتيب الصحيح.
حرية اختيار التكنولوجيا ...
هي هناك. من الجدير بالذكر فقط أن الحرية غالبًا ما تحد من الفوضى. من المهم جدًا هنا عدم اختيار التقنيات لمجرد "اللعب" معهم.
الاستقلال التنموي ...
كيفية إنشاء دائرة اختبار للتطبيق بأكمله (من العديد من المكونات)؟ ولكنك لا تزال بحاجة إلى تحديثه باستمرار. كل هذا يؤدي إلى حقيقة أن
العدد الفعلي لحلقات الاختبار ، التي يمكننا ، من حيث المبدأ ، احتواؤها ،
ضئيلة .
ولكن لنشر كل هذا محليًا؟ .. اتضح أنه غالبًا ما يقوم المطور بعمله بشكل مستقل ، ولكن بشكل عشوائي ، لأنه عليه الانتظار حتى يتم إصدار الدائرة للاختبار.
تحجيم منفصل ...
نعم ، لكنها محدودة في مجال DBMS المستخدم. في مثال الهندسة المعمارية المعينة ، لن تواجه كاساندرا مشاكل ، ولكن MySQL و PostgreSQL سيواجهونها.
موثوقية أكبر ...
ليس ذلك فحسب ، في الواقع ، غالبًا ما يؤدي فشل إحدى الخدمات الصغيرة إلى كسر الأداء الصحيح للنظام بأكمله ، فهناك أيضًا مشكلة جديدة:
من الصعب جدًا جعل كل خدمة صغيرة متسامحة مع الخطأ . نظرًا لأن الخدمات الصغيرة تستخدم تقنيات مختلفة (memcache و Redis وما إلى ذلك) ، يحتاج الجميع إلى التفكير في كل شيء وتطبيقه ، وهو أمر ممكن بالطبع ، ولكنه يتطلب موارد ضخمة.
قياس الحمولة ...
كل شيء جيد حقا مع هذا.
خفة الخدمات الصغيرة ...
لم نحصل فقط على أعباء
شبكة ضخمة (استعلامات DNS ، وما إلى ذلك) ، ولكن أيضًا بسبب الاستعلامات الفرعية العديدة ، بدأنا في
نسخ البيانات (ذاكرة التخزين المؤقت للمخزن) ، مما أدى إلى مساحة تخزين كبيرة.
وهنا نتيجة تلبية توقعاتنا:
ولكن هذا ليس كل شيء!
لأن:
- على الأرجح نحن بحاجة إلى ناقل رسائل.
- كيفية عمل نسخة احتياطية متسقة في الوقت المناسب؟ الخيار الحقيقي الوحيد هو إيقاف حركة المرور لهذا. ولكن كيف نفعل ذلك على الإنتاج؟
- إذا كنا نتحدث عن دعم العديد من المناطق ، فإن تنظيم الاستدامة في كل منها هو مهمة تستغرق وقتًا طويلاً.
- هناك مشكلة في إجراء تغييرات مركزية. على سبيل المثال ، إذا كنا بحاجة إلى تحديث إصدار PHP ، فإننا نحتاج إلى الالتزام بكل مستودع (وهناك العشرات منها).
- إن الزيادة في التعقيد التشغيلي المرتجل أمر هائل.
ماذا تفعل بكل هذا؟
ابدأ بتطبيق متجانسة .
تشير تجربة فاولر
إلى أن جميع تطبيقات الخدمات الصغيرة الناجحة تقريبًا قد بدأت باستخدام متراصة ، والتي أصبحت كبيرة جدًا ، وبعد ذلك تم كسرها. في الوقت نفسه ، واجهت جميع الأنظمة التي تم إنشاؤها كخدمة صغيرة منذ البداية مشكلات خطيرة عاجلاً أم آجلاً.
هناك فكرة قيّمة أخرى وهي أنه حتى ينجح مشروع بهندسة خدمات صغيرة ، يجب أن تعرف جيدًا
كل من مجال الموضوع وكيفية عمل الخدمات الصغيرة . وأفضل طريقة لمعرفة مجال الموضوع هي إنشاء متآلف.
ولكن ماذا لو كنا بالفعل في هذا الموقف؟
الخطوة الأولى لحل أي مشكلة هي الموافقة عليها وفهم أنها مشكلة لم نعد نريدها.
إذا في حالة تراكم مترابط (عندما نفدت الفرصة لشراء الموارد لها) ، فقد قطعناها ، ثم في هذه الحالة نحصل على القصة المعاكسة: عندما لا تساعد الخدمة الدقيقة المفرطة بعد الآن ، ولكنها تتداخل -
تقطع الفائض والتكبير!
على سبيل المثال ، للصورة الجماعية التي نوقشت أعلاه ...
تخلص من أكثر الخدمات الدقيقة المشبوهة:
اجمع بين جميع الخدمات الصغيرة المسؤولة عن إنشاء الواجهة الأمامية:
... في خدمة مايكرو واحدة مكتوبة بلغة / إطار عمل (حديث وعادي ، كما تظن بنفسك):
سيكون لديه ORM واحد (DBMS واحد) وأول تطبيقين:
... بشكل عام ، يمكن نقل المزيد هناك ، بعد الحصول على النتيجة التالية:
علاوة على ذلك ، في Kubernetes نقوم بتشغيل كل هذا في حالات منفصلة ، مما يعني أنه لا يزال بإمكاننا قياس الحمل وقياسها بشكل منفصل.
تلخيص
انظر إلى الصورة على نطاق أوسع. في كثير من الأحيان ، تنشأ كل هذه المشاكل المتعلقة بالخدمات الدقيقة نظرًا لحقيقة أن شخصًا ما قام بمهمته ، لكنه أراد "تشغيل الخدمات الصغيرة".
في كلمة "microservices" ، يكون الجزء "الصغير" غير ضروري . إنها "صغيرة" فقط لأنها أصغر من كتلة ضخمة. لكن لا تفكر فيهم كشيء صغير.
وبالنسبة للفكر النهائي ، عد إلى الجدول الأصلي:
تتلخص الملاحظة المكتوبة إليه
(أعلى اليمين) في حقيقة أن
مهارات الفريق التي تجعل مشروعك دائمًا ما تكون أساسية - سيلعبون دورًا رئيسيًا في اختيارك بين الخدمات الصغيرة والمونوليث. إذا لم يكن لدى الفريق مهارات كافية ، لكنه بدأ في تقديم خدمات دقيقة ، فإن القصة ستكون قاتلة بالتأكيد.
مقاطع فيديو وشرائح
فيديو من الخطاب (~ 50 دقيقة ، للأسف ، لا ينقل المشاعر العديدة للزوار ، والتي حددت إلى حد كبير مزاج التقرير ، ولكن كما هو):
عرض التقرير:
ملاحظة
تقارير أخرى على مدونتنا:
قد تكون مهتمًا أيضًا بالمطبوعات التالية: