توسيع نطاق عميل API من خلال الاتصال المتعدد

يتم تشغيل الحل القياسي لعميل API واتساب للأعمال على حاوية Docker واحدة. وفي حالة رغبتك في تقسيم الحمل وكان لديك خوادم متعددة ترسل وتتلقى رسائل في واتساب، يمكنك الاستفادة من حل الاتصال المتعدد الذي نوفره فوق كل ذلك.

نظرة عامة

عند استخدام التوّفر العالي، تكون حاوية Docker واحدة فقط مسؤولة عن إرسال رسائل إلى خوادم واتساب وتلقيها منه. وإذا تجاوزت نسبة استخدام الشبكة للمراسلة الحد الأقصى لمعدل حاوية Docker مفردة، فسيحدث تراكم لعمليات إرسال الرسائل وسيزيد وقت تأخر إرسال الرسالة. لتوسيع نطاق عميل API واتساب للأعمال، يدعم حل الاتصال المتعدد التقسيم لتوزيع الحمولات عبر العديد من حاويات Docker. ولا ندعم حاليًا سوى التقسيم الثابت بالقسم رقم 1 أو 2 أو 4 أو 8 أو 16 أو 32. تكون الإتاحة العالية حالة خاصة من حل multiconnect حيث يكون القسم بالرقم 1.

مجموعة multiconnect بالقسم رقم 2

تتضمن المجموعة عقدتي Coreapp وهما (CoreApp 1 وCoreApp 3) حيث إنهما مسؤولتان عن إرسال رسائل إلى خادم واتساب وتلقيها منه في الوقت نفسه. ولا تنتمي كل الرسائل إلا إلى قسم واحد بناءً على معرف المستلم.

التقسيم

يستخدم عميل واجهة API واتساب للأعمال التقسيم للوصول إلى حل multiconnect. وبناءً على أرقام الأقسام التي قمت بإعدادها، ستخزّن قاعدة البيانات خريطة قسم تحدد القسم الذي يتعين انتقال الرسائل إليه بناءً على معرف المستلم (أو اسم مستخدم واتساب). وفيما يلي الدالة التي تحدد ذلك:

shard_id = hash(recipient-id) % shard-number

يتم تعيين كل قسم إلى حاوية Docker قيد التشغيل (Coreapp). وسيحدد Webapp حاوية Docker التي يتعين إرسال طلب الرسالة إليها بناءً على إرجاع هذه الدالة. كما أنها توصيك بإعداد أجهزة بالجزء رقم + X بغرض إمكانية تحمل حالات فشل الجهاز X.

في الرسم البياني المكون من قسمين لحل الاتصال المتعدد بالأعلى، يتم توجيه الرسائل إلى CoreApp 1 وCoreApp 3 استنادًا إلى وظيفة التقسيم. في حين تُعد عقدة CoreApp 2 ثانوية — فهي جاهزة، ولكن لا تمتلك اتصال نشط بخوادم واتساب. افترض أن العقدة CoreApp 1 تستدعي الرسائل لـ shard=0 وأن العقدة CoreApp 3 تستدعي الرسائل لـ shard=1. إذا توقفت العقدة CoreApp 1، فستتأثر الرسائل من shard=0 فقط. وسيستمر النظام في إرسال واستقبال الرسائل التي تنتمي إلى shard=1 باستخدام العقدة CoreApp 3. ومثلما هو الحال في التوّفر العالي، ستكشف العقدة Master 1 عن وجود أية حالة فشل في العقدة CoreApp 1 وتجاوز فشل في نسبة استخدام الشبكة في القسم shard=0 للعقدة CoreApp 2. علمًا بأن عملية تجاوز الفشل هذه تستغرق حوالي 35 ثانية.

إعداد الاتصال المتعدد

بمجرد إعداد المجموعة وفقًا لـ مستندات التوّفر العالي، استخدم الطلب التالي لتشغيل الاتصال المتعدد.

الطلب

