أنا متأكد من أن العنوان تسبب في رد فعل صحي - "حسنًا ، لقد بدأ مرة أخرى ..." لكن اسمحوا لي أن أسترعي انتباهك لمدة 5-10 دقائق ، وسأحاول ألا أخدع التوقعات.
سيكون هيكل المقال على النحو التالي: يتم أخذ بيان نمطي وإظهار "طبيعة" ظهور هذه الصورة النمطية. آمل أن يسمح لك ذلك بالنظر في اختيار نموذج تبادل البيانات في مشاريعك من زاوية جديدة.
لتوضيح ماهية RPC ، أقترح النظر في معيار JSON-RPC 2.0 . ليس هناك وضوح مع REST. ولا ينبغي أن يكون. كل ما تحتاج لمعرفته حول REST - لا يمكن تمييزه عن HTTP .
طلبات RPC أسرع وأكثر فاعلية لأنها تسمح بطلبات الدُفعات.
النقطة المهمة هي أنه في RPC ، يمكن إجراء العديد من الإجراءات في طلب واحد. على سبيل المثال ، قم بإنشاء مستخدم ، أضف صورة رمزية له وفي نفس الطلب ، سجّله في بعض الموضوعات. طلب واحد فقط ، وكم جيدة!
في الواقع ، إذا كان لديك عقدة خلفية واحدة فقط ، فسيبدو ذلك أسرع مع طلب دفعي. لأن ثلاثة طلبات REST ستتطلب ثلاثة أضعاف موارد من عقدة واحدة لإقامة اتصالات.
يرجى ملاحظة أن الطلب الأول في حالة REST يجب أن يُرجع معرف المستخدم للطلبات اللاحقة. مما يؤثر سلبا على النتيجة الكلية.
ولكن يمكن العثور على مثل هذه البنى التحتية ، في الحلول الداخلية و Enterprise. كملاذ أخير ، في مشاريع الويب الصغيرة. ولكن لا ينبغي بناء حلول WEB الكاملة ، والمسمى أيضًا HighLoad ، على هذا النحو. يجب أن تفي بنيتها التحتية بمعايير التوافر الكبير وعبء العمل. والصورة تتغير.
يشير اللون الأخضر إلى قنوات نشاط البنية التحتية في نفس السيناريو. لاحظ كيف يتصرف RPC الآن. يستخدم الطلب بنية أساسية واحدة فقط من الموازن إلى الواجهة الخلفية. بينما لا يزال REST يخسر في الطلب الأول ، ولكنه يعوض عن الوقت الضائع باستخدام البنية التحتية بأكملها.
يكفي أن تدخل في البرنامج النصي ليس طلبين للتخصيب ، ولكن ، على سبيل المثال ، خمسة أو عشرة ... والإجابة على السؤال "من سيفوز الآن؟" يصبح غير واضح.
أقترح أن ننظر إلى المشكلة على نطاق أوسع. يُظهر الرسم التخطيطي كيفية استخدام قنوات البنية الأساسية ، ولكن البنية الأساسية لا تقتصر على القنوات. أحد المكونات الهامة للبنية التحتية المحملة بشكل كبير هي ذاكرة التخزين المؤقت. دعنا نحصل على بعض القطع الأثرية للمستخدم الآن. عدة مرات. قل 32 مرة.
تعرف على كيفية "استرداد" البنية التحتية على RPC بشكل واضح لتلبية متطلبات الحمل الكبير. الشيء هو أن REST يستخدم القدرة الكاملة لبروتوكول HTTP ، على عكس RPC. في الرسم البياني أعلاه ، تتحقق هذه القدرة من خلال طريقة الطلب - الحصول على.
أساليب HTTP ، من بين أمور أخرى ، لديها استراتيجيات التخزين المؤقت. يمكنك التعرف عليهم في وثائق HTTP . بالنسبة إلى RPC ، يتم استخدام طلبات POST التي لا تعتبر ذات معنى ، أي أن التكرار المتكرر لطلبات POST نفسها قد يؤدي إلى نتائج مختلفة (على سبيل المثال ، بعد إرسال كل تعليق ، ستظهر نسخة أخرى من هذا التعليق) ( المصدر ).
وبالتالي ، لا تتمكن RPCs من استخدام ذاكرة التخزين المؤقت للبنية التحتية بكفاءة. هذا يؤدي إلى حقيقة أنه يجب عليك "استيراد" ذاكرة التخزين المؤقت للبرنامج. يوضح الرسم البياني Redis في هذا الدور. تتطلب ذاكرة التخزين المؤقت الرقيقة ، بدورها ، للمطور طبقة كود إضافية وتغييرات مهمة في البنية.
دعونا الآن نحسب عدد الطلبات "التي ولدت" لـ REST و RPC في البنية التحتية قيد النظر؟
[*] في أفضل الأحوال (إذا تم استخدام ذاكرة التخزين المؤقت المحلية) 1 طلب (واحد!) ، في أسوأ 32 طلبات واردة.
بالمقارنة مع المخطط الأول ، فإن الفرق مذهل. الفوز REST هو واضح الآن. لكنني أقترح عدم التوقف عند هذا الحد. البنية التحتية المتقدمة تشمل CDN. غالبًا ما يحل مشكلة مواجهة هجمات DDoS و DoS. نحصل على:
هنا ل RPC ، يصبح كل شيء المؤسف للغاية. RPC ببساطة غير قادر على تفويض العمل مع تحميل CDN. يمكن للمرء الاعتماد فقط على أنظمة لمواجهة الهجمات.
هل من الممكن انهاء هذا؟ ومرة أخرى ، لا. أساليب HTTP ، كما ذكر أعلاه ، لها "سحر" خاص بها. ولسبب وجيه يتم استخدام طريقة GET بالكامل على الإنترنت. يرجى ملاحظة أن هذه الطريقة قادرة على الوصول إلى جزء من المحتوى ، وأنها قادرة على تحديد الشروط التي يمكن أن تفسر عناصر البنية التحتية قبل نقل التحكم إلى التعليمات البرمجية الخاصة بك ، إلخ. كل هذا يسمح لك بإنشاء بنى تحتية مرنة وقابلة للإدارة يمكنها استيعاب تدفقات الطلبات الكبيرة حقًا. وفي RPC ، يتم تجاهل هذه الطريقة ...
إذن لماذا هي الأسطورة المستمرة لدرجة أن طلبات الدُفعات (RPC) أسرع؟ شخصيا ، يبدو لي أن معظم المشاريع لا تصل ببساطة إلى هذا المستوى من التطور عندما تكون REST قادرة على إظهار قوتها. علاوة على ذلك ، في المشروعات الصغيرة ، من المرجح أن يظهر ضعفه.
اختيار REST أو RPC ليس اختيارًا تطوعيًا للفرد في المشروع. هذا الاختيار يجب أن يفي بمتطلبات المشروع. إذا كان المشروع قادرًا على الضغط من REST على كل ما يمكنه فعلاً ، وهو ضروري بالفعل ، فسيكون REST اختيارًا ممتازًا.
ولكن إذا كنت ترغب في الحصول على جميع أرباح REST ، فسوف تحتاج إلى تعيين مطورين لتوسيع نطاق البنية التحتية بسرعة ، والمسؤولين لإدارة البنية التحتية ، ومهندس معماري لتصميم جميع طبقات خدمة WEB ... وسيقوم المشروع ببيع ثلاث عبوات من السمن النباتي يوميًا ... سوف تتوقف على RPC منذ هذا البروتوكول هو أكثر فائدة. لا يتطلب معرفة متعمقة لتشغيل ذاكرات التخزين المؤقت والبنية التحتية ، ولكن يركز المطور على مكالمات بسيطة ومفهومة للإجراءات اللازمة. سيكون العمل مسروراً.
تعد طلبات RPC أكثر موثوقية لأنها يمكنها تنفيذ طلبات الدفعات في معاملة واحدة
هذه الخاصية من RPC هو زائد واضح ، كما من السهل الحفاظ على قاعدة البيانات في حالة متسقة. ولكن مع REST ، كل شيء أكثر تعقيدًا. قد تصل الطلبات بشكل غير متسق على العقد الخلفية المختلفة.
هذا "العيب" في REST هو الجانب الآخر من مزاياه الموضحة أعلاه - القدرة على الاستخدام الفعال لجميع موارد البنية التحتية. إذا كانت البنية التحتية سيئة التصميم ، وأكثر من ذلك إذا كانت بنية المشروع وقاعدة البيانات على وجه الخصوص مصممة بشكل سيئ ، فإن هذا يعد ألمًا كبيرًا حقًا.
ولكن هل طلبات الدفعات موثوقة كما تبدو؟ دعنا ننظر إلى الحالة: إنشاء مستخدم ، إثراء ملف التعريف الخاص به مع بعض الوصف وإرسال رسالة نصية قصيرة مع سر لإكمال التسجيل. أي ثلاث مكالمات في طلب دفعة واحدة.
لننظر في المخطط. ويعرض البنية التحتية مع عناصر توافر عالية. هناك قناتان اتصال مستقلتان مع عبّارات SMS. لكن ... ماذا نرى؟ عند إرسال رسالة نصية قصيرة ، يحدث الخطأ 503 - الخدمة غير متاحة مؤقتًا. لأن يتم إرسال إرسال الرسائل القصيرة في طلب دفعي ، ثم يجب استرجاع الطلب بأكمله. تم إلغاء الإجراءات في DBMS. يتلقى العميل خطأ.
المحاولة التالية هي يانصيب. إما أن يذهب الطلب إلى العقدة نفسها مرة أخرى ويعود خطأ ، أو أنك محظوظ وسيتم تنفيذه. ولكن الشيء الرئيسي هو أنه على الأقل بمجرد أن تعمل البنية التحتية لدينا دون جدوى. كان هناك حمولة ، ولكن لا ربح.
حسنًا ، دعنا نتخيل أننا متوترًا (!) وفكرنا في الخيار حيث يمكن إكمال الطلب جزئيًا بنجاح. والباقي ، سنحاول مرة أخرى الوفاء بعد فاصل زمني (ما الذي يقرر الجبهة؟). ولكن بقي اليانصيب. طلب إرسال رسالة نصية قصيرة مع احتمال 50/50 سوف تفشل مرة أخرى.
أوافق ، من جانب العميل ، لا تبدو الخدمة موثوقة كما نود ... ولكن ماذا عن REST؟
يستخدم REST HTTP السحر مرة أخرى ، ولكن الآن مع رموز الاستجابة. في حالة حدوث خطأ 503 على بوابة الرسائل القصيرة ، تقوم الواجهة الخلفية ببث هذا الخطأ إلى الموازن. يقوم موازن يتلقى هذا الخطأ ، ودون قطع الاتصال مع العميل ، بإرسال الطلب إلى عقدة أخرى تعالج الطلب بنجاح. أي يتلقى العميل النتيجة المتوقعة ، وتؤكد البنية التحتية على درجة عالية من "الوصول للغاية". المستخدم سعيد.
ومرة أخرى ، هذا ليس كل شيء. لم يتلق الموازن فقط رمز الاستجابة 503. يُنصح بتزويد هذا الرمز برأس "إعادة المحاولة" عند الرد. يوضح الرأس للموازن أنه لا ينبغي عليك إزعاج هذه العقدة على هذا المسار لفترة محددة. وطلبات إرسال الرسائل القصيرة التالية سيتم إرسالها على الفور إلى العقدة التي ليس لديها مشاكل مع بوابة الرسائل القصيرة.
كما نرى ، موثوقية JSON-RPC مبالغ فيها. في الواقع ، من الأسهل تنظيم تناسق قاعدة البيانات. لكن الضحية ، في هذه الحالة ، ستكون موثوقية النظام ككل.
الاستنتاج يشبه إلى حد كبير الاستنتاج السابق. عندما تكون البنية التحتية بسيطة ، فإن وضوح JSON-RPC هي بلا شك ميزة إضافية. إذا كان المشروع ينطوي على توفر عالي مع حمولة عالية ، فإن REST تبدو وكأنها حل أكثر دقة وإن كان أكثر تعقيدًا.
عتبة دخول REST أدناه
أعتقد أن التحليل أعلاه ، الذي كشف عن الصور النمطية الثابتة حول RPC ، أظهر بوضوح أن الحد الأدنى لدخول REST أعلى مما هو عليه في RPC. ويرجع ذلك إلى الحاجة إلى فهم عميق لبروتوكول HTTP ، بالإضافة إلى الحاجة إلى معرفة كافية بعناصر البنية التحتية الحالية التي يمكن وينبغي استخدامها في مشاريع WEB.
إذن لماذا يعتقد الكثير من الناس أن REST سيكون أسهل؟ رأيي الشخصي هو أن هذه البساطة الظاهرة تأتي من REST يتجلى. أي REST ليس بروتوكولًا ، لكنه مفهوم ... REST ليس له معيار ، فهناك بعض التوصيات ... REST ليس أكثر تعقيدًا من HTTP. الحرية الظاهرة والفوضى تجذب "الفنانين الأحرار".
مما لا شك فيه ، REST ليس أكثر تعقيدًا من HTTP. لكن HTTP نفسه هو بروتوكول مصمم جيدًا وقد تم إثباته على مدار عقود. إذا لم يكن هناك فهم عميق ل HTTP نفسه ، فلا يمكن الحكم على REST.
ولكن عن RPC - يمكنك. يكفي أن تأخذ مواصفاتها. هل تحتاج إلى JSON-RPC غبي ؟ أم أنها الماكرة الراحة؟ الأمر متروك لك.
آمل مخلصًا أنني لم أضيع وقتك سدى.