ما هو Service Discovery في Microservices

ما هو اكتشاف الخدمة؟ ولماذا تحتاج إليه؟

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

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

تغييرات عنوان IP قد تربك الزوار.

بإدخال DNS كآلية لاكتشاف الخدمة، يمكن الآن التعامل مع تغييرات IP بمرونة.

مقدمة عن أنظمة اكتشاف الخدمة الشائعة

كجزء من نظام اكتشاف الخدمة، يحتاج إلى تلبية أربع وظائف على الأقل:

1. واجهة برمجة التطبيقات (API) للتسجيل
2. واجهة برمجة التطبيقات (API) للاستعلام
3. التوفر العالي: بعد كل شيء، نظام اكتشاف الخدمة هو العصب الرئيسي للنظام بأكمله ولا يمكن أن يتعطل أو ينهار
4. النظام البيئي: كما نعلم جميعًا، المبرمجون كسالى ويفضلون وجود مكتبة يمكنها التفاعل مع واجهات برمجة التطبيقات بسهولة

لنلقي نظرة على بعض أنظمة اكتشاف الخدمة مفتوحة المصدر الشائعة في السوق:

Consul

Consul هو نظام اكتشاف خدمة طورته شركة Hashicorp، وهي شركة رائدة في البرمجيات مفتوحة المصدر. كبرنامج قديم أصدر نسخته الأولى في 17 أبريل 2014، يتمتع Consul بواحد من أغنى النظم البيئية وحتى لديه مطورون خارجيون يطورون SDK لـ Haskell له. معظم SDKs الخاصة بـ Consul هي مجرد غلاف لواجهة برمجة التطبيقات HTTP الخاصة به، لذا لا يوجد الكثير من العمل التطويري.

يدعم Consul تسجيل الخدمات والاستعلام عنها عبر واجهة برمجة التطبيقات HTTP. كما يدعم HTTP long polling لإرسال البيانات في الوقت المناسب أثناء الاستعلامات لتجنب الاقتراع. أيضًا، يدعم Consul الاستعلام عن مثيل الخدمة المقابلة عبر DNS.

يتميز نشر Consul بأن كل مثيل من Consul يسمى وكيلًا، والذي يمكن أن يكون عميلًا أو خادمًا. على جانب العميل، يحتفظ Consul بحالة العميل؛ على جانب الخادم، يدعم Consul النشر الموزع عبر خوارزمية الاتفاق Raft، لتحقيق التوفر العالي.

Eureka

Eureka هو مشروع مفتوح المصدر من Netflix، وهو أيضًا قديم جدًا (هناك آثار للتسجيلات تعود إلى عام 2012). ومع ذلك، لم يتم صيانة المشروع لمدة عام. قام العديد من المستخدمين بالانتقال إلى Nacos، والذي سيتم ذكره أدناه.

يدعم Eureka التفاعل عبر واجهة برمجة التطبيقات HTTP وSDK الخاص بـ Java. تم جلب العديد من مستخدمي Eureka في الواقع من خلال مشاريع في النظام البيئي لـ Java مثل Spring Cloud. تصميم Eureka للتوفر العالي، إذا كنت تريد وصفه بمصطلحات CAP (نظرية CAP تنص على أن النظام الموزع يمكنه توفير اثنين فقط من ثلاث خصائص في وقت واحد: الاتساق، التوفر، وتحمل التقسيم)، فهو AP، مما يسمح للعملاء برؤية بيانات منتهية الصلاحية عند تقسيم الشبكة، مما يتجنب الكوارث الثانوية بسبب مشاكل الشبكة.

Nacos

Nacos هو نظام اكتشاف خدمة طورته Alibaba، واسمه يأتي من تجميع الحروف الأولى من Naming وConfiguration Service. منذ إصدار النسخة 0.1.0 في 20 يوليو 2018، تطور Nacos الآن إلى النسخة 2.1.

مثل العديد من مشاريع Alibaba مفتوحة المصدر، يتمتع Nacos بشعبية كبيرة بين مطوري Java في الصين، وشعبيته أكبر حتى من Eureka.

يدعم تسجيل الخدمات والاستعلام عنها عبر واجهة برمجة التطبيقات HTTP وSDKs مثل Java/Go/Python/NodeJS/C#. حاليًا، يعمل مطورو Nacos أيضًا على واجهات برمجة تطبيقات جديدة تعتمد على gRPC. بالنسبة لواجهة برمجة التطبيقات HTTP، يدعم Nacos حاليًا فقط الاقتراع للحصول على قائمة الخدمات. لذا يفضل Nacos الرسمي نهج SDK، وهو نهج اقتراع + دفع يعتمد على UDP مع أداء أفضل في الوقت الفعلي. يعمل Nacos أيضًا على واجهات برمجة تطبيقات جديدة تعتمد على gRPC، والتي ستقدم قدرات دفع من جانب الخادم، وهي فائدة كبيرة لتلك الأنظمة التي لا يمكنها الوصول إلى SDK.

التوفر العالي لـ Nacos يرجع جزئيًا إلى قدرات الاستمرارية المقدمة في SDK العميل، وجزئيًا إلى اتساق جانب الخادم عبر كل من بروتوكولات Raft وDistro.

طرق الواجهة الشائعة ومزاياها وعيوبها

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

1. HTTP polling
2. DNS
3. HTTP long polling أو gRPC server streaming

HTTP polling سهل التنفيذ ولكنه ليس في الوقت الفعلي.

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

HTTP long polling أو gRPC server streaming هو الأكثر في الوقت الفعلي من بين الثلاثة. نظرًا لأن كلاهما يعتمدان على HTTP، يمكن تخصيص الاستجابة بسهولة. العيب هو أنهما صعبان نسبيًا في التنفيذ على جانب العميل.

كيف يتفاعل APISIX مع أنظمة اكتشاف الخدمة

كبوابة سحابية أصلية، يدعم APISIX جلب العقد الأعلى من نظام اكتشاف الخدمة وهو مصمم لدعم التفاعل مع نظام اكتشاف الخدمة على كل من مستوى البيانات ومستوى التحكم.

مستوى البيانات

يدعم APISIX التكامل مع DNS وEureka وConsul (وضع KV) وNacos وK8s على مستوى البيانات.

عند التفاعل مع خدمات DNS، سيستخدم APISIX سجلات SRV أو A/AAAA لـ DNS للحصول على العقدة الأعلى المحددة لخدمة ما. عند تقديم طلب للوصول إلى العقدة الأعلى، سيحاول أولاً جلبها من ذاكرة التخزين المؤقت لـ DNS. إذا لم يكن موجودًا، سيبدأ استعلام DNS للحصول على عنوان IP المحدد داخل السجل المقابل.

أما بالنسبة لأنواع اكتشاف الخدمة الأخرى، يتم مزامنتها في الخلفية. عند تقديم طلب للوصول إلى العقدة الأعلى، يتم جلب جزء البيانات المقابل لاسم الخدمة من البيانات المزامنة حاليًا. بالنسبة لـ K8s وConsul KV، يمكننا الحصول على عنوان IP المتغير في الوقت الفعلي بهذه الطريقة، حيث يدعمان HTTP long polling. بالنسبة لـ Eureka وNacos، نحن حاليًا نقوم فقط بالاقتراع للحصول على البيانات.

مستوى التحكم

يدعم APISIX أيضًا اكتشاف الخدمة على مستوى التحكم. نحن نعمل على apisix-seed، والذي سيقوم بمزامنة البيانات من نظام اكتشاف الخدمة إلى etcd بحيث يمكن لمستوى البيانات مزامنة أحدث العقد الأعلى من etcd.

لقد قمنا الآن بتنفيذ دعم لـ Nacos وZookeeper على مستوى التحكم. نظرًا لأن دعم اكتشاف الخدمة على مستوى التحكم يتم عبر SDK الرسمي، فإنه يتمتع بمزايا غير متوفرة مع طريقة HTTP العادية. على سبيل المثال، في تنفيذ apisix-seed لـ Nacos، ندعم الدفع القائم على UDP، لذا تكون البيانات أكثر كفاءة في الوقت من HTTP polling.

مزايا دعم APISIX لسيناريوهات اكتشاف الخدمة

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

هذه ميزة يمكن أن تقلل بشكل كبير من كمية العمل المطلوبة عند نقل بوابة، على سبيل المثال، من Spring Cloud Gateway إلى APISIX. إذا كان Spring Cloud Gateway يستخدم لتطبيق Eureka أو Nacos لاكتشاف الخدمة، يمكن إجراء الانتقال إلى النظام الجديد ببساطة عن طريق تمكين دعم Eureka أو Nacos داخل APISIX.

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

لنقتبس النص الأصلي لقرض هوان بي:

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

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

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

في المستقبل، سندعم أيضًا تكامل مكونات تسجيل الخدمة واكتشافها المختلفة على APISIX Ingress Controller لتسهيل استخدام المستخدمين. في ذلك الوقت، سيتمكن المستخدمون ليس فقط من تحديد نقاط نهاية خدمة K8s كعقد أعلى على APISIX Ingress Controller، ولكن أيضًا من دمج العقد التي تم الحصول عليها بواسطة اكتشاف الخدمة.