ما هو gRPC؟

RPC، أو استدعاء الإجراءات عن بعد، هو نموذج اتصال لتفاعل العميل / الخادم الذي يمكن الاستدعاءات عن بُعد من الظهور والعمل كاستدعاءات محلية. إنها تقنية قديمة، يعود تاريخها النظري إلى سبعينيات القرن العشرين، مع تطبيقات أولية شوهدت في مشاريع الحوسبة الرائدة مثل ARPANET و Xerox PARC.

في استدعاء الإجراءات عن بُعد (RPC)، يتفاعل العميل مع تمثيل الخادم، والذي يبدو محلياً ولكنه في الواقع وسيط. يُشار إلى هذا الوسيط عادةً باسم كعب، والذي يتعامل مع تنظيم البيانات وإلغاء تنظيمها (أي تحويل البيانات إلى تنسيق مناسب للإرسال وتحويل النتائج المستلمة من الخادم إلى التنسيق الأصلي). نظرا لأنه أسلوب بنائي للاتصال بين العميل / الخادم ، فإنه يستخدم بشكل شائع في تصميم واجهة برمجة التطبيقات.

هناك العديد من التطبيقات المختلفة لأطر عمل RPC، بما في ذلك XML-RPC و JSON-RPC. تستخدم هذه التطبيقات HTTP كبروتوكول نقل، وتختلف في الغالب في نوع التنسيق. يعود تاريخ هذه التنفيذات إلى تسعينيات القرن العشرين وعقد الألفينيات، وقد أظهرت نقاط قوة RPC: فقد قامت بتبسيط التطوير، وتجريد تعقيدات الاتصالات الشبكية، وكانت خفيفة الوزن، وسهلة الاستخدام نسبيًا، وقابلة للقراءة من قبل البشر.

ومع ذلك، فإن العديد من البيئات الحديثة - خاصةً تلك التي تستخدم بنيات الخدمات المصغرة والبيئات متعددة التكتلات والأنظمة ذات الأحمال العالية للبيانات - تتطلب إطار عمل أسرع وعالي الأداء لربط التطبيقات الموزعة. من الناحية المثالية، يسهّل هذا الإطار نقل البيانات بشكل أكثر كفاءة وفي الوقت الفعلي بين الخدمات التي تعمل عبر بيئات ومركز البيانات مختلفة.

تم تطوير gRPC لتلبية هذه الحاجة، حيث يوفر زمن انتقال قصير ومعدل نقل عاليًا من خلال تسلسل البيانات واستخدامه لبروتوكول HTTP/2، وقدرات البث ثنائي الاتجاه، وتوليد التعليمات البرمجية والمزيد.

تم إصدار gRPC في البداية في عام 2015، وهو نفس العام الذي تم فيه إصدار HTTP/2. فهو يعالج أوجه القصور في تطبيقات RPC القديمة بشكل أساسي من خلال استخدامه لمخازن البروتوكول المؤقتة، أو Protobuf، ولغة تعريف الواجهة (IDL) الخاصة به. يقوم Protobuf بتسلسل وتشفير البيانات المنظمة إلى نظام ثنائي. يؤدي هذا إلى جعل البيانات أكثر إحكاماً، مما يتيح نقلًا أسرع وأداءً أعلى.

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

سيكون من المنطقي أن يرمز gRPC إلى "Google Remote Procedure Call". لكن فريق gRPC في grpc.io يدعي بوقاحة أنه يرمز إلى "gRPC Remote Procedure Call". يشير موقع GitHub الخاص بها إلى أن الحرف "g" يشير إلى شيء مختلف مع كل إصدار (بدءًا من "gregarious" إلى "Goose" إلى "Guadalupe River Park Conservancy"). على أية حال، قامت Google بتطوير gRPC وأصدرته كمشروع مفتوح المصدر في عام 2015.

يقدم gRPC نسخة حديثة ومحدثة من RPC، مع دعم للغات الحديثة وميزات وتحسينات إضافية. تشمل الميزات ما يلي:

• لغة تصميم واجهة (IDL) تسمى المخازن المؤقتة للبروتوكول
• استخدام HTTP/2 لنقل البيانات
• البث ثنائي الاتجاه
• إنشاء التعليمات البرمجية
• أربعة أنواع من الطرق
• التكامل مع الأمان المستند إلى TLS
• دعم Interceptor للتسجيل والتتبع والمصادقة والمزيد

