AWS SAA 13 - Building Decoupled Architectures

🎯 Building Decoupled Architectures — بناء بنى مفصولة

فصل مكونات البنية (Decoupling) هو نمط معماري أساسي لبناء تطبيقات مرنة وقابلة للتوسع والصيانة. يشرح هذا المقال فوائد الفصل بين مكونات التطبيق وخدمات AWS التي تمكن ذلك، مثل Amazon SQS (قوائم الرسائل) و SNS (الإشعارات) و EventBridge (التوجيه بالأحداث).

1️⃣ Decoupling Architecture Concept — مفهوم فصل البنية المعمارية

📖 Decoupling يشير إلى فصل المكونات في النظام بحيث تعمل بشكل مستقل — هذا القسم يناقش دوافع الفصل وتقنياته.
الفصل يزيل التبعيات المباشرة بين المكونات المرتبطة بحيث يمكن لكل مكون أن يعمل ويفشل ويتوسع بشكل مستقل عن الآخرين — مما يزيد مرونة النظام وقابليته للتوسع.

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

2️⃣ Tight Coupling in Three-Tier Architecture — الاقتران المتماسك في البنية ثلاثية الطبقات

📖 Tight coupling يشير إلى نظام تكون فيه المكونات المرتبطة معتمدة على بعضها البعض — تغيير أو فشل في مكون واحد يجبر على تغيير أو فشل في المكونات الأخرى.
في بنية ثلاثية الطبقات، الطبقات (عرض، منطق أعمال، قاعدة بيانات) قد تكون مطورة بشكل مستقل لكنها تبقى متماسكة مع بعضها. الاتصال بين الطبقات متزامن (Synchronous) — يرسل المصدر طلباً وينتظر الرد قبل المتابعة.

📋 تحديات البنى المتماسكة:

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

شركة نقلت تطبيق الويب من الخوادم الداخلية إلى AWS ببنية ثلاثية الطبقات: Amazon EC2 لخادم الويب وخادم التطبيق، وAmazon RDS لقاعدة البيانات. إذا فشل خادم التطبيق، يتوقف النظام بالكامل. لتوسيع طبقة الويب، يضطر مسؤول النظام لتحديث كود التوجيه لكل خادم جديد — عملية يدوية بطيئة وعرضة للأخطاء.

3️⃣ Tight Coupling Increases Scaling Complexity — الاقتران المتماسك يزيد تعقيد التوسع

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

📋 تعقيدات التوسع:

• إضافة خادم ويب جديد: توصيلتان من Route 53 إلى الخادم الجديد + توصيلتان من الخادم الجديد إلى خادمي التطبيق = 3 توصيلات.
• إضافة خادم تطبيق جديد: توصيلة من كل خادم ويب إلى خادم التطبيق الجديد = 3 توصيلات إضافية.
• تعطل خادم تطبيق واحد: أداء كل خوادم الويب يتأثر لأنها متصلة مباشرة به.

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

4️⃣ Decoupling Between Layers — الفصل بين الطبقات

📖 على مستوى البنية التحتية، الطريقة الفعالة لتخفيف مشاكل التماسك هي إدخال مكون وسيط بين الطبقات المعتمدة — مثل Elastic Load Balancing (ELB).
مع Loose coupling، تقلل التبعيات باستخدام حلول مُدارة كوسيط بين طبقات النظام — الوسيط يعالج الأعطال والتوسع تلقائياً.

📋 خطوات تطبيق الفصل على مستوى البنية التحتية:

• إضافة ALB أمام خوادم الويب — يوزع حركة المرور ويراقب صحة المثيلات.
• إضافة ALB بين خوادم الويب وخوادم التطبيق — إدارة تلقائية للأحمال وتوجيه الفشل.
• إضافة خادم ويب جديد الآن يتطلب توصيلتين فقط (واحدة إلى ALB1 والأخرى إلى ALB2).

نفس الشركة السابقة تطبق الفصل على بنيتها: ALB أمام خوادم الويب + ALB بين خوادم الويب وخوادم التطبيق. الآن، إضافة خادم ويب جديد يحتاج توصيلتين فقط بدلاً من 3. عند تعطل خادم تطبيق، ALB يكتشفه تلقائياً ويوقف إرسال الحركة إليه — بدون تدخل يدوي.

5️⃣ Tight Coupling Within the Application — الاقتران المتماسك داخل التطبيق

📖 التماسك يحدث أيضاً داخل التطبيق نفسه عندما تُنفذ وتُنشر كل وظائف الأعمال (Business functions) في وحدة واحدة — مثل التطبيق المتجانس (Monolithic application).
المشكلة في وظيفة واحدة يمكن أن تبطئ أو توقف كل وظائف التطبيق الأخرى، وتغيير وظيفة واحدة يتطلب وضع التطبيق بأكمله في الصيانة.

📋 تحديات التطبيق المتجانس:

• تباطؤ في وظيفة واحدة (مثل تحويل الصور) يضعف أداء التطبيق بأكمله.
• تعطل وظيفة واحدة يؤدي إلى توقف الاستجابة لكل الطلبات الواردة.
• تغيير وظيفة واحدة يستلزم إعادة نشر التطبيق بالكامل.

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

6️⃣ Decoupling: Microservices Architecture — الفصل: بنية الخدمات المصغرة

📖 Microservice architecture تقسّم وظائف التطبيق إلى أجزاء يمكن أن تتوسع وتفشل بشكل مستقل — كل Microservice يعمل في عمليته الخاصة ويحافظ على بياناته الخاصة ويعرض وظيفته عبر API محددة.
هذا ينتج بنية تطبيق بمكونات قابلة لإعادة الاستخدام وقابلة للتوسع وموثوقة. الميكروسيرفسات منفصلة (Loosely coupled) وتتواصل بشكل متزامن أو غير متزامن.

📋 خصائص الميكروسيرفسات:

