SNS vs SQS vs Kinesis: توقف عن التخمين وابدأ الاختيار الصحيح

SNS vs SQS vs Kinesis: توقف عن التخمين وابدأ الاختيار الصحيح

لأكون صريحًا معكم: أول مرة اضطررت فيها للاختيار بين SNS وSQS، جلست أحدق في شاشة AWS لمدة 40 دقيقة، فتحت سبعة تبويبات، وفي النهاية ظللت أشك في قراري. كان ذلك منذ سنوات، واليوم لدى AWS ستة—نعم، ستة—خدمات مختلفة لتوصيل الأحداث. حتى المعماريين الكبار يشعرون بالارتباك.

لكن الحقيقة أن هذه ليست مشكلة صعبة، فقط حين تتوقف عن التفكير في الخدمات نفسها وتبدأ التفكير في **شكل البيانات**. هل تحتاج دفع (push) أم سحب (pull)؟ إعادة قراءة؟ بث متعدد (fan-out)؟ توجيه مبني على المحتوى؟ هذا هو القرار الفعلي.

دعني أوضحها لك من خلال إطار كنت أتمنى أن أعرفه في ذلك الوقت.

المتنافسون (نظرة سريعة، انطباعية)

SNS — مكبر الصوت
SNS (خدمة الإشعارات البسيطة، https://aws.amazon.com/sns/) هي خدمة نشر واشتراك بنمط الدفع. تنشر رسالة، وSNS يدفعها فورًا لكل مشترك—دوال Lambda، وطوابير SQS، ونقاط HTTP، والبريد الإلكتروني، وحتى إشعارات الجوال. صُممت لتكون "أرسل وانسَ" بطبيعتها: SNS لا يحتفظ بالرسائل ونادرًا ما يعيد المحاولة. لو ما في أحد يستمع، الرسالة ضاعت.

**استخدمه عندما:** حدث واحد لازم يفعّل عدة إجراءات في نفس الوقت.

SQS — الطابور الموثوق
SQS (https://aws.amazon.com/sqs/) طابور يعمل بنمط السحب. المنتجون يضعون الرسائل، والمستهلكون يسحبونها ويعالجونها بالسرعة اللي تناسبهم. هذا ليس نشر/اشتراك—إنه نقطة إلى نقطة. الرسائل تعيش حتى 14 يومًا، وطوابير FIFO تعطيك ترتيبًا صارمًا ومعالجة "مرة واحدة بالضبط".

**استخدمه عندما:** تريد فصل منتج عن مستهلك وتحتاج موثوقية بدون توجيه معقّد.

Kinesis — شريط آلة الزمن
Kinesis (https://aws.amazon.com/kinesis/) منصة لتدفقات البيانات. عكس SQS، حيث الرسالة تستهلك وتُحذف، هنا Kinesis يسمح لعدة مستهلكين بقراءة نفس التدفق كلٌّ على حدة، ويعيد قراءة البيانات حتى 365 يومًا. وترتيب البيانات صارم حسب الشارد (shard)، والإنتاجية ضخمة.

**استخدمه عندما:** عندك بيانات متدفقة بكميات كبيرة وتحتاج إعادة قراءة.

MSK — كافكا بلا صداع (حسنًا، صداع أقل)
MSK (تدفق مُدار لـ Apache Kafka، https://aws.amazon.com/msk/) هو كافكا مُدار. تحصل على نظام كافكا كامل—المواضيع، الأقسام، مجموعات المستهلكين، Kafka Connect، وksqlDB—بدون أن تبني الكتلة بنفسك. لكنك ما زلت مسؤولًا عن تحديد أحجام الأجهزة (brokers)، وضبط الأداء، وتحديث أنظمة التشغيل.

**استخدمه عندما:** عندك خبرة مسبقة بكافكا، أو محتاج Kafka Connect، أو تنقل كافكا موجود فعلًا.

EventBridge — الموجّه الذكي
EventBridge (https://aws.amazon.com/eventbridge/) هو الوافد الجديد اللي كبر بسرعة. إنه ناقل أحداث (event bus) مع فلترة وتوجيه قويين مبنيين على المحتوى. أنت ما تنشر الرسالة وتدعي—تقدر تفلتر، وتحوّل، وتوجّه الأحداث لوجهات مختلفة حسب محتواها. كمان يتعامل مع الأحداث المجدولة (كرون مدمج) ويتكامل بشكل طبيعي مع أكثر من 140 خدمة AWS.

**استخدمه عندما:** منطق التوجيه يعتمد على محتوى الحدث، أو عندما تبني معمارية قائمة على الأحداث بجدية.

RabbitMQ — المخضرم المجرّب
RabbitMQ (https://www.rabbitmq.com/) هو وسيط الرسائل مفتوح المصدر عمره عقد. يدعم بروتوكولات متعددة (AMQP، MQTT، STOMP)، ويقدم توجيهًا مرنًا عبر الـ exchanges والـ bindings، ويشتغل في أي مكان. على AWS، عادة تشغّله على EC2 (https://aws.amazon.com/ec2/) أو تستخدم خدمة مُدارة من طرف ثالث.

**استخدمه عندما:** تحتاج أنماط توجيه معقدة مثل topic exchanges مع wildcards، أو دعم عدة بروتوكولات.

مصفوفة القرار (ورقة الغش)

كفاية مقارنة جداول المواصفات. اسأل نفسك هذه الأسئلة الستة:

| السؤال | الخيار الأفضل |
|---|---|
| فصل واحد لواحد (one-to-one)؟ | SQS |
| بث واحد لكثير (fan-out)؟ | SNS أو EventBridge |
| عدة مستهلكين مستقلين؟ | Kinesis |
| عندك خبرة كافكا أو محتاج نظامها البيئي؟ | MSK |
| توجيه مبني على محتوى الرسالة؟ | EventBridge |
| توجيه معقّد/موجود + بروتوكولات متعددة؟ | RabbitMQ |

فلسفتي: **افترض استخدام خدمات AWS الأصلية إلا إذا كان عندك سبب واضح لغير ذلك.** تشغيل وسيط خاص بك عبارة عن شغل تشغيلي ما تحتاجه في 2026.

سيناريوهات من الواقع

السيناريو الأول: سلسلة طلبات متجر إلكتروني

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

هذا بث متعدد كلاسيكي. اختياري: **SNS أو EventBridge**. تنشر حدث "order.placed" مرة واحدة، وSNS يدفعه في نفس اللحظة إلى Lambda للإيميل، وطابور SQS للمخزون، وخدمة الشحن. لكن لو تريد فلترة (مثلًا، إشعار الاحتيال فقط للطلبات اللي فوق 100 دولار)، قواعد EventBridge المبنية على المحتوى هي اللي تكسب. بتتحصل على مستهلكين أبسط—يوصلهم فقط اللي يخصهم.

السيناريو الثاني: تحليلات Clickstream

منصتك تستقبل ملايين النقرات في الساعة، وثلاثة فرق—التحليلات، تعلّم الآلة، والأمن—يحتاجون يستهلكون هذه البيانات كلٌّ على حدة. وكل فريق يريد إعادة قراءة البيانات لأسبوع على الأقل.

هذه منطقة **Kinesis**. مع SQS، إذا مستهلك واحد قرأ الرسالة، تختفي من الباقي. لكن Kinesis Data Streams يسمح لثلاثة مستهلكين مستقلين بقراءة نفس التدفق في نفس الوقت، كلٌّ بسرعته. إذا فريق التحليلات يتكلم لغة كافكا أصلًا، فـ MSK بديل مناسب—لكن Kinesis يحتاج جهد تشغيلي أقل.

السيناريو الثالث: نظام قديم بتوجيه معقد

عم تريد تحديث نظام نقاط بيع قديم يستخدم RabbitMQ مع topic exchanges مثل `order.created.retail` و `warehouse.stock.low`. فيه مئات مفاتيح التوجيه مربوطة بخدمات خلفية.

نقل هذا المنطق إلى SNS سيكون كارثة—SNS يدعم فقط فلترة اشتراك أساسية، وليس أنماطًا معقدة. **RabbitMQ** أو **EventBridge** كلاهما يصلح. EventBridge يعطيك تكاملًا أصليًا مع AWS وسجلّ مخططات (schema registry)، لكن إعادة ربط كل قواعد التوجيه تأخذ وقتًا. إبقاء RabbitMQ يعني مجهود ترحيل أقل، لكن يتركك تدير أجهزة EC2 لفترة طويلة. أنا شخصيًا أختار EventBridge إذا كان الفريق عنده وقت ومجهود؛ وإلا، شغّل RabbitMQ وركّز على الأمور الأهم.

نصائح عملية من الميدان

1. **ابدأ بـ SQS + Lambda.** هذا أبسط نمط غير متزامن في AWS. وهو يغطي 90% من احتياجات فصل الواجهة الخلفية. أضف SNS لما تحتاج بثًا متعددًا، وEventBridge لما تحتاج توجيهًا ذكيًا.

2. **فكر في إعادة القراءة من اليوم الأول.** السؤال الصعب ليس "هل تقدر خدمتي تتعامل مع رسالة فاشلة؟" السؤال الحقيقي: "هل تقدر خدمتي تتعامل مع *قراءة نفس الرسالة مرتين*؟" Kinesis وMSK يسهّلون إعادة القراءة. SQS FIFO يضمن لك "مرة واحدة بالضبط" لكنه يحد من الإنتاجية.

3. **احترم حدود الاحتفاظ.** SNS لا يحتفظ بأي شيء. SQS سقفه 14 يومًا. Kinesis يوصل 365 يومًا مع الاحتفاظ الممتد. MSK افتراضيًا 7 أيام (ويمكن رفعه). إذا محتاج سجلات تدقيق أو إعادة معالجة، اختر بناءً على ذلك.

4. **استخدم long polling مع SQS.** يجمع الرسائل على مدار 20 ثانية بدلًا من استطلاع الطوابير الفارغة باستمرار. هذا التغيير البسيط ممكن يقلل فاتورتك 90%.

5. **لا تعقّد الأمور.** شفت ناس يشغّلون Lambda يطلق SNS، وSNS ينشر إلى SQS، وSQS يدفع إلى Lambda ثانية، والثانية تفريغ في Kinesis—لأجل رفع ملف بسيط. كل خطوة تضيف تأخيرًا وطريقة جديدة للفشل. مجرد أنك تقدر تسلسل كل شيء ما يعني أنه لازم.

الأسئلة الشائعة

هل يمكن استخدام SNS وSQS معًا؟
طبعًا—وهذا من أقوى الأنماط في AWS. SNS يبث إلى عدة طوابير SQS، وكل طابور يُعالج بشكل مستقل بواسطة خدمة مختلفة. هذا يجمع قوة البث المتعدد من SNS مع موثوقية SQS واحتفاظه وإعادة محاولاته. وهذا النمط هو الأساس لمعظم المعماريات الجادة المبنية على الأحداث في AWS.

هل EventBridge سيحل مكان SNS؟
ليس تمامًا، لكنه يقترب. EventBridge يعمل كل شيء يفعله SNS—نشر/اشتراك، بث متعدد—وزيادةً على ذلك فلترة المحتوى، واكتشاف المخططات، وتكامل عميق مع AWS. للمشاريع الجديدة، أفضّل EventBridge افتراضيًا. لكن إذا عندك حالة استخدام بسيطة مثل دفع حدث إلى Lambda، يبقى SNS أبسط للفهم والتشغيل.

متى أختار MSK بدل Kinesis؟
اختر MSK عندما يكون فريقك يعرف كافكا مسبقًا، أو تحتاج Kafka Connect أو ksqlDB، أو تنقل بنية كافكا موجودة. أما Kinesis فهو المكسب عندما تبدأ من الصفر، وتريد جهدًا تشغيليًا أقل، ولا تحتاج النظام البيئي لكافكا.

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

خواطر أخيرة

خدمة الرسائل "الأفضل" ليست تلك التي تملك أكبر عدد من الميزات. بل التي تناسب شكل مشكلتك: SQS لفصل بسيط. SNS للبث المتعدد. Kinesis للتدفق مع إعادة القراءة. MSK لكافكا على نطاق واسع. EventBridge للتوجيه الذكي. RabbitMQ للتعقيد العريق.

الآن عندك مصفوفة قرار ذهنية كانت ستوفر عليّ 40 دقيقة وسبعة تبويبات في أول يوم. انطلق وابنِ شيئًا رائعًا.