حالات استخدام شبكة الخدمة

تقريبا. ترجمة. : مؤلف هذا المقال (Luc Perkins) هو مدافع عن مطور CNCF ، موطن لمشاريع مفتوحة المصدر مثل Linkerd و SMI (واجهة شبكة الخدمة) و Kuma (بالمناسبة ، هل تساءلت أيضًا عن سبب عدم إدراج Istio في هذه القائمة؟ .). في محاولة أخرى لتحقيق فهم أفضل للضجيج العصري الذي يسمى شبكة الخدمة لمجتمع DevOps ، يستشهد بـ 16 قدرة مميزة توفرها هذه الحلول. تعد شبكة الخدمة واحدة من أهم الموضوعات في هندسة البرمجيات



اليوم(وهي محقة في ذلك!). أجد هذه التكنولوجيا واعدة بشكل لا يصدق وأحلم بأن أشهد اعتمادها على نطاق واسع (عندما يكون ذلك منطقيًا بالطبع). ومع ذلك ، لا تزال محاطة بهالة من الغموض بالنسبة لمعظم الناس. علاوة على ذلك ، حتى أولئك الذينيعرفها جيدًا ، غالبًا ما يكون من الصعب صياغة مزاياها وما هي بالضبط (بما في ذلك خادمك المتواضع). في هذه المقالة ، سأحاول معالجة الموقف من خلال سرد سيناريوهات مختلفة لاستخدام "شبكات الخدمة" *.



* تقريبا. ترجمة.: من الآن فصاعدًا ، في المقالة ، سنستخدم مثل هذه الترجمة ("شبكة الخدمة") لشبكة الخدمة الجديدة.



لكن أولاً ، أريد أن أبدي بعض التعليقات:

• , . , service mesh Twitter 2015 ( « ») Linkerd, - .
• — . , , .
• في الوقت نفسه ، لا يدعم كل تطبيق شبكة خدمة موجود كل حالات الاستخدام هذه. لذلك ، يجب قراءة تعبيراتي مثل "service mesh can ..." على أنها "منفصلة ، وربما يمكن لجميع تطبيقات شبكة الخدمة الشائعة ...".
• ترتيب الأمثلة لا يهم.

قائمة قصيرة:

• اكتشاف الخدمة
• التشفير.
• المصادقة والتخويل؛
• توزيع الحمل؛
• كسر الدائرة
• مقياس تلقائي.
• عمليات نشر الكناري
• عمليات النشر الأزرق والأخضر ؛
• فحص طبي؛
• سفك الأحمال
• انعكاس حركة المرور
• عازلة؛
• تحديد المعدل وإعادة المحاولة والمهلة ؛
• القياس عن بعد.
• تدقيق؛
• التصور.

1. اكتشاف الخدمة

TL ؛ DR: اتصل بخدمات أخرى على الشبكة باستخدام أسماء بسيطة.



يجب أن تكون الخدمات قادرة على "اكتشاف" بعضها البعض تلقائيًا عبر الاسم المناسب - على سبيل المثال service.api.production، pets/stagingأو cassandra. تتميز البيئات السحابية بالمرونة ، ويمكن لاسم واحد إخفاء عدة حالات من الخدمة. من الواضح أنه في مثل هذه الحالة يكون من المستحيل فعليًا ترميز جميع عناوين IP.



بالإضافة إلى ذلك ، عندما تجد خدمة أخرى ، يجب أن تكون قادرة على إرسال الطلبات إلى هذه الخدمة دون خوف من أن ينتهي بهم الأمر عند مدخل مثيلها الخامل. بمعنى آخر ، يجب أن تراقب شبكة الخدمة صحة جميع مثيلات الخدمة وتحافظ على تحديث قائمة المضيفين.



تنفذ كل شبكة خدمة آلية اكتشاف الخدمة بشكل مختلف. في الوقت الحالي ، الطريقة الأكثر شيوعًا هي التفويض لعمليات خارجية مثل DNS Kubernetes. في الماضي ، على Twitter ، استخدمنا نظام تسمية Finagle لهذا الغرض . بالإضافة إلى ذلك ، تتيح تقنية شبكة الخدمة إمكانية ظهور آليات تسمية مخصصة (على الرغم من أنني لم أجد بعد أي تطبيق SM بهذه الوظيفة).

