ينص مبدأ عدم اليقين في Heisenberg على أنه من المستحيل قياس موضع الجسم وسرعته في وقت واحد. إذا تحرك كائن ، فلن يكون له موقع. وإذا كان الموقع ، فهذا يعني أنه ليس لديه سرعة.
بالنسبة إلى الخدمات المصغرة على منصة Red Hat OpenShift (وتشغيل Kubernetes) ، فبفضل البرنامج المفتوح المصدر المقابل ، يمكنهم الإبلاغ في الوقت نفسه عن أدائهم وصحتهم. بالطبع ، هذا لا يدحض Heisenberg القديم ، لكنه يلغي عدم اليقين عند العمل مع التطبيقات السحابية. يسهل Istio تنظيم التتبع (التتبع) ومراقبة هذه التطبيقات للحفاظ على كل شيء تحت السيطرة.
تحديد المصطلحات
من خلال
التتبع نعني نشاط نظام التسجيل. يبدو الأمر عامًا ، لكن في الواقع إحدى القواعد الرئيسية هنا هي تفريغ تتبع البيانات إلى وحدة التخزين المناسبة دون الحاجة إلى القلق بشأن تنسيقها. وكل عمل البحث عن البيانات وتحليلها يُعهد إلى المستهلكين. يستخدم Istio نظام التتبع Jaeger ، الذي ينفذ نموذج بيانات OpenTracing.
بالتتبعات (تتبعات ، وتستخدم كلمة "آثار" هنا في معنى "آثار" ، كما هو الحال ، على سبيل المثال ، في اختبار بالستية) ، سنعني البيانات التي تصف تمامًا مرور طلب أو وحدة عمل ، كما يقولون ، "من وإلى". على سبيل المثال ، كل ما يحدث من لحظة قيام المستخدم بالضغط على زر في صفحة ويب حتى يتم إرجاع البيانات ، بما في ذلك جميع الخدمات المصغرة المتضمنة في ذلك. يمكننا أن نقول أن تتبع واحد يصف بالكامل (أو يحاكي) مرور الطلب ذهابا وإيابا. في واجهة Jaeger ، تتحلل المسارات إلى مكونات على طول المحور الزمني ، مثل كيف يمكن تحليل السلسلة إلى روابط منفصلة. فقط بدلاً من الروابط يتكون المسار من ما يسمى بالمساحات.
Span هو الفاصل الزمني من بداية وحدة العمل وحتى اكتمالها. مواصلة القياس ، يمكننا أن نقول أن كل فترة هي حلقة منفصلة في السلسلة. قد تمتد فترة أو لا تحتوي على امتداد طفل واحد أو أكثر. نتيجة لذلك ، فإن فترة المستوى الأعلى (فترة الجذر) سيكون لها نفس المدة الإجمالية للتتبع الذي تنتمي إليه.
المراقبة هي في الواقع مراقبة نظامك - من خلال العيون ، من خلال واجهة مستخدم أو عن طريق الأتمتة. يعتمد الرصد على بيانات التتبع. في Istio ، يتم تطبيق المراقبة باستخدام أدوات Prometheus ولديه واجهة مستخدم مقابلة. يدعم بروميثيوس المراقبة التلقائية باستخدام تنبيهات التنبيهات ومديري التنبيهات.
اترك النكات
لكي يكون التتبع ممكنًا ، يجب أن ينشئ التطبيق مجموعة من النطاقات. ثم يجب تصديرها إلى Jaeger ، بحيث يقوم بدوره بإنشاء تمثيل مرئي للتتبع. من بين أشياء أخرى ، تشير هذه المسافات إلى اسم العملية ، وكذلك الطوابع الزمنية لبدايتها ونهايتها. يتم إرسال المسافات عبر إعادة توجيه رؤوس طلبات HTTP الخاصة بـ Jaeger من الطلبات الواردة إلى الطلبات الصادرة. اعتمادًا على لغة البرمجة المستخدمة ، قد يتطلب ذلك تعديلًا طفيفًا لرمز مصدر التطبيق. التالي مثال لرمز Java (عند استخدام Spring Boot Framework) الذي يضيف رؤوس B3 (Zipkin-style) إلى طلبك في فئة التكوين Spring:
يتم استخدام إعدادات الرأس التالية:
إذا كنت تستخدم Java ، فيمكنك ترك الكود بدون تغيير ، ما عليك سوى إضافة بضعة أسطر إلى ملف Maven POM وتعيين متغيرات البيئة. فيما يلي الأسطر التي تحتاج إلى إضافتها إلى ملف POM.XML لتطبيق Jaeger Tracer Resolver:
ويتم تعيين متغيرات البيئة المقابلة في Dockerfile:
هذا كل شيء ، الآن تم إعداده بالكامل ، وسوف تبدأ خدماتنا المصغرة في توليد بيانات التتبع.
نحن ننظر بشكل عام
يتضمن Istio لوحة تحكم بسيطة تعتمد على Grafana. عند تهيئة كل شيء وتشغيله على النظام الأساسي لـ Red Hat OpenShift PaaS (في مثالنا ، يتم نشر Red Hat OpenShift و Kubernetes في صورة مصغرة) ، يتم تشغيل هذه اللوحة باستخدام الأمر التالي:
open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"
تتيح لك لوحة Grafana تقييم النظام بسرعة. يظهر جزء من هذه اللوحة في الشكل أدناه:
هنا يمكنك أن ترى أن عميل microservice يستدعي تفضيل microservice v1 ، وهذا بدوره يدعو توصية microservices v1 و v2. تحتوي لوحة Grafana على كتلة صف Dashboard للمقاييس عالية المستوى ، مثل إجمالي عدد الطلبات (حجم الطلب العالمي) ، والنسبة المئوية للطلبات الناجحة (معدلات النجاح) ، وأخطاء 4xx. بالإضافة إلى ذلك ، هناك طريقة عرض شبكة Server مع رسوم بيانية لكل خدمة وكتلة صف الخدمات لعرض معلومات مفصلة لكل حاوية لكل خدمة.
الآن حفر أعمق
من خلال تتبع تمت تهيئته بشكل صحيح ، يتيح لك Istio ، كما يقولون ، على الفور الخروج من الصندوق إلى الخوض في تحليل أداء النظام. في Jaeger UI ، يمكنك عرض التتبعات ومعرفة مدى عمقها وعمقها ، بالإضافة إلى اختناقات الأداء المحلية. عند استخدام Red Hat OpenShift على النظام الأساسي المصغر ، قم بتشغيل Jaeger UI باستخدام الأمر التالي:
minishift openshift service jaeger-query --in-browser
ما يمكن قوله عن التتبع على هذه الشاشة:
- وهي مقسمة إلى 7 فترات.
- وقت التنفيذ الكلي هو 6.99 مللي ثانية.
- تأخذ توصية خدمة microservice ، وهي الأخيرة في السلسلة ، 0.69 مللي ثانية.
تتيح لك الرسوم البيانية من هذا النوع معرفة الموقف بسرعة حيث يعاني أداء النظام بأكمله بسبب خدمة واحدة تعمل بشكل سيء.
الآن لنقم بتعقيد المهمة وإطلاق مثيلين من خدمة microservice: v2 باستخدام مقياس oc - replicas = 2 نشر / توصية-v2. هنا القرون سيكون لدينا بعد هذا:
إذا عدنا الآن إلى Jaeger ونشرنا فترة خدمة التوصية ، فسنرى أي طلبات جراب يتم توجيهها إلى. وبالتالي ، يمكننا بسهولة توطين الفرامل على مستوى جراب معين. يجب أن تنظر إلى حقل node_id:
أين وكيف يذهب كل شيء
الآن نذهب إلى واجهة بروميثيوس ومن المتوقع تمامًا أن نرى هناك أن الطلبات بين الإصدارين الثاني والأول من خدمة التوصية مقسمة إلى نسبة 2: 1 ، بدقة بعدد قرون العمل. علاوة على ذلك ، فإن هذا الرسم البياني سيتغير ديناميكيًا عند توسيع نطاق القرون لأعلى ولأسفل ، مما سيكون مفيدًا بشكل خاص مع Canary Deployment (سنبحث في مخطط النشر هذا بمزيد من التفاصيل في المرة القادمة).
إنها البداية فقط
في الواقع ، اليوم ، كما يقولون ، لم نلمس إلا قليلاً مخزنًا للمعلومات المفيدة عن جايجر وغرافانا وبروميثيوس. بشكل عام ، كان هذا هو هدفنا - لإرشادك في الاتجاه الصحيح وفتح آفاق Istio.
وتذكر ، كل هذا مدمج بالفعل في Istio. عند استخدام لغات برمجة معينة (على سبيل المثال ، Java) والأطر (على سبيل المثال ، Spring Boot) ، يمكن تحقيق كل ذلك دون لمس رمز التطبيق نفسه تمامًا. نعم ، يجب تعديل الشفرة قليلاً إذا كنت تستخدم لغات أخرى ، في المقام الأول Nodejs أو C #. ولكن نظرًا لأن التتبع (اقرأ ، "التتبع") هو أحد المتطلبات الأساسية لإنشاء أنظمة سحابية موثوقة ، في أي حال ، سيكون عليك تحرير الرمز سواء كان لديك Istio أم لا. فلماذا لا تنفق الجهد أكثر ربحية؟
على الأقل من أجل الإجابة دائما على الأسئلة "أين؟" و "كيف سريع؟" مع اليقين 100 ٪.
الفوضى الهندسية في Istio: كان تصور
تساعد القدرة على كسر الأشياء على ضمان عدم كسرها
اختبار البرمجيات ليس فقط شيئًا معقدًا ، ولكنه شيء مهم أيضًا. في الوقت نفسه ، يعد اختبار الصحة (على سبيل المثال ، ما إذا كانت دالة تُرجع النتيجة الصحيحة) شيئًا واحدًا ، والاختبار في شبكة غير موثوق بها هو مهمة مختلفة تمامًا (يُعتقد غالبًا أن الشبكة تعمل دائمًا دون إخفاقات ، وهذه هي أول المفاهيم الخاطئة الثمانية المتعلقة بالتوزيع الحوسبة). تتمثل إحدى صعوبات حل هذه المشكلة في كيفية محاكاة حالات الفشل في النظام أو تقديمها عن قصد عن طريق إجراء ما يسمى بالحقن الخاطئ. يمكن القيام بذلك عن طريق تعديل التعليمات البرمجية المصدر للتطبيق نفسه. لكنك لن تختبر الكود الأصلي ، ولكن نسخته التي تحاكي على وجه التحديد الإخفاقات. ونتيجة لذلك ، فإنك تواجه خطر الدخول في احتضان مميت لحقن العيوب والتصادم مع أكياس الهيسن - وهي حالات فشل تختفي عند محاولة اكتشافها.
والآن سنبين كيف يساعد Istio في التغلب على هذه الصعوبات بواحدة.
كيف يبدو عندما يكون كل شيء على ما يرام
النظر في السيناريو التالي: لدينا اثنين من القرون لدينا توصية microservice ، والتي اتخذناها من البرنامج التعليمي Istio. يتم وضع علامة جراب واحد كـ v1 والآخر كـ v2. كما ترون ، في حين أن كل شيء يعمل بشكل جيد:
(بالمناسبة ، الرقم الموجود على اليمين هو مجرد عداد اتصال لكل جراب)
لكننا لسنا بحاجة إلى هذا ، أليس كذلك؟ حسنًا ، دعنا نحاول كسر كل شيء دون لمس الكود المصدري على الإطلاق.
نرتب انقطاع في عمل microservice
يوجد أدناه ملف yaml لقاعدة توجيه Istio ، والذي سيفشل في نصف الحالات (خطأ الخادم 503):
يرجى ملاحظة أننا نصف صراحة أنه في نصف الحالات ، يجب إعادة الخطأ 503.
وهنا لقطة من أمر curl الذي تم إطلاقه في الحلقة بعد تنشيط هذه القاعدة لمحاكاة حالات الفشل. كما ترون ، نصف الطلبات يُرجع الخطأ 503 ، وبغض النظر عن pod - v1 أو v2 - يذهبون إلى:
لاستعادة التشغيل العادي ، يكفي إزالة هذه القاعدة ، وفي حالتنا ، فإن الأمر istioctl delete routerule توصية -503 -n تعليمي. البرنامج التعليمي هنا هو اسم مشروع Red Hat OpenShift الذي يدير برنامج Istio التعليمي الخاص بنا.
جعل التأخير الاصطناعي
تساعد الأخطاء الصناعية 503 في اختبار النظام لتحمل الأعطال ، لكن القدرة على التنبؤ بالتأخيرات والتعامل معها يجب أن تثير إعجابك أكثر. والتأخير في الحياة الحقيقية يحدث في كثير من الأحيان من الفشل. الخدمة الميكروية البطيئة هي السم الذي يعاني منه النظام بأكمله. بفضل Istio ، يمكنك اختبار الكود المتعلق بتأخير المعالجة دون تغييرها على الإطلاق. للبدء ، سوف نوضح كيفية القيام بذلك في حالة حدوث تأخير في الشبكة مقدمة بشكل مصطنع.
يرجى ملاحظة أنه بعد هذا الاختبار ، قد تحتاج (أو تريد) إلى تحسين التعليمات البرمجية الخاصة بك. والخبر السار هو ، في هذه الحالة ، سوف تتصرف بشكل استباقي ، وليس بشكل تفاعلي. هذه هي الطريقة التي ينبغي بناء دورة التطوير: اختبار الترميز-ردود الفعل-الترميز-الاختبار ...
هذا ما تبدو عليه القاعدة ... على الرغم من أنك تعرف ماذا؟ Istio بسيط جدًا ، وملف yaml هذا واضح جدًا بحيث يتحدث كل شيء في هذا المثال عن نفسه ، فقط ألقِ نظرة:
في نصف الحالات ، سيكون لدينا تأخير لمدة 7 ثوان. وهذا لا ينطبق على الإطلاق كما لو أننا أدخلنا أمر السكون في الكود المصدري ، لأن Istio حقًا يؤخر الطلب لمدة 7 ثوانٍ. نظرًا لأن Istio يدعم تتبع Jaeger ، فإن هذا التأخير ممتاز في واجهة المستخدم المنحرفة لـ Jaeger ، كما هو موضح في لقطة الشاشة أدناه. انتبه إلى الطلب الطويل في الركن الأيمن العلوي من المخطط - مدته 7.02 ثانية:
يسمح لك هذا السيناريو باختبار الكود وفقًا لظروف اختفاء الشبكة. ومن الواضح أننا بإزالة هذه القاعدة ، سنقوم بإزالة التأخير المصطنع. نكرر ، ولكن مرة أخرى فعلنا كل هذا دون لمس الكود المصدر.
لا تتراجع ولا تستسلم
ميزة أخرى لـ Istio مفيدة لهندسة الفوضى هي المكالمات المتكررة للخدمة بعدد محدد من المرات. النقطة المهمة هنا هي عدم التوقف عن المحاولة عندما ينتهي الطلب الأول بالخطأ 503 - وربما ، وللمرة الحادية عشرة من الشهر الحالي ، نحن محظوظون. ربما تكمن الخدمة فقط لفترة قصيرة لسبب أو لآخر. نعم ، يجب اكتشاف هذا السبب والقضاء عليه. ولكن هذا هو ما حدث لاحقًا ، ولكن الآن دعونا نحاول جعل النظام يواصل العمل.
لذلك ، نريد أن تقدم الخدمة خطأ 503 من وقت لآخر ، وبعد ذلك سوف يحاول Istio الاتصال به مرة أخرى. وهنا نحتاج بوضوح إلى طريقة لإنشاء الخطأ 503 ، دون لمس الكود نفسه ...
توقف عن الانتظار! نحن فقط فعلنا ذلك.
هذا الملف سيجعل خدمة التوصية - v2 تولد خطأ 503 في نصف الحالة:
من الواضح أن جزءًا من الطلبات سيفشل:
والآن سنستخدم وظيفة إعادة المحاولة Istio:
تقوم قاعدة التوجيه هذه بثلاث محاولات مع فاصل ثانيتين ، ويجب أن تقلل (وتفضل إزالة كاملة من الرادار) أخطاء 503:
نلخصها: لقد توصلنا إليها حتى أن Istio ، أولاً ، أنشأ خطأ 503 لنصف الطلبات. وثانيا ، يقوم نفس Istio بإجراء ثلاث محاولات لإعادة الاتصال بالخدمة في حالة حدوث خطأ 503. ونتيجة لذلك ، يعمل كل شيء على ما يرام. وبالتالي ، باستخدام وظيفة إعادة المحاولة ، حققنا وعدنا بعدم التراجع وعدم الاستسلام.
ونعم ، لقد فعلنا ذلك مرة أخرى دون لمس الكود على الإطلاق. كل ما نحتاجه هو قاعدتي توجيه Istio:
كيف لا ندع المستخدم أسفل أو سبعة لا تنتظر
والآن نحول الموقف من الداخل إلى الخارج وننظر في السيناريو عندما لا تضطر إلى التراجع والاستسلام لبعض الوقت المحدد فقط. ثم تحتاج فقط إلى التوقف عن محاولة معالجة الطلب حتى لا تجبر الجميع على الانتظار لأي خدمة فرملة واحدة. بمعنى آخر ، لن نحمي الموقف المفقود ، لكننا سننتقل إلى خط الاحتياطي حتى لا نخذل المستخدم في الموقع ولا يجبره على أن يظل في جهل.
في Istio ، يمكنك تعيين مهلة الطلب. إذا تجاوزت الخدمة هذه المهلة ، فسيتم إرجاع الخطأ 504 (عبّارة العبّارة) - مرة أخرى ، كل ذلك يتم من خلال تكوين Istio. لكن سيتعين علينا إضافة أمر السكون إلى الكود المصدري للخدمة (ثم ، بالطبع ، تنفيذ إعادة الإنشاء وإعادة الانتشار) لمحاكاة التشغيل البطيء للخدمة. للأسف ، لن تعمل بطريقة أخرى.
لذلك ، أدخلنا فترة راحة لمدة ثلاث ثوانٍ في رمز خدمة التوصية v2 ، وأعدنا بناء الصورة المقابلة وأعدنا وضع حاوية ، والآن سنضيف مهلة باستخدام قاعدة توجيه Istio التالية:
توضح لقطة الشاشة أعلاه أننا نحاول الاتصال بخدمة التوصية إذا لم نتلق ردًا خلال ثانية واحدة ، أي قبل حدوث الخطأ 504. بعد تطبيق قاعدة التوجيه هذه (وإضافة فترة راحة مدتها ثلاث ثوانٍ إلى رمز خدمة التوصية : v2) ، نحصل على هذا:
نكرر مرة أخرى ، ولكن يمكن تعيين المهلة دون لمس الكود المصدر. ومن المزايا الإضافية هنا أنه يمكنك الآن تعديل الكود الخاص بك بحيث يستجيب لمهلة ، ومن السهل اختبار هذه التحسينات باستخدام Istio.
والآن كل ذلك معا
يعد إجراء فوضى صغيرة باستخدام Istio طريقة رائعة لاختبار الشفرة وموثوقية النظام ككل. ستكون أنماط الرجوع إلى الخلف والحاجز وكسر الدارة وآليات إنشاء حالات فشل وتأخير مصطنعين وأيضًا المكالمات المتكررة والمهلة الزمنية مفيدة للغاية عند إنشاء أنظمة سحابية تتحمل الأخطاء. إلى جانب Kubernetes و Red Hat OpenShift ، تساعدك هذه الأدوات على مواجهة المستقبل بثقة.