POST /v1/account/shards
{
    "cc": "country-code",
    "phone_number": "phone-number",
    "shards": 1 | 2 | 4 | 8 | 16 | 32,
    "pin": "pin",
    "cert": "verified-name-cert-in-base64"
}

المعلمات

الاستجابة

201 Created   : You successfully changed shard number 
403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it

استرداد معلومات القسم

الطلب

GET /v1/account/shards

الاستجابة

{
  "account": {
      "shards": number-of-shards 
  }
}

أسعار إرسال الرسائل

اطلع على المرجع، الرسائل، الأداء.

تفاصيل نشر AWS

عناوين URL للقوالب:

• المؤسسة: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
• قاعدة البيانات: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_db.yml?versionId=3.vthzENa7qUOuZrozcX9hDk9n8.kdTg
• Lambda: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_lambda.yml?versionId=gqIhZaXkX_NylKaPJMDBlQNk9.Pl_34b
• الشبكة: https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

يتيح لك القالب تكوين عدد مثيلات حاوية Coreapp النشطة التي سيتم إنشاؤها. وينشئ القالب مثيلاً إضافيًا واحدًا لحاوية Coreapp للمساعدة في التبديل السريع في حالة فشل Coreapp.

ينشئ القالب العدد التالي من المثيلات لكل نوع بيئة في الاتصال المتعدد، افتراضيًا، عند تمكين التوّفر العالي:

• الإنتاج: مثيلات EC2: 3، حاوية الويب: 3، حاوية Coreapp: 3، حاوية Master: 3
• التجهيز: مثيلات EC2 : 3، حاوية الويب: 3، حاوية Coreapp : 3، حاوية Master : 3

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

تعيين حجم مثيل RDS

يحدد معدل طلب API وعدد مثيلات Coreapp النشطة عدد عمليات الاتصال بقاعدة البيانات. ومع وجود 8 مثيلات Coreapp ومعدل API يبلغ 100 رسالة/ثانية، يتطلب الأمر حوالي 700 اتصال بقاعدة البيانات (مع تعطيل SSL) و1200 اتصال بقاعدة البيانات (عند تمكين SSL). مع ذلك، في وجود 32 من مثيلات Coreapp النشطة ومعدل API يبلغ 250 رسالة/ثانية، يتطلب الأمر حوالي 1700 اتصال بقاعدة البيانات.

في الإصدار الحالي، استخدمنا db.m4.2xlarge لـ 8 من مثيلات Coreapp النشطة (مع تعطيل تشفير الاتصال بقاعدة البيانات) واستخدمنا db.m4.4x.large لـ 32 من مثيلات Coreapp النشطة (مع تمكين تشفير الاتصال بقاعدة البيانات). يوفر الجدول التالي إرشادات حول تحديد فئة مثيل RDS والحد الأقصى لعدد الاتصالات التي يمكن أن يدعمها:

التكوين

• تتحكم مثيلات Coreapp النشطة التي تم تعيينها في قالب فقط في عدد مثيلات Coreapp التي تم إنشاؤها. ومع ذلك، لتنشيط العملية نفسها، يجب استخدام تعيين الأقسام (موضحة في القسم إعداد الاتصال المتعدد). علمًا بأن القيمة الافتراضية للأقسام هي 1.
• تأكد دائمًا من أن عدد مثيلات Coreapp أكبر من أو يساوي عدد الأقسام التي تم تعيينها في API.
• لزيادة عدد الأقسام:

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

  • استخدم تعيين الأقسام لتقليل عدد أقسام/مثيلات Coreapp النشطة.
  • بمجرد إعادة تشغيل جميع مثيلات Coreapp بنجاح، قم بتحديث المكدس بعدد مثيلات Coreapp النشطة نفسه.
  • ملاحظة: قد يؤدي تحديث المكدس إلى إنهاء مثيلات Coreapp النشطة حاليًا والتي تعرض القسم. ومع ذلك، فإن مثيلات Coreapp النشطة الأخرى سيتم تعيينها بعد وقت قصير. بعبارة أخرى، قد يكون هناك وقت تعطل إضافي (~35 ثانية تقريبًا) أثناء هذا الإجراء.