2. التشفير

TL ؛ DR: تخلص من حركة المرور غير المشفرة بين الخدمات واجعل العملية آلية وقابلة للتطوير.



من الجيد أن تعرف أن المهاجمين لا يمكنهم اختراق شبكتك الداخلية. تقوم جدران الحماية بعمل ممتاز في هذا الصدد. ولكن ماذا يحدث إذا دخل أحد المتطفلين؟ هل يستطيع أن يفعل ما يشاء مع حركة المرور داخل الخدمة؟ دعونا نأمل ألا يحدث ذلك. لمنع هذا السيناريو ، يجب عليك تنفيذ شبكة خالية من الثقة يتم فيها تشفير كل حركة المرور بين الخدمات. تحقق معظم شبكات الخدمة الحديثة ذلك من خلال TLS المتبادلة .(TLS المتبادلة ، mTLS). في بعض الحالات ، يعمل mTLS في مجموعات وسحب كاملة (أعتقد أن الاتصالات بين الكواكب سيتم ترتيبها يومًا ما بطريقة مماثلة).



بالطبع ، بالنسبة إلى mTLS ، تكون شبكة الخدمة اختيارية . يمكن لكل خدمة رعاية TLS الخاصة بها ، ولكن هذا يعني أنه سيكون من الضروري إيجاد طريقة لإنشاء الشهادات وتوزيعها بين مضيفي الخدمة وتضمين التعليمات البرمجية في التطبيق الذي سيحمل هذه الشهادات من الملفات. نعم ، تذكر أيضًا تجديد هذه الشهادات على فترات منتظمة. تعمل شبكات الخدمة على أتمتة mTLS باستخدام أنظمة مثل SPIFFE ، والتي بدورها تعمل على أتمتة عملية إصدار الشهادات وتدويرها .

3. المصادقة والترخيص

TL ؛ DR: حدد الشخص الذي بدأ الطلب وحدد ما يُسمح له بفعله قبل وصول الطلب إلى الخدمة.



غالبا ما يرغبون في معرفة الخدمات التي يتم جعل الطلب (التوثيق)، واستخدام هذه المعلومات، أن تقرر ما سمح هذا الموضوع للقيام (إذن). في هذه الحالة ، الضمير "who" يمكنه إخفاء:

1. خدمات أخرى. وهذا ما يسمى "مصادقة الأقران ". على سبيل المثال ، webتريد خدمة الوصول إلى خدمة db. عادةً ما تحل شبكات الخدمة هذه المشكلات مع mTLS: تعمل الشهادات في هذه الحالة كمعرف ضروري.
2. -. « ». , haxor69 . , , JSON Web Tokens.
   
   
   
   . , users, , permissions .. service mesh , .

بعد أن نحدد من جاء الطلب ، نحتاج إلى تحديد ما يُسمح لهذا الموضوع القيام به. تسمح لك بعض شبكات الخدمة بتحديد السياسات الأساسية (حول من يمكنه فعل ماذا) في ملفات YAML أو في سطر الأوامر ، بينما يقدم البعض الآخر التكامل مع أطر عمل مثل Open Policy Agent . الهدف النهائي هو التأكد من أن خدماتك تقبل أي طلبات ، على افتراض أنها تأتي من مصدر موثوق به وأن هذا الإجراء مسموح به.

4. موازنة الحمل

TL ؛ DR: توزيع التحميل عبر مثيلات الخدمة وفقًا لنمط معين.



غالبًا ما تتكون "الخدمة" داخل طائفة الخدمة من العديد من الأمثلة المماثلة. على سبيل المثال ، cacheتتكون الخدمة اليوم من 5 نسخ ، وقد يزيد عددها غدًا إلى 11. cacheيجب توزيع الطلبات الموجهة إليها وفقًا لغرض معين. على سبيل المثال ، قم بتقليل وقت الاستجابة أو زيادة احتمالية الوصول إلى حالة صحية. خوارزمية round-robin الأكثر استخدامًا (Round-robin) ، ولكن هناك العديد من الخوارزميات الأخرى - على سبيل المثال ، طريقة الطلبات الموزونة (المرجحة) (يمكنك تحديد الهدف المفضل) ، الحلقي (الحلقة)التجزئة (باستخدام تجزئة متسقة للمضيفات الأولية) أو أقل طريقة طلب (يُفضل المثيل الذي يحتوي على أقل عدد من الطلبات).



