أنا متأكد من أن العنوان تسبب في رد فعل صحي - "حسنًا، لقد بدأ الأمر مرة أخرى..." ولكن دعني أجذب انتباهك لمدة 5 إلى 10 دقائق، وسأحاول ألا أخيب توقعاتك.
سيكون هيكل المقال على النحو التالي: يتم أخذ عبارة نمطية والكشف عن "طبيعة" ظهور هذه الصورة النمطية. آمل أن يسمح لك هذا بالنظر إلى اختيار نموذج تبادل البيانات في مشاريعك من زاوية جديدة.
لكي أكون واضحًا بشأن ماهية RPC، أقترح النظر في المعيار . مع REST لا يوجد وضوح. ولا ينبغي أن يكون. كل ما تحتاج لمعرفته حول REST - لا يمكن تمييزه عنه .
تعد طلبات RPC أسرع وأكثر كفاءة لأنها تسمح لك بتقديم طلبات مجمعة.
النقطة المهمة هي أنه في RPC يمكنك استدعاء عدة إجراءات مرة واحدة في طلب واحد. على سبيل المثال، قم بإنشاء مستخدم، وأضف صورة رمزية له، وفي نفس الطلب، قم بإشتراكه في بعض المواضيع. طلب واحد فقط، وكم الفائدة!
في الواقع، إذا كان لديك عقدة خلفية واحدة فقط، فستبدو أسرع مع الطلب المجمع. لأن ثلاثة طلبات REST ستتطلب ثلاثة أضعاف الموارد من عقدة واحدة لإنشاء الاتصالات.
لاحظ أن الطلب الأول في حالة REST يجب أن يُرجع معرف المستخدم حتى يتم تقديم الطلبات اللاحقة. مما يؤثر أيضًا سلبًا على النتيجة الإجمالية.
ولكن لا يمكن العثور على مثل هذه البنى التحتية إلا في الحلول الداخلية والمؤسسات. كملاذ أخير، في مشاريع الويب الصغيرة. لكن حلول الويب الكاملة، وحتى تلك التي تسمى HighLoad، لا تستحق البناء. يجب أن تستوفي بنيتها التحتية معايير التوافر والتحميل العالي. والصورة تتغير.
يتم تمييز قنوات نشاط البنية التحتية في نفس السيناريو باللون الأخضر. لاحظ كيف يتصرف RPC الآن. يستخدم الطلب البنية التحتية على ساق واحدة فقط من الموازن إلى الواجهة الخلفية. في حين أن REST لا يزال يخسر في الطلب الأول، فإنه يعوض الوقت الضائع باستخدام البنية التحتية بأكملها.
يكفي أن ندخل في السيناريو ليس طلبين للتخصيب، بل خمسة أو عشرة على سبيل المثال... والإجابة على سؤال "من يفوز الآن؟" يصبح غير واضح.
أقترح إلقاء نظرة أوسع على المشكلة. يوضح الرسم التخطيطي كيفية استخدام قنوات البنية الأساسية، ولكن البنية الأساسية لا تقتصر على القنوات. أحد المكونات المهمة للبنية التحتية عالية التحميل هو ذاكرة التخزين المؤقت. دعونا الآن نحصل على نوع من قطعة أثرية للمستخدم. مرارا وتكرارا. لنفترض 32 مرة.
شاهد كيف تحسنت البنية الأساسية لـ RPC بشكل ملحوظ لتلبية متطلبات الحمل العالي. الشيء هو أن REST يستخدم القوة الكاملة لبروتوكول HTTP، على عكس RPC. في الرسم البياني أعلاه، يتم تحقيق هذه القوة من خلال طريقة الطلب - GET.
أساليب HTTP، من بين أمور أخرى، لديها استراتيجيات التخزين المؤقت. يمكنك العثور عليها في الوثائق في . بالنسبة لـ RPC، يتم استخدام طلبات POST، والتي لا تعتبر غير فعالة، أي أن التكرار المتكرر لنفس طلبات POST قد يؤدي إلى نتائج مختلفة (على سبيل المثال، بعد إرسال كل تعليق، ستظهر نسخة أخرى من هذا التعليق) ().
وبالتالي، RPC غير قادر على استخدام ذاكرات التخزين المؤقت للبنية الأساسية بشكل فعال. وهذا يؤدي إلى الحاجة إلى "استيراد" ذاكرة التخزين المؤقت للبرامج. يُظهر الرسم البياني Redis في هذا الدور. تتطلب ذاكرة التخزين المؤقت للبرنامج بدورها من المطور إضافة طبقة إضافية من التعليمات البرمجية وتغييرات ملحوظة في البنية.
دعونا الآن نحسب عدد الطلبات التي "ولدتها" REST و RPC في البنية التحتية قيد النظر؟
طلبات
البريد الوارد
إلى الواجهة الخلفية
إلى نظام إدارة قواعد البيانات
إلى ذاكرة التخزين المؤقت الناعمة (Redis)
المجموع
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
بالمقارنة مع المخطط الأول، فإن الفرق لافت للنظر. الآن أصبحت فائدة REST واضحة. لكنني أقترح عدم التوقف عند هذا الحد. تتضمن البنية التحتية المطورة CDN. غالبًا ما يحل أيضًا مشكلة مكافحة هجمات DDoS وDoS. نحن نحصل:
هذا هو المكان الذي تصبح فيه الأمور سيئة للغاية بالنسبة لـ RPC. RPC ببساطة غير قادر على تفويض عبء العمل إلى CDN. لا يمكننا الاعتماد إلا على الأنظمة لمواجهة الهجمات.
هل من الممكن أن تنتهي هنا؟ ومرة أخرى، لا. أساليب HTTP، كما ذكرنا أعلاه، لها "سحر" خاص بها. وليس من قبيل الصدفة أن يتم استخدام طريقة GET على نطاق واسع على الإنترنت. لاحظ أن هذه الطريقة قادرة على الوصول إلى جزء من المحتوى، وقادرة على تعيين الشروط التي يمكن لعناصر البنية التحتية تفسيرها قبل نقل التحكم إلى التعليمات البرمجية الخاصة بك، وما إلى ذلك. كل هذا يسمح لك بإنشاء بنيات تحتية مرنة وسهلة الإدارة يمكنها التعامل مع تدفقات كبيرة من الطلبات. ولكن في RPC يتم تجاهل هذه الطريقة....
فلماذا تستمر الأسطورة القائلة بأن الطلبات المجمعة (RPC) أسرع؟ شخصيًا، يبدو لي أن معظم المشاريع ببساطة لا تصل إلى مستوى من التطوير حيث تكون REST قادرة على إظهار قوتها. علاوة على ذلك، في المشاريع الصغيرة، فهو أكثر استعدادًا لإظهار نقاط ضعفه.
إن اختيار REST أو RPC ليس اختيارًا إراديًا للفرد في المشروع. يجب أن يلبي هذا الاختيار متطلبات المشروع. إذا كان المشروع قادرًا على استخلاص كل ما يمكنه فعله من REST، وكان يحتاج إليه حقًا، فسيكون REST خيارًا ممتازًا.
ولكن، للحصول على جميع فوائد REST، إذا كنت بحاجة إلى توظيف متخصصين في تطوير المشروع لتوسيع نطاق البنية التحتية بسرعة، ومسؤولين لإدارة البنية التحتية، ومهندس معماري لتصميم جميع طبقات خدمة الويب... والمشروع ، في الوقت نفسه، يبيع ثلاث علب من السمن النباتي يوميًا... سألتزم بـ RPC، لأن... هذا البروتوكول أكثر نفعية. لن يتطلب الأمر معرفة عميقة بكيفية عمل ذاكرات التخزين المؤقت والبنية التحتية، ولكنه سيركز المطور على استدعاءات بسيطة ومفهومة للإجراءات التي يحتاجها. الأعمال سوف تكون سعيدة.
تعد طلبات RPC أكثر موثوقية لأنها يمكنها تنفيذ الطلبات المجمعة ضمن معاملة واحدة
تعتبر خاصية RPC هذه ميزة أكيدة، لأنها من السهل الحفاظ على اتساق قاعدة البيانات. ولكن مع REST يصبح الأمر أكثر تعقيدًا. قد تصل الطلبات بشكل غير متسق إلى العقد الخلفية المختلفة.
هذا "العيب" في REST هو الجانب الآخر من ميزته الموضحة أعلاه - القدرة على استخدام جميع موارد البنية التحتية بكفاءة. إذا كانت البنية التحتية سيئة التصميم، والأكثر من ذلك إذا كانت بنية المشروع وقاعدة البيانات على وجه الخصوص سيئة التصميم، فهذا يمثل ألمًا كبيرًا حقًا.
ولكن هل الطلبات المجمعة موثوقة كما تبدو؟ دعونا نلقي نظرة على حالة: نقوم بإنشاء مستخدم وإثراء ملفه الشخصي ببعض الوصف ونرسل له رسالة نصية قصيرة تحتوي على سر لإكمال التسجيل. أولئك. ثلاث مكالمات في طلب دفعة واحدة.
دعونا نلقي نظرة على الرسم البياني. إنه يقدم بنية تحتية ذات عناصر توفر عالية. هناك قناتان اتصال مستقلتان مع بوابات الرسائل القصيرة. لكن... ماذا نرى؟ عند إرسال رسالة نصية قصيرة، يحدث خطأ 503 - الخدمة غير متاحة مؤقتًا. لأن يتم حزم إرسال الرسائل القصيرة في طلب دفعة، ثم يجب التراجع عن الطلب بأكمله. يتم إلغاء الإجراءات في نظام إدارة قواعد البيانات (DBMS). يتلقى العميل خطأ.
المحاولة التالية هي اليانصيب. إما أن يصل الطلب إلى نفس العقدة مرارًا وتكرارًا ويعيد خطأً، أو ستكون محظوظًا وسيتم تنفيذه. لكن الشيء الرئيسي هو أنه على الأقل مرة واحدة كانت بنيتنا التحتية تعمل دون جدوى. كان هناك حمولة، ولكن لا يوجد ربح.
حسنًا، لنتخيل أننا أجهدنا أنفسنا (!) وفكرنا في الخيار الذي يمكن فيه إكمال الطلب جزئيًا بنجاح. وسنحاول استكمال الباقي مرة أخرى بعد فترة زمنية (أيهما؟ هل الجبهة هي التي تقرر؟). لكن اليانصيب بقي على حاله. طلب إرسال الرسائل القصيرة لديه فرصة 50/50 للفشل مرة أخرى.
أوافق، من جانب العميل، لا تبدو الخدمة موثوقة كما نود... ماذا عن REST؟
يستخدم REST سحر HTTP مرة أخرى، ولكن الآن مع رموز الاستجابة. عند حدوث خطأ 503 على بوابة الرسائل القصيرة، تقوم الواجهة الخلفية ببث هذا الخطأ إلى الموازن. يتلقى الموازن هذا الخطأ ودون قطع الاتصال بالعميل، يرسل الطلب إلى عقدة أخرى تقوم بمعالجة الطلب بنجاح. أولئك. يحصل العميل على النتيجة المتوقعة، وتؤكد البنية التحتية لقبها العالي "سهل الوصول إليه". المستخدم سعيد.
И опять это не все. Балансировщик не просто получил код ответа 503. Этот код при ответе, по стандарту, желательно снабдить заголовком “Retry-After». Заголовок дает понять балансировщику, что не стоит беспокоить эту ноду по этому роуту в течении заданного времени. И следующие запросы на отправку SMS будут направляться сразу на ноду, у которой нет проблем с SMS шлюзом.
كما نرى، فإن موثوقية JSON-RPC مبالغ فيها. في الواقع، من الأسهل تنظيم الاتساق في قاعدة البيانات. لكن التضحية، في هذه الحالة، ستكون موثوقية النظام ككل.
الاستنتاج يشبه إلى حد كبير الاستنتاج السابق. عندما تكون البنية التحتية بسيطة، فإن وضوح JSON-RPC يعد بالتأكيد ميزة إضافية. إذا كان المشروع يتضمن توفرًا عاليًا مع حمل مرتفع، فإن REST يبدو كحل أكثر صحة، على الرغم من أنه أكثر تعقيدًا.
عتبة الدخول إلى REST أقل
أعتقد أن التحليل أعلاه، الذي فضح الصور النمطية الراسخة حول RPC، أظهر بوضوح أن عتبة الدخول إلى REST أعلى بلا شك من عتبة RPC. ويرجع ذلك إلى الحاجة إلى فهم عميق لكيفية عمل HTTP، بالإضافة إلى الحاجة إلى المعرفة الكافية حول عناصر البنية التحتية الحالية التي يمكن ويجب استخدامها في مشاريع الويب.
فلماذا يعتقد الكثير من الناس أن REST سيكون أبسط؟ رأيي الشخصي هو أن هذه البساطة الواضحة تأتي من REST تتجلى في نفسها. أولئك. REST ليس بروتوكولًا ولكنه مفهوم... REST ليس له معيار، وهناك بعض الإرشادات... REST ليس أكثر تعقيدًا من HTTP. إن الحرية والفوضى الظاهرة تجتذب "الفنانين الأحرار".
بالطبع، REST ليس أكثر تعقيدًا من HTTP. لكن HTTP نفسه عبارة عن بروتوكول مصمم جيدًا وقد أثبت جدارته على مدار عقود. إذا لم يكن هناك فهم عميق لـ HTTP نفسه، فلا يمكن الحكم على REST.
ولكن فيما يتعلق بـ RPC - يمكنك ذلك. ويكفي أن تأخذ مواصفاته. فهل تحتاج ؟ أم أنها لا تزال صعبة بقية؟ انت صاحب القرار.
وآمل مخلصا أنني لم أضيع وقتك.
المصدر: www.habr.com