• كل ميكروسيرفس يعمل في حاوية (Container) مستقلة — يمكن توسيعه بشكل منفصل.
• فشل ميكروسيرفس واحد لا يؤثر على الميكروسيرفسات الأخرى.
• يمكن إضافة ميزات إلى مكون مع تقليل المخاطر على المكونات التي تعتمد عليه.

تقسيم التطبيق المتجانس السابق إلى ثلاث ميكروسيرفسات: Finance (معاملات مالية)، Transcoding (تحويل الصور)، Calculations (حسابات). Finance يتوسع إلى 3 حاويات لأنه يستقبل طلبات أكثر، بينما Calculations يعمل بحاوية واحدة. فشل Transcoding في حاوية لا يؤثر على Finance و Calculations في الحاويات الأخرى.

7️⃣ Offloading Requests: Amazon SQS and Amazon SNS — تفريغ الطلبات: Amazon SQS و Amazon SNS

📖 لتحسين المرونة عبر Loose coupling، اجعل تفاعلات المكونات غير متزامنة (Asynchronous) حيثما أمكن — عبر وسيط تخزين دائم مثل طابور (Queue) أو موضوع (Topic).
يتضمن هذا النموذج مكوناً يولد الأحداث (Producer) وآخر يستهلكها (Consumer) — يتواصلان عبر وسيط بدلاً من الاتصال المباشر.

📋 مكونات النموذج:

• Producer: المكون الذي يولد الأحداث — يضع رسالة في الطابور ويعود فوراً للعميل بدون انتظار.
• Consumer: المكون الذي يعالج الرسائل — يسحب الرسائل من الطابور ويعالجها بالسرعة المناسبة.
• Queue/Topic: وسيط التخزين الدائم — يفصل المنتج عن المستهلك ويمتص التقلبات في الضغط.

تطبيق ويب يعاني من بطء في تحويل الصور. الحل: نقل منطق التحويل إلى تطبيق مستهلك منفصل. المتصفح يرفع الصورة ← الميكروسيرفس يخزنها في S3 ويضع رسالة في SQS ← يرد فوراً للعميل ← تطبيق التحويل يسحب الرسالة ويعالج الصورة ← بعد الانتهاء، SNS يرسل إيميل للمستخدم. المستخدم لا ينتظر — الطلب يُعالج في الخلفية.

8️⃣ Decoupling with Amazon MQ — الفصل باستخدام Amazon MQ

📖 ماذا لو أراد تطبيق داخلي (On-premises) استخدام تطبيق معالجة الصور في AWS Cloud؟ الحل هو Amazon MQ — يسمح بفصل التطبيقات الداخلية عن التطبيقات السحابية عبر الرسائل غير المتزامنة.
Amazon MQ يخزن الرسائل عبر Amazon EFS أو Amazon EBS، ويعطي العملاء خارج AWS Cloud القدرة على إعادة استخدام الوظائف بطريقة مرنة ومتسقة.

تطبيق داخلي في مقر الشركة يريد إرسال صور لتحويلها عبر تطبيق سحابي في AWS. بدلاً من ربط التطبيق الداخلي مباشرة بالتطبيق السحابي (اقتران متماسك)، يستخدم Amazon MQ كوسيط — التطبيق الداخلي يرسل الرسالة إلى MQ، والتطبيق السحابي يسحبها ويعالجها.

9️⃣ Decoupling Solution Categories — فئات حلول الفصل

📖 حلول الفصل (Loose coupling) تحل مشاكل التكامل المتماسك ويمكن تحقيقها عبر حلول متزامنة (Synchronous) وغير متزامنة (Asynchronous).

📋 فئات حلول الفصل:

• Synchronous – Infrastructure level: ELB (مثل ALB بين الطبقات).
• Synchronous – Application level: Microservice architecture.
• Asynchronous – Queue based: Amazon SQS.
• Asynchronous – Topic based: Amazon SNS وAmazon MQ.

لفصل تطبيق المقهى: Synchronous: ALB بين خوادم الويب والتطبيق + تقسيم التطبيق إلى ميكروسيرفسات (Finance، Orders، Inventory). Asynchronous: SQS لطلبات المعالجة البطيئة، SNS لإشعارات العملاء، Amazon MQ للتواصل مع الأنظمة الداخلية القديمة.

الفصل بين المكونات يشبه فريق عمل في مطعم: لو كان الطباخ يتحدث مباشرة مع كل نادل (Tight coupling) — أي نادل جديد يحتاج تدريباً خاصاً، وأي خطأ في طلب يربك المطبخ كله. أما مع وجود منصة طلبات مركزية (Queue) — النُدّال يضعون الطلبات والطباخ يأخذها بالترتيب — أي نادل جديد يضع الطلبات بنفس الطريقة، والطباخ يعمل دون مقاطعة.

✅ خلاصة: فصل البنية المعمارية

• الأنظمة المتماسكة يصعب توسيعها وتخلق اختناقات ونقاط فشل فردية.
• الفصل يزيل التبعيات المباشرة بين المكونات — يسمح بالتوسع والمرونة.
• حلول الفصل تقسم طبقات البنية التحتية أو وظائف التطبيق وتقدم مكوناً وسيطاً بينها.
• يمكن أن تكون متزامنة (ELB، Microservices) أو غير متزامنة (SQS، SNS، Amazon MQ).
• الفصل غير المتزامن يستخدم الرسائل والطوابير أو المواضيع لفصل المنتج عن المستهلك.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Tight coupling	الاقتران المتماسك	نظام تعتمد مكوناته على بعضها البعض — تغيير أو فشل واحد يؤثر على البقية.
Loose coupling	الفصل / الاقتران المرن	نظام تزيل مكوناته التبعيات المباشرة — تعمل وتفشل وتتوسع بشكل مستقل.
Microservice	خدمة مصغرة	وحدة برمجية مستقلة تعمل في عمليتها الخاصة وتؤدي وظيفة واحدة محددة.
Producer	المنتج	المكون الذي يولد الأحداث والرسائل ويضعها في طابور أو موضوع.
Consumer	المستهلك	المكون الذي يسحب الرسائل من الطابور أو يستقبلها من الموضوع ويعالجها.
Synchronous	متزامن	نمط اتصال يرسل فيه المصدر طلباً وينتظر الرد قبل المتابعة.
Asynchronous	غير متزامن	نمط اتصال يرسل فيه المصدر رسالة دون انتظار رد فوري.