المخازن المؤقتة للبروتوكول (Protocol Buffers)، المعروفة باسم Protobuf، هو تنسيق بيانات عبر المنصات تم تطويره بواسطة Google ويستخدم إعداد تسلسل البيانات المنظمة. في الواقع ، يعمل كوسيط قوي بين العميل والخادم الذي يقوم بإعداد تسلسل الطلبات إلى رمز ثنائي للإرسال.

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

بشكل أساسي، يقوم المطورون بإنشاء ملف نصي باللاحقة ".proto" يحتوي على جميع المعلومات حول بنية البيانات. تستند هذه المعلومات إلى المخطط، مما يعني أنها تحدد المعلمات والأساليب والمخرجات المحتملة - وهو وصف لبنية البيانات. على سبيل المثال، قد يكون لديك إدخال لـ "المستخدم"، والذي يشير إلى أن هذه البيانات ستتضمن "الاسم" و "عنوان البريد الإلكتروني" و "مكونات البيتزا المفضلة".

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

يمكن للمطورين استخدام محول برمجي يسمى Protoc لإنشاء شيفرة برمجية بأي لغة من اللغات العديدة المدعومة، بما في ذلك C# وC++C وDart وGo وJava وKotlin وNode.js, Objective-C، PHP، Python و Ruby. يخدم هذا الرمز العديد من الوظائف: فهو عادة ما يتضمن فئات أو وحدات ، ويتعامل مع التسلسل إلى ثنائي وإلغاء التسلسل من ثنائي وإزالة تعقيدات تبادل البيانات. لا داعي لأن يقلق المطورون بشأن تغليف الشبكة، والتجميع، والتحديث من أجل التوافق والتنفيذ؛ حيث إن Protobuf يتعامل مع كل ذلك.

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

HTTP/2 هو بروتوكول نقل - طريقة تستخدمها أجهزة الكمبيوتر والخوادم لتبادل المعلومات - يستخدم تنسيقًا ثنائيًا لإرسال الرسائل، ويقلل من اتصالات TCP ويستخدم ضغط الرؤوس، وكل ذلك يساعد في جعله أسرع وأكثر كفاءة من سابقه (HTTP/1.1). كما أنه يمكّن تعدد الإرسال، أو القدرة على إرسال تدفقات متعددة متزامنة على اتصال واحد؛ ويستخدم gRPC ما يسمى بالقنوات لتمكين التدفقات المتعددة عبر تلك الاتصالات المتعددة. يتم إرسال الرسائل كإطارات بيانات HTTP/2، قد يحتوي كل منها على رسائل gRPC متعددة.

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

يستخدم gRPC أداة مترجم تسمى Protoc لإنشاء كل من كود العميل والخادم تلقائيا بلغات مختلفة بناء على تعريفات الخدمة وهياكل الرسائل المحددة في ملف .proto. يمكن استخدام المكونات الإضافية لتوسيع دعم العديد من اللغات.

يقوم Protoc بإنشاء فئات الوصول إلى البيانات باللغة المحددة في التعريف الأولي. توفر هذه الفئات معالجات بسيطة للحقول مثل [الاسم]، بالإضافة إلى طرق لتسلسل البنية وتحليلها من وإلى البايت الخام^.1

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

يحتوي gRPC على تكامل مدمج مع TLS (أمان طبقة النقل)، والذي يقوم بتشفير تبادل البيانات بين العميل والخادم ويمكّن المستخدمين من المساعدة في تأمين الاتصالات.

يدعم نظام gRPC المصادقة القابلة للتوصيل والتتبع والتسجيل والمقاييس وموازنة التحميل والتحقق من السلامة وغير ذلك الكثير. 

يحتوي gRPC على أربعة أنواع مختلفة من الأساليب، والتي تشير إلى كيفية إرسال الرسالة واستقبالها من قبل عميل gRPC وخادم gRPC. وهذه الأنواع هي:

أحادي: استدعاء بسيط يرسل فيه العميل طلبًا واحدًا ويرد الخادم باستجابة واحدة.

تدفق من جانب الخادم: استدعاء يرسل فيه العميل طلبًا واحدًا، لكن الخادم يرد باستجابات متعددة.

تدفق من جانب العميل: استدعاء يرسل فيه العميل طلبات متعددة ويرد الخادم باستجابة واحدة. يمكن للخادم اختيار الانتظار حتى يتوقف التدفق الكامل لطلبات العميل قبل المعالجة والاستجابة.

تدفق ثنائي الاتجاه: يقوم كل من العميل والخادم بإرسال مكالمات متعددة ذهاباً وإياباً بشكل متزامن، مما يتيح الاتصال في الوقت الفعلي.

