19 سبتمبر في موسكو الاجتماع المواضيعي الأول HUG (مجموعة مستخدمي Highload++)، والذي كان مخصصًا للخدمات الصغيرة. كان هناك عرض تقديمي بعنوان "تشغيل الخدمات الصغيرة: الحجم مهم، حتى لو كان لديك Kubernetes"، والذي شاركنا فيه خبرة Flant الواسعة في تشغيل المشاريع باستخدام بنية الخدمات الصغيرة. في البداية، سيكون مفيدًا لجميع المطورين الذين يفكرون في استخدام هذا النهج في مشروعهم الحالي أو المستقبلي.
مقدمة (50 دقيقة، أكثر إفادة بكثير من المقال)، بالإضافة إلى المقتطف الرئيسي منه في شكل نص.
ملحوظة: الفيديو والعرض التقديمي متاحان أيضًا في نهاية هذا المنشور.
مقدمة
عادةً ما يكون للقصة الجيدة بداية وحبكة رئيسية وحل. هذا التقرير أشبه بمقدمة، وهو مأساوي في ذلك الوقت. من المهم أيضًا ملاحظة أنه يوفر وجهة نظر خارجية للخدمات الصغيرة. التشغيل.
سأبدأ بهذا الرسم البياني الذي مؤلفه (في عام 2015) مارتن فاولر:
ويوضح كيف أنه في حالة تطبيق متجانس يصل إلى قيمة معينة، تبدأ الإنتاجية في الانخفاض. تختلف الخدمات الصغيرة من حيث أن الإنتاجية الأولية معها أقل، ولكن مع زيادة التعقيد، فإن تدهور الكفاءة ليس ملحوظًا بالنسبة لهم.
سأضيف إلى هذا الرسم البياني لحالة استخدام Kubernetes:
لماذا يعد التطبيق الذي يحتوي على خدمات صغيرة أفضل؟ لأن مثل هذه البنية تطرح متطلبات جدية للبنية، والتي بدورها تغطيها تمامًا إمكانيات Kubernetes. من ناحية أخرى، ستكون بعض هذه الوظائف مفيدة للوحدة المتراصة، لا سيما وأن الكتلة المتراصة النموذجية اليوم ليست كتلة متجانسة تمامًا (ستتوفر التفاصيل لاحقًا في التقرير).
كما ترون، فإن الرسم البياني النهائي (عندما تكون كل من التطبيقات المتجانسة وتطبيقات الخدمات الصغيرة موجودة في البنية التحتية مع Kubernetes) لا يختلف كثيرًا عن الرسم الأصلي. سنتحدث بعد ذلك عن التطبيقات التي يتم تشغيلها باستخدام Kubernetes.
الخدمات الصغيرة المفيدة والضارة
وهنا الفكرة الرئيسية:
ما هو طبيعي بنية الخدمات الصغيرة؟ يجب أن يجلب لك فوائد حقيقية، مما يزيد من كفاءة عملك. إذا عدنا إلى الرسم البياني، فإليك ما يلي:
إذا اتصلت بها مفيد، ثم على الجانب الآخر من الرسم البياني سيكون هناك ضار الخدمات المصغرة (تتداخل مع العمل):
العودة إلى "الفكرة الرئيسية": هل يجب أن أثق بتجربتي على الإطلاق؟ منذ بداية هذا العام لقد بحثت 85 مشروع. لم تكن جميعها عبارة عن خدمات صغيرة (حوالي ثلث إلى نصفها كان لديها مثل هذه البنية)، لكن هذا لا يزال عددًا كبيرًا. نحن (شركة Flant) كمتعاقدين خارجيين تمكنا من رؤية مجموعة واسعة من التطبيقات التي تم تطويرها في كل من الشركات الصغيرة (مع 5 مطورين) وفي الشركات الكبيرة (حوالي 500 مطور). ومن المزايا الإضافية أننا نرى هذه التطبيقات حية وتتطور على مر السنين.
لماذا الخدمات المصغرة؟
هناك سؤال حول فوائد الخدمات الصغيرة من مارتن فاولر الذي سبق ذكره:
- حدود واضحة للنمطية؛
- نشر مستقل
- حرية اختيار التقنيات.
لقد تحدثت كثيرًا مع مهندسي البرمجيات ومطوريها وسألتهم عن سبب حاجتهم إلى الخدمات المصغرة. وقمت بإعداد قائمة توقعاتهم. وهنا ما حدث:
فإذا وصفنا بعض النقاط "في الأحاسيس" فإن:
- حدود واضحة للوحدات النمطية: هنا لدينا متراصة رهيبة، والآن سيتم ترتيب كل شيء بدقة في مستودعات Git، حيث يكون كل شيء "على الرفوف"، ولا يتم خلط الدافئة والناعمة؛
- استقلالية النشر: سنكون قادرين على طرح الخدمات بشكل مستقل بحيث يسير التطوير بشكل أسرع (نشر ميزات جديدة بالتوازي)؛
- استقلالية التطوير: يمكننا تقديم هذه الخدمة الصغيرة إلى فريق/مطور واحد، وتلك إلى فريق آخر، وبفضل ذلك يمكننا التطوير بشكل أسرع؛
- боموثوقية أكبر: في حالة حدوث تدهور جزئي (سقوط خدمة صغيرة واحدة من أصل 20)، سيتوقف زر واحد فقط عن العمل، وسيستمر النظام ككل في العمل.
بنية الخدمات الصغيرة النموذجية (الضارة).
لشرح لماذا الواقع ليس هو ما نتوقعه، سأقدم جماعي صورة لبنية الخدمات الصغيرة بناءً على الخبرة من العديد من المشاريع المختلفة.
ومن الأمثلة على ذلك متجر تجريدي عبر الإنترنت سيتنافس مع Amazon أو على الأقل OZON. تبدو بنية الخدمات الصغيرة الخاصة بها كما يلي:
لمجموعة من الأسباب، تتم كتابة هذه الخدمات الصغيرة على منصات مختلفة:
نظرًا لأن كل خدمة صغيرة يجب أن تتمتع بالاستقلالية، فإن الكثير منها يحتاج إلى قاعدة بيانات وذاكرة تخزين مؤقت خاصة بها. البنية النهائية هي كما يلي:
ما هي عواقبه؟
لدى فاولر هذا أيضًا - حول "الدفع" مقابل استخدام الخدمات الصغيرة:
وسنرى ما إذا كانت توقعاتنا قد تحققت.
حدود واضحة للوحدات...
لكن ما هو عدد الخدمات الصغيرة التي نحتاج بالفعل إلى إصلاحها؟لطرح التغيير؟ هل يمكننا حتى معرفة كيف يعمل كل شيء دون تتبع موزع (بعد كل شيء، تتم معالجة أي طلب بواسطة نصف الخدمات الصغيرة)؟
هناك نمط ""، وهنا اتضح أنها كتلة من التراب موزعة. لتأكيد ذلك، إليك توضيح تقريبي لكيفية سير الطلبات:
استقلالية الانتشار...
لقد تم تحقيق ذلك من الناحية الفنية: يمكننا طرح كل خدمة صغيرة على حدة. ولكن في الممارسة العملية عليك أن تأخذ في الاعتبار أنه يتم طرحه دائمًا العديد من الخدمات الصغيرة، وعلينا أن نأخذ في الاعتبار ترتيب طرحها. بطريقة جيدة، نحتاج عمومًا إلى اختبار ما إذا كنا نقوم بطرح الإصدار بالترتيب الصحيح في دائرة منفصلة.
حرية اختيار التكنولوجيا...
هي تكون. فقط تذكر أن الحرية غالبًا ما تحد من الخروج على القانون. من المهم جدًا هنا عدم اختيار التقنيات لمجرد "اللعب" بها.
استقلالية التنمية..
كيفية عمل حلقة اختبار للتطبيق بأكمله (مع العديد من المكونات)؟ ولكن لا تزال بحاجة إلى تحديثه باستمرار. كل هذا يؤدي إلى حقيقة ذلك العدد الفعلي لدوائر الاختباروالتي يمكننا من حيث المبدأ احتوائها، تبين أنه ضئيل.
ماذا عن نشر كل هذا محلياً؟.. يتبين أنه في كثير من الأحيان يقوم المطور بعمله بشكل مستقل، ولكن “عشوائياً”، لأنه يضطر إلى الانتظار حتى تصبح الدائرة مجانية للاختبار.
تحجيم منفصل...
نعم، ولكنه محدود في مجال نظام إدارة قواعد البيانات (DBMS) المستخدم. في مثال البنية الموضح، لن تواجه Cassandra مشكلات، لكن MySQL وPostgreSQL ستواجهانها.
Боموثوقية أكبر...
لا يؤدي فشل إحدى الخدمات الصغيرة في الواقع إلى تعطيل الأداء الصحيح للنظام بأكمله فحسب، بل هناك أيضًا مشكلة جديدة: إن جعل كل خدمة صغيرة متسامحة مع الأخطاء أمر صعب للغاية. نظرًا لأن الخدمات الصغيرة تستخدم تقنيات مختلفة (memcache، وRedis، وما إلى ذلك)، لكل منها تحتاج إلى التفكير في كل شيء وتنفيذه، وهو أمر ممكن بالطبع، ولكنه يتطلب موارد ضخمة.
إمكانية قياس الأحمال...
هذا جيدا حقا.
"خفة" الخدمات الصغيرة...
ليس لدينا فقط ضخمة النفقات العامة للشبكة (تتضاعف طلبات DNS، وما إلى ذلك)، ولكن أيضًا بسبب الاستعلامات الفرعية العديدة التي بدأناها تكرار البيانات (مخابئ التخزين)، مما أدى إلى قدر كبير من التخزين.
وهذه هي نتيجة تلبية توقعاتنا:
لكن هذا ليس كل شيء!
لأن:
- على الأرجح سنحتاج إلى حافلة الرسائل.
- كيفية عمل نسخة احتياطية متسقة في الوقت المناسب؟ الوحيد حقيقي الخيار هو إيقاف حركة المرور لهذا الغرض. ولكن كيف نفعل هذا في الإنتاج؟
- إذا كنا نتحدث عن دعم العديد من المناطق، فإن تنظيم الاستدامة في كل منها مهمة كثيفة العمالة للغاية.
- تنشأ مشكلة إجراء تغييرات مركزية. على سبيل المثال، إذا أردنا تحديث إصدار PHP، فسنحتاج إلى الالتزام بكل مستودع (وهناك العشرات منهم).
- النمو في التعقيد التشغيلي هو، بشكل مرتجل، أسي.
ماذا تفعل مع كل هذا؟
ابدأ بتطبيق متجانس. تجربة فاولر أن جميع تطبيقات الخدمات الصغيرة الناجحة تقريبًا بدأت كوحدة متراصة أصبحت كبيرة جدًا ثم تم كسرها. في الوقت نفسه، تقريبًا جميع الأنظمة التي تم إنشاؤها كخدمات صغيرة منذ البداية واجهت مشكلات خطيرة عاجلاً أم آجلاً.
فكرة أخرى قيمة هي أنه لكي ينجح مشروع ذو بنية خدمات صغيرة، يجب أن تعرف جيدًا ومجال الموضوع وكيفية عمل الخدمات المصغرة. وأفضل طريقة لتعلم مجال الموضوع هي إنشاء وحدة متراصة.
ولكن ماذا لو كنا بالفعل في هذا الوضع؟
الخطوة الأولى لحل أي مشكلة هي الاتفاق معها وفهم أنها مشكلة، ولا نريد أن نعاني منها بعد الآن.
إذا قمنا، في حالة وجود كتلة متراصة متضخمة (عندما نفدت لدينا فرصة شراء موارد إضافية لها)، بقطعها، ففي هذه الحالة تظهر القصة المعاكسة: عندما لا تساعد الخدمات الصغيرة المفرطة، ولكنها تعيق - قطع الزائدة والتكبير!
على سبيل المثال، بالنسبة للصورة الجماعية التي تمت مناقشتها أعلاه...
تخلص من الخدمات الصغيرة الأكثر إثارة للشكوك:
الجمع بين جميع الخدمات الصغيرة المسؤولة عن إنشاء الواجهة الأمامية:
... في خدمة صغيرة واحدة، مكتوبة بلغة/إطار عمل واحد (حديث وطبيعي، كما تعتقد بنفسك):
سيحتوي على ORM واحد (DBMS واحد) وأول تطبيقين:
... ولكن بشكل عام يمكنك نقل المزيد هناك والحصول على النتيجة التالية:
علاوة على ذلك، في Kubernetes نقوم بتشغيل كل هذا في حالات منفصلة، مما يعني أنه لا يزال بإمكاننا قياس الحمل وتوسيع نطاقه بشكل منفصل.
يلخص
ننظر إلى الصورة الأكبر. في كثير من الأحيان، تنشأ كل هذه المشاكل المتعلقة بالخدمات الصغيرة لأن شخصًا ما تولى مهمته، ولكنه أراد "اللعب بالخدمات الصغيرة".
في كلمة "الخدمات الصغيرة" الجزء "الصغير" زائد عن الحاجة.. إنها "صغيرة" فقط لأنها أصغر من كتلة ضخمة. لكن لا تفكر فيهم كشيء صغير.
ولفكرة أخيرة، دعونا نعود إلى المخطط الأصلي:
مذكرة مكتوبة عليه (اعلى اليمين) يتلخص في حقيقة ذلك مهارات الفريق الذي يصنع مشروعك هي دائمًا مهارات أساسية - سوف يلعبون دورًا رئيسيًا في اختيارك بين الخدمات الصغيرة والمتراصة. إذا لم يكن لدى الفريق المهارات الكافية، لكنه بدأ في تقديم الخدمات المصغرة، فستكون القصة قاتلة بالتأكيد.
مقاطع الفيديو والشرائح
فيديو من الخطاب (حوالي 50 دقيقة؛ لسوء الحظ، لا ينقل المشاعر العديدة للزوار، والتي حددت إلى حد كبير مزاج التقرير، ولكن هذا هو الحال):
عرض التقرير:
PS
تقارير أخرى على مدونتنا:
- «» (ديمتري ستولياروف ؛ 28 مايو 2018 في RootConf);
- «» (ديمتري ستولياروف ؛ 7 نوفمبر 2017 على HighLoad ++);
- «» (ديمتري ستولياروف ؛ 6 يونيو 2017 في RootConf);
- «» (ديمتري ستولياروف ؛ 8 نوفمبر 2016 على HighLoad ++);
- «» (ديمتري ستولياروف ؛ 31 مايو 2016 في RootConf).
قد تكون مهتمًا أيضًا بالمنشورات التالية:
- «"؛
- «"؛
- «".
المصدر: www.habr.com