1️⃣ Decoupling Applications with Amazon SQS — فصل التطبيقات باستخدام Amazon SQS

📖 هذا القسم يصف كيف يعمل Amazon Simple Queue Service (Amazon SQS) ومتى تستخدمه لفصل تطبيقاتك.
Amazon SQS هو خدمة طوابير رسائل مُدارة بالكامل — تتيح فصل مكونات التطبيق لتشغيلها وفشلها بشكل مستقل.

2️⃣ Point-to-Point Messaging — التراسل المباشر (Point-to-point)

📖 Point-to-point messaging هو نموذج رسائل غير متزامن يساعد في تنفيذ بنية منفصلة — يسمح لتطبيقين بالتواصل عبر الرسائل وطابور رسائل (Message queue).
يُسمى Point-to-point لأن التطبيق المُرسل يعرف التطبيق المُستقبل ويرسل الرسائل لمستهلك واحد فقط. التطبيق المُرسل = Producer (يولد الرسائل ويضعها في الطابور). التطبيق المُستقبل = Consumer (يسحب الرسائل من الطابور ويعالجها).

📋 خصائص Point-to-point messaging:

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

تطبيق معالجة طلبات: العميل يقدم طلباً (Producer) ← يضع رسالة الطلب في طابور SQS ← تطبيق التوصيل (Consumer) يسحب الرسالة ويعالجها. إذا كان تطبيق التوصيل مشغولاً، الطلب ينتظر في الطابور بأمان حتى يصبح جاهزاً.

3️⃣ Amazon Simple Queue Service (SQS) — خدمة الطوابير البسيطة (SQS)

📖 Amazon SQS هو خدمة طوابير رسائل مُدارة بالكامل — يساعد في دمج وفصل الأنظمة البرمجية الموزعة ومكونات التطبيق — يوفر إمكانيات طوابير عالية التوفر وآمنة ومتينة.

📋 مميزات Amazon SQS:

• مُدار بالكامل — يعمل على نطاق واسع ويعالج مليارات الرسائل يومياً.
• يخزن كل الطوابير والرسائل ضمن منطقة AWS واحدة عالية التوفر مع مناطق توفر متعددة.
• واجهتان للوصول: AWS Management Console وواجهة API عبر AWS SDKs.
• الحماية من الفشل: تكرار التخزين يحمي من فشل أي حاسوب أو شبكة أو منطقة توفر.

تطبيق تجارة إلكترونية يستخدم SQS لفصل خدمة استلام الطلبات عن خدمة معالجة الدفع. التطبيق الأمامي (website) يضع رسالة الطلب في طابور SQS فور استلامه — الزبون يحصل على تأكيد فوري. خلف الكواليس، خدمة الدفع تسحب الرسائل من الطابور وتعالج كل طلب بالترتيب — آلاف الرسائل تنتظر بأمان دون فقدان.

4️⃣ Amazon SQS Benefits — فوائد Amazon SQS

📖 Amazon SQS يقدم أربع فوائد رئيسية: مُدار بالكامل، موثوقية، أمان، وقابلية توسع.

📋 فوائد Amazon SQS:

• Fully managed: لا حاجة لإدارة برامج الرسائل أو صيانة البنية التحتية — AWS يؤمن ويدير كل شيء.
• Reliability: توصيل كميات كبيرة من البيانات دون فقدان الرسائل — تخزينها على خوادم متعددة.
• Security: إرسال بيانات حساسة بأمان بين التطبيقات — تشفير Server-side encryption (SSE) عبر AWS KMS.
• Scalability: توسع مرن حسب الاستخدام — بدون الحاجة لتخطيط السعة أو التهيئة المسبقة.

شركة نقل تستخدم طابور SQS لتنسيق عمليات التوصيل. الطابور يتوسع تلقائياً من 100 رسالة في الشتاء إلى 50,000 رسالة في رمضان — بدون أي تعديل. كل الرسائل تصل بأمان، والبيانات مشفرة. الفريق لا يدير أي خوادم أو برمجيات وسيطة.

5️⃣ Amazon SQS Core Components — المكونات الأساسية لـ Amazon SQS

📖 المكونات الأساسية لـ Amazon SQS هي Message (الرسالة) وQueue (الطابور) وDead-letter queue (DLQ).

📋 مكونات SQS الأساسية:

• Message: يصل حجمها إلى 256 كيلوبايت (يمكن تمديدها لـ 2 جيجابايت عبر Amazon SQS Extended Client Library). تبقى في الطابور حتى تُحذف أو تنتهي مدة الاحتفاظ (افتراضي 4 أيام، حد أقصى 14 يوماً).
• Queue: نوعان — Standard Queue وFIFO Queue. معلمات قابلة للتكوين: فترة الاحتفاظ، مهلة الرؤية، زمن انتظار الاستلام.
• Dead-letter queue (DLQ): طابور مرتبط بمصدر — يستقبل الرسائل التي تعذرت معالجتها بعد تجاوز الحد الأقصى لمحاولات المعالجة.

تطبيق معالجة صور يضع مهمة تحويل في طابور SQS. إذا فشلت المعالجة (صورة تالفة مثلاً)، بعد 3 محاولات تنتقل الرسالة تلقائياً إلى DLQ. المطور يراجع DLQ لاحقاً لتحليل سبب الفشل — بدون فقدان أي طلب.

6️⃣ Example: Decoupling with Amazon SQS — مثال على الفصل باستخدام Amazon SQS

📖 مثال: تطبيق ويب يعالج طلبات الزبائن — وظيفتا استلام الطلبات (Order capture) وتنفيذ الطلبات (Order fulfillment). يمكن فصل البنية بإدخال طابور SQS بينهما.

