ملحوظة. ترجمة.: مؤلف هذا المقال (Luc Perkins) هو أحد المدافعين عن المطورين في مؤسسة CNCF، التي تعد موطنًا لمشاريع مفتوحة المصدر مثل Linkerd وSMI (Service Mesh Interface) وKuma (بالمناسبة، هل تساءلت أيضًا عن سبب إنشاء Istio؟ ليس في هذه القائمة؟). مرة أخرى يحاول أن يجعل مجتمع DevOps يفهم بشكل أفضل الضجيج العصري المسمى "شبكة الخدمة"، فهو يسرد 16 قدرة مميزة توفرها مثل هذه الحلول.
اليوم - أحد أهم المواضيع في مجال هندسة البرمجيات (وهذا صحيح!). أعتقد أن هذه التكنولوجيا واعدة بشكل لا يصدق وأود أن أراها معتمدة على نطاق واسع (عندما يكون ذلك منطقيًا بالطبع). ومع ذلك، لا يزال محاطًا بهالة من الغموض بالنسبة لمعظم الناس. وفي الوقت نفسه، حتى أولئك الذين معروف مع ذلك، غالبًا ما يكون من الصعب صياغة مزاياها وما هي بالضبط (بما في ذلك مزاياك الحقيقية). في هذه المقالة سأحاول تصحيح الوضع من خلال سرد مختلف استخدم حالات "شبكات الخدمة"*.
* ملحوظة ترجمة: هنا وفي المقالة سيتم استخدام هذه الترجمة ("شبكة الخدمة") بالضبط للمصطلح الجديد "شبكة الخدمة".
لكن أولاً أريد أن أدلي ببعض التعليقات:
- لم أعمل مطلقًا مع شبكات الخدمة أو استخدمتها خارج المشروعات التي بدأتها في تعليمي الخاص. ومن ناحية أخرى، كنت أنا من كتب مجموعة من الوثائق لشبكة الخدمة الداخلية لتويتر في عام 2015 (لم تكن تسمى حتى "شبكة الخدمة" في ذلك الوقت) وشاركت في تطوير الموقع الإلكتروني والتوثيق لـ ، وهذا يعني شيئا.
- قائمتي تقريبية وغير كاملة. قد تكون هناك حالات استخدام غير معروفة بالنسبة لي، ومن المرجح أن تظهر خيارات جديدة بمرور الوقت مع تطور التكنولوجيا وتزايد شعبيتها.
- وفي الوقت نفسه، لا يدعم كل تطبيق لشبكة الخدمة الحالية جميع حالات الاستخدام المدرجة. لذلك، يجب قراءة عباراتي مثل "يمكن لشبكة الخدمة..." على أنها "فردية، وربما يمكن لجميع تطبيقات شبكة الخدمة الشائعة...".
- ترتيب الأمثلة لا يحدث أي فرق.
قائمة قصيرة:
- اكتشاف الخدمة؛
- التشفير؛
- المصادقة والتخويل؛
- توزيع الحمل؛
- كسر الدائرة
- التحجيم التلقائي؛
- عمليات نشر الكناري؛
- عمليات النشر باللونين الأزرق والأخضر؛
- فحص طبي؛
- سفك الأحمال
- انعكاس حركة المرور؛
- عازلة؛
- تحديد معدل الطلب، وإعادة المحاولة، والمهلة؛
- القياس عن بعد؛
- مراجعة؛
- التصور.
1. اكتشاف الخدمة
TL;DR: اتصل بالخدمات الأخرى على الشبكة باستخدام أسماء بسيطة.
يجب أن تكون الخدمات قادرة على "العثور" على بعضها البعض تلقائيًا باستخدام الأسماء المناسبة - على سبيل المثال، service.api.production, pets/staging أو cassandra. تتميز البيئات السحابية بالمرونة، ويمكن لاسم واحد إخفاء العديد من مثيلات الخدمة. من الواضح أنه في مثل هذه الحالة يكون من المستحيل فعليًا تشفير كافة عناوين IP.
بالإضافة إلى ذلك، عندما تجد خدمة ما أخرى، يجب أن تكون قادرة على إرسال الطلبات إلى تلك الخدمة دون خوف من أن ينتهي بها الأمر عند إدخال مثيلها المعطل. بمعنى آخر، يجب أن تراقب شبكة الخدمة سلامة جميع مثيلات الخدمة وتحافظ على قائمة المضيفين محدثة قدر الإمكان.
تنفذ كل شبكة خدمة آلية اكتشاف الخدمة بشكل مختلف. الطريقة الأكثر شيوعًا حاليًا هي تفويض العمليات الخارجية مثل Kubernetes DNS. في الماضي، استخدمنا على تويتر نظام تسمية لهذا الغرض . بالإضافة إلى ذلك، تتيح تقنية شبكة الخدمة إمكانية ظهور آليات تسمية مخصصة (على الرغم من أنني لم أر بعد أي تطبيق SM بمثل هذه الوظيفة).
2. التشفير
TL;DR: تخلص من حركة المرور غير المشفرة بين الخدمات واجعل هذه العملية آلية وقابلة للتطوير.
من الجيد أن تعرف أن المهاجمين لا يمكنهم اختراق شبكتك الداخلية. تقوم جدران الحماية بعمل رائع في هذا. ولكن ماذا يحدث إذا دخل المتسلل إلى الداخل؟ هل سيكون قادرًا على فعل ما يريد مع حركة المرور داخل الخدمة؟ دعونا نأمل ألا يحدث هذا بعد كل شيء. ولمنع هذا السيناريو، يجب عليك إنشاء شبكة ذات ثقة معدومة حيث يتم تشفير كل حركة المرور بين الخدمات. تحقق معظم شبكات الخدمة الحديثة ذلك من خلال التبادل (TLS المتبادل، mTLS). في بعض الحالات، يعمل mTLS في السحب والمجموعات بأكملها (أعتقد أنه سيتم ترتيب الاتصالات بين الكواكب بشكل مماثل يومًا ما).
وبطبيعة الحال، لشبكة خدمة mTLS خياري. يمكن لكل خدمة الاهتمام بـ TLS الخاصة بها، ولكن هذا يعني أنك ستحتاج إلى إيجاد طريقة لإنشاء الشهادات، وتوزيعها عبر مضيفي الخدمة، وتضمين التعليمات البرمجية في التطبيق الذي سيقوم بتحميل هذه الشهادات من الملفات. نعم، لا تنس تجديد هذه الشهادات على فترات منتظمة. تعمل الخدمة على أتمتة mTLS مع أنظمة مثل والتي بدورها تقوم بأتمتة عملية إصدار الشهادات وتدويرها.
3. المصادقة والترخيص
TL;DR: حدد هوية مقدم الطلب وحدد ما يُسمح له بفعله قبل أن يصل الطلب إلى الخدمة.
الخدمات غالبا ما تريد أن تعرف الذي ينفذ الطلب (المصادقة)، وباستخدام هذه المعلومات، يقرر أن يُسمح لجهة معينة بالقيام (التفويض). في هذه الحالة يمكن إخفاء الضمير "من":
- خدمات أخرى. وهذا ما يسمى "المصادقة" نظير" على سبيل المثال، الخدمة
webيريد الوصول إلى الخدمةdb. عادةً ما تحل شبكات الخدمة مثل هذه المشكلات باستخدام mTLS: تعمل الشهادات في هذه الحالة كمعرف ضروري. - بعض المستخدمين البشر. وهذا ما يسمى "المصادقة" طلب" على سبيل المثال، المستخدم
haxor69يريد شراء مصباح جديد. توفر شبكات الخدمة آليات مختلفة، على سبيل المثال. .لقد فعل الكثير منا هذا في كود التطبيق. يأتي الطلب، ونحن ننظر من خلال الجدول
users، ابحث عن المستخدم وقارن كلمة المرور، ثم حدد العمودpermissionsإلخ. في حالة شبكة الخدمة، يحدث هذا قبل أن يصل الطلب إلى الخدمة.
بمجرد أن نحدد الجهة التي جاء منها الطلب، نحتاج إلى تحديد ما يُسمح لهذا الكيان بفعله. تسمح لك بعض شبكات الخدمة بتعيين السياسات الأساسية (حول من يمكنه فعل ماذا) كملفات YAML أو في سطر الأوامر، بينما يقدم البعض الآخر التكامل مع أطر عمل مثل . الهدف النهائي هو أن تقبل خدماتك أي طلب، على افتراض أنه يأتي من مصدر موثوق به и هذا الإجراء مسموح به.
4. موازنة التحميل
TL;DR: توزيع الحمل عبر مثيلات الخدمة وفقًا لنمط محدد.
غالبًا ما تتكون "الخدمة" داخل قسم الخدمة من العديد من الحالات المتطابقة. على سبيل المثال، اليوم الخدمة cache يتكون من 5 نسخ، وغدا قد يرتفع عددهم إلى 11. يتم إرسال الطلبات إلى cache، يجب أن يتم توزيعها وفقا لغرض محدد. على سبيل المثال، يمكنك تقليل زمن الوصول أو زيادة احتمالية الوصول إلى مثيل صالح للعمل. الخوارزمية الأكثر استخدامًا هي Round-robin، ولكن هناك العديد من الخوارزميات الأخرى - على سبيل المثال، الطريقة المرجحة (موزون) الاستعلامات (يمكنك تحديد الأهداف المفضلة)، رنين (جرس) التجزئة (باستخدام التجزئة المتسقة عبر المضيفين الرئيسيين) أو طريقة الطلب الأقل (تُعطى الأفضلية للمثيل الذي يحتوي على أقل عدد من الطلبات).
تحتوي الموازنات الكلاسيكية على وظائف أخرى، مثل التخزين المؤقت لـ HTTP وحماية DDoS، ولكنها ليست ذات صلة كبيرة بحركة المرور من الشرق إلى الغرب (أي لتدفق حركة المرور داخل مركز البيانات - تقريبًا.) (النطاق النموذجي لشبكة الخدمة). بالطبع، ليس من الضروري استخدام شبكة خدمة لموازنة التحميل، ولكنها تسمح لك بتعيين سياسات الموازنة والتحكم فيها لكل خدمة من طبقة تحكم مركزية، وبالتالي القضاء على الحاجة إلى تشغيل وتكوين موازنات تحميل منفصلة في مكدس الشبكة .
5. كسر الدائرة
TL;DR: إيقاف حركة المرور إلى الخدمة التي بها مشكلات والتحكم في الضرر في أسوأ السيناريوهات.
إذا لم تتمكن الخدمة لسبب ما من التعامل مع حركة المرور، فإن شبكة الخدمة توفر عدة خيارات لحل هذه المشكلة (ستتم مناقشة الخيارات الأخرى في الأقسام المناسبة). يعد قطع الدائرة هو الخيار الأكثر خطورة لفصل الخدمة عن حركة المرور. ومع ذلك، فإنه في حد ذاته لا معنى له - هناك حاجة إلى خطة احتياطية. يمكن توفير الضغط الخلفي () إلى الخدمات التي تقدم طلبات (فقط لا تنس تكوين شبكة الخدمة الخاصة بك لهذا!) ، أو على سبيل المثال، تلوين صفحة الحالة باللون الأحمر وإعادة توجيه المستخدمين إلى إصدار آخر من الصفحة مع "الحوت المتساقط" ("Twitter is تحت").
لا تسمح لك شبكات الخدمة بالتعريف فقط عندما سوف يتبع الاغلاق و أن هذا سوف يتبع. في هذه الحالة، يمكن أن تتضمن كلمة "متى" أي مجموعة من المعلمات المحددة: إجمالي عدد الطلبات لفترة معينة، وعدد الاتصالات المتوازية، والطلبات المعلقة، وعمليات إعادة المحاولة النشطة، وما إلى ذلك.
ربما لا ترغب في إساءة استخدام ميزة قطع الدائرة الكهربائية، ولكن من الجيد أن تعرف أن لديك خطة احتياطية في حالة الطوارئ.
6. التحجيم التلقائي
TL;DR: زيادة أو تقليل عدد مثيلات الخدمة وفقًا للمعايير المحددة.
شبكات الخدمة ليست برامج جدولة، لذا فهي ليست كذلك تنفيذ تحجيم نفسك. ومع ذلك، يمكنهم تقديم معلومات على أساسها سيبني المخططون قراراتهم. نظرًا لأن شبكات الخدمة تتمتع بإمكانية الوصول إلى كل حركة المرور بين الخدمات، فإن لديها معلومات شاملة حول ما يحدث: ما هي الخدمات التي تواجه مشكلات، وما هي الخدمات التي يتم تحميلها بشكل خفيف جدًا (يتم إهدار السعة المخصصة لها)، وما إلى ذلك.
على سبيل المثال، يقوم Kubernetes بتوسيع نطاق الخدمات استنادًا إلى استخدام وحدة المعالجة المركزية والذاكرة في البودات (راجع تقريرنا ""- تقريبًا. ترجمة.)، ولكن إذا قررت التوسع بناءً على أي مقياس آخر (في حالتنا، مرتبط بحركة المرور)، فستحتاج إلى مقياس خاص. إدارة يوضح كيفية القيام بذلك مع , и لكن العملية نفسها معقدة للغاية. نود أن تعمل شبكة الخدمة على تبسيط ذلك من خلال السماح لنا ببساطة بتعيين شروط مثل "زيادة عدد مثيلات الخدمة auth، إذا تجاوز عدد الطلبات المعلقة الحد خلال دقيقة واحدة."
7. عمليات نشر الكناري
TL;DR: اختبار الميزات الجديدة أو إصدارات الخدمة على مجموعة فرعية من المستخدمين.
لنفترض أنك تقوم بتطوير منتج SaaS وتنوي طرح نسخة جديدة رائعة منه. لقد اختبرته في التدريج وكان رائعًا. ولكن لا تزال هناك بعض المخاوف بشأن سلوكها في الظروف الحقيقية. بمعنى آخر، أنت بحاجة إلى اختبار الإصدار الجديد على مشاكل حقيقية دون المخاطرة بثقة المستخدم. تعتبر عمليات نشر الكناري رائعة لهذا الغرض. إنها تسمح لك بإظهار ميزة جديدة لمجموعة فرعية من المستخدمين. قد تتكون هذه المجموعة الفرعية من المستخدمين الأكثر ولاءً أو أولئك الذين يعملون مع الإصدار المجاني من المنتج، أو المستخدمين الذين أعربوا عن رغبتهم في أن يكونوا "فئران تجارب".
تقوم شبكات الخدمة بتنفيذ ذلك من خلال السماح لك بتحديد المعايير التي تحدد من سيشاهد إصدار التطبيق، وتوجيه حركة المرور وفقًا لذلك. ومع ذلك، لا شيء يتغير بالنسبة للخدمات نفسها. يعتقد الإصدار 1.0 من الخدمة أن جميع الطلبات تأتي من المستخدمين الذين يجب عليهم مشاهدتها، ويعتقد الإصدار 1.1 نفس الشيء بالنسبة لمستخدميه. وفي الوقت نفسه، يمكنك تغيير النسبة المئوية لحركة المرور بين الإصدارين القديم والجديد، وإعادة توجيه عدد متزايد من المستخدمين إلى الإصدار الجديد إذا كان يعمل بشكل مستقر وأعطت "خنازير غينيا" الضوء الأخضر للمضي قدمًا.
8. عمليات النشر باللونين الأزرق والأخضر
TL;DR: اطرح ميزة جديدة رائعة، ولكن كن مستعدًا لاستعادة كل شيء على الفور.
معنى هو طرح خدمة "زرقاء" جديدة، وإطلاقها بالتوازي مع الخدمة "الخضراء" القديمة. إذا سارت الأمور بسلاسة وكان أداء الخدمة الجديدة جيدًا، فمن الممكن تعطيل الخدمة القديمة تدريجيًا. (للأسف، يومًا ما ستكرر هذه الخدمة "الزرقاء" الجديدة مصير الخدمة "الخضراء" وتختفي...) تختلف عمليات النشر باللونين الأزرق والأخضر عن عمليات النشر الكناري حيث تغطي الوظيفة الجديدة الجميع في وقت واحد المستخدمين (وليس جزءا)؛ النقطة المهمة هنا هي أن يكون لديك "ملاذ آمن" جاهز في حالة حدوث خطأ ما.
توفر شبكات الخدمة طريقة مريحة للغاية لاختبار الخدمة "الزرقاء" والتحول على الفور إلى خدمة "خضراء" عاملة في حالة حدوث مشكلات. ناهيك عن حقيقة أنهم يقدمون على طول الطريق الكثير من المعلومات (انظر "القياس عن بعد" أدناه) حول عمل "الأزرق"، مما يساعد على فهم ما إذا كان جاهزًا للتشغيل الكامل.
ملحوظة. ترجمة.: يمكنك قراءة المزيد حول استراتيجيات النشر المختلفة في Kubernetes (بما في ذلك الكناري المذكور والأزرق/الأخضر وغيرها) في .
9. فحص الصحة
TL;DR: تتبع مثيلات الخدمة التي تعمل والاستجابة لتلك التي لم تعد تعمل.
فحص طبي (فحص طبي) يساعد في تحديد ما إذا كانت مثيلات الخدمة جاهزة لقبول حركة المرور ومعالجتها. على سبيل المثال، في حالة خدمات HTTP، قد يبدو فحص السلامة كطلب GET إلى نقطة النهاية /health. إجابة 200 OK سيعني أن المثيل سليم، أي شيء آخر - أنه غير جاهز لاستقبال حركة المرور. تتيح لك شبكات الخدمة تحديد الطريقة التي سيتم بها فحص الوظائف وتكرار إجراء هذا الفحص. يمكن بعد ذلك استخدام هذه المعلومات لأغراض أخرى - على سبيل المثال، لموازنة الحمل وكسر الدائرة.
وبالتالي، فإن التحقق من الصحة ليس حالة استخدام قائمة بذاتها، ولكنه يستخدم عادة لتحقيق أهداف أخرى. وأيضًا، اعتمادًا على نتائج عمليات التحقق من السلامة، قد تكون هناك حاجة إلى إجراءات خارج نطاق أهداف شبكة الخدمة الأخرى: على سبيل المثال، تحديث صفحة الحالة، أو إنشاء مشكلة على GitHub، أو ملء تذكرة JIRA. وتوفر شبكة الخدمة آلية ملائمة لأتمتة كل هذا.
10. سفك الأحمال
TL;DR: إعادة توجيه حركة المرور استجابةً للارتفاع المؤقت في الاستخدام.
إذا كانت خدمة معينة مثقلة بحركة المرور، فيمكنك إعادة توجيه بعض هذه الحركة مؤقتًا إلى موقع آخر (أي "تفريغ"، "نقل" (يصلط) له هناك). على سبيل المثال، إلى خدمة النسخ الاحتياطي أو مركز البيانات، أو إلى مركز دائم عنوان. ونتيجة لذلك، ستستمر الخدمة في معالجة بعض الطلبات بدلاً من تعطلها وإيقاف معالجة كل شيء تمامًا. يُفضل فصل الأحمال عن كسر الدائرة، لكن لا يزال من غير المستحسن إساءة استخدامها. فهو يساعد على منع حالات الفشل المتتالية التي تتسبب في تعطل الخدمات النهائية.
11. توازي/انعكاس حركة المرور
TL;DR: أرسل طلبًا واحدًا إلى عدة أماكن في وقت واحد.
في بعض الأحيان تكون هناك حاجة لإرسال طلب (أو مجموعة معينة من الطلبات) إلى عدة خدمات في وقت واحد. والمثال النموذجي هو إرسال جزء من حركة الإنتاج إلى خدمة التدريج. يرسل خادم ويب الإنتاج الرئيسي طلبًا إلى خدمة المصب products.production وفقط له. وتقوم شبكة الخدمة بنسخ هذا الطلب بذكاء وإرساله إلى products.staging، وهو ما لا يعرفه خادم الويب.
هناك حالة أخرى ذات صلة باستخدام شبكة الخدمة والتي يمكن تنفيذها بالإضافة إلى توازي حركة المرور . يتضمن ذلك إرسال نفس الطلبات إلى إصدارات مختلفة من الخدمة والتحقق مما إذا كانت جميع الإصدارات تتصرف بنفس الطريقة. لم أواجه حتى الآن تطبيقًا شبكيًا للخدمة مع نظام اختبار الانحدار المتكامل مثل لكن الفكرة نفسها تبدو واعدة.
12. العزل
TL;DR: قم بتقسيم شبكة الخدمة الخاصة بك إلى شبكات صغيرة.
يُعرف أيضًا باسم تجزئةالعزل هو فن تقسيم شبكة الخدمة إلى أجزاء متميزة منطقيًا لا تعرف شيئًا عن بعضها البعض. العزلة تشبه إلى حد ما إنشاء شبكات افتراضية خاصة. يتمثل الاختلاف الأساسي في أنه لا يزال بإمكانك الاستمتاع بجميع مزايا شبكة الخدمة (مثل اكتشاف الخدمة)، ولكن مع مزيد من الأمان. على سبيل المثال، إذا كان المهاجم قادرًا على اختراق خدمة على شبكة فرعية واحدة، فلن يتمكن من رؤية الخدمات التي تعمل على شبكات فرعية أخرى أو اعتراض حركة المرور الخاصة بها.
وبالإضافة إلى ذلك، قد تكون الفوائد أيضًا تنظيمية. قد ترغب في تقسيم خدماتك إلى شبكة فرعية استنادًا إلى هيكل شركتك وإعفاء المطورين من العبء المعرفي الناتج عن الاضطرار إلى وضع شبكة الخدمة بأكملها في الاعتبار.
13. تحديد معدل الطلب وإعادة المحاولة والمهلة
TL;DR: لم تعد بحاجة إلى تضمين مهام إدارة الطلبات الجوهرية في قاعدة التعليمات البرمجية الخاصة بك.
يمكن اعتبار كل هذه الأشياء حالات استخدام منفصلة، لكنني قررت دمجها بسبب ميزة واحدة مشتركة: وهي أنها تتولى مهام إدارة دورة حياة الطلب التي تعالجها عادةً مكتبات التطبيقات. إذا كنت تقوم بتطوير خادم ويب في Ruby on Rails (غير متكامل مع شبكة الخدمة) الذي يقدم طلبات إلى الخدمات الخلفية عبر ، سيتعين على التطبيق أن يقرر ما يجب فعله إذا فشلت طلبات N. سيتعين عليك أيضًا معرفة مقدار حركة المرور التي ستتمكن هذه الخدمات من معالجتها وترميز هذه المعلمات باستخدام مكتبة خاصة. بالإضافة إلى ذلك، سيتعين على التطبيق أن يقرر متى يحين وقت الاستسلام والسماح للطلب بالتلاشي (استنادًا إلى المهلة الزمنية). ومن أجل تغيير أي من المعلمات المذكورة أعلاه، سيتعين إيقاف خادم الويب وإعادة تكوينه وتشغيله مرة أخرى.
إن تفريغ هذه المهام إلى شبكة خدمة لا يعني فقط أن مطوري الخدمة لن يضطروا إلى التفكير فيها، بل يعني أيضًا أنه يمكن عرضها بطريقة أكثر عالمية. إذا تم استخدام سلسلة معقدة من الخدمات، على سبيل المثال A -> B -> C -> D -> E، فيجب أن تؤخذ دورة حياة الطلب بأكملها في الاعتبار. إذا كانت المهمة هي تمديد المهلات في الخدمة C، فمن المنطقي القيام بذلك دفعة واحدة، وليس على أجزاء: عن طريق تحديث رمز الخدمة والانتظار حتى يتم قبول طلب السحب ويقوم نظام CI بنشر الخدمة المحدثة.
14. القياس عن بعد
TL;DR: اجمع كل المعلومات الضرورية (وليس تمامًا) من الخدمات.
القياس عن بعد هو مصطلح عام يتضمن المقاييس والتتبع الموزع والسجلات. توفر شبكات الخدمة آليات لجمع ومعالجة الأنواع الثلاثة من البيانات. هذا هو المكان الذي تصبح فيه الأمور ضبابية بعض الشيء لأن عدد الخيارات الممكنة كبير جدًا. لجمع المقاييس هناك وغيرها من الأدوات التي يمكن استخدامها لجمع السجلات , , وآخرون. (على سبيل المثال ClickHouse مع موقعنا لـ K8s - تقريبًا. ترجمة.)، للتتبع الموزع هناك وما إلى ذلك وهلم جرا. قد تدعم كل شبكة خدمة بعض الأدوات دون غيرها. سيكون من المثير للاهتمام معرفة ما إذا كان المشروع قادرًا على ذلك توفير بعض التقارب.
في هذه الحالة، تتمثل ميزة تقنية شبكة الخدمة في أن الحاويات الجانبية يمكنها، من حيث المبدأ، جمع كل البيانات المذكورة أعلاه من خدماتها. بمعنى آخر، لديك نظام واحد لجمع القياس عن بعد تحت تصرفك، ويمكن لشبكة الخدمة معالجة كل هذه المعلومات بطرق مختلفة. على سبيل المثال:
- السجلات الخلفية من خدمة معينة في واجهة سطر الأوامر (CLI)؛
- مراقبة حجم الطلبات من لوحة معلومات شبكة الخدمة؛
- جمع الآثار الموزعة وإرسالها إلى نظام مثل Jaeger.
الاهتمام والحكم الذاتي: وبوجه عام، يعد القياس عن بعد مجالًا يكون فيه التداخل القوي من شبكة الخدمة غير مرغوب فيه. إن جمع المعلومات الأساسية وتتبع بعض المقاييس الذهبية بشكل سريع مثل معدل نجاح الطلب وزمن الوصول أمر جيد، ولكن دعونا نأمل ألا نرى ظهور مجموعات فرانكنشتاين التي تحاول استبدال الأنظمة المتخصصة، والتي أثبت بعضها بالفعل نفسه وتمت دراسته جيدًا .
15. التدقيق
TL;DR: أولئك الذين ينسون دروس التاريخ محكوم عليهم بتكرارها.
التدقيق هو فن مراقبة الأحداث الهامة في النظام. في حالة شبكة الخدمة، قد يعني هذا تتبع من قدم طلبات إلى نقاط نهاية محددة لخدمات معينة، أو عدد المرات التي وقعت فيها بعض الأحداث المتعلقة بالأمان في الشهر الماضي.
ومن الواضح أن التدقيق يرتبط ارتباطًا وثيقًا بالقياس عن بعد. الفرق هو أن القياس عن بعد يرتبط عادة بأشياء مثل الإنتاجية والسلامة التقنية، في حين أن التدقيق يمكن أن يتعلق بالقضايا القانونية وغيرها من القضايا التي تتجاوز المجال الفني البحت (على سبيل المثال، الامتثال للائحة العامة لحماية البيانات (GDPR) - اللائحة العامة للاتحاد الأوروبي بشأن حماية البيانات).
16. التصور
TL;DR: يعيش React.js - مصدر لا ينضب للواجهات الفاخرة.
ربما هناك مصطلح أفضل، لكني لا أعرفه. أعني ببساطة تمثيلًا رسوميًا لشبكة الخدمة أو بعض مكوناتها. يمكن أن تتضمن هذه المرئيات مؤشرات مثل متوسط زمن الاستجابة ومعلومات التكوين الجانبي ونتائج فحص السلامة والتنبيهات.
يتضمن العمل في بيئة موجهة نحو الخدمة حملاً معرفيًا أعلى بكثير مقارنةً بجلالة مونوليث. ولذلك، ينبغي خفض الضغط المعرفي بأي ثمن. يمكن أن تكون الواجهة الرسومية البسيطة لشبكة الخدمة مع القدرة على النقر فوق الزر والحصول على النتيجة المرجوة حاسمة لنمو شعبية هذه التكنولوجيا.
لم يتم تضمينها في القائمة
كنت أنوي في الأصل تضمين عدد قليل من حالات الاستخدام في القائمة، لكنني قررت بعد ذلك عدم القيام بذلك. وإليكم هذه الأسباب مع أسباب قراري:
- مركز البيانات المتعددة. في رأيي، هذه ليست حالة استخدام بقدر ما هي مجال ضيق ومحدد لتطبيق شبكات الخدمة أو مجموعة من الوظائف مثل اكتشاف الخدمة.
- الدخول والخروج. هذه منطقة ذات صلة، لكنني اقتصرت (ربما بشكل مصطنع) على حالة استخدام "حركة المرور بين الشرق والغرب". الدخول والخروج يستحق مقالة منفصلة.
اختتام
هذا كل شئ حتى الان! مرة أخرى، هذه القائمة عشوائية للغاية وعلى الأرجح غير كاملة. إذا كنت تعتقد أنني فاتني شيئًا ما أو أخطأت في شيء ما، فيرجى الاتصال بي على تويتر (). يرجى احترام قواعد الحشمة.
PS من المترجم
يستند الرسم التوضيحي لعنوان المقالة إلى صورة من المقالة ""(بقلم جريجوري ماكينون). وهو يوضح كيف انتقلت بعض الوظائف من التطبيقات (باللون الأخضر) إلى شبكة خدمة توفر اتصالات بينية فيما بينها (باللون الأزرق).
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «".
المصدر: www.habr.com
