ملاحظة perev. : أصبحت شبكات الخدمة بالتأكيد حلاً مناسبًا في البنية التحتية الحديثة للتطبيقات التي تتبع بنية الخدمة الصغيرة. على الرغم من أن Istio قد يسمعها العديد من مهندسي DevOps ، إلا أنه منتج جديد إلى حد ما ، والذي قد يكون شاملاً فيما يتعلق بالميزات المقدمة ، مما يتطلب وقتًا كبيرًا للتعرف على بعضهم البعض. قام المهندس الألماني رينور مالوكو ، المسؤول عن الحوسبة السحابية للعملاء الكبار في شركة الاتصالات السلكية واللاسلكية Orange Networks ، بكتابة سلسلة رائعة من المواد التي تتيح لك الغوص بسرعة وبعمق في Istio. يبدأ قصته بما يمكن أن يفعله Istio وكيف يمكنك رؤيته بسرعة بأم عينيك.Istio هو مشروع مفتوح المصدر تم تطويره بالتعاون مع فرق من Google و IBM و Lyft. إنه يحل الصعوبات التي تنشأ في التطبيقات القائمة على خدمات microservices ، على سبيل المثال ، مثل:
- إدارة المرور : المهلات ، إعادة المحاولة ، موازنة التحميل ؛
- الأمن : المصادقة والترخيص للمستخدم النهائي ؛
- الملاحظة : التتبع ، والرصد ، وقطع الأشجار.
يمكن حلها جميعًا على مستوى التطبيق ، ولكن بعد ذلك ستتوقف خدماتك عن أن تكون "صغيرة". جميع الجهود الإضافية لحل هذه المشاكل هي مضيعة إضافية لموارد الشركة التي يمكن استخدامها مباشرة لقيم العمل. النظر في مثال:
مدير المشروع: كم من الوقت لإضافة ملاحظات؟
المطور: اثنين من سباقات السرعة.
النائب: ماذا؟
R: جعل CRUD جزءًا بسيطًا من المهمة ، لكن ما زلنا بحاجة إلى مصادقة المستخدمين والخدمات وتفويضهم. نظرًا لأن الشبكة غير موثوق بها ، ستحتاج إلى تنفيذ الطلبات المتكررة ، وكذلك نمط قاطع الدائرة في العملاء. ومع ذلك ، للتأكد من عدم سقوط النظام بالكامل ، ستحتاج إلى مهلات وحواجز (لمزيد من التفاصيل حول كلا النموذجين المذكورين ، انظر المزيد في المقالة - الترجمة تقريبًا.) ، ومن أجل اكتشاف المشكلات والمراقبة والتتبع و [...]
النائب: أوه ، فلنقم فقط بإدخال هذه الميزة في خدمة المنتج.
أعتقد أن الفكرة واضحة: حجم الخطوات والجهود المطلوبة لإضافة خدمة واحدة ضخم. في هذه المقالة ، سنبحث في كيفية إزالة Istio لجميع الصعوبات المذكورة أعلاه (والتي لا تستهدف منطق الأعمال) من الخدمات.
ملاحظة : تفترض هذه المقالة أن لديك معرفة عملية عن Kubernetes. خلاف ذلك ، أوصي بقراءة
المقدمة الخاصة بي إلى Kubernetes وفقط بعد ذلك استمر في قراءة هذه المادة.
فكرة إستيو
في عالم خالٍ من Istio ، تقدم إحدى الخدمات طلبات مباشرة إلى أخرى ، وفي حالة حدوث عطل ، يجب أن تعالج الخدمة نفسها: إجراء محاولة جديدة ، وتوفير مهلة ، وفتح قاطع دارة ، إلخ.
شبكة المرور في Kubernetesيقدم Istio أيضًا حلاً متخصصًا ، منفصل تمامًا عن الخدمات ويعمل عن طريق التدخل في تفاعل الشبكة. وهكذا ينفذ:
- التسامح مع الخطأ : بناءً على رمز الحالة في الاستجابة ، فإنه يفهم ما إذا كان الطلب قد فشل ، وتشغيله مرة أخرى.
- نشرات الكناري : تعيد التوجيه إلى الإصدار الجديد من الخدمة فقط نسبة مئوية ثابتة من عدد الطلبات.
- المراقبة والمقاييس : كم من الوقت استجابت الخدمة؟
- التتبع والملاحظة : إضافة رؤوس خاصة لكل طلب وتتبعها في الكتلة.
- الأمان : يستخرج الرمز المميز JWT ويصادق ويصرح للمستخدمين.
هذه مجرد بعض الاحتمالات (حقا ، فقط بعض!) لإثارة اهتمامك. الآن دعنا نتعمق في التفاصيل الفنية!
هندسة معمارية
يعترض Istio كل حركة مرور الشبكة ويطبق مجموعة من القواعد عليها ، مع إدخال وكيل ذكي في كل حافظة في شكل حاوية جانبية. تشكل الوكلاء الذين يقومون بتنشيط جميع الميزات "
طائرة بيانات" ، ويمكن تهيئتها ديناميكيًا باستخدام
"طائرة التحكم" .
طائرة البيانات
تسمح الوكلاء المدرجون في السنفات لـ Istio بالوفاء بسهولة بالمتطلبات التي نحتاجها. على سبيل المثال ، تحقق من وظائف إعادة المحاولة وقاطع الدائرة.
كيف يتم تنفيذ المحاولات وكسر الدارات في برنامج Envoyلتلخيص:
- Envoy (يتحدث عن وكيل موجود في حاوية جانبية يتم توزيعه كمنتج منفصل - الترجمة تقريبًا.) يرسل طلبًا إلى المثيل الأول من الخدمة B ويحدث فشل.
- المبعوث Sidecar إعادة المحاولة . (1)
- يتم إرجاع الطلب الفاشل إلى الوكيل الذي يطلق عليه.
- هذا يفتح Circuit Breaker ويستدعي الخدمة التالية للطلبات اللاحقة. (2)
هذا يعني أنك لست مضطرًا إلى استخدام مكتبة إعادة المحاولة التالية ، وليس عليك القيام بالتطبيق الخاص بك لكسر الدارة واكتشاف الخدمة بلغة البرمجة X أو Y أو Z. كل هذا وأكثر من ذلك بكثير متاح خارج الصندوق في Istio ولا يتطلب
أي تغييرات على الكود.
عظيم! الآن قد ترغب في الذهاب في رحلة مع Istio ، ولكن لا تزال هناك بعض الشكوك ، أسئلة مفتوحة. إذا كان هذا حلاً عالميًا لجميع المناسبات في الحياة ، فعندئذ يكون لديك شكوك مشروعة: في النهاية ، كل هذه القرارات في الواقع لا تتناسب مع أي مناسبة.
وأخيرا ، أنت تسأل: "هل قابلة للتخصيص؟"
أنت الآن جاهز لرحلة بحرية - ودعونا نتعرف على طائرة التحكم.
طائرة التحكم
وهو يتألف من ثلاثة مكونات:
Pilot و
Mixer و
Citadel ، والتي تعمل معًا لتهيئة Envoys لتوجيه حركة المرور وتطبيق السياسات وجمع بيانات القياس عن بُعد. بشكل تخطيطي ، يبدو كل هذا كما يلي:
تفاعل طائرة التحكم مع طائرة البياناتيتم تكوين المبعوثين (أي ، مستوى البيانات) باستخدام
Kubernetes CRD (تعريفات الموارد المخصصة) المعرّفة من قِبل Istio ومصممة خصيصًا لهذا الغرض. بالنسبة لك ، هذا يعني أنه يبدو أنها المورد التالي في Kubernetes مع بناء جملة مألوف. بعد الإنشاء ، سيتم التقاط هذا المورد بواسطة طائرة التحكم وتطبيقه على المبعوثين.
نسبة خدمة Istio
وصفنا موقف Istio تجاه الخدمات ، ولكن ليس العكس: كيف ترتبط الخدمات بـ Istio؟
بصراحة ، يعرف استيو عن وجود الخدمات وكذلك الأسماك - عن الماء عندما يسألون أنفسهم: "ما هي المياه بشكل عام؟".
توضيح من فيكتوريا ديميراكوبولوس : - كيف تحب الماء؟ - ما هو الماء بشكل عام؟وبالتالي ، يمكنك أن تأخذ مجموعة العمل وبعد نشر مكونات Istio ، ستستمر الخدمات الموجودة فيه في العمل ، وبعد إزالة هذه المكونات ، سيكون كل شيء على ما يرام. من الواضح أنك بذلك ستفقد الفرص التي توفرها Istio.
نظرية كافية - دعونا نضع هذه المعرفة موضع التنفيذ!
Istio في الممارسة العملية
يتطلب Istio مجموعة Kubernetes التي تتوفر فيها 4 وحدات معالجة فردية على الأقل و 8 جيجابايت من ذاكرة الوصول العشوائي. لرفع الكتلة بسرعة واتباع الإرشادات الواردة في المقالة ، أوصي باستخدام Google Cloud Platform ، التي تقدم للمستخدمين الجدد
300 دولار مجانًا .
بعد إنشاء كتلة وتكوين الوصول إلى Kubernetes من خلال الأداة المساعدة لوحدة التحكم ، يمكنك تثبيت Istio من خلال مدير حزمة Helm.
هيلم التثبيت
تثبيت عميل Helm على جهاز الكمبيوتر الخاص بك ، كما يقولون في
الوثائق الرسمية . سوف نستخدمها لإنشاء قوالب لتثبيت Istio في القسم التالي.
تثبيت Istio
قم بتنزيل موارد Istio من
أحدث إصدار (يتم تغيير رابط المؤلف الأصلي إلى الإصدار 1.0.5 إلى الإصدار الحالي ، أي 1.0.6 - تقريبا. ترجمة.) ، قم باستخراج المحتويات إلى دليل واحد ، والذي سأتصل به في المستقبل
[istio-resources] .
لسهولة تحديد موارد Istio ، قم بإنشاء مساحة اسم
istio-system istio في مجموعة K8s:
$ kubectl create namespace istio-system
أكمل التثبيت
[istio-resources] إلى الدليل
[istio-resources] وتشغيل الأمر:
$ helm template install/kubernetes/helm/istio \ --set global.mtls.enabled=false \ --set tracing.enabled=true \ --set kiali.enabled=true \ --set grafana.enabled=true \ --namespace istio-system > istio.yaml
سيقوم هذا الأمر بإخراج المكونات الرئيسية لـ Istio إلى ملف
istio.yaml . قمنا بتغيير القالب القياسي لأنفسنا ، مع تحديد المعلمات التالية:
global.mtls.enabled ضبط global.mtls.enabled على false (بمعنى أن مصادقة mTLS معطلة - الترجمة تقريبًا) لتبسيط عملية المواعدة ؛- يتيح
tracing.enabled تتبع الاستعلام باستخدام Jaeger؛ - يقوم
kiali.enabled بتثبيت Kiali في كتلة لتصور الخدمات وحركة المرور ؛ grafana.enabled بتعيين Grafana لتصور المقاييس التي تم جمعها.
نحن نطبق الموارد التي تم إنشاؤها باستخدام الأمر:
$ kubectl apply -f istio.yaml
اكتمال تثبيت Istio في الكتلة! انتظر حتى يتم
Running جميع
istio-system مساحة اسم
istio-system طريق تشغيل الأمر التالي:
$ kubectl get pods -n istio-system
نحن الآن على استعداد للمتابعة في القسم التالي ، حيث سنقوم برفع التطبيق وتشغيله.
تطبيق تحليل المعنويات
دعنا نأخذ مثالاً على تحليل المشاعر لتطبيق microservice المستخدم في
مقالة مقدمة سبق ذكرها
في Kubernetes . أنها معقدة بما يكفي لإظهار قدرات Istio في الممارسة العملية.
يتكون التطبيق من أربعة خدمات ميكروية:
- خدمة SA-Frontend ، التي تقدم تطبيقات الواجهة الأمامية على Reactjs ؛
- خدمة SA-WebApp التي تخدم طلبات تحليل المشاعر ؛
- خدمة SA- المنطق ، الذي يؤدي التحليل العاطفي ؛
- خدمة SA-Feedback ، التي تتلقى تعليقات من المستخدمين حول دقة التحليل.
في هذا المخطط ، بالإضافة إلى الخدمات ، نرى أيضًا مراقب الدخول ، والذي يقوم في Kubernetes بتوجيه الطلبات الواردة إلى الخدمات المقابلة. يستخدم Istio مفهومًا مشابهًا داخل بوابة الدخول ، ستتبعه تفاصيله.
بدء تطبيق مع وكيل من Istio
لمزيد من العمليات المذكورة في المقال ، استنساخ مستودع
إتقان إتقان . أنه يحتوي على التطبيق والعروض ل Kubernetes و Istio.
إدراج Sidecar
الإدراج يمكن أن يتم
تلقائيا أو
يدويا . لإدراج حاويات جانبية تلقائيًا ، يلزمك تعيين
istio-injection=enabled التسمية
istio-injection=enabled على
istio-injection=enabled ، والتي تتم بواسطة الأمر التالي:
$ kubectl label namespace default istio-injection=enabled namespace/default labeled
الآن سوف تتلقى كل جراب الذي سيتم نشره في مساحة الاسم الافتراضية الحاوية الجانبية الخاصة به. للتحقق من ذلك ، لنقم بتثبيت تطبيق اختبار عن طريق الانتقال إلى الدليل الجذر
[istio-mastery] وتشغيل الأمر التالي:
$ kubectl apply -f resource-manifests/kube persistentvolumeclaim/sqlite-pvc created deployment.extensions/sa-feedback created service/sa-feedback created deployment.extensions/sa-frontend created service/sa-frontend created deployment.extensions/sa-logic created service/sa-logic created deployment.extensions/sa-web-app created service/sa-web-app created
بعد توسيع الخدمات ، سوف نتحقق من أن القرون تحتوي على حاويتين (مع الخدمة نفسها
kubectl get pods لها) ، من خلال تنفيذ الأمر
kubectl get pods والتأكد من أن القيمة
2/2 موضحة تحت عمود
READY ، مما يرمز إلى تشغيل كلتا الحاويتين:
$ kubectl get pods NAME READY STATUS RESTARTS AGE sa-feedback-55f5dc4d9c-c9wfv 2/2 Running 0 12m sa-frontend-558f8986-hhkj9 2/2 Running 0 12m sa-logic-568498cb4d-2sjwj 2/2 Running 0 12m sa-logic-568498cb4d-p4f8c 2/2 Running 0 12m sa-web-app-599cf47c7c-s7cvd 2/2 Running 0 12m
بصريا يبدو مثل هذا:
مبعوث الوكلاء في واحدة من القرونالآن وبعد تشغيل التطبيق ، نحتاج إلى السماح لحركة المرور الواردة بالدخول إلى التطبيق.
بوابة الدخول
أفضل ممارسة لتحقيق ذلك (للسماح بحركة المرور في الكتلة) هي من خلال
Ingress Gateway في Istio ، والذي يقع عند "حدود" الكتلة ويسمح لك بتمكين ميزات Istio مثل التوجيه وموازنة التحميل والأمن ومراقبة حركة المرور الواردة.
تم تثبيت مكون Ingress Gateway والخدمة التي تقوم بإعادة توجيهها إلى الخارج في الكتلة أثناء تثبيت Istio. لمعرفة عنوان IP الخارجي للخدمة ، قم بما يلي:
$ kubectl get svc -n istio-system -l istio=ingressgateway NAME TYPE CLUSTER-IP EXTERNAL-IP istio-ingressgateway LoadBalancer 10.0.132.127 13.93.30.120
سنستمر في الوصول إلى التطبيق عبر عنوان IP هذا (سأشير إليه باسم EXTERNAL-IP) ، لذلك من أجل الراحة سنكتب القيمة في متغير:
$ EXTERNAL_IP=$(kubectl get svc -n istio-system \ -l app=istio-ingressgateway \ -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')
إذا حاولت الوصول إلى عنوان IP هذا من خلال متصفح الآن ، فستتلقى خطأ خدمة غير متوفر ، لأن
بشكل افتراضي ، يقوم Istio بحظر كل حركة المرور الواردة حتى يتم تعريف Gateway.
بوابة الموارد
Gateway عبارة عن CRD (تعريف مورد مخصص) في Kubernetes ، تم تعريفه بعد تثبيت Istio في كتلة وتنشيط القدرة على تحديد المنافذ والبروتوكول والمضيفات التي نريد السماح لحركة المرور الواردة بها.
في حالتنا ، نريد السماح لحركة مرور HTTP إلى المنفذ 80 لجميع المضيفين. يتم تنفيذ المهمة من خلال التعريف التالي
( http-gateway.yaml ) :
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: http-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"
لا يحتاج هذا التكوين إلى تفسير باستثناء
istio: ingressgateway . باستخدام هذا المحدد ، يمكننا الإشارة إلى أي بوابة دخول يتم تطبيق التكوين عليها. في حالتنا ، هذه هي وحدة التحكم في بوابة الدخول ، والتي تم تثبيتها افتراضيًا في Istio.
يتم تطبيق التكوين عن طريق استدعاء الأمر التالي:
$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created
تتيح البوابة الآن الوصول إلى المنفذ 80 ، ولكن ليس لديها فكرة عن مكان توجيه الطلبات. هذا سيتطلب
خدمات افتراضية .
VirtualService الموارد
يخبر VirtualService Ingress Gateway كيفية توجيه الطلبات المسموح بها داخل الكتلة.
يجب إرسال الطلبات إلى طلبنا التي تأتي عبر بوابة http إلى خدمات sa-frontend و sa-web-app و sa-feedback:
طرق لتكوين مع VirtualServicesالنظر في الطلبات التي ينبغي إرسالها إلى SA-Frontend:
- يجب إرسال مطابقة تامة على المسار
/ المسار إلى SA-Frontend للحصول على index.html؛ - يجب إرسال المسارات التي تسبق
/static/* إلى SA-Frontend لاستلام الملفات الثابتة المستخدمة في الواجهة الأمامية ، مثل CSS و JavaScript ؛ - يجب إرسال المسارات التي تندرج تحت التعبير العادي
'^.*\.(ico|png|jpg)$' إلى SA-Frontend ، لأن هذه هي الصور المعروضة على الصفحة.
يتحقق التنفيذ من خلال التكوين التالي
( sa-virtualservice-external.yaml ): kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: / - uri: exact: /callback - uri: prefix: /static - uri: regex: '^.*\.(ico|png|jpg)$' route: - destination: host: sa-frontend # 2 port: number: 80
نقاط مهمة:
- تشير VirtualService إلى الطلبات الواردة عبر http-gateway ؛
- تحدد
destination الخدمة التي يتم إرسال الطلبات إليها.
ملاحظة : يتم تخزين التكوين أعلاه في ملف
sa-virtualservice-external.yaml ، والذي يحتوي أيضًا على إعدادات التوجيه في SA-WebApp و SA-Feedback ، ولكن تم اختصاره هنا في المقالة للإيجاز.
تطبيق VirtualService عن طريق الاتصال:
$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created
ملاحظة : عندما نستخدم موارد Istio ، فإن خادم Kubernetes API Server يثير حدثًا يتلقى Istio Control Plane ، وبعد ذلك يتم تطبيق التكوين الجديد على وكلاء Envoy لكل جراب. ويبدو أن وحدة التحكم في مدخل البوابة هي المبعوث التالي الذي تم تكوينه في طائرة التحكم. كل هذا على الرسم البياني يشبه هذا:
تكوين Istio-IngressGateway لتوجيه الاستعلامأصبح تحليل المعنويات متاحًا على
http://{EXTERNAL-IP}/ . لا تقلق إذا حصلت على حالة "لم يتم العثور على": في
بعض الأحيان ، يستغرق الأمر وقتًا طويلاً حتى يتم تفعيل التكوين وتحديث ذاكرة التخزين المؤقت لـ Envoy .
قبل المتابعة ، اعمل قليلاً مع التطبيق لإنشاء حركة مرور
(وجوده ضروري للوضوح في الخطوات التالية - الترجمة تقريبًا) .
كيالي: الملاحظة
للوصول إلى واجهة Kiali الإدارية ، قم بتشغيل الأمر التالي:
$ kubectl port-forward \ $(kubectl get pod -n istio-system -l app=kiali \ -o jsonpath='{.items[0].metadata.name}') \ -n istio-system 20001
... وفتح
http: // localhost: 20001 / ، تسجيل الدخول كمشرف / مسؤول. ستجد هنا العديد من الميزات المفيدة ، على سبيل المثال ، للتحقق من تكوين مكونات Istio ، وتصور الخدمات استنادًا إلى المعلومات التي تم جمعها عند اعتراض طلبات الشبكة ، وتلقي الإجابات على الأسئلة "من يتصل بمن؟" ، "أي إصدار من الخدمة تعطل؟" الخ بشكل عام ، استكشف إمكانيات Kiali قبل الانتقال إلى تصور المقاييس باستخدام Grafana.
غرافانا: تصور المقاييس
تدخل المقاييس التي تم جمعها في Istio إلى Prometheus وتصورها مع Grafana. للدخول إلى واجهة مشرف Grafana ، قم بتشغيل الأمر أدناه ، ثم افتح
http: // localhost: 3000 / :
$ kubectl -n istio-system port-forward \ $(kubectl -n istio-system get pod -l app=grafana \ -o jsonpath={.items[0].metadata.name}) 3000
من خلال النقر على القائمة
الرئيسية في الجزء العلوي الأيسر واختيار
لوحة معلومات خدمة Istio في الركن الأيمن العلوي ، ابدأ
بخدمة sa-web-app للنظر إلى المقاييس التي تم جمعها:
نحن هنا في انتظار أداء فارغ وممل تمامًا - لن توافق الإدارة على ذلك مطلقًا. لنقم بإنشاء حمل صغير باستخدام الأمر التالي:
$ while true; do \ curl -i http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}'; \ sleep .8; done
الآن لدينا الكثير من الرسوم البيانية ، بالإضافة إلى أدوات بروميثيوس الرائعة للمراقبة و Grafana لتصور المقاييس ، مما سيتيح لنا التعرف على الأداء والحالة الصحية والتحسينات / تدهور الخدمات مع مرور الوقت.
أخيرًا ، دعنا ننظر إلى تتبع الطلبات في الخدمات.
جايجر: أثر
سنحتاج إلى البحث عن المفقودين ، لأنه كلما زاد عدد الخدمات التي نقدمها ، زاد صعوبة الوصول إلى سبب الفشل. دعنا ننظر إلى حالة بسيطة من الصورة أدناه:
مثال نموذجي لطلب فاشل عشوائييأتي الطلب ، يسقط -
ما هو السبب؟ الخدمة الأولى؟ أم الثاني؟ هناك استثناءات في كليهما - دعنا ننظر إلى سجلات كل منهما. كم مرة تجد نفسك تفعل هذا؟ عملنا يشبه محققو البرامج أكثر من المطورين ...
هذه مشكلة واسعة الانتشار في الخدمات الصغيرة ويتم حلها عن طريق أنظمة التتبع الموزعة التي تمر فيها الخدمات بعضها البعض برأس فريد ، وبعد ذلك يتم إعادة توجيه هذه المعلومات إلى نظام التتبع ، حيث يتم تعيينها إلى بيانات الطلب. هنا هو التوضيح:
لتحديد الطلب ، استخدم TraceIdيستخدم Istio Jaeger Tracer ، الذي ينفذ إطار عمل OpenTracing API مستقل عن البائع. يمكنك الوصول إلى واجهة مستخدم Jaeger باستخدام الأمر التالي:
$ kubectl port-forward -n istio-system \ $(kubectl get pod -n istio-system -l app=jaeger \ -o jsonpath='{.items[0].metadata.name}') 16686
انتقل الآن إلى
http: // localhost: 16686 / واختر خدمة
sa-web-app . إذا لم تظهر الخدمة في القائمة المنسدلة ، فقم بعرض / إنشاء نشاط على الصفحة وتحديث الواجهة. بعد ذلك ، انقر فوق الزر "
العثور على تتبعات" ، والذي سيُظهر أحدث تتبعات - حدد أي - ستظهر معلومات مفصلة عن جميع الآثار:
يظهر هذا التتبع:
- يأتي الطلب إلى istio-ingressgateway (هذا هو أول تفاعل مع إحدى الخدمات ، ويتم إنشاء معرف التتبع للطلب) ، وبعد ذلك ترسل البوابة الطلب إلى خدمة sa-web-app .
- في خدمة sa-web-app ، يتم استلام الطلب من قِبل Envoy sidecar ، ويتم إنشاء "تابع" في النطاق (وبالتالي نراه في التتبع) وإعادة توجيهه إلى حاوية sa-web-app . ( Span هي وحدة منطقية للعمل في Jaeger لها اسم ، والوقت الذي بدأت فيه العملية ومدتها. يمكن أن تمتد المسافات وترتيبها. رسم بياني موجه من spans يشكل تتبعًا. - تقريبًا - ترجمة.)
- هنا ، تتم معالجة الطلب من خلال أسلوب تحليل المشاعر . يتم إنشاء هذه الآثار بالفعل بواسطة التطبيق ، أي أنها تتطلب تغييرات على الرمز.
- من هذه اللحظة ، يتم بدء طلب POST لمنطق sa . يجب إعادة توجيه معرف التتبع من sa-web-app .
- ...
ملاحظة : في الخطوة 4 ، يجب أن يرى التطبيق الرؤوس التي تم إنشاؤها بواسطة Istio ونقلها إلى الطلبات اللاحقة ، كما هو موضح في الصورة أدناه:
(A) Istio هي المسؤولة عن إعادة توجيه الرؤوس ؛ (ب) الخدمات هي المسؤولة عن الرؤوس.Istio يفعل الجزء الأكبر من العمل ، كما يولد رؤوس للطلبات الواردة ، يخلق مسافات جديدة في كل جانب جانبي ويعيد توجيهها. ومع ذلك ، بدون العمل مع الرؤوس داخل الخدمات ، سيتم فقد مسار التتبع الكامل للطلب.
يجب اعتبار العناوين التالية (إعادة توجيه):
x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context
ومع ذلك ، فهذه مهمة بسيطة لتبسيط تنفيذها ، فهناك
العديد من المكتبات الموجودة بالفعل - على سبيل المثال ، في خدمة sa-web-app ، يقوم عميل RestTemplate بإعادة توجيه هذه الرؤوس إذا قمت ببساطة بإضافة مكتبات Jaeger و OpenTracing اعتمادًا
عليها .
لاحظ أن تطبيق تحليل الشعور يوضح التطبيقات على Flask و Spring و ASP.NET Core.والآن بعد أن أصبح من الواضح ما نحصل عليه من الصندوق (أو "خارج الصندوق" تقريبًا) ، سننظر في مسائل التوجيه الدقيق ، وإدارة حركة مرور الشبكة ، والأمن ، وما إلى ذلك!
ملاحظة perev. : اقرأ عن هذا في الإصدار التالي من Istio Rinor Maloku ، والذي سيكون متاحًا على مدونتنا في المستقبل القريب. استكمال (14 مارس): لقد تم بالفعل نشر الجزء الثاني .PS من المترجم
اقرأ أيضًا في مدونتنا: