استكشاف فوائد استخدام بوابة API لـ Kafka

مقدمة موجزة عن Kafka

تم إنشاء Kafka في الأصل بواسطة LinkedIn كنظام مراسلة موزع يعتمد على تنسيق Zookeeper ويتضمن أقسامًا ونسخًا متعددة. تم التبرع به لاحقًا لمؤسسة Apache Software Foundation. بفضل إمكانياته الاستثنائية في الإنتاجية، والاستمرارية، وقدرات التوسع الأفقي، أصبح Kafka منصة معالجة تدفق موزعة معتمدة على نطاق واسع في الصناعة.

لدى Kafka ثلاث حالات استخدام رئيسية:

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

البنية الفنية لـ Kafka

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

المفاهيم الأساسية

موضوع Kafka والقسم

في Kafka، يتم تصنيف الرسائل حسب الموضوعات. عادة ما يحدد المنتجون موضوعًا عند إرسال الرسائل، بينما يقوم المستهلكون عادة بالاشتراك في موضوع لاستهلاك الرسائل.

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

المنتج والمستهلك

المنتج يشير إلى الطرف الذي يرسل الرسائل، وهو مسؤول عن إنشاء الرسائل وإرسالها إلى وسطاء Kafka.

المستهلك يشير إلى الطرف الذي يستقبل الرسائل، وهو مسؤول عن الاتصال بوسيط مجموعة Kafka، والاشتراك في موضوع معين، واستهلاك الرسائل.

وسطاء Kafka

يمكن اعتبار الوسيط كعقدة أو مثيل مستقل لـ Kafka. تتكون مجموعة Kafka من وسيط واحد أو أكثر.

لماذا يحتاج Kafka إلى بوابة API

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

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

الاتصال المباشر بـ Kafka

يمكن أن يؤدي الاتصال المباشر بـ Kafka إلى عدد من القيود والمخاطر عند استخدامه كوسيط قائمة انتظار الرسائل:

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

بوابة API تعزز قابلية استخدام Kafka

تحويل بروتوكول الاتصال

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

تحديد المعدل

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

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

من خلال تنفيذ وظائف تحديد المعدل هذه، يمكن حماية عقد Kafka بشكل فعال، مما يضمن استقرارها.

دعم المصادقة

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

قدرة المراقبة

هناك حاليًا العديد من منتجات المراقبة المتاحة لـ Kafka، مثل Kafka Eagle، Kafka Monitor، Kafka Manager، إلخ. لكل منها مزاياها وعيوبها. من الصعب تحقيق قدرة مراقبة عالمية، وتكاليف التخصيص مرتفعة نسبيًا. علاوة على ذلك، يمكن أن يكون دمجها مع أنظمة المراقبة الداخلية صعبًا. بناء نظام مراقبة Kafka من الصفر مكلف أيضًا، حيث تغطي معلومات المراقبة لـ Kafka العديد من الجوانب، وتتطلب مقاييس المراقبة التي يوفرها Kafka نفسها معالجة معقدة من خلال Java Management Extension (JMX).

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

التحديثات المتتالية لـ Kafka

يتم عرض خدمات Kafka من خلال عناوين الوسطاء، والتي يحتاج المنتجون والمستهلكون إلى توفيرها في معلومات التكوين الخاصة بهم للاتصال بمجموعة Kafka. عادة ما يتم تنسيق قائمة العناوين كـ host1:port1، host2:port2، ويمكن أن تحتوي على عنوان واحد أو أكثر مفصولة بفواصل.

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

مع بوابة API لـ Kafka، يمكن تكوين عناوين الوسطاء في طبقة البوابة، ولا يحتاج العملاء بعد الآن إلى التركيز على التفاصيل المحددة لوسطاء Kafka. حتى إذا تغير عنوان الوسيط، يظل العملاء غير متأثرين. هذا يجعل من السهل إجراء تحديثات متتالية لـ Kafka دون القلق بشأن تأثيرها على العملاء.

ملخص

وبالتالي، من خلال إضافة بوابة API إلى Kafka، يصبح من السهل توفير وظائف تحديد المعدل، والمصادقة، والمراقبة، والتحديثات المتتالية لخدمات Kafka من خلال الوظائف الغنية لبوابة API.

استخدام Apache APISIX لتوسيع Kafka

Apache APISIX هو بوابة API عالية الأداء وفورية تحت مؤسسة Apache Software Foundation. يوفر مجموعة من ميزات إدارة حركة المرور المتطورة، بما في ذلك موازنة الحمل، والخدمات العلوية الديناميكية، الإصدار التدريجي، وكسر الدائرة، المصادقة، والمراقبة. كبوابة API، يساعد APISIX الشركات على معالجة حركة المرور للواجهات البرمجية والخدمات الصغيرة بسرعة وأمان ويستخدم على نطاق واسع في Kubernetes Ingress وشبكة الخدمات. من خلال إضافة طبقة APISIX أمام خدمة Kafka، يمكن للشركات الاستفادة من نظام البرمجيات الغني للمنصة لتمكين وكالة الرسائل، وتسليم السجلات، وتحديد المعدل، والمراقبة، وغيرها من القدرات. مع APISIX، يمكن معالجة حركة المرور من الشمال إلى الجنوب من العملاء إلى الخوادم وحركة المرور من الشرق إلى الغرب بين الخدمات الصغيرة للشركات بشكل فعال.

وكالة رسائل Kafka

يوفر APISIX القدرة على وكالة رسائل Kafka. يمكن للعملاء التواصل مباشرة مع APISIX، الذي يتعامل مع تحويل بروتوكول الرسائل بين العملاء و Kafka.

لتمكين ميزة وكالة Kafka في APISIX، نحتاج فقط إلى إضافة مسار كما يلي:

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/Kafka' \
    -H 'X-API-KEY: <api-key>' \
    -H 'Content-Type: application/json' \
    -d '{
    "uri": "/Kafka",
    "plugins": {
        "Kafka-proxy": {
            "sasl": {
                "username": "user",
                "password": "pwd"
            }
        },
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 503,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
    "upstream": {
        "nodes": {
            "Kafka-server1:9092": 1,
            "Kafka-server2:9092": 1,
            "Kafka-server3:9092": 1
        },
        "type": "none",
        "scheme": "Kafka"
    }
}'

يقوم هذا الطلب بإنشاء مسار مع URI /Kafka في APISIX، والذي يرتبط بثلاث عقد وسطاء Kafka كخدمات علوية. يتم استخدام المكون الإضافي kafka-proxy لإضافة مصادقة SASL/PLAIN لطلبات Kafka. يدعم التكوين في APISIX التحديثات الساخنة، لذلك يمكن تعديل وسطاء Kafka دون الحاجة إلى إعادة تشغيل بوابة API أو تعطيل العميل.

بالإضافة إلى ذلك، يتم تمكين المكون الإضافي limit-count لهذا المسار لتوفير دعم لتحديد المعدل. يحدد تكوين المكون الإضافي أنه يُسمح بمرور طلبين فقط خلال فترة 60 ثانية، وسيتم رفض أي طلبات إضافية بواسطة APISIX برمز حالة 503.

دفع السجلات

يسمح المكون الإضافي kafka-logger في APISIX بدفع السجلات ككائنات JSON إلى مجموعة Apache Kafka.

إليك مثال على التكوين:

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
       "kafka-logger": {
            "brokers" : [
              {
                "host" :"127.0.0.1",
                "port" : 9092
              },
              {
                "host" :"127.0.0.1",
                "port" : 9093
              }
            ],
           "kafka_topic" : "test2",
           "key" : "key1"
       }
    },
    "upstream": {
       "nodes": {
           "127.0.0.1:1980": 1
       },
       "type": "roundrobin"
    },
    "uri": "/hello"
}'

يوفر APISIX أكثر من مجرد القدرة على وكالة رسائل Kafka. كما يوفر التتبع، والمقاييس، وتسجيل السجلات من خلال مكونات إضافية مختلفة، تغطي جميع جوانب المراقبة. مع تكوين بسيط للمكونات الإضافية على APISIX، يمكن التكامل مع خدمات مراقبة أخرى مثل Prometheus، و Skywalking، وغيرها، مما يعزز قدرات مراقبة مجموعات Kafka.

ملخص

تسلط هذه المقالة الضوء على مزايا تنفيذ بوابة API لـ Kafka، وتستخدم Apache APISIX كدراسة حالة لتوضيح كيف يوفر ميزات مثل تحديد المعدل، والمصادقة، والمراقبة، والتحديثات المتتالية لـ Kafka.