📋 فوائد هذا النموذج:

• الطابور يعمل كممتص للصدمات — امتصاص التقلبات في حركة المرور، والتطبيقان يتوسعان بشكل مستقل.
• يمكن معالجة الطلبات بالسرعة التي تناسب إدارة التكاليف — الطلبات تُخزَّن مؤقتاً في الطابور.
• إذا حدث استثناء في التطبيق، يمكن إعادة محاولة المعالجة أو توجيه الرسالة إلى DLQ للمعالجة لاحقاً.

تطبيق المقهى (Café) لاستلام الطلبات يعمل على 3 مثيلات موزعة خلف ALB. كل مثيل يضع الطلبات في طابور "Customer Orders". تطبيق التوصيل يعمل على مثيلين يسحبان الرسائل ويعالجانها. إذا زادت الطلبات في رمضان، طابور SQS يمتص الزحام — تطبيق التوصيل يلحق بالمعالجة بالسرعة المناسبة.

7️⃣ Queue Types — أنواع الطوابير

📖 Amazon SQS يدعم نوعين من الطوابير: Standard Queue وFIFO Queue — لكل منهما خصائص مختلفة تناسب حالات استخدام مختلفة.

الخاصية	Standard Queue	FIFO Queue
التوصيل	At-least-once (قد تصل الرسالة أكثر من مرة)	Exactly once (مرة واحدة فقط)
الترتيب	Best-effort (قد تختلف أحياناً)	First-in-first-out (ترتيب دقيق)
الإنتاجية	غير محدودة تقريباً	حتى 300 طلب API في الثانية (3,000 مع التجميع)
الاستخدام الأمثل	عندما يمكن معالجة الرسائل أكثر من مرة وبأي ترتيب	عندما يجب الحفاظ على ترتيب الرسائل بدقة

Standard Queue: تطبيق إشعارات — إذا وصل إشعار مزدوج أو خارج الترتيب، لا مشكلة كبيرة. FIFO Queue: تطبيق معاملات بنكية — يجب أن تصل الأوامر بالترتيب (خصم ← إيداع) ومرة واحدة فقط — FIFO Queue يضمن ذلك.

8️⃣ Queue Settings: Polling Type — إعدادات الطابور: نوع الاستقصاء

📖 عند إنشاء طابور SQS، تحتاج إلى اختيار نوع الاستقصاء المناسب (Polling type) — Short polling أو Long polling.

📋 مقارنة أنواع الاستقصاء:

• Short polling: القيمة الافتراضية (زمن انتظار = 0). يستقصي مجموعة فرعية من الخوادم فقط — استجابة سريعة لكن استجابات فارغة كثيرة ← تكلفة أعلى.
• Long polling: قيمة غير صفرية (حد أقصى 20 ثانية). يستقصي كل الخوادم — ينتظر حتى تصل رسالة أو ينتهي زمن الانتظار — استجابات أقل لكن تكلفة أقل.

🔑 نصيحة أساسية: في معظم الحالات، Long polling هو الخيار الأفضل — يقلل التكلفة ويحسن الكفاءة. الاستثناء: تطبيقات تحتاج استجابة فورية (مثل أسعار الأسهم) أو تستخدم خيطاً واحداً لاستقصاء طوابير متعددة.

تطبيق معالجة طلبات يستقبل 100 طلب في الساعة. مع Short polling: يستقصي كل ثانية → 3600 استقصاء في الساعة → 3500 استجابة فارغة → تكلفة عالية. مع Long polling (20 ثانية): 180 استقصاء فقط في الساعة → تكلفة أقل 20 مرة — والرسائل تصل بدون تأخير.

9️⃣ Queue Settings: Visibility Timeout — إعدادات الطابور: رؤية الرسالة

📖 Visibility timeout هو الفترة الزمنية التي يمنع فيها Amazon SQS المستهلكين الآخرين من استلام ومعالجة نفس الرسالة — يساعد في منع المعالجة المزدوجة.

📋 خصائص Visibility timeout:

• الافتراضي: 30 ثانية. الحد الأقصى: 12 ساعة.
• يجب أن تساوي أقصى وقت تحتاجه معالجة وحذف الرسالة.
• إذا انتهت المهلة قبل حذف الرسالة ← تصبح مرئية للمستهلكين الآخرين وقد تُعالج مرة أخرى.
• يمكن تجاوز المهلة على مستوى الرسالة عند استلامها.

تطبيق تحويل الفيديو — معالجة فيديو مدته 5 دقائق تستغرق أحياناً دقيقتين وأحياناً 3 دقائق. إعداد Visibility timeout = 4 دقائق (أكثر من أقصى وقت متوقع). إذا استغرق التحويل 5 دقائق بسبب ملف كبير، المهلة تنتهي ← مستهلك آخر يسحب نفس الرسالة ويبدأ المعالجة — حماية من الفقدان.

🔟 How an SQS Queue Works — كيفية عمل طابور رسائل SQS

📖 السيناريو التالي يوضح دورة حياة رسالة في طابور SQS وكيف يعمل Amazon SQS messaging:

📋 خطوات دورة حياة الرسالة:

• 1. المنتج يرسل رسالة إلى الطابور ← توزع عبر خوادم الطابور بشكل متكرر.
• 2. المستهلك يسحب الرسالة ← تبدأ مهلة الرؤية (مثلاً 40 ثانية) ← الرسالة تصبح غير مرئية للمستهلكين الآخرين.
• 3. المستهلك يعالج الرسالة ويحذفها من الطابور خلال مهلة الرؤية — هذا يمنع معالجتها مرة أخرى.
• إذا انتهت المهلة: الرسالة تصبح مرئية مرة أخرى لمستهلك آخر — ضمان أن كل الرسالة تُعالج حتى لو فشل المستهلك الأول.

