لماذا نصنع شبكة خدمة المؤسسة

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

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

يعد التفاعل بين هذه الخدمات وإدارتها مهمة أساسية لـ Service Mesh. في الواقع ، هذا نموذج شبكة للعديد من الوكلاء ، تتم إدارته مركزيًا ويؤدي مجموعة من الوظائف المفيدة جدًا.

على مستوى الوكيل (مستوى البيانات):

• تعيين ونشر سياسات موازنة التوجيه وحركة المرور
• توزيع المفاتيح والشهادات والرموز
• مجموعة من القياس عن بعد ، وتشكيل مقاييس المراقبة
• التكامل مع البنية التحتية للأمن والمراقبة

على مستوى مستوى التحكم:

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

دائرة المستخدمين المهتمين بتطوير هذه التكنولوجيا واسعة جدًا - من الشركات الناشئة الصغيرة إلى شركات الإنترنت الكبيرة ، مثل PayPal.

لماذا تحتاج إلى Service Mesh في قطاع الشركات

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

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

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

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

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

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

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

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

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

لماذا يعد تخصيص شبكة الخدمة ضروريًا

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

خدمة التعامل مع الحدث

دعنا نتخيل أننا بحاجة إلى إجراء معالجة الأحداث في الوقت الفعلي - وهو نظام يحلل تصرفات العميل في الوقت الفعلي ويمكنه على الفور تقديم عرض مناسب له. لتنفيذ هذه الوظيفة ، استخدم نمط معماري يسمى العمارة المدفوعة بالحدث (EDA). لا يدعم أي من Service Mesh الحالية مثل هذه الأنماط ، وهذا مهم للغاية ، خاصة بالنسبة للبنك!

من الغريب أن يتم دعم "استدعاء الإجراء البعيد" (RPC) بواسطة جميع إصدارات Service Mesh ، لكنهم ليسوا أصدقاء مع EDA. لأن Service Mesh هي نوع من التكامل الموزع الحديث ، و EDA هو نمط معماري وثيق الصلة للغاية يسمح لك بالقيام بأشياء فريدة من حيث تجربة العملاء.

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

خدمة نقل الملفات

بالإضافة إلى EDA ، سيكون من الجيد أن تكون قادرًا على نقل الملفات: على نطاق Enterprise ، غالبًا ما يكون تكامل الملفات فقط ممكنًا. على وجه الخصوص ، يتم استخدام النمط المعماري ETL (استخراج وتحويل وتحميل). في ذلك ، كقاعدة عامة ، يتبادل الجميع الملفات حصريًا: يتم استخدام البيانات الضخمة ، وهو أمر غير مناسب للدفع بطلبات منفصلة. تمنحك القدرة على دعم نقل الملفات أصليًا في Enterprise Service Mesh المرونة التي يحتاجها عملك.

خدمة التنظيم

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

AI و ML

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

خدمة بوابة API (بوابة API)

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

• أمن. المشكلات المتعلقة بـ ddos ​​ونقاط ضعف البروتوكول والتطبيقات وأنظمة التشغيل وما إلى ذلك.
• حجم. عندما يصل عدد واجهات برمجة التطبيقات التي سيتم منحها للعملاء إلى الآلاف أو حتى مئات الآلاف ، فهناك حاجة إلى نوع من أدوات الإدارة لهذه المجموعة من واجهات برمجة التطبيقات. أنت بحاجة إلى مراقبة واجهة برمجة التطبيقات باستمرار: سواء كانت تعمل أم لا ، وفي أي حالة ، وما هي حركة المرور القادمة ، وما هي الإحصاءات ، وما إلى ذلك. يجب أن تكون بوابة API قادرة على التعامل مع هذه المهمة ، مما يجعل العملية برمتها قابلة للإدارة وآمنة. بفضل هذا المكون ، تتعلم Enterprise Service Mesh كيفية نشر كل من واجهة برمجة التطبيقات الداخلية وواجهة برمجة التطبيقات الخارجية بسهولة.

خدمة الدعم لبروتوكولات وتنسيقات بيانات محددة (بوابة AS)

في الوقت الحالي ، يمكن أن تعمل معظم حلول Service Mesh في الأصل فقط مع حركة مرور HTTP و HTTP2 أو في وضع مبتور على مستوى TCP / IP. لدى Enterprise Service Mesh العديد من بروتوكولات نقل البيانات المحددة للغاية. قد تستخدم بعض الأنظمة وسطاء الرسائل ، بينما يتم دمج البعض الآخر على مستوى قاعدة البيانات. إذا كان لدى الشركة SAP ، فيمكنها أيضًا استخدام نظام التكامل الخاص بها. وكل هذا يعمل ويشكل جزءًا مهمًا من العمل.

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

هذه هي الطريقة التي نقدم بها إصدار الشركة من Service Mesh (شبكة خدمة المؤسسة). يحل التخصيص الموصوف معظم المشكلات التي تنشأ عند محاولة استخدام إصدارات جاهزة مفتوحة المصدر لمنصة التكامل. بعد أن ظهرت قبل عامين فقط ، تستمر بنية Service Mesh في التطور ، ويسعدنا أن نكون قادرين على المساهمة في تطويرها. نأمل أن تكون تجربتنا مفيدة لك.

المصدر: www.habr.com