تحتوي موازين التحميل التقليدية على ميزات أخرى ، مثل التخزين المؤقت لـ HTTP وحماية DDoS ، لكنها ليست ذات صلة كبيرة بحركة المرور بين الشرق والغرب (على سبيل المثال ، لحركة المرور التي تتدفق داخل مركز البيانات - تقريبًا.) (الاستخدام النموذجي للخدمة شبكة). بالطبع ، ليس من الضروري استخدام شبكة خدمة لموازنة الحمل ، ولكنها تتيح لك تحديد سياسات الموازنة والتحكم فيها لكل خدمة من طبقة إدارة مركزية ، وبالتالي التخلص من الحاجة إلى بدء وتكوين الموازنات الفردية في مكدس الشبكة.

5. كسر الدائرة

TL ؛ DR: أوقف حركة المرور إلى الخدمة التي بها مشكلات وتحكم في الضرر في سيناريوهات أسوأ الحالات.



إذا كانت الخدمة ، لأي سبب من الأسباب ، غير قادرة على التعامل مع حركة المرور ، فإن شبكة الخدمة توفر عدة خيارات لحل هذه المشكلة (ستتم مناقشة البعض الآخر في الأقسام المقابلة). يعد كسر الدائرة أخطر طريقة لفصل خدمة عن حركة المرور. ومع ذلك ، فإنه ليس له معنى من تلقاء نفسه - فأنت بحاجة إلى خطة احتياطية. قد يوفر ضغطًا عكسيًا ( ضغطًا عكسيًا ) على الخدمات التي تستفسر عنها (فقط لا تنس إعداد شبكة الخدمة الخاصة بك لذلك!) ، أو ، على سبيل المثال ، تلطيخ حالة الصفحة باللون الأحمر وإعادة توجيه المستخدمين إلى إصدار آخر من الصفحة باستخدام "الحوت الساقط" («Twitter هو أسفل ").



شبكات الخدمة لا أكثر من مجرد تحديد متى و ماذا سيحدث بعد ذلك. في هذه الحالة ، يمكن أن تتضمن "when" أي مجموعة من المعلمات المحددة: العدد الإجمالي للطلبات لفترة معينة ، وعدد الاتصالات المتوازية ، والطلبات المعلقة ، وعمليات إعادة المحاولة النشطة ، وما إلى ذلك.



ربما لا تريد إساءة استخدام كسر الدائرة ، ولكن من الجيد أن تعرف أن هناك خطة طوارئ لحالات الطوارئ.

6. مقياس تلقائي

TL ؛ DR: زيادة أو تقليل عدد مثيلات الخدمة بناءً على المعايير المحددة.



شبكات الخدمة ليست برامج جدولة ، لذا فهي لا تتوسع من تلقاء نفسها. ومع ذلك ، يمكنهم تقديم معلومات على أساس أي المخططين سيتخذون القرارات. نظرًا لأن شبكات الخدمة تتمتع بإمكانية الوصول إلى كل حركة المرور بين الخدمات ، فإن لديها ثروة من المعلومات حول ما يحدث: ما هي الخدمات التي تواجه مشكلات ، وما الخدمات التي يتم تحميلها بشكل ضعيف جدًا (يتم إهدار الطاقة المخصصة لها) ، إلخ.



على سبيل المثال ، يقوم Kubernetes بتوسيع نطاق الخدمات اعتمادًا على استخدام وحدة المعالجة المركزية والذاكرة في البودات (راجع حديثنا " القياس التلقائي وإدارة الموارد في Kubernetes " - الترجمة تقريبًا.)، ولكن إذا قررت القياس بناءً على أي مقياس آخر (في حالتنا ، يتعلق بالزيارات) ، فستحتاج إلى مقياس خاص. A تعليمي مثل هذا يظهر لك كيفية القيام بذلك مع المبعوث ، Istio و بروميثيوس ، ولكن العملية نفسها معقد جدا. نود أن تقوم شبكة الخدمة بتبسيطها ببساطة عن طريق السماح بشروط مثل "زيادة عدد مثيلات الخدمة authإذا تجاوز عدد الطلبات المعلقة الحد لمدة دقيقة".

7. عمليات الانتشار الكناري

TL ؛ DR: جرب الميزات الجديدة أو إصدارات الخدمة على مجموعة فرعية من المستخدمين.



لنفترض أنك تقوم بتطوير منتج SaaS وتنوي طرح إصدار جديد رائع منه. لقد اختبرت ذلك في التدريج وعملت بشكل رائع. لكن لا تزال هناك مخاوف معينة بشأن سلوكها في الظروف الحقيقية. بمعنى آخر ، من الضروري اختبار الإصدار الجديد على مهام حقيقية ، دون المخاطرة بثقة المستخدم. عمليات نشر الكناري رائعة لهذا الغرض. تسمح لك بإظهار ميزة جديدة لمجموعة فرعية من المستخدمين. يمكن أن تتكون هذه المجموعة الفرعية من المستخدمين الأكثر ولاءً ، أو أولئك الذين يستخدمون الإصدار المجاني من المنتج ، أو المستخدمين الذين أعربوا عن رغبتهم في أن يكونوا خنازير غينيا.



تقوم شبكات الخدمة بهذا من خلال السماح لك بتحديد المعايير التي تحدد من يرى إصدار التطبيق الخاص بك وتوجيه حركة المرور وفقًا لذلك. في الوقت نفسه ، لا شيء يتغير بالنسبة للخدمات نفسها. يعتقد الإصدار 1.0 من الخدمة أن جميع الطلبات تأتي من المستخدمين الذين يجب أن يطلعوا عليها ، ويفترض الإصدار 1.1 نفس الشيء بالنسبة لمستخدميه. في غضون ذلك ، يمكنك تغيير النسبة المئوية لحركة المرور بين الإصدارين القديم والجديد ، وإعادة توجيه عدد متزايد من المستخدمين إلى الإصدار الجديد ، إذا كان يعمل بثبات ، وتعطيك "التجريبية" الضوء الأخضر.

8. عمليات الانتشار الأزرق والأخضر

TL ؛ DR: طرح الميزة الجديدة الرائعة ، ولكن كن مستعدًا لإعادة كل شيء على الفور.



الهدف من عمليات النشر باللون الأزرق والأخضر هو طرح خدمة زرقاء جديدة من خلال تشغيلها بالتوازي مع الخدمة الخضراء القديمة. إذا سارت الأمور بسلاسة وأثبتت الخدمة الجديدة نفسها بشكل جيد ، فيمكن إيقاف تشغيل الخدمة القديمة تدريجيًا. (للأسف ، في يوم من الأيام ستكرر هذه الخدمة "الزرقاء" الجديدة مصير الخدمة "الخضراء" وتختفي ...) تختلف عمليات النشر باللونين الأزرق والأخضر عن عمليات النشر الكناري من حيث أن الوظيفة الجديدة تغطي جميع المستخدمين في وقت واحد (وليس جزءًا فقط) ؛ النقطة هنا هي أن يكون لديك "ميناء احتياطي" جاهز في حالة حدوث خطأ ما.



توفر شبكات الخدمة طريقة مريحة للغاية لاختبار الخدمة الزرقاء والتحول فورًا إلى اللون الأخضر العامل في حالة حدوث مشكلة. ناهيك عن حقيقة أنهم يقدمون الكثير من المعلومات على طول الطريق (انظر العنصر "القياس عن بعد" أدناه) حول عمل "الأزرق" ، مما يساعد على فهم ما إذا كان جاهزًا للاستغلال الكامل.



تقريبا. ترجمة. : اقرأ المزيد حول استراتيجيات النشر المختلفة في Kubernetes (بما في ذلك الكناري المذكور والأزرق / الأخضر وغيرها) في هذه المقالة .

9. فحص الصحة

TL ؛ DR: تتبع مثيلات الخدمة التي تم تشغيلها والرد على تلك التي لم تعد كذلك.



A الفحص الطبي يساعد على أن تقرر ما إذا مثيلات الخدمة جاهزة لاستقبال والمرور العملية. على سبيل المثال ، في حالة خدمات HTTP ، قد يبدو الفحص الصحي وكأنه طلب GET لنقطة نهاية /health. 200 OKستعني الإجابة أن المثيل سليم ، أي حالة أخرى - أنه غير جاهز لاستقبال حركة المرور. تتيح لك شبكات الخدمة تحديد كل من الطريقة التي سيتم بها التحقق من الصحة وتكرار إجراء هذا الفحص. يمكن بعد ذلك استخدام هذه المعلومات لأغراض أخرى ، مثل موازنة التحميل وفصل الدائرة.



وبالتالي ، فإن الفحص الصحي ليس حالة استخدام مستقلة ، ولكنه يستخدم عادة لتحقيق أهداف أخرى. أيضًا ، بناءً على نتائج الفحوصات الصحية ، قد تكون الإجراءات الخارجية (فيما يتعلق بالأهداف الأخرى لشبكات الخدمة) مطلوبة: على سبيل المثال ، قم بتحديث صفحة الحالة ، أو إنشاء مشكلة على GitHub ، أو ملء بطاقة JIRA. وتوفر شبكة الخدمة آلية يدوية لأتمتة كل هذا.

10. سفك الأحمال

TL ؛ DR: إعادة توجيه حركة المرور استجابة لارتفاع مؤقت في الاستخدام.



إذا كانت الخدمة مثقلة بحركة المرور ، يمكنك مؤقتًا إعادة توجيه بعض هذه الحركة إلى موقع آخر (أي "تفريغ" أو " إلقاءها" هناك). على سبيل المثال ، إلى خدمة النسخ الاحتياطي أو مركز البيانات ، أو إلى موضوع بولسار دائم . نتيجة لذلك ، ستستمر الخدمة في معالجة جزء من الطلبات بدلاً من التعطل وإيقاف معالجة كل شيء على الإطلاق. يُفضل تفريغ الحمولة على كسر الدائرة ، لكن لا يزال من غير المرغوب فيه الإفراط في استخدامها. يساعد في منع حالات الفشل المتتالية التي تتسبب في تعطل الخدمات المتلقية للمعلومات.

11. موازاة حركة المرور / انعكاس

TL ؛ DR: أرسل طلبًا واحدًا إلى مواقع متعددة في وقت واحد.



في بعض الأحيان يصبح من الضروري إرسال طلب (أو بعض عينات الطلبات) إلى عدة خدمات في وقت واحد. من الأمثلة النموذجية إرسال جزء من حركة الإنتاج إلى خدمة مرحلية. يرسل خادم الويب الرئيسي للإنتاج طلبًا إلى خدمة المصب products.productionفقط. وتقوم شبكة الخدمة بنسخ هذا الطلب بذكاء وإرساله إليه products.staging، والذي لا يعرفه خادم الويب.



حالة استخدام شبكة الخدمة الأخرى ذات الصلة والتي يمكن تنفيذها فوق موازاة حركة المرور هي اختبار الانحدار... يتضمن إرسال نفس الطلبات إلى إصدارات مختلفة من الخدمة والتحقق مما إذا كانت جميع الإصدارات تتصرف بنفس الطريقة. لم أجد بعد تنفيذ شبكة خدمة مع نظام اختبار انحدار متكامل مثل Diffy ، لكن الفكرة نفسها تبدو واعدة.

12. العزل

TL ؛ DR: قسم شبكة الخدمة إلى شبكات صغيرة.



يُعرف أيضًا باسم التجزئة ، والعزلة هي فن تقسيم شبكة الخدمة إلى مقاطع مميزة منطقيًا لا تعرف شيئًا عن بعضها البعض. العزلة تشبه إلى حد ما إنشاء شبكات افتراضية خاصة. يتمثل الاختلاف الأساسي في أنه لا يزال بإمكانك الاستفادة الكاملة من شبكة الخدمة (مثل اكتشاف الخدمة) ، ولكن مع مزيد من الأمان. على سبيل المثال ، إذا تمكن المهاجم من اختراق خدمة على إحدى الشبكات الفرعية ، فلن يتمكن من معرفة الخدمات التي تعمل على الشبكات الفرعية الأخرى أو اعتراض حركة المرور الخاصة بها.



بالإضافة إلى ذلك ، يمكن أن تكون الفوائد تنظيمية. قد ترغب في تقسيم خدماتك إلى شبكات فرعية بناءً على هيكل مؤسستك وتخفيف العبء المعرفي للمطورين المتمثل في الحفاظ على شبكة الخدمة بأكملها في الاعتبار.

13. تحديد معدل ، وإعادة المحاولة والمهلة

TL ؛ DR: لم تعد هناك حاجة لتضمين المهام الملحة لإدارة الطلبات في قاعدة الشفرة.



يمكن النظر إلى كل هذه الأشياء كحالات استخدام منفصلة ، لكنني قررت دمجها بسبب شيء واحد مشترك: أنها تتولى مهام إدارة دورة حياة الطلب ، والتي يتم التعامل معها عادةً بواسطة مكتبات التطبيقات. إذا كنت تقوم بتطوير خادم ويب Ruby on Rails (غير مدمج مع شبكة الخدمة) الذي يقدم طلبات إلى خدمات الخلفية عبر gRPC، سيتعين على التطبيق أن يقرر ما يجب فعله إذا فشلت طلبات N. سيتعين عليك أيضًا معرفة مقدار حركة المرور التي ستتمكن هذه الخدمات من التعامل معها وترميز هذه المعلمات باستخدام مكتبة خاصة. بالإضافة إلى ذلك ، سيتعين على التطبيق تحديد موعد الاستسلام وترك الطلب يفسد (عن طريق المهلة). ومن أجل تغيير أي من المعلمات المذكورة أعلاه ، يجب إيقاف خادم الويب وإعادة تكوينه وإعادة تشغيله.



إن نقل هذه المهام إلى شبكة الخدمة لا يعني فقط أن مطوري الخدمة لا يحتاجون إلى التفكير فيها ، ولكن يمكن عرضها بطريقة أكثر عالمية. إذا تم استخدام سلسلة معقدة من الخدمات ، على سبيل المثال A -> B -> C -> D -> E ، فيجب مراعاة دورة الحياة الكاملة للطلب. إذا كانت المهمة تتمثل في تمديد المهلات في الخدمة C ، فمن المنطقي القيام بذلك مرة واحدة ، وليس في أجزاء: عن طريق تحديث رمز الخدمة وانتظار قبول طلب السحب ونظام CI لنشر الخدمة المحدثة.

14. القياس عن بعد

TL ؛ DR: اجمع كل المعلومات الضرورية (وليس تمامًا) من الخدمات.



القياس عن بعد هو مصطلح عام يتضمن المقاييس والتتبع الموزع والتسجيل. توفر شبكات الخدمة آليات لجمع ومعالجة جميع أنواع البيانات الثلاثة. هذا هو المكان الذي تصبح فيه الأشياء غامضة بعض الشيء حيث يوجد العديد من الخيارات المتاحة. لجمع المقاييس ، هناك بروميثيوس وأدوات أخرى ، لجمع السجلات ، يمكنك استخدام فلوينتد ، لوكي ، فيكتور ، وما إلى ذلك (على سبيل المثال ، ClickHouse مع مخزننا لـ K8s - تقريبًا ترجمة) ، للحصول على التتبع الموزع هناك Jaegerإلخ قد تدعم كل شبكة خدمة بعض الأدوات دون غيرها. سيكون من الغريب معرفة ما إذا كان مشروع القياس عن بُعد المفتوح يمكن أن يوفر بعض التقارب.



في هذه الحالة ، تتمثل ميزة تقنية شبكة الخدمة في أن الحاويات الجانبية يمكنها ، من حيث المبدأ ، جمع كل البيانات المذكورة أعلاه من خدماتها. بمعنى آخر ، يمكنك الحصول على نظام جمع قياس عن بعد واحد تحت تصرفك ، ويمكن لشبكة الخدمة معالجة كل هذه المعلومات بطرق مختلفة. على سبيل المثال:

• سجلات الذيل من خدمة معينة في CLI ؛
• تتبع حجم الطلبات من لوحة معلومات شبكة الخدمة ؛
• جمع الآثار الموزعة وإعادة توجيهها إلى نظام مثل Jaeger.

الانتباه ، الحكم الذاتي: بشكل عام ، القياس عن بعد هو منطقة لا يكون فيها التداخل القوي لشبكة الخدمة مرغوبًا فيه. جمع المعلومات الأساسية وتتبع بعض "المقاييس الذهبية" مثل معدلات النجاح والكمون على الفور أمر جيد ، ولكن دعونا نأمل ألا نرى مكدسات فرانكشتاين التي تحاول استبدال الأنظمة المتخصصة ، والتي أثبت بعضها بالفعل أنها ممتازة. ومدروسة جيدا.

15. التدقيق

TL ؛ DR: أولئك الذين ينسون دروس التاريخ محكوم عليهم بتكرارها.



التدقيق هو فن مراقبة الأحداث المهمة في النظام. في حالة شبكة الخدمة ، قد يعني هذا تتبع من قدم طلبات لنقاط نهاية معينة لخدمات معينة ، أو عدد مرات وقوع حدث أمني في الشهر الماضي.



من الواضح أن التدقيق يرتبط ارتباطًا وثيقًا بالقياس عن بُعد. يتمثل الاختلاف في أن القياس عن بُعد يرتبط عادةً بأشياء مثل الأداء والصحة الفنية ، في حين أن التدقيق يمكن أن يكون مرتبطًا بالمسائل القانونية وغيرها من القضايا التي تتجاوز المجال التقني البحت (على سبيل المثال ، الامتثال لمتطلبات اللائحة العامة لحماية البيانات - اللائحة العامة للاتحاد الأوروبي لحماية البيانات).

16. التصور

TL ؛ DR: تحيا React.js - مصدر لا ينضب من الواجهات الفاخرة.



ربما هناك مصطلح أفضل ، لكني لا أعرفه. أعني فقط تمثيل رسومي لشبكة الخدمة أو بعض مكوناتها. يمكن أن تتضمن هذه المرئيات مؤشرات مثل متوسط ​​زمن الوصول ومعلومات تكوين السيارة الجانبية ونتائج فحص الصحة والتنبيهات.



العمل في بيئة موجهة نحو الخدمة يحمل عبئًا معرفيًا أعلى بكثير من صاحب الجلالة المتراصة. لذلك ، يجب تقليل الضغط المعرفي بأي ثمن. يمكن أن تكون الواجهة الرسومية المبتذلة لشبكة خدمة مع القدرة على النقر فوق الزر والحصول على النتيجة المرجوة أمرًا بالغ الأهمية لنمو شعبية هذه التقنية.

غير مدرج في القائمة

كنت أنوي في الأصل تضمين عدد قليل من حالات الاستخدام في القائمة ، لكنني قررت بعد ذلك عدم القيام بذلك. ها هم ، مع أسباب قراري:

• مركز بيانات متعدد . في رأيي ، هذه ليست حالة استخدام بقدر ما هي منطقة ضيقة ومحددة لتطبيق شبكات الخدمة أو مجموعة من الوظائف مثل اكتشاف الخدمة.
• الدخول والخروج . هذه منطقة ذات صلة ، لكنني اقتصرت (ربما بشكل مصطنع) على سيناريو حركة المرور بين الشرق والغرب. الدخول والخروج يستحقان مادة منفصلة.

خاتمة

هذا كل شئ حتى الان! مرة أخرى ، هذه القائمة مؤقتة للغاية وعلى الأرجح غير مكتملة. إذا كنت تعتقد أني أفتقد شيئًا ما أو أخطأت في شيء ما ، فيرجى الاتصال بي على Twitter ( lucperkins ). يرجى مراعاة قواعد اللياقة.

PS من المترجم

كأساس لتوضيح عنوان المقال ، صورة من المقال " ما هي شبكة الخدمة (ومتى تستخدم واحدة)؟ "(بقلم جريجوري ماكينون). يُظهر كيف انتقلت بعض الوظائف من التطبيقات (باللون الأخضر) إلى شبكة الخدمة ، والتي توفر الترابط بينها (باللون الأزرق).



اقرأ أيضًا على مدونتنا:

• « خدمة الشبكة: أنت بحاجة إلى معرفة كل مهندس برمجيات عن أكثر تقنيات haypovoy ” ؛
• " ما المقصود بشبكة الخدمة ولماذا أحتاجها [لتطبيق الخدمات المصغرة المستند إلى السحابة]؟ "؛
• " العودة إلى الخدمات المصغرة مع Istio. الجزء 1 ".