مستهلك يسحب رسالة طلب من طابور SQS — مهلة الرؤية 40 ثانية تبدأ. المستهلك يعالج الطلب (يتصل بقاعدة البيانات، يؤكد الدفع، يحدّث المخزون) ويحذف الرسالة. إذا تعطل المستهلك قبل الحذف، بعد 40 ثانية مستهلك آخر يسحب نفس الرسالة ويعالجها — لا يفقد أي طلب.

1️⃣1️⃣ Amazon SQS Use Cases — حالات استخدام Amazon SQS

📖 أربع حالات استخدام رئيسية لـ Amazon SQS: طوابير العمل، التخزين المؤقت والتجميع، تفريغ الطلبات، وتحفيز Auto Scaling.

📋 حالات استخدام SQS:

• Work queues: فصل مكونات تطبيق موزع تعالج العمل بمعدلات مختلفة — مثلاً نظام ملاحة يجمع بيانات من آلاف السيارات.
• Buffering and batch operations: تخزين مؤقت ضد التقلبات — مثلاً تطبيق تداول أسهم يفصل تسجيل الصفقات عن تحديث أرصدة العملاء.
• Request offloading: نقل العمليات البطيئة خارج مسار الطلب التفاعلي — مثلاً تطبيق بنكي يفصل واجهة الدفع عن معالجة الفاتورة.
• Trigger EC2 Auto Scaling: استخدام عدد الرسائل في الطابور كمقياس لتحفيز التوسع — مثلاً تطبيق توصيل يضيف مثيلات إذا زادت الطلبات في الطابور عن 10.

تطبيق معالجة طلبات يعمل على Auto Scaling group. يراقب CloudWatch عدد الرسائل في طابور SQS. عندما يزيد العدد عن 10 رسائل، ينطلق Auto Scaling ويضيف مثيل EC2. عندما يقل العدد، يزيل المثيلات — إدارة ذكية للتكلفة والأداء معاً.

SQS يشبه صندوق بريد إلكتروني — صندوق البريد هو الطابور، المرسل (Producer) يضع الرسالة ويذهب، المستقبل (Consumer) يفتح الصندوق عندما يكون مستعداً. Short polling: تفتح الصندوق كل دقيقة لترى إن كان هناك رسالة جديدة — معظم المرات يكون فارغاً. Long polling: تضع يدك في الصندوق وتنتظر 20 ثانية — إذا جاءت رسالة، تمسكها فوراً. أسهل وأقل جهداً.

✅ خلاصة: فصل التطبيقات باستخدام Amazon SQS

• Amazon SQS هو خدمة طوابير رسائل مُدارة بالكامل — يفصل مكونات التطبيق لتشغيلها بشكل مستقل.
• يدعم نوعين: Standard (توصيل مرة واحدة على الأقل، ترتيب تقريبي) وFIFO (توصيل مرة واحدة، ترتيب دقيق).
• الرسائل التي لا يمكن معالجتها تنتقل إلى Dead-letter queue (DLQ).
• Long polling يقلل التكلفة عبر تقليل الاستجابات الفارغة — يُفضل في معظم الحالات.
• المنتج يرسل رسالة ← المستهلك يعالج ويحذف خلال فترة الرؤية — إذا انتهت المهلة، الرسالة تُعالج مرة أخرى.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon SQS	خدمة الطوابير البسيطة	خدمة طوابير رسائل مُدارة بالكامل لفصل مكونات التطبيقات.
Standard Queue	طابور قياسي	توصيل مرة واحدة على الأقل — ترتيب غير مضمون — إنتاجية غير محدودة.
FIFO Queue	طابور FIFO	توصيل مرة واحدة بالترتيب الدقيق — إنتاجية محدودة.
Visibility timeout	مهلة الرؤية	فترة منع المستهلكين الآخرين من رؤية الرسالة أثناء معالجتها.
Dead-letter queue (DLQ)	طابور الرسائل الميتة	طابور يستقبل الرسائل التي تعذرت معالجتها بعد عدة محاولات.
Long polling	الاستقصاء الطويل	استقصاء كل الخوادم والانتظار حتى تصل رسالة — يقلل التكلفة.
Short polling	الاستقصاء القصير	استقصاء مجموعة فرعية من الخوادم — استجابة فورية لكن تكلفة أعلى.

1️⃣ Decoupling Applications with Amazon SNS — فصل التطبيقات باستخدام Amazon SNS

📖 هذا القسم يصف كيف يعمل Amazon Simple Notification Service (Amazon SNS) لفصل البنى المتماسكة ومتى تستخدم هذه الخدمة.
Amazon SNS هو خدمة إشعارات Pub/Sub مُدارة بالكامل — تتيح فصل التطبيقات عبر الإشعارات الفورية.

2️⃣ Publish/Subscribe (Pub/Sub) Messaging — التراسل بنشر/اشتراك (Pub/Sub)

📖 Publish/subscribe (pub/sub) messaging هو نموذج رسائل يمكن استخدامه لفصل التطبيقات بشكل غير متزامن — يسمح بإرسال رسالة إلى تطبيقات متعددة دون أن يعرف المرسل تفاصيلها.
التطبيق المُرسل يُسمى Publisher — ينشر الرسائل إلى وجهة وسيطة تُسمى Topic. التطبيقات المُستقبلة تُسمى Subscribers — تشترك في الموضوع لتستقبل الرسائل تلقائياً عبر آلية Push.

📋 خصائص Pub/sub messaging:

• الناشر ينشر رسالة إلى Topic واحد ← يُدفع لكل المشتركين فوراً.
• الموضوعات لا تخزن الرسائل — تدفعها فوراً للمشتركين (عكس الطوابير).
• المشتركون يؤدون وظائف مختلفة — كل واحد يفعل شيئاً مختلفاً بالرسالة بالتوازي.
• الناشر لا يعرف من هم المشتركون — والمشتركون لا يعرفون من الناشر.

