عندما تبدأ خدماتك الصغيرة في "الإخفاء والبحث": قم بحل مشاكل اكتشاف الخدمة

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

هذا هو ما يبدو تقريبًا في بنية الخدمات الصغيرة عندما تكتشف الخدمة مشكلة ما.

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

لماذا هذا الصداع؟

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

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

يؤدي هذا إلى السؤال الأساسي: في بيئة متغيرة ديناميكيًا، كيف يمكن للخدمات العثور على بعضها البعض تلقائيًا وتخصيص المهام بذكاء؟

نظام دليل أكثر "حيًا".

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

وهذا ما تفعله آلية اكتشاف الخدمة. يتكون عادةً من جزأين: سجل خدمة موثوق (مثل القائمة الديناميكية)، وآلية الاكتشاف (التي تسمح للخدمات بالاستعلام عن هذه القائمة).

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

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

بناء هذا الجسر في عالم جافا

هناك العديد من الأدوات الشائعة لتنفيذ هذه المجموعة من المنطق في Java. على سبيل المثال، تم تصميم Netflix Eureka ليكون خفيف الوزن ويمكن تسجيل الخدمة واكتشافها بسهولة. أما بالنسبة لـ Consul، فبالإضافة إلى اكتشاف الخدمة، فهو يأتي أيضًا مزودًا بفحص الصحة وتخزين القيمة الرئيسية، والذي يحتوي على المزيد من الوظائف. ظهر ZooKeeper في وقت سابق وهو مستقر، لكن إعداده يتطلب القليل من الجهد.

ما الذي تفكر فيه عند الاختيار؟ معرفة الفريق أمر مهم. هناك أيضًا دعم مجتمعي - عندما تواجه مشكلة ما، هل هناك الكثير من المعلومات التي يمكنك العثور عليها؟ هل يتناسب مع مكدس التكنولوجيا الخاص بك؟ على سبيل المثال، تشعر عائلة Spring Cloud براحة شديدة عند دمج Eureka. إذا كنت تستخدم Spring Boot، فقد يكون هذا المسار أكثر سلاسة.

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

تجنب المزالق الشائعة

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

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

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

من المفيد إلى المفيد: كن أكثر ذكاءً

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

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

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

لذلك، العودة إلى السؤال الأصلي

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

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

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

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

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