شبكة الخدمة هي نمط معماري مشهور لدمج الخدمات الصغيرة والانتقال إلى البنية التحتية السحابية. من الصعب للغاية الاستغناء عنه في عالم الحوسبة السحابية. تتوفر بالفعل العديد من تطبيقات شبكة الخدمة مفتوحة المصدر في السوق ، لكن وظائفها وموثوقيتها وأمانها ليست كافية دائمًا ، لا سيما عندما يتعلق الأمر بمتطلبات الشركات المالية الكبيرة في جميع أنحاء البلاد. لذلك ، قررنا في Sbertech تخصيص "شبكة الخدمة" ونريد التحدث حول ما هو رائع في "شبكة الخدمة" ، وما هو غير جيد وما الذي سنفعله به.
تزداد شعبية قالب شبكة الخدمة مع تزايد شعبية التكنولوجيا السحابية. إنها طبقة بنية أساسية مخصصة تعمل على تبسيط التفاعل بين خدمات الشبكات المختلفة. تتكون التطبيقات السحابية الحديثة من مئات بل وآلاف من هذه الخدمات ، يمكن لكل منها الحصول على آلاف النسخ.
يمثل التفاعل بين هذه الخدمات وإدارتها مهمة رئيسية لشبكة الخدمة. في الواقع ، هذا نموذج شبكة من مجموعة متنوعة من الوكلاء ، تتم إدارته مركزيًا وتؤدي مجموعة من الوظائف المفيدة للغاية.
على مستوى الوكيل (مستوى البيانات):- تعيين سياسات التوجيه وحركة المرور وتوزيعها
- توزيع المفاتيح والشهادات والرموز
- جمع القياس عن بعد ، وتشكيل مقاييس الرصد
- التكامل مع الأمن ومراقبة البنية التحتية
على مستوى طائرة التحكم:- تطبيق سياسات التوجيه وموازنة حركة المرور
- إدارة عمليات إعادة المحاولة والمهلة الزمنية ، وتعريف العقد "الميتة" (كسر الدائرة) ، وإدارة المواقف الخاطئة (أخطاء الحقن) وضمان مرونة الخدمات من خلال آليات أخرى
- استدعاء المصادقة / التفويض
- تجاهل المقاييس (الملاحظة)
دائرة المستخدمين المهتمين بتطوير هذه التكنولوجيا واسعة للغاية - من الشركات الناشئة الصغيرة إلى شركات الإنترنت الكبيرة ، على سبيل المثال ، PayPal.
ما هي شبكة الخدمة في قطاع الشركات؟
باستخدام شبكة الخدمة يجلب العديد من الفوائد الواضحة. أولاً وقبل كل شيء ، إنه مناسب للمطورين:
تظهر منصة تقنية لكتابة التعليمات البرمجية التي تعمل على تبسيط الاندماج بشكل كبير في البنية التحتية السحابية نظرًا لحقيقة أن طبقة النقل معزولة تمامًا عن منطق التطبيق.
بالإضافة إلى ذلك ،
تبسط Service Mesh العلاقة بين الموردين والمستهلكين. اليوم ، أصبح من الأسهل بكثير على الموردين والمستهلكين لواجهة برمجة التطبيقات الاتفاق على واجهات وعقود خاصة بهم ، دون إشراك وسيط تكامل خاص ومحكّم لهذا - حافلة خدمة للشركات. يؤثر هذا النهج بشكل كبير على مؤشرين. تتزايد سرعة تقديم وظائف جديدة إلى السوق (الوقت إلى السوق) ، ولكن في نفس الوقت ترتفع تكلفة الحل ، حيث يجب أن يتم التكامل بشكل مستقل. استخدام شبكة الخدمة من قبل فرق تطوير الأعمال يساعد في الحفاظ على التوازن هنا. ونتيجة لذلك ، يمكن لمقدمي واجهة برمجة التطبيقات التركيز بشكل حصري على مكون التطبيق في خدمتهم وببساطة نشره في شبكة الخدمة - ستصبح واجهة برمجة التطبيقات متوفرة على الفور لجميع العملاء ، وستكون جودة التكامل جاهزة للإنتاج ولن تتطلب سطرًا واحدًا من التعليمات البرمجية الإضافية.
ميزة أخرى هي أن
المطور ، باستخدام Service Mesh ، يركز فقط على وظائف العمل - على المنتج وليس على المكون التكنولوجي لخدمته. على سبيل المثال ، لا يتعين عليك التفكير في حقيقة أنه في حالة استدعاء الخدمة عبر الشبكة ، قد ينقطع الاتصال. بالإضافة إلى ذلك ، تساعد شبكة الخدمة في موازنة حركة المرور بين نسخ الخدمة نفسها: إذا ماتت إحدى النسخ ، فسيقوم النظام بتحويل كل حركة المرور إلى النسخ الحية المتبقية.
تعد
شبكة الخدمة أساسًا جيدًا لإنشاء تطبيقات موزعة ، حيث تخفي عن العميل تفاصيل تقديم مكالمات إلى خدماته داخليًا وخارجيًا. يتم عزل جميع التطبيقات التي تستخدم Service Mesh على طبقة النقل من الشبكة ومن بعضها البعض: لا يوجد اتصال بينها. في هذه الحالة ، يحصل المطور على السيطرة الكاملة على خدماته.
تجدر الإشارة إلى أن
تحديث التطبيقات الموزعة في بيئة تستخدم فيها شبكة الخدمة أصبح أكثر سهولة. على سبيل المثال ، النشر باللون الأزرق / الأخضر ، حيث تتوفر بيئتان للتطبيق للتثبيت ، واحدة منها لا يتم تحديثها وهي في وضع الاستعداد. يتم الرجوع إلى الإصدار السابق في حالة الإصدار غير الناجح بواسطة جهاز توجيه خاص ، وهو دور تتوافق "شبكة الخدمة" معه بشكل مثالي
. يمكنك استخدام
إصدار الكناري للتشغيل في الإصدار الجديد - قم بتبديل 10٪ فقط من حركة المرور أو الطلبات من مجموعة العملاء التجريبية إلى الإصدار الجديد. حركة المرور الرئيسية يذهب إلى الإصدار القديم ، لا شيء يكسر.
شبكة الخدمة تعطينا أيضا سيطرة SLA في الوقت الحقيقي . لن يسمح نظام الوكلاء الموزعين بإغراق الخدمة عندما يتجاوز أحد العملاء الحصة الصادرة لها. إذا كان النطاق الترددي لواجهة برمجة التطبيقات محدودًا ، فلن يتمكن أي شخص من خنقها بعدد كبير من المعاملات: شبكة الخدمة أمام الخدمة ولا تسمح بحركة مرور إضافية. سوف تنجح ببساطة في طبقة التكامل ، وستستمر الخدمات نفسها في العمل دون ملاحظة ذلك.
إذا كانت الشركة ترغب في خفض تكلفة تطوير حلول التكامل ، فإن Service Mesh تساعد أيضًا:
يمكنك التبديل إلى إصدارها المفتوح المصدر من المنتجات التجارية . تعتمد Enterprise Service Mesh لدينا على الإصدار المفتوح المصدر من Service Mesh.
ميزة أخرى هي
توافر مجموعة واحدة كاملة من خدمات التكامل . نظرًا لأن كل التكامل مبني من خلال هذه الطبقة الوسيطة ، يمكننا إدارة كل حركة تكامل الاتصالات والاتصالات بين التطبيقات التي تشكل جوهر أعمال الشركة. انها مريحة جدا.
أخيرًا ،
تدفع Service Mesh الشركة إلى الانتقال إلى بنية أساسية حيوية. الآن العديد من يتطلع نحو حاويات. من خلال نشر متراصة في الخدمات المصغرة ، من الجميل أن يتم تنفيذها بالكامل - الموضوع آخذ في الازدياد. ولكن عندما تحاول نقل نظام جديد يعمل منذ سنوات عديدة إلى مسار جديد ، فإنك تواجه على الفور عددًا من المشاكل: دفع كل شيء إلى حاويات ونشره على النظام الأساسي ليس بالأمر السهل. وتنفيذ وتزامن وتفاعل هذه المكونات الموزعة هو موضوع صعب آخر. كيف سيتواصلون مع بعضهم البعض؟ هل سيكون هناك إخفاقات متتالية؟ تتيح لك Service Mesh حل بعض هذه المشكلات وتسهيل الانتقال من البنية القديمة إلى الجديدة نظرًا لحقيقة أنه يمكنك نسيان منطق تبادل الشبكات.
لماذا تخصيص شبكة الخدمة
في شركتنا ، تتعايش مئات الأنظمة والوحدات معًا ، ووقت التشغيل مشغول جدًا. لذا فإن النمط البسيط ، عندما يتصل نظام ما بنظام آخر ويتلقى إجابة ، لا يكفي ، لأننا في الإنتاج نريد المزيد. أكثر ما تحتاجه من شبكة خدمة الشركات؟
خدمة معالجة الأحداث
تخيل أننا بحاجة إلى إجراء حدث في الوقت الفعلي - وهو نظام يقوم في الوقت الفعلي بتحليل تصرفات العميل ويمكنه على الفور تقديم عرض مناسب له. لتنفيذ هذه الوظيفة ، يتم استخدام
نمط معماري يسمى هندسة تستند إلى الحدث (EDA) . لا تدعم أيا من شبكة الخدمة ذات الصلة مثل هذه الأنماط ، ولكن هذا مهم للغاية ، خاصة بالنسبة للبنك!
من الغريب أن استدعاء الإجراء عن بُعد (RPC) يدعم جميع إصدارات شبكة الخدمة ، وأنهم ليسوا أصدقاء مع EDA. نظرًا لأن Service Mesh عبارة عن شكل من أشكال التكامل الموزع الحديث ، و EDA هو نمط معماري مناسب جدًا يتيح لك القيام بأشياء فريدة فيما يتعلق بتجربة العملاء.
يجب أن تحل شبكة خدمة المؤسسة الخاصة بنا هذه المشكلة. بالإضافة إلى ذلك ، نريد أن نرى فيه تنفيذ مضمون للتسليم والبث ومعالجة الأحداث المتكاملة باستخدام مجموعة متنوعة من المرشحات والقوالب.
خدمة نقل الملفات
بالإضافة إلى EDA ، سيكون من اللطيف أن تكون قادرًا على نقل الملفات: على نطاق المؤسسة ، يكون تكامل الملف ممكنًا في أغلب الأحيان. على وجه الخصوص ، يتم استخدام نمط ETL المعماري (استخراج ، تحويل ، تحميل - "استخراج ، تحويل ، تحميل"). كقاعدة عامة ، يتبادل الجميع الملفات حصريًا: يستخدمون بيانات كبيرة ، وهذا غير عملي للتقدم في طلبات منفصلة. توفر لك القدرة على دعم عمليات نقل الملفات في Enterprise Service Mesh المرونة التي تحتاجها لعملك.
خدمة الاوركسترا
في المنظمات الكبيرة ، هناك دائمًا فرق مختلفة تصنع منتجات مختلفة. على سبيل المثال ، في أحد البنوك ، تعمل بعض الفرق مع الودائع ، بينما يعمل البعض الآخر مع منتجات ائتمانية ، وهناك الكثير من هذه الحالات. هؤلاء هم أشخاص مختلفون وفرق مختلفة تصنع منتجاتها وتطور واجهات برمجة التطبيقات الخاصة بها وتقدمها للآخرين. وغالبًا ما تكون هناك حاجة لتكوين هذه الخدمات ، وكذلك تنفيذ المنطق المعقد للدعوة التسلسلية لمجموعة API. لحل هذه المشكلة ، هناك حاجة إلى حل في طبقة التكامل ، والتي من شأنها تبسيط كل هذا المنطق المركب (استدعاء العديد من واجهات برمجة التطبيقات ، ووصف مسار الطلبات ، وما إلى ذلك). هذه هي خدمة التنسيق في Enterprise Service Mesh.
منظمة العفو الدولية و ML
عندما تتواصل الخدمات الميكروية من خلال طبقة تكامل واحدة ، فإن Service Mesh ، بالطبع ، يعرف كل شيء عن مكالمات كل خدمة. نحن نجمع القياس عن بعد: من اتصل بمن ، ومتى ، والوقت ، وعدد المرات ، وهلم جرا. عندما يكون هناك مئات الآلاف من هذه الخدمات والمليارات من المكالمات ، كل هذا يتراكم ويشكل بيانات كبيرة. يمكن تحليل هذه البيانات باستخدام الذكاء الاصطناعي والتعلم الآلي وما إلى ذلك ، ثم القيام ببعض الأشياء المفيدة بناءً على نتائج التحليل. سيكون من المناسب على الأقل نقل جزئي إلى ذكاء اصطناعي إدارة كل حركة مرور الشبكة ومكالمات التطبيقات المدمجة في شبكة الخدمة.
خدمة بوابة API
كقاعدة عامة ، تحتوي شبكة الخدمة على وكلاء وخدمات تصل إلى بعضهم البعض داخل المحيط الموثوق به. ولكن هناك أيضا نظراء الخارجية. متطلبات واجهة برمجة التطبيقات لهذه المجموعة من العملاء أكثر خطورة. نقسم هذه المهمة إلى قسمين رئيسيين.
- الأمن. المشكلات المتعلقة ddos ، تعرض البروتوكولات والتطبيقات وأنظمة التشغيل وما إلى ذلك.
- النطاق . عندما تذهب فاتورة واجهة برمجة التطبيقات (API) التي يجب تقديمها للعملاء إلى الآلاف أو حتى مئات الآلاف ، فهناك حاجة لبعض الوسائل لإدارة مجموعة واجهات برمجة التطبيقات هذه. تحتاج إلى مراقبة واجهة برمجة التطبيقات (API) باستمرار: هل تعمل أم لا ، وفي أي حالة ، وما حركة المرور الجارية ، والإحصاءات ، وما إلى ذلك. يجب أن تتعامل بوابة API مع هذه المهمة ، مما يجعل العملية بأكملها قابلة للإدارة وآمنة. بفضل هذا المكون ، تتعلم Enterprise Service Mesh نشر واجهات برمجة التطبيقات الداخلية والخارجية دون صعوبة كبيرة.
خدمة الدعم لبروتوكولات معينة وتنسيقات البيانات (بوابة AS)
حاليًا ، لا يمكن لمعظم حلول شبكة الخدمة أن تعمل إلا بشكل أصلي مع زيارات HTTP و HTTP2 أو في الوضع المقطوع على مستوى TCP / IP. يحتوي Enterprise Service Mesh على العديد من بروتوكولات نقل البيانات المحددة للغاية. قد تستخدم بعض الأنظمة سماسرة الرسائل ؛ بينما يتم دمج أنظمة أخرى على مستوى قاعدة البيانات. إذا كانت الشركة لديها SAP ، فيمكنها أيضًا استخدام نظام التكامل الخاص بها. وكل هذا يعمل وهو جزء مهم من العمل.
لا يمكنك قول مجرد: "دعنا نتخلى عن إرثنا وننشئ أنظمة جديدة يمكنها استخدام شبكة الخدمة". لتكوين صداقات لجميع الأنظمة القديمة بأخرى جديدة (على هندسة الخدمات المصغرة) ، ستحتاج الأنظمة التي يمكنها استخدام Service Mesh إلى نوع من المحولات والوسائط والبوابات. موافق ، سيكون من الرائع أن يتم تسليمه في صندوق مع الخدمة. بوابة AS يمكن أن تدعم أي خيار التكامل. فقط تخيل أنك تقوم فقط بتثبيت شبكة خدمة Enterprise وهي جاهزة للتفاعل مع جميع البروتوكولات التي تحتاج إليها. بالنسبة لنا ، هذا النهج مهم جدا.
هذه هي الطريقة التي نقدم بها إصدار الشركة من شبكة الخدمة (Enterprise Service Mesh). التخصيص الموصوف يحل معظم المشكلات التي تنشأ عند محاولة استخدام إصدارات مفتوحة المصدر جاهزة من منصة التكامل. بعد ظهوره منذ عامين فقط ، تستمر بنية Service Mesh في التطور ، ويسعدنا أن نتمكن من المساهمة في تطويرها. نأمل أن تكون خبرتنا مفيدة لك.