تطبيق مقهى يريد إرسال إشعارات عند توفر صنف جديد. العمليات (Publisher) تنشر رسالة "كابتشينو جاهز" إلى Topic. المشتركون: تطبيق المحمول (إشعار push للعميل)، الإيميل (إيصال للعميل)، نظام المخزون (تحديث الكمية). Topic واحد ← 3 تصرفات مختلفة بالتوازي.

3️⃣ Amazon Simple Notification Service (SNS) — خدمة الإشعارات البسيطة (SNS)

📖 Amazon SNS هو خدمة Pub/Sub مُدارة بالكامل — تساعد في فصل التطبيقات عبر الإشعارات — توفر إمكانيات إشعارات عالية التوسع وآمنة وفعالة من حيث التكلفة.

📋 مميزات Amazon SNS:

• مُدار بالكامل — لا صيانة ولا إدارة — دفع حسب الاستخدام.
• يخزن نسخاً متعددة من الرسالة عبر مناطق توفر متعددة قبل تأكيد الاستلام للناشر.
• بعد نشر الرسالة، يحذفها Amazon SNS — لا يُبقي الرسائل (على عكس SQS).
• يمكنك إنشاء Topic وضبط سياسات لتقييد من ينشر أو يشترك — دعم TLS لتأمين القناة.

تطبيق مراقبة: خادم الإنتاج يكتشف أن استخدام CPU تجاوز 90% ← ينشر رسالة إلى SNS Topic ← المشتركون: إيميل مسؤول النظام، SMS لمسؤول الأمن، Lambda تطبق Auto Healing تلقائياً. كل هذا في ثوانٍ — بدون استقصاء أو تدخل يدوي.

4️⃣ Subscriber Types — أنواع المشتركين

📖 Amazon SNS يدعم سبعة أنواع من المشتركين (Subscribers) — من الإيميل إلى Lambda إلى SQS.

📋 أنواع المشتركين في SNS:

• Email destination: إرسال الرسالة إلى بريد إلكتروني — نص عادي أو JSON.
• Mobile text messaging (SMS): إرسال رسالة نصية إلى رقم هاتف.
• Mobile push notifications: إشعار دفع مباشر لتطبيق جوال.
• HTTP/HTTPS endpoint: إرسال POST request إلى عنوان URL.
• AWS Lambda function: استدعاء Lambda لتنفيذ منطق أعمال مخصص.
• SQS queue: إرسال الرسالة إلى طابور SQS للمعالجة لاحقاً.
• Amazon Kinesis Data Firehose: إرسال إلى تدفق Firehose للتخزين والتحليلات.

شركة توصيل تريد إشعار العملاء بحالة الطلب: SNS Topic واحد. مشترك إيميل → إيصال إلكتروني. مشترك SMS → رسالة "طلبك في الطريق". مشترك SQS → طابور لتحديث نظام المخزون. مشترك Lambda → إرسال إشعار push للتطبيق. كل مشترك يستقبل نفس الرسالة ويعالجها بطريقته.

5️⃣ Amazon SNS Use Cases — حالات استخدام Amazon SNS

📖 حالات استخدام Amazon SNS: تنبيهات التطبيقات والأنظمة، إشعارات الإيميل والنصوص، وإشعارات الدفع للجوال.

📋 حالات استخدام SNS:

• Application and system alerts: إشعار فوري عند وقوع حدث — مثل تغيير في Auto Scaling group.
• Push email and text messaging: إرسال عناوين الأخبار المستهدفة للمشتركين عبر الإيميل أو SMS.
• Mobile push notifications: إرسال إشعارات لتطبيق جوال — مثلاً "تحديث متوفر" مع رابط التحميل.

تطبيق أخبار يريد إرسال تنبيهات عاجلة. مستخدمون يشتركون في Topic "أخبار عاجلة". عندما يحدث حدث مهم، الناشر ينشر رسالة ← Topic يدفعها لكل المشتركين: البعض عبر إيميل، البعض عبر SMS (للأخبار العاجلة جداً)، البعض عبر إشعار تطبيق الجوال.

6️⃣ Example: Using Amazon SQS with Amazon SNS — مثال: استخدام Amazon SQS مع Amazon SNS

📖 استخدام Amazon SNS مع Amazon SQS في سيناريو Fanout — رسالة تُنشر إلى Topic ثم تُنسخ وتُدفع إلى طوابير SQS متعددة للمعالجة المتوازية غير المتزامنة.

📋 خطوات سيناريو Fanout:

• 1. تطبيق جوال يرفع صورة إلى Amazon S3 bucket.
• 2. حدث S3 ينشر رسالة إلى SNS Topic تحتوي رابط الصورة.
• 3. Topic يدفع (fans out) الرسالة إلى 3 طوابير SQS: thumbnail، mobile size، web size.
• 4. كل طابور يُراقب من تطبيق منفصل في Auto Scaling group خاص به — يعالج الحجم المناسب.
• 5. كل تطبيق يخزن النتيجة في S3 bucket آخر — بشكل مستقل ومتوازي.

تطبيق إنستغرام مصغر: المستخدم يرفع صورة ← تصل لـ S3 ← S3 يرسل إشعار لـ SNS Topic ← Topic يوزع على 3 طوابير SQS. التطبيق الأول ينتج صورة مصغرة (thumbnail)، الثاني يضبط للمحمول، الثالث للويب. كل تطبيق يعمل بالتوازي — التحويل يحدث في دقائق بدلاً من انتظار المستخدم.

7️⃣ Amazon SNS Considerations — اعتبارات استخدام Amazon SNS

📖 اعتبارات مهمة عند استخدام Amazon SNS: كل إشعار يحتوي رسالة واحدة منشورة، لا يمكن استرجاع الرسالة بعد التسليم، وخيارات الموضوع القياسي و FIFO.

📋 اعتبارات SNS:

• كل رسالة تحتوي على رسالة واحدة منشورة — لا يوجد recall أو استرجاع بعد التسليم الناجح.
• نوعان من المواضيع: Standard Topic (ترتيب تقريبي) وFIFO Topic (ترتيب دقيق — إذا كان الترتيب مطلوباً).
• يمكن تخصيص سياسة التسليم لنقطة HTTP/HTTPS — التحكم بعدد مرات إعادة المحاولة وسلوك الفشل.
• عند استنفاد سياسة التسليم، SNS يتوقف عن إعادة المحاولة ويتجاهل الرسالة — ما لم يُرفق DLQ بالاشتراك.

تطبيق إشعارات يستخدم HTTP endpoint لمشترك خارجي. إذا كان الخادم الخارجي غير متاح، SNS يعيد المحاولة وفق سياسة مخصصة (مثلاً 3 محاولات بفاصل 5 دقائق). بعد استنفاد المحاولات، تنتقل الرسالة إلى DLQ لمراجعتها لاحقاً بدلاً من فقدانها.

8️⃣ Comparison: Amazon SNS vs Amazon SQS — مقارنة بين Amazon SNS و Amazon SQS

📖 الجدول التالي يلخص الفروقات الرئيسية بين Amazon SNS وAmazon SQS:

الخاصية	Amazon SNS	Amazon SQS
نموذج الرسائل	Publisher-Subscriber	Producer-Consumer
نموذج التوزيع	One to many (واحد إلى متعدد)	One to one (واحد إلى واحد)
آلية التوصيل	Push (سلبي — يدفع الرسالة)	Pull (نشط — يسحب الرسالة)
استمرار الرسالة	لا — تُحذف بعد النشر	نعم — تبقى حتى يحذفها المستهلك
معرفة المستقبل	الناشر لا يعرف المشتركين	المنتج يعرف المستهلك

اختيار الأداة حسب الحاجة: SNS ← "أريد إعلام كل التطبيقات عند رفع صورة جديدة" (one-to-many, push). SQS ← "أريد تطبيقاً واحداً يعالج الطلبات بالترتيب" (one-to-one, pull). معاً: SNS يوزع على طوابير SQS متعددة ← كل طابور يُعالج بمستهلك واحد ← أفضل ما في العالمين.

الفرق بين SNS و SQS مثل:
🗣️ SNS (Pub/Sub): يشبه مذياع FM — المحطة (Publisher) تبث على تردد معين، وأي رايتو (Subscriber) يضبط على نفس التردد يستقبل البث فوراً. البث لا يُسجل — إذا فتحت الراديو متأخراً، فاتك البرنامج.
📬 SQS (Point-to-point): يشبه صندوق بريد شخصي — المرسل (Producer) يضع الرسالة ويرحل، المستقبل (Consumer) يفتح الصندوق ويأخذ الرسالة عندما يكون مستعداً — الرسالة تبقى في الصندوق حتى يأخذها.

✅ خلاصة: فصل التطبيقات باستخدام Amazon SNS

• Amazon SNS هو خدمة Pub/Sub مُدارة — تنشئ Topic، تنشئ مشتركين، وتنشر رسائل إلى Topic.
• يمكن استخدام Topics لفصل الناشرين عن المشتركين و Fanout الرسائل لمستلمين متعددين.
• خدمات AWS يمكنها النشر إلى SNS Topic لتفعيل Event-driven computing.
• يدعم 7 أنواع من المشتركين: إيميل، SMS، Push، HTTP، Lambda، SQS، Kinesis Firehose.
• SNS = Push (واحد إلى متعدد، غير مستمر). SQS = Pull (واحد إلى واحد، مستمر).

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon SNS	خدمة الإشعارات البسيطة	خدمة Pub/Sub مُدارة بالكامل للإشعارات الفورية.
Topic	الموضوع	قناة اتصال ينشر فيها Publisher الرسائل ويشترك فيها Subscribers.
Publisher	الناشر	التطبيق الذي يرسل الرسائل إلى SNS Topic.
Subscriber	المشترك	التطبيق الذي يستقبل الرسائل من SNS Topic.
Fanout	التوزيع المتعدد	إرسال رسالة واحدة من Topic إلى عدة طوابير/نقاط نهاية بالتوازي.
Push mechanism	آلية الدفع	SNS يدفع الرسالة فوراً إلى المشترك — بدون استقصاء.
Pull mechanism	آلية السحب	المستهلك يسحب الرسالة من الطابور — استقصاء دوري.

1️⃣ Decoupling a Hybrid Application with Amazon MQ — فصل تطبيق هجين باستخدام Amazon MQ

📖 هذا القسم يقدم وصفاً تمهيدياً لخدمة Amazon MQ — وكيف تفصل التطبيقات الهجينة (Hybrid applications) بين البيئات الداخلية والسحابية.

2️⃣ Amazon MQ — خدمة وسيط الرسائل المُدارة (Amazon MQ)

📖 Amazon MQ هو خدمة وسيط رسائل (Message broker) مُدارة بالكامل لـ Apache ActiveMQ وRabbitMQ — يسهل إعداد وتشغيل وإدارة وسيط الرسائل في AWS Cloud.
Amazon MQ يقدم حلاً قائماً على الطوابير والمواضيع لفصل التطبيقات — يتيح لتطبيقات بلغات برمجة وأنظمة تشغيل مختلفة التواصل عبر بروتوكولات مراسلة قياسية.

📋 مميزات Amazon MQ:

• يدير التجهيز والإعداد والصيانة — يقلل مسؤولياتك التشغيلية.
• يدعم بروتوكولات قياسية: JMS، NMS، AMQP، STOMP، MQTT، WebSocket.
• يمكن الترحيل من أي وسيط رسائل يستخدم هذه المعايير — غالباً بدون إعادة كتابة كود المراسلة.
• يدعم كلاً من الطوابير (Queues) والمواضيع (Topics) — كحل هجين.

شركة لديها تطبيق جافا داخلي يستخدم ActiveMQ للتواصل بين المكونات — تريد الانتقال إلى AWS لتحسين التكاليف. بدلاً من إعادة كتابة كود JMS بالكامل، ترحل إلى Amazon MQ — تغيير نقطة النهاية فقط. كل الكود القديم يعمل كما هو مع تكلفة أقل وصيانة أقل.