كل من gRPC وREST هي أنماط بنائية شائعة الاستخدام في تصميم واجهة برمجة التطبيقات. هناك العديد من أوجه التشابه بينهما؛ فكلاهما يتبعان بنية العميل/الخادم، ويعتمدان على الاتصال القائم على HTTP، وهما بلا حالة ولا يعتمدان على اللغة. لكنها تختلف أيضًا في طرق رئيسية تجعل كل منها مثاليًا لحالات استخدام مختلفة.

تنسيق البيانات: تستخدم واجهات برمجة تطبيقات REST APIs تنسيقات نصية عادية مثل JSON و XML. يستخدم gRPC Protobuf لتشفير البيانات إلى نظام ثنائي.

نمط الاتصال: يدعم gRPC أربع طرق: البث الأحادي وتدفق الخادم وتدفق العميل والبث ثنائي الاتجاه. يستخدم REST نظامًا أحاديًا للطلب والاستجابة.

إنشاء التعليمات البرمجية: يوفر gRPC ميزة مدمجة لإنشاء التعليمات البرمجية؛ بينما لا يوفر REST ذلك، على الرغم من وجود مكونات إضافية متاحة.

نمط التصميم: يحتوي gRPC على تصميم موجه نحو الخدمة ، حيث تُعرف عمليات الخادم القابلة للاستدعاء بأنها خدمات أو وظائف. في REST، يكون التصميم موجهًا نحو الموارد، حيث تُستخدم أساليب HTTP للوصول إلى موارد الخادم من خلال نقاط النهاية المحددة في عناوين URL.

البروتوكول: يستخدم بروتوكول gRPC HTTP/2، بينما يعتمد REST على HTTP/1.1.

الترابط: العميل والخادم في gRPC مرتبطان ارتباطًا وثيقًا، ما يعني أن كلاً من العميل والخادم يجب أن يكون لهما حق الوصول إلى ملف proto الخاص بالبرمجيات الوسيطة نفسه. أي تغيير في أحدهما يتطلب تغييرًا في الآخر. في REST، يكون الترابط ضعيفًا. وهذه الاستقلالية تعني أن التغييرات في أحد العناصر لا تؤثر في العنصر الآخر.

يستخدم gRPC غالبًا لواجهات برمجة التطبيقات المعقدة التي تربط خدمات متعددة في بيئة موزعة. تجعل قدرة التدفق في الوقت الحقيقي والأداء العالي من gRPC مناسبًا للعديد من حالات الاستخدام بما في ذلك الخدمات المصغرة والبث وربط عملاء إنترنت الأشياء.

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

نظرًا لأن gRPC لا يعتمد على اللغة، فيمكنه تمكين الاتصال بين الخدمات المكتوبة بلغات برمجة مختلفة. بالإضافة إلى ذلك، توفر تعريفات Protobuf مخططًا قويًا يساعد في حماية سلامة بيانات الخدمة المصغرة.

تعني قدرات البث ثنائي الاتجاه لـ gRPC أنه يمكنه بث البيانات في كلا الاتجاهين بشكل متزامن بين العميل والخادم عبر اتصال شبكة واحد. تجعل هذه القدرة gRPC مثاليًا للعمليات الجارية مثل مؤتمرات الفيديو أو عندما يريد المستخدم استخدام جزء من مجموعة البيانات أثناء نقل البيانات الأخرى.

يشير إنترنت الأشياء إلى شبكة من الأجهزة المتصلة أو العملاء. تُشمل أجهزة إنترنت الأشياء (IOT) - والمعروفة أيضًا باسم "الأشياء الذكية" - أجهزة "المنزل الذكي" البسيطة مثل منظمات الحرارة الذكية، والأجهزة القابلة للارتداء مثل الساعات الذكية والملابس التي تدعم تقنية RFID والآلات الصناعية المعقدة وأنظمة النقل². وتُستخدم واجهات برمجة تطبيقات gRPC غالبًا لتسهيل تبادل البيانات المتناسق بين هذه الأجهزة.

بفضل دعمها للبث ثنائي الاتجاه وقدراتها الملائمة للخدمات المصغرة (ووضعها كمشروع CNCF)، يتم استخدام gRPC بشكل متزايد لواجهات برمجة التطبيقات للسحابة الأصلية .

