لقد انتهت العطلات ونعود مع نشرتنا الثانية في سلسلة Istio Service Mesh.
موضوع اليوم هو Circuit Breaker ، والذي يُترجم إلى الروسية على أنه كهربائي ، ويعني "قاطع الدائرة" ، بلغة مشتركة - "قاطع الدائرة". فقط في Istio يقوم هذا الجهاز بفصل الدوائر غير المختصرة أو المحملة ، ولكن الحاويات المعيبة.
كيف ينبغي أن تعمل بشكل مثالي
عندما تتم إدارة الخدمات الصغيرة بواسطة Kubernetes ، على سبيل المثال ، كجزء من منصة OpenShift ، فإنها تتزايد تلقائيًا للأعلى وللأسفل اعتمادًا على الحمل. نظرًا لأن الخدمات الصغيرة تعمل في القرون ، يمكن أن يكون هناك عدة حالات من الخدمات الميكروية في حاويات في نقطة نهاية واحدة ، وسوف تقوم Kubernetes بتوجيه الطلبات وتحقيق التوازن بين الحمل بينهما. و - من الناحية المثالية - كل هذا يجب أن يعمل بشكل مثالي.
نتذكر أن الخدمات الصغيرة صغيرة وسريعة الزوال. غالبًا ما يتم الاستخفاف بالزمن المؤقت ، الذي يعني هنا بساطة الظهور والاختفاء. ولادة ولادة الحالة التالية من microservice في جراب المتوقع تماما ، OpenShift و Kubernetes تفعل ذلك بشكل جيد ، وكل شيء يعمل بشكل جيد - ولكن مرة أخرى من الناحية النظرية.
كيف حقا العمل
الآن تخيل أن حالة معينة من الخدمة المجهرية ، أي الحاوية ، أصبحت غير صالحة للاستعمال: إما أنها لا تستجيب (الخطأ 503) أو ، وهو أمر غير سار ، يتفاعل ، ولكن ببطء شديد. بمعنى آخر ، يتم كتم الصوت أو عدم الاستجابة للطلبات ، لكنه لا يقوم تلقائيًا بإزالته من التجمع. ما يجب القيام به في هذه الحالة؟ حاول مرة أخرى؟ إزالته من مخطط التوجيه؟ وماذا يعني "بطيء جدًا" - كم هو بالأرقام ، ومن الذي يحددها؟ ربما فقط أعطه استراحة وحاول في وقت لاحق؟ إذا كان الأمر كذلك ، كم في وقت لاحق؟
ما هو تجمع الطرد في Istio
وهنا تأتي Istio إلى الإنقاذ من خلال قواطع الدائرة Circuit Breaker ، التي تزيل الحاويات المعيبة مؤقتًا من مجموعة موارد التوجيه وموازنة التحميل ، مع تنفيذ إجراء Pool Ejection.
باستخدام إستراتيجية كشف خارجية ، يقوم Istio باكتشاف منحنيات pod التي تم إخراجها من الصف العام وإزالتها من تجمع الموارد لفترة محددة ، تسمى "نافذة السكون".
لإظهار كيف يعمل هذا في Kubernetes على منصة OpenShift ، نبدأ بلقطة شاشة للخدمات الميكروية العاملة بشكل طبيعي من المثال في مستودع
Red Hat Developer Demos . هنا لدينا اثنين من القرون ، v1 و v2 ، في كل منها يعمل حاوية واحدة. عندما لا يتم استخدام قواعد التوجيه الخاصة بـ Istio ، فإن Kubernetes افتراضيًا يطبق توجيه دائن متوازن متوازن:
الاستعداد لحادث تحطم الطائرة
قبل القيام بتجميع القذف ، يجب عليك إنشاء قاعدة توجيه Istio. لنفترض أننا نريد توزيع الطلبات بين القرون فيما يتعلق بـ 50/50. بالإضافة إلى ذلك ، سنزيد عدد حاويات v2 من حاوية إلى حالتين ، مثل هذا:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
الآن نحدد قاعدة التوجيه بحيث يتم توزيع حركة المرور بين القرون بنسبة 50/50.
وهنا هي نتيجة هذه القاعدة:
من الممكن الشكوى من أن هذه الشاشة ليست 50/50 ، ولكن 14: 9 ، ولكن بمرور الوقت سيتحسن الموقف.
نرتب الفشل
والآن ، سنقوم بتعطيل إحدى حاويتي v2 بحيث يكون لدينا حاوية واحدة v1 وحاوية صحية v2 وحاوية واحدة فاشلة v2:
إصلاح الحادث
لذلك ، لدينا حاوية معيبة ، ولقد حان الوقت لقذف البركة. باستخدام تهيئة بسيطة للغاية ، سنستبعد هذه الحاوية الفاشلة من أي أنظمة توجيه لمدة 15 ثانية في توقع أن تعود إلى حالة صحية (إما ستتم إعادة التشغيل ، أو ستستعيد الأداء). إليك ما يبدو عليه هذا التكوين ونتائج عمله:
كما ترون ، لم تعد الحاوية الفاشلة v2 تُستخدم عند توجيه الطلبات ، حيث تمت إزالتها من التجمع. ولكن بعد 15 ثانية سيعود تلقائيًا إلى حمام السباحة. في الواقع ، لقد أظهرنا فقط كيف يعمل Pool Ejection.
البدء في بناء العمارة
يسمح لك Pool Ejection ، إلى جانب إمكانات المراقبة في Istio ، بالبدء في إنشاء إطار عمل لاستبدال الحاويات المعيبة تلقائيًا لتقليل أو حتى التوقف عن التعطل.
لدى ناسا شعار واحد رفيع المستوى - الفشل ليس خيارًا ، من تأليف مدير الطيران
جين كرانتز . يمكن ترجمتها إلى الروسية كـ "الهزيمة ليست خيارًا" ، والنقطة هنا هي أنه يمكن عمل كل شيء للعمل بإرادة كافية. ومع ذلك ، في الحياة الواقعية ، لا تحدث الإخفاقات فقط ، بل لا مفر منها ، في كل مكان وفي كل شيء. وكيف تتعامل معهم في حالة الخدمات المصغرة؟ في رأينا ، من الأفضل عدم الاعتماد على قوة الإرادة ، ولكن على قدرات الحاويات ، و
Kubernetes ، و
Red Hat OpenShift ، و
Istio .
كما كتبنا أعلاه ، تطبق Istio مفهوم قواطع الدوائر الكهربائية ، والتي أثبتت نفسها في العالم المادي. ومثلما يقوم الجهاز التلقائي بفصل جزء مشكلة في الدائرة ، يقوم البرنامج Circuit Breaker في Istio بقطع الاتصال بين تدفق الطلب وحاوية المشكلة عندما يكون هناك خطأ ما في نقطة النهاية ، على سبيل المثال ، عندما تعطل الخادم أو بدأ في التباطؤ.
علاوة على ذلك ، في الحالة الثانية ، هناك المزيد من المشكلات فقط ، لأن فرامل الحاوية الواحدة لا تتسبب فقط في سلسلة من التأخير في الخدمات التي تصل إليها ، ونتيجة لذلك ، تقلل من أداء النظام ككل ، ولكنها تسبب أيضًا طلبات متكررة لخدمة التشغيل البطيء بالفعل ، مما يؤدي إلى تفاقم الوضع فقط .
قواطع دوائر نظريا
Circuit Breaker عبارة عن وكيل يتحكم في تدفق الطلبات إلى نقطة النهاية. عندما تتوقف هذه النقطة عن العمل أو ، وفقًا للإعدادات ، تبدأ في التباطؤ ، ينقطع الوكيل عن الحاوية. ثم يتم إعادة توجيه حركة المرور إلى حاويات أخرى ، أيضًا ، لمجرد موازنة التحميل. يظل الاتصال مفتوحًا (مفتوحًا) لإطار نوم محدد ، على سبيل المثال ، دقيقتين ، ثم يعتبر نصف مفتوحًا (مفتوحًا لمدة نصف) تحدد محاولة إرسال الطلب التالي حالة الاتصال الإضافية. إذا كان كل شيء على ما يرام مع الخدمة ، يعود الاتصال إلى حالة التشغيل ويغلق مرة أخرى. في حالة استمرار وجود خطأ في الخدمة ، يتم فتح الاتصال وإعادة تمكين نافذة السكون. إليك ما يبدو عليه مخطط حالة Circuit Breaker المبسط:
من المهم أن نلاحظ هنا أن كل هذا يحدث على مستوى ، إذا جاز التعبير ، بنية النظام. لذلك ، سيتعين عليك في مرحلة ما تعليم تطبيقاتك العمل مع Circuit Breaker ، على سبيل المثال ، تقديم قيمة افتراضية استجابة أو ، إن أمكن ، تجاهل وجود الخدمة. يتم استخدام نمط الحاجز لهذا ، لكنه خارج نطاق هذه المقالة.
قواطع دوائر في الممارسة
على سبيل المثال ، سنطلق على OpenShift نسختين من خدماتنا microservice. ستعمل النسخة 1 بشكل جيد ، ولكن في الإصدار الثاني سنبني على تأخير لمحاكاة الفرامل على الخادم. لعرض النتائج ، استخدم أداة
الحصار :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
كل شيء يبدو للعمل ، ولكن بأي ثمن؟ للوهلة الأولى ، لدينا توفر بنسبة 100 ٪ ، ولكن نلقي نظرة فاحصة - الحد الأقصى لمدة المعاملة يصل إلى 12 ثانية. من الواضح أن هذا عنق الزجاجة ويحتاج إلى التطريز.
للقيام بذلك ، سوف نستخدم Istio للقضاء على الوصول إلى الحاويات البطيئة. إليك ما يشبه التكوين المقابل باستخدام Circuit Breaker:
يشير السطر الأخير مع المعلمة httpMaxRequestsPerConnection إلى أنه يجب فتح الاتصال عند محاولة إنشاء اتصال آخر - ثاني - بالإضافة إلى الاتصال الموجود. نظرًا لأن الحاوية الخاصة بنا تقلد خدمة الكبح ، فستحدث مثل هذه المواقف بشكل دوري ، ومن ثم سيعود Istio إلى الخطأ 503 ، وهنا سيظهر الحصار:
حسنًا ، لدينا Circuit Breaker ، ماذا بعد؟
لذلك ، قمنا بتنفيذ إيقاف تشغيل تلقائي ، دون لمس الكود المصدر للخدمات نفسها. باستخدام الإجراء Circuit Breaker وإجراء إخراج البركة الموضحة أعلاه ، يمكننا إزالة حاويات الفرامل من تجمع الموارد حتى تعود إلى وضعها الطبيعي ، والتحقق من حالتها على تردد معين - في مثالنا ، هذه دقيقتان (معلمة sleepWindow).
يرجى ملاحظة أن قدرة التطبيق على الاستجابة للخطأ 503 لا تزال مضبوطة على مستوى شفرة المصدر. هناك العديد من الاستراتيجيات للعمل مع Circuit Breaker ، والتي يتم تطبيقها حسب الموقف.
في المنشور
التالي: سنتحدث عن التتبع والمراقبة ، اللذين تم بالفعل تضمينهما بالفعل أو إضافته بسهولة إلى Istio ، بالإضافة إلى كيفية إدخال الأخطاء في النظام عن قصد.