3️⃣ Use Case: Hybrid Cloud Environment — حالة استخدام: البيئة السحابية الهجينة

📖 في بيئة هجينة (Hybrid cloud environment)، Amazon MQ يربط التطبيقات الداخلية (On-premises) مع التطبيقات السحابية — مع الحفاظ على الأنظمة القديمة (مثل Mainframe) في مكانها.
Amazon MQ يتيح إرسال الرسائل بين التطبيقات في السحابة والتطبيقات داخل المؤسسة — يمكن استدعاء Lambda من طوابير ومواضيع Amazon MQ لدمج الأنظمة القديمة مع البنى اللاخدمية.

نظام محاسبة داخلي (On-premises) يريد إرسال فواتير إلى تطبيق سحابي للمعالجة. مسؤول النظام ينشئ وسيط Amazon MQ لـ ActiveProxy في منطقة توفر واحدة، ويخزّن الرسائل على EBS محسّن لزمن انتقال منخفض. النظام الداخلي يرسل الفاتورة إلى MQ ← التطبيق السحابي يسحبها ويعالجها ← النظام القديم لا يتغير.

4️⃣ Choosing the Right Decoupling Solution — اختيار حل الفصل المناسب

📖 اختيار حل الفصل المناسب يعتمد على حالة الاستخدام: Amazon SQS وAmazon SNS للتطبيقات السحابية الجديدة، Amazon MQ للتطبيقات الهجينة والترحيل.

المعيار	Amazon SQS	Amazon SNS	Amazon MQ
الاستخدام	تطبيقات سحابية	تطبيقات سحابية أصلية	تطبيقات هجينة + ترحيل
نموذج الرسائل	Producer-Consumer	Publisher-Subscriber	Producer-Consumer + Pub/Sub
API	Amazon SQS API	Amazon SNS API	بروتوكولات قياسية (JMS, AMQP...)
نموذج التسعير	Pay per request	Pay per request	Pay per hour + Pay per GB

🔑 توصية AWS: للتطبيقات السحابية الجديدة → استخدم SQS و SNS. لدمج التطبيقات الداخلية مع السحابية أو ترحيل وسائط الرسائل → استخدم Amazon MQ — بروتوكولات قياسية بدون إعادة كتابة الكود.

شركة لديها ثلاثة سيناريوهات: (1) تطبيق جديد لفصل طلبات الدفع ← SQS. (2) إشعارات متعددة عند رفع ملف ← SNS + SQS Fanout. (3) نظام مخزون داخلي قديم يريد التواصل مع التطبيق السحابي الجديد ← Amazon MQ (بروتوكول JMS قياسي — لا تغيير في الكود القديم). كل أداة في مكانها الصحيح.

اختيار أداة الفصل المناسبة مثل اختيار وسيلة نقل:
📬 SQS = شاحنة توصيل (Point-to-point): تأخذ البضائع من مستودع إلى مستودع واحد محدد.
📡 SNS = محطة راديو (Pub/Sub): تبث إشارة وكل من لديه رايتو يستقبلها — تصل للكل فوراً.
🔌 Amazon MQ = محطة قطار دولية (Standard protocols): تأتي قطارات من أنظمة مختلفة (JMS، AMQP، MQTT) وكلها تلتقي في المحطة المركزية — حتى القطارات القديمة يمكنها الوصول.

✅ خلاصة: فصل تطبيق هجين باستخدام Amazon MQ

• Amazon MQ هو خدمة مُدارة لـ ActiveMQ و RabbitMQ — إعداد وتشغيل وسائط الرسائل في السحابة.
• متوافق مع بروتوكولات المراسلة القياسية المفتوحة — JMS، AMQP، MQTT وغيرها.
• يمكن استخدام Amazon MQ لدمج البيئات الداخلية والسحابية بشكل منفصل.
• يمكن الترحيل من وسائط الرسائل مفتوحة المصدر الداخلية إلى AWS دون إعادة كتابة الكود.
• SQS/SNS = تطبيقات سحابية جديدة. Amazon MQ = تطبيقات هجينة وترحيل.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon MQ	أمازون إم كيو	خدمة وسيط رسائل مُدارة لـ ActiveMQ و RabbitMQ.
Message broker	وسيط الرسائل	برمجية وسيطة تتيح لأنظمة مختلفة التواصل عبر الرسائل.
ActiveMQ	أكتيف إم كيو	وسيط رسائل مفتوح المصدر شائع في تطبيقات المؤسسات.
RabbitMQ	رابيت إم كيو	وسيط رسائل مفتوح المصدر خفيف ومرن.
Hybrid cloud	السحابة الهجينة	بيئة تجمع بين البنية التحتية الداخلية والسحابية.
JMS	خدمة رسائل جافا	واجهة برمجة رسائل قياسية لتطبيقات جافا.
AMQP	بروتوكول الرسائل المتقدم	بروتوكول مراسلة مفتوح قياسي من الطبقة السابعة.

🚀 الخاتمة

في هذه الوحدة تعلمنا الفرق بين البنى المتماسكة (Tightly coupled) والبنى المنفصلة (Loosely coupled) — وكيف أن البنى المتماسكة يصعب توسيعها وتخلق نقاط فشل فردية. تعمقنا في Amazon SQS كخدمة طوابير تُفصل التطبيقات عبر Point-to-point messaging مع نوعي الطوابير Standard وFIFO، ومفاهيم مثل Visibility timeout وLong polling وDead-letter queue. استعرضنا Amazon SNS كخدمة Pub/Sub تدفع الرسائل فوراً لمشتركين متعددين — مع سيناريو Fanout الذي يجمع قوة SNS و SQS معاً. وأخيراً، تعرفنا على Amazon MQ كحاجتك للبيئات الهجينة — حيث يمكن ربط التطبيقات الداخلية القديمة مع التطبيقات السحابية الحديثة عبر بروتوكولات قياسية مثل JMS وAMQP.

تعديل المقال