تحتاج معظم تطبيقات البرامج إلى أن تكون قادرة على الاتصال برمز آخر لعدة أسباب. يمكن أن يكون هذا أي شيء من التكامل إلى إضافة وظائف جديدة. للتأكد من إمكانية ارتباط البرنامج بالتطبيقات الأخرى ولضمان تكاملها مع البرامج الأخرى ، يستخدم المطورون واجهات برمجة التطبيقات . هذا هو السبب في أن واجهة برمجة التطبيقات ضرورية لمعظم البرامج. من خلال دورها كجسر عبر الأنظمة ، تمكّن واجهات برمجة التطبيقات الأفراد من الوصول إلى مجموعة متنوعة من خدمات الويب. لذلك ، من المهم اختيار التقنية المناسبة لتقديم واجهة برمجة تطبيقات لمشروعك.
تحتاج أي مؤسسة ترغب في مشاركة تطبيقها أو نظامها الأساسي مع مستخدميها إلى استخدام واجهات برمجة التطبيقات. هناك العديد من الطرق لتطوير وضبط واجهات برمجة التطبيقات لجعلها مناسبة تمامًا لتطبيقك. يعد gRPC من أحدث الطرق التي يستخدمها المبرمجون لتصميم واجهات برمجة التطبيقات. دعونا نلقي نظرة على ما هو gRPC وإيجابياته وسلبياته.
ما هو gRPC ؟
gRPC لـ Google Remote Procedure Call. gRPC هو إطار عمل RPC مفتوح المصدر يُستخدم لإنشاء واجهات برمجة تطبيقات سريعة وقابلة للتطوير. إنها تمكن من تطوير الأنظمة المتصلة بالشبكة والاتصال المفتوح بين تطبيقات العميل gRPC. تم تبني gRPC من قبل العديد من شركات التكنولوجيا الكبرى ، بما في ذلك Google و IBM و Netflix والمزيد. يعتمد إطار عمل gRPC على مكدسات التكنولوجيا المتطورة مثل HTTP / 2 والمخازن المؤقتة للبروتوكول والمزيد من أجل حماية API المثلى واستدعاءات الإجراءات عن بُعد عالية الأداء وقابلية التوسع.
ما هي RPC ؟
كان RPC و REST - Representational State Transfer - تاريخيًا طريقتين منفصلتين لبناء واجهات برمجة التطبيقات. بالإضافة إلى ذلك ، تُستخدم بروتوكولات مثل SOAP و GraphQL أيضًا لهذا الغرض. تتيح لك استدعاءات الإجراءات عن بُعد كتابة البرامج كما لو كانت تعمل محليًا ، على الرغم من أنها قد تعمل على جهاز مختلف.
هم الإطار الأكثر استخدامًا لتصميم واجهات برمجة التطبيقات. على عكس استدعاء بروتوكول HTTP النموذجي ، يستخدم RPC استدعاء دالة كطريقة أساسية للتفاعل بين الخادم والعميل. RPC هي تقنية منتجة لإنشاء واجهات برمجة التطبيقات لأن التبادلات بسيطة والمحتويات خفيفة الوزن. تحاكي خدمات gRPC أيضًا بنية الاتصالات هذه. يستخدم RPC IDL - Interface Definition Language للتعاقد مع نوع البيانات والأساليب التي سيتم استدعاؤها. أصبحت خدمات gRPC المعتمدة من RPCs شائعة جدًا في السنوات الأخيرة.
لماذا تم تطوير خدمات gRPC ؟
نظرًا لأن المزيد من المؤسسات تفتح قنوات للتكامل ، فقد أصبح من الصعب ربط هذه البرامج. تعد واجهات برمجة تطبيقات RPC تحديًا للتكامل والمخاطرة في التوزيع لأنها قد تكشف عن تفاصيل داخلية. تم تطويرها في العديد من لغات البرمجة وترتبط ارتباطًا وثيقًا بالإطار الأساسي.
تمت معالجة هذه المشكلة ، وزادت إمكانية الوصول إلى واجهة برمجة التطبيقات عندما تم إطلاق REST API في عام 2000. على وجه التحديد ، أعطت المستخدمين طريقة ثابتة لاسترداد المعلومات بشكل غير مباشر من خلال الأصول باستخدام تقنيات HTTP القياسية مثل GET و PUT و POST وغيرها. يتمثل التمييز الأساسي لـ RPC من REST API في أنه مع RPC ، تتم معالجة العمليات ، ولكن ليس من السهل التنبؤ بما يمكن أن تكون عليه العمليات في الأنظمة المختلفة.
لا يمكن REST API أن تحل محل RPC المباشر وخفيف الوزن تمامًا لأنها أنتجت قدرًا كبيرًا من البيانات الوصفية ، حتى في حين أنها قدمت تنسيقًا محسنًا للتعامل مع العديد من التطبيقات. أدى ذلك إلى الظهور النهائي GraphQL و gRPC من Google.
قامت Google ببناء gRPC في عام 2015 كإضافة إلى إطار عمل RPC لربط العديد من بنية الخدمات المصغرة المصممة بتقنيات مختلفة. كان gRPC في الأصل مرتبطًا ارتباطًا وثيقًا بالبنية التحتية الأساسية لـ Google ، ولكنه أصبح في النهاية مفتوح المصدر وموحدًا للاستخدام من قبل عامة الناس.
نظرة عامة على مفاهيم gRPC
يعد استخدام التقنيات المتطورة ، التي تتمتع بأداء عالٍ مقارنة بـ JSON و XML وتوفر قدرًا أكبر من تكامل واجهة برمجة التطبيقات ، مسؤولاً عن إنشاء gRPC. بعض مفاهيم gRPC التي يجب أن تكون على دراية بها هي:
مخازن البروتوكول
المخازن المؤقتة للبروتوكول ، والمعروفة أيضًا باسم Protobuf ، هي معايير تسلسل أو إلغاء تسلسل تجعل من السهل تحديد التطبيقات وتنفيذ إنشاء رمز مكتبات العميل تلقائيًا. يعد الإصدار الأحدث ، proto3 ، أبسط في الاستخدام ويوفر أحدث الإمكانات لـ gRPC.
تعمل ملفات .Proto على تمكين خدمات gRPC والاتصالات بين عملاء gRPC ورسائل الخادم. يتم تحميل ملف .proto في الذاكرة عند التنفيذ بواسطة برنامج التحويل البرمجي Protobuf - protoc. ينشئ هذا المحول البرمجي gRPC عميل gRPC وخادم gRPC التي تستخدم بنية الذاكرة لتسلسل البيانات الثنائية وإلغاء تسلسلها. يتم إرسال واستلام كل اتصال بين المستخدم والخدمة عن بُعد بعد إنشاء الكود في gRPC.
نظرًا لأن البيانات تُترجم إلى شكل ثنائي وتكون الإشارات المشفرة أصغر حجمًا ، فإن التحليل باستخدام Protobuf يستخدم طاقة أقل CPU لـ gRPC. لذلك ، حتى في أجهزة الكمبيوتر التي تحتوي على CPU أضعف ، مثل الهواتف المحمولة ، يتم إرسال الرسائل بسرعة أكبر باستخدام gRPC.
HTTP / 2
تم بناء خدمة gRPC على HTTP / 2 ، إصدار HTTP / 1.1 الذي يحتوي على قيود أقل. على الرغم من أنه يعمل مع بروتوكول HTTP الأقدم ، إلا أن HTTP / 2 لديه العديد من الميزات المعقدة لـ gRPC. يتضمن ذلك طبقة تأطير ثنائية ، والتي تقسم كل استعلام HTTP / 2 والردود إلى رسائل أصغر وتؤطرها في تنسيق ثنائي لتحسين تسليم الرسائل. بالإضافة إلى ذلك ، يدعم gRPC طلبات واستجابات متعددة من العميل وخادم gRPC في دفق ثنائي الاتجاه ثنائي الاتجاه.
يحتوي HTTP / 2 على طريقة للتحكم في التدفق تسمح بالتحكم الدقيق في ذاكرة الوصول العشوائي ( RAM) اللازمة لتخزين الحزم أثناء الطيران. كما يوفر ضغط الرأس لخدمات gRPC. يتم تشفير كل شيء في HTTP / 2 قبل الإرسال ، حتى الرؤوس ، التي توفر استدعاءات إجراء عن بُعد عالية الأداء. يوفر gRPC معالجة غير متزامنة ومتزامنة باستخدام HTTP / 2 ، مما يتيح تنفيذ العديد من أنواع RPC التفاعلية والمتدفقة.
بمساعدة كل خصائص HTTP / 2 ، يمكن لخدمات gRPC استخدام موارد أقل ، مما يؤدي إلى أوقات استجابة أسرع بين التطبيقات المستندة إلى مجموعة النظراء وخدمات gRPC وعمر بطارية أطول لعملاء gRPC يعملون على الأجهزة المحمولة.
تدفق
الفكرة الحاسمة التي يدعمها gRPC هي التدفق ، مما يسمح بتنفيذ العديد من العمليات داخل طلب واحد. يجعل gRPC هذا ممكنًا من خلال ميزة تعدد إرسال HTTP / 2 ، والتي تسمح بإرسال استجابات أو طلبات متعددة أو تلقيها في وقت واحد عبر TCP واحد - Transmission Control Protocol في الإرسال. تنسيقات الدفق الأساسية هي RPCs المتدفقة للخادم ، و RPCs المتدفقة للعميل ، و RPC s RPC ثنائية الاتجاه.
القنوات
على عكس تدفقات HTTP / 2 ، التي تسمح بالعديد من التدفقات المتزامنة على اتصال طلب واحد ، تدعم القناة التي تحتوي على gRPC تدفقات متعددة مستمرة عبر طلبات متعددة. يتم توظيفهم لبناء كعب العميل وإعطاء آلية للربط بخادم gRPC على IP ومنفذ محدد.
هندسة gRPC
تتكون بنية gRPC من كل من عميل gRPC وخادم gRPC. تحتوي كل خدمة عميل gRPC على كعب أو ملف يتم إنشاؤه تلقائيًا ، والذي يشبه واجهة تحتوي على العمليات البعيدة النشطة. يبدأ عميل gRPC استدعاء إجراء محلي إلى كعب يحتوي على وسيطات ليتم إعادة توجيهها إلى رسائل خادم gRPC. ثم يرسل كعب العميل gRPC الاستعلام إلى وحدة وقت العميل المحلية على الكمبيوتر المحلي بعد إجراء تسلسل للوسيطات باستخدام إجراء تنظيم Protobuf.
يستخدم نظام التشغيل بروتوكول HTTP / 2 للتواصل مع كمبيوتر الخادم البعيد. يقبل نظام تشغيل الخادم الرسائل ويستدعي عملية كعب الخادم ، والتي تستخدم Protobuf لاستدعاء العملية المناسبة بعد فك تشفير المعلمات الواردة. ثم تتلقى طبقة نقل العميل الاستجابة المشفرة من كعب الخادم. يمر التنفيذ مرة أخرى إلى المتصل بعد أن يتلقى كعب العميل gRPC رسائل الاستجابة ويفكك الوسائط المتوفرة.
إيجابيات gRPC
يتمتع gRPC بالعديد من المزايا مقارنة بآليات تصميم واجهة برمجة التطبيقات الأخرى. gRPC أيضًا على تحسين بنية RPC. فيما يلي أبرز فوائد خدمات gRPC:
- مكالمات الإجراءات عن بعد عالية الأداء
باستخدام Protobuf و HTTP / 2 ، توفر خدمات gRPC ما يصل إلى 10 أضعاف الأداء العالي وحماية واجهة برمجة التطبيقات لتفاعل REST + JSON. باستخدام دفعات الخادم وتعدد الإرسال وضغط الرأس ، يوفر HTTP / 2 تصنيفات عالية الأداء لخدمات gRPC. في حين أن تعدد الإرسال يلغي تأخير رأس الخط ، فإن دفع الخادم يجعل من الممكن لـ HTTP / 2 دفع المواد من الخادم إلى العميل قبل أن تكون مطلوبة. يتم ضغط الرسائل بشكل أكثر فاعلية باستخدام HTTP / 2 ، مما يؤدي إلى تحميل أسرع مع خدمات gRPC.
- تدفق
يشتمل وصف الخدمة لخدمات gRPC المتدفقة بالفعل على مبادئ دفق نهاية العميل أو الخادم. ونتيجة لذلك ، أصبح بناء عملاء gRPC وخدمات البث أسهل بكثير.
- رمز الجيل
يعد إنشاء الكود لبرامج عميل gRPC وخادم gRPC هو المكون الرئيسي لنهج ويب gRPC. لإنشاء التعليمات البرمجية من ملف .proto ، تستخدم وحدات gRPC برنامج التحويل البرمجي .protoc. يتم التحكم في تنسيق Protobuf من خلال إنشاء الكود في gRPC ، والذي يستخدم لتحديد تنسيقات البيانات ونقاط نهاية التطبيق. يمكنه إنشاء أجزاء كعب روتين للشبكة من جانب العميل وهياكل عظمية من جانب الخادم ، مما يقلل من مقدار الوقت اللازم لتصميم البرامج مع مجموعة متنوعة من الخدمات في خدمات gRPC.
- التوافقية
يتم دعم العديد من الأنظمة ولغات البرمجة ، مثل Java و Ruby و Go و C # والمزيد ، بواسطة موارد ومكتبات gRPC. باستخدام لغات البرمجة هذه ، يمكن للمطورين إنشاء تطبيقات عالية الأداء مع الاستفادة من التوافق الكامل عبر الأنظمة الأساسية مع gRPC. هذا بفضل شكل الأسلاك الثنائية Protobuf وإنشاء رمز فعال لجميع الأنظمة تقريبًا.
- حماية
يتم ضمان أمان واجهة برمجة التطبيقات في gRPC باستخدام HTTP / 2 عبر جلسة TLS مشفرة من طرف إلى طرف. يشجع gRPC على اعتماد SSL / TLS لتشفير البيانات والمصادقة بين الخادم وعميل gRPC.
- الإنتاجية وسهولة الاستخدام
نظرًا لأن gRPC هو بديل كامل لـ RPC ، فإنه يعمل بدون عوائق في مجموعة واسعة من الأنظمة واللغات. gRPC أيضًا على أدوات رائعة ، حيث يتم إنشاء الكثير من التعليمات البرمجية المعيارية الضرورية يدويًا. يمكن للمهندسين الآن التركيز بشكل أكبر على الوظائف الأساسية بسبب توفير الوقت بشكل كبير مع gRPC.
سلبيات gRPC
على الرغم من أننا نأمل أن يتم حل عيوب gRPC في النهاية ، إلا أنها تشكل بعض المشكلات لاستخدامها الآن. بعض سلبيات gRPC التي يجب أن تكون على دراية بها هي:
- عدم النضج
يمكن أن يكون تطوير التكنولوجيا عائقًا كبيرًا أمام اعتمادها. هذا واضح أيضًا أثناء استخدام gRPC. GraphQL ، أحد أقران gRPC ، على أكثر من 14 ألف استعلام على StackOverflow ، بينما gRPC على أقل قليلاً من 4k في الوقت الحالي. يفتقر مجتمع gRPC إلى المعرفة بأفضل الممارسات والحلول والنجاحات نظرًا لعدم وجود الكثير من مساعدة المبرمج لـ HTTP / 2 ، بالإضافة إلى المخازن المؤقتة للبروتوكول خارج Google. ومع ذلك ، مع توسع مجتمع gRPC ، سيتطور هذا في النهاية.
- دعم متصفح محدود
نظرًا لعدم وجود مستعرض ويب gRPC حالي يمكنه التعامل مع إطارات HTTP / 2 ، فلا يمكنك استدعاء خدمة gRPC بشكل فعال من المستعرض نظرًا لأن gRPC Web يعتمد بشكل أساسي على HTTP / 2. نتيجة لذلك ، يجب عليك استخدام وكيل مع gRPC ، والذي يأتي مع العديد من العيوب.
- غير مقروء من قبل البشر
على عكس XML و JSON ، فإن ملفات Protobuf ليست قابلة للقراءة من قبل الإنسان حيث يتم ضغط البيانات إلى تنسيق ثنائي. يجب أن يستخدم المطورون أدوات إضافية ، مثل بروتوكول انعكاس الخادم وموجه أوامر gRPC لتقييم الحمولات ، وتنفيذ استكشاف الأخطاء وإصلاحها ، وإنشاء استعلامات يدوية.
- منحنى التعلم حاد
سوف يستغرق الأمر بعض الوقت للتعرف على المخازن المؤقتة للبروتوكول واكتشاف طرق للتعامل مع احتكاك HTTP / 2 ، على عكس REST و GraphQL ، وكلاهما يستخدم في الغالب JSON.
كيف يساعد AppMaster ؟
يؤدي No-code إلى تغيير الطريقة التي ينظر بها الأشخاص إلى البرمجة. يتيح إنشاء No-code للأشخاص إمكانية التعلم وإنشاء البرامج بشكل أسرع من خلال إنشاء التعليمات البرمجية . يعد إنشاء الكود لتطبيقك أبسط باستخدام منصات no-code مثل AppMaster. لا توجد مشكلات تتعلق بالملكية أيضًا ، نظرًا لأن إنشاء الكود محمي ، وستكون الكود الذي تنشئه ملكًا لك وحدك. يمكنك إنشاء تطبيقات العميل والخادم بشكل أسرع وأكثر سهولة باستخدام AppMaster.
يتيح النظام الأساسي لإنشاء التطبيقات no-code في AppMaster للمطورين استخدام بروتوكول gRPC لتقديم الطلبات بين بنية الخدمات المصغرة في الخلفية. سنقوم في العام المقبل بتوسيع دعم gRPC من خلال تضمين API لكل من تطبيقات gRPC Web و gRPC Mobile.
استنتاج
على الرغم من أن خدمات gRPC لها العديد من المزايا التي تجعلها جذابة للشركات والمطورين ، إلا أن قرار استخدام خدمات gRPC على خدمات أخرى مثل REST أو SOAP يعتمد على التطبيق الخاص بك. في حين أن بعض البرامج ستتمتع بفوائد عالية الأداء مع gRPC ، فقد يكون البعض الآخر أكثر ملاءمة لبدائلها. يجب أن تفهم عيوب ومزايا خدمات gRPC وأن تقرر ما إذا كانت تناسبك أم لا.
