اكتشاف الخدمة في الأنظمة الموزعة على سبيل المثال القنصل. الكسندر سيغاتشيف

أقترح أن تتعرف على نص تقرير ألكسندر سيغاتشيف عن خدمة الاكتشاف في الأنظمة الموزعة باستخدام Consul كمثال.

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

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

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

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

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

ما الأشياء الأخرى التي يسهل القيام بها باستخدام اكتشاف الخدمة؟ يمكن لـ Service Discovery تخزين تكوينات nginx ، والشهادات ، وقائمة بخوادم الواجهة الخلفية النشطة.

يتيح لك اكتشاف الخدمة أيضًا اكتشاف الفشل واكتشاف الأعطال. ما هي المخططات المحتملة عند اكتشاف حالات الفشل؟

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

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

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

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

ما هو القنصل؟

• بادئ ذي بدء ، إنه اكتشاف الخدمة.

• لديها آلية للتحقق من التوفر - التحقق من الصحة.

• لديه أيضًا متجر KV.

• ويستند إلى القدرة على استخدام Multi Datacenter.

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

دعونا نلقي نظرة على المصطلحات المستخدمة في القنصل.

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

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

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

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

ما API التي يوفرها القنصل؟ من أجل الحصول على المعلومات ، لدى القنصل نوعان من واجهات برمجة التطبيقات.

هذا هو DNS API. بشكل افتراضي ، يعمل Consul على المنفذ 8600. يمكننا تكوين طلب وكيل وتوفير الوصول من خلال حل محلي ، من خلال DNS المحلي. يمكننا الاستعلام حسب المجال والحصول على معلومات الرد حول عنوان IP.

HTTP API - أو يمكننا طلب معلومات حول خدمة معينة محليًا على المنفذ 8500 والحصول على استجابة JSON ، ما هو IP الذي يمتلكه الخادم ، والمضيف ، والمنفذ المسجل. ويمكن تمرير معلومات إضافية عبر الرمز المميز.

ماذا تحتاج لتشغيل القنصل؟

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

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

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

كيف يتم تقديم الشيكات الصحية؟ في دليل تكوين القنصل ، نكتب قاعدة تحقق في شكل Json. الخيار الأول هو التوفر في هذا المثال لنطاق google.com. ونقول إنه بعد فاصل زمني مدته 30 ثانية ، عليك إجراء هذا الفحص. وبالتالي ، نتحقق من أن العقدة لديها وصول إلى الشبكة الخارجية.

الخيار الثاني هو اختبار نفسك. نستخدم الضفيرة المعتادة لسحب المضيف المحلي على المنفذ المحدد بفاصل 10 ثوانٍ.

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

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

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

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

يمكنك أيضًا إرسال معلومات إلى القنصل حول حالة الأقراص ، حول متوسط ​​الحمل.

الأسئلة

سؤال: لدينا حاوية رصيف ، كيف نستخدمها مع القنصل؟

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

س: هل يقوم القنصل نفسه بتشغيل حاوية الرصيف؟

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

سؤال: اتضح أنه داخل حاوية عامل الإرساء التي نحاول توصيلها بـ Service Discovery ، يجب أن يكون هناك نوع من المنطق يمكن أن يعطي بيانات إلى القنصل؟

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

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

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

سؤال: هل يمكن نشر هذا على الإنترنت؟

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

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

الجواب: لست متأكدا من وجود تفاصيل الشيكات.

سؤال: الحالة الراهنة ليست مهمة بقدر أهمية الديناميكيات.

الجواب: للتحليل ، نعم.

سؤال: هل من الأفضل عدم استخدام خدمة اكتشاف القنصل عامل ميناء؟

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

سؤال: هل المخطط مع قائد الخادم يبطئ بدء التطبيق ككل؟ وكيف يحدد القنصل قائدًا جديدًا إذا كان هذا الشخص كاذبًا؟

الجواب: لقد وصفوا البروتوكول بأكمله. إذا كنت مهتمًا ، يمكنك القراءة.

سؤال: القنصل يعمل كخادم كامل وكل الطلبات تطير من خلاله؟

الإجابة: لا يعمل كخادم كامل ، ولكنه يأخذ منطقة معينة. وعادة ما ينتهي بـ service.consul. وبعد ذلك نذهب منطقيا. نحن لا نستخدم أسماء النطاقات في الإنتاج ، أي البنية التحتية الداخلية ، والتي عادة ما تكون مخفية خلف التخزين المؤقت للخادم إذا عملنا عبر DNS.

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

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

الدردشة على منتجات hashicorp - دردشة مستخدمي Hashicorp: القنصل ، البدوي ، Terraform

ملاحظة بخصوص الفحوصات الصحية. يستخدم القنصل ، مثل Kubernetes ، نفس النظام للتحقق من الحالة الصحية للخدمة بناءً على حالة الرمز.

200 OK for healthy
503 Service Unavailable for unhealthy

مصادر:
https://www.consul.io/docs/agent/checks.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://thoslin.github.io/microservice-health-check-in-kubernetes/

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