أنت هنا > أخبار

أخبار

لماذا تحتاج تطبيقات المؤسسات إلى هندسة شبكة الخدمة

التاريخ:2021-02-10الساخنة:172

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

أدخل الخدمةبنية شبكية.

خدمة شبكة العمارة

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

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

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

لماذا هذا مطلوب ؟

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

وبالتالي فإن تطبيقات المؤسسات المعقدة التي تحتوي على عدد كبير من الخدمات الدقيقة تحتاج إلى بنية شبكة خدمة.

أليس هذا ما فعلته واجهات برمجة التطبيقات ؟

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

تقوم بوابات API بإدارة الاتصال بين التطبيق ، والآخرين داخل وخارج بنية المؤسسة.يوفر نقطة دخول واحدة إلى التطبيق ، للطلبات من جميع العملاء الخارجيين ، ويتعامل مع مصادقة المستخدم والتوجيه والمراقبة ومعالجة الأخطاء. كما أنه يستخلص التعقيد الأساسي للتطبيق ، مع الخدمات الدقيقة المكونة له ، من عملاء خارجيين.

من ناحية أخرى ، تدير بنية شبكة الخدمة الاتصال بين الخدمات الصغيرة داخل التطبيق.

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

ما هي المشاكل التي تحلها شبكة الخدمة ؟

تعمل شبكة الخدمة بشكل أساسي على حل المخاوف حول زيادة الاعتماد المتبادل الذي يتسلل إلى التطبيقات القائمة على الخدمة الدقيقة أثناء حجمها في التعقيد. وإليك كيف:

نشر إصدارات متعددة الخدمات في وقت واحد

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

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

رؤية مفصلة في الاتصالات بين الخدمات

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

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

اختبار خدمة Microservice

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

شبكة الخدمة هي الطريقة المثلى لمحاكاة هذه الأخطاء في الأنظمة ودراسة الاستجابة المرتبطة بها.

خطأ التسامح

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

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

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

 

السابق:ما هو الكسوة المعمارية ؟

التالي:الكسوة شبكة معدنية موسعة من الألومنيوم

مقالات ذات صلة

leave your message