يُستخدم gRPC لإنشاء مكتبات عملاء بالعديد من لغات البرمجة المختلفة. يتم إنشاء هذه المكتبات بناءً على تعريف الخدمة المقدم في ملفات .proto؛ بمجرد تعريف الخدمة، يقوم gRPC تلقائيًا بإنشاء رمز العميل بلغة برمجة مختارة.

هذه القدرة تبسط العمل للمطورين، وتتيح لهم التركيز على منطق التطبيق بدلاً من التعليمات البرمجية للاتصالات منخفضة المستوى.

يوفر gRPC العديد من الفوائد للمجموعات والمطورين الذين يقومون ببناء واجهات برمجة التطبيقات ذات متطلبات الأداء العالي. وتتضمن هذه الفوائد ما يلي:

نقل أسرع وأكثر كفاءة: هناك العديد من العوامل التي تساهم في الأداء العالي لـ gRPC. أولاً، يقلل تسلسل Protobuf من حجم الرسالة ويمكن نقل الحزم الأصغر بسرعة أكبر. يتم أيضاً تحليل Binary بشكل أكثر كفاءة من تنسيقات النص العادي مثل JSON أو XML.

وبالإضافة إلى ذلك، يستخدم gRPC نظام نقل النص عبر بروتوكول الإنترنت (HTTP/2)، وهو أسرع وأكثر كفاءة من HTTP/1.1، مما يؤدي إلى تقليل زمن الانتقال واستخدام النطاق الترددي بشكل أكبر.

قابلية أكبر للنقل: نظرًا لأن gRPC يستخدم المخازن المؤقتة للبروتوكول (آلية تسلسل لا تعتمد على اللغة والمنصة) لوصف هياكل البيانات وواجهات RPC، يمكن استخدامه لتمكين الاتصال بين الخدمات المكتوبة بلغات مختلفة عبر منصات مختلفة.

تقليل أخطاء وقت التشغيل: يوفر Protobuf تصنيفًا قويًا، مما يعني أنه يفرض بنية بيانات ثابتة ومحددة بوضوح. تعزز الكتابة القوية الاتساق والكشف المبكر عن الأخطاء، مما يقلل من فرصة حدوث أخطاء في وقت التشغيل.

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

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

التعقيد: تعريف هياكل الرسائل والخدمات في ملفات .proto، كما يتطلب gRPC ، يمكن أن يكون أكثر صعوبة من العمل مع التنسيقات المستندة إلى النص مثل XML و JSON.

سهولة الاستخدام: يمكن أن تقدم gRPC والمخازن المؤقتة للبروتوكول و HTTP/2 منحنى تعليميًا حادًا للمطورين المعتادين على العمل مع REST.

تصحيح الأخطاء: قد يكون من الصعب فحص تطبيقات gRPC وتصحيحها وتسجيلها لأن التنسيق الثنائي غير قابل للقراءة البشرية. هناك أدوات يمكنها تحويل النظام الثنائي، لكنها تتطلب خطوة إضافية، مقارنةً بـ XML أو JSON.

الحداثة والدعم: gRPC ليس قديمًا مثل الأنماط البنائية الشائعة الأخرى مثل REST وليس لديه مجتمع كبير أو قدر كبير من الدعم للمكونات الإضافية والوثائق. وباعتباره إطار عمل أحدث، هناك عدد أقل من الأدوات (مثل أدوات الفحص الأمني) المتاحة لـ gRPC مقارنةً ببعض الأنماط الأكثر رسوخًا.

قيود المتصفحات: نظرًا إلى أن متصفحات الويب لا تدعم بروتوكول gRPC في الأصل، فمن غير الممكن استدعاء خدمة gRPC مباشرةً من تطبيق يستند إلى المتصفح. وتتمثل إحدى طرق التغلب على هذه المشكلة في استخدام وكيل مثل gRPC-Web. يعمل gRPC-Web بشكل أساسي كطبقة ترجمة بين بروتوكول HTTP الخاص بالمتصفح وبروتوكول gRPC.

يبدأ تطبيق الويب استدعاء gRPC باستخدام مكتبة عميل gRPC-Web JavaScript لإرسال طلب gRPC تم تكييفه لتوافق المستعرض. يتم إرسال الطلب إلى خادم وكيل يحول الطلب إلى طلب gRPC قياسي ويعيد توجيهه إلى خادم الواجهة الخلفية لـ gRPC. يقوم خادم gRPC بمعالجة الطلب، ويرسل استجابة إلى الخادم الوكيل، ويقوم الوكيل مرة أخرى بتحويل الاستجابة إلى تنسيق gRPC-Web قبل تمريرها إلى العميل.