ما هو gRPC؟ شرح مخازن البروتوكول والتدفق والهندسة المعمارية

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

في الأيام القليلة الماضية كنت أغوص بعمق في gRPC. سأشارك بعضًا من اكتشافاتي الكبيرة هنا في هذه المقالة.

لاحظ أنني سأركز على المفاهيم أكثر من تفاصيل التنفيذ. سوف تتعلم البنية الأساسية لـ gRPC نفسها. ستتعلم أيضًا:

  • لماذا يتم استخدام gRPC على نطاق واسع من قبل المطورين
  • كيف يعمل بشكل جيد
  • وكيف يعمل كل شيء تحت الغطاء.

دعنا نعود قليلا

قبل أن نندفع إلى gRPC ، يجب أن نلقي نظرة على ماهية استدعاءات الإجراءات عن بُعد .

RPC هو شكل من أشكال الاتصال بين العميل والخادم الذي يستخدم استدعاء دالة بدلاً من استدعاء HTTP المعتاد.

يستخدم IDL (لغة تعريف الواجهة) كشكل من أشكال العقد بشأن الوظائف المطلوب استدعاؤها ونوع البيانات.

إذا لم تكن قد أدركت ذلك بعد ، فإن RPC في gRPC تعني استدعاء الإجراء البعيد. ونعم ، يكرر gRPC هذا النمط المعماري لاتصالات خادم العميل ، عبر استدعاءات الوظائف.

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

نظرة عامة على gRPC

في عام 2015 ، افتتحت Google مشروعها الذي سيكون في النهاية هو المشروع الذي يسمى gRPC. ولكن ما الذي يرمز إليه حرف "g" في gRPC؟

قد يفترض الكثير من الناس أنه من أجل Google لأن Google صنعته ، لكنها لا تفعل ذلك.

يغير Google معنى "g" لكل إصدار إلى النقطة التي قاموا فيها بعمل README لسرد جميع المعاني.

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

ما الذي يجعل gRPC مشهورًا جدًا؟

هناك العديد من الأسباب وراء شهرة gRPC:

  • التجريد سهل (إنه استدعاء وظيفي)
  • إنه مدعوم بالعديد من اللغات
  • إنه أداء للغاية
  • غالبًا ما تكون مكالمات HTTP مربكة ، لذا فإن هذا يسهل الأمر

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

غالبًا ما تقوم Microservices بتشغيل العديد من الخدمات بلغات برمجة مختلفة. سيكون لديهم أيضًا في كثير من الأحيان الكثير من الخدمات لتفاعلات الخدمة.

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

تحظى gRPC بشعبية كبيرة في خدمة مكالمات الخدمة ، حيث يصعب غالبًا فهم مكالمات HTTP للوهلة الأولى.

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

يمكن أيضًا كتابة بعض الخدمات بلغات مختلفة ويأتي gRPC مع مكتبات متعددة لدعم ذلك.

الأداء هو الكرز في المقدمة - وهو الكرز الكبير.

هندسة gRPC

لقد ذكرت عدة مرات أن أداء gRPC جيد جدًا ، لكن قد تتساءل ما الذي يجعله جيدًا؟ ما الذي يجعل gRPC أفضل بكثير من RPC عندما تكون تصميماتها متشابهة جدًا؟

فيما يلي بعض الاختلافات الرئيسية التي تجعل gRPC فعالاً للغاية.

HTTP / 2

كان HTTP معنا لفترة طويلة. الآن ، تستخدم جميع خدمات الواجهة الخلفية تقريبًا هذا البروتوكول.

كما تظهر الصورة أعلاه ، ظل HTTP / 1.1 مناسبًا لفترة طويلة.

ثم في عام 2015 ، ظهر HTTP / 2 واستبدل HTTP / 1.1 بشكل أساسي باعتباره بروتوكول النقل الأكثر شيوعًا على الإنترنت.

إذا كنت تتذكر أن عام 2015 كان أيضًا العام الذي ظهر فيه gRPC ، فلم يكن ذلك مصادفة على الإطلاق. تم إنشاء HTTP / 2 أيضًا بواسطة Google ليتم استخدامه بواسطة gRPC في بنيته.

HTTP / 2 هو أحد الأسباب الرئيسية التي تجعل أداء gRPC جيدًا. وفي هذا القسم التالي ، سترى السبب.

طلب / استجابة مضاعفة

في بروتوكول HTTP التقليدي ، لا يمكن إرسال طلبات متعددة أو الحصول على استجابات متعددة معًا في اتصال واحد. يجب إنشاء اتصال جديد لكل منهم.

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

تقوم هذه الطبقة الثنائية بتغليف البيانات وترميزها. في هذه الطبقة ، يتم تقسيم طلب / استجابة HTTP إلى إطارات.

يحتوي إطار الرؤوس على معلومات رؤوس HTTP النموذجية ، ويحتوي إطار البيانات على الحمولة. باستخدام هذه الآلية ، من الممكن الحصول على بيانات من طلبات متعددة في اتصال واحد.

يسمح هذا للحمولات من طلبات متعددة بنفس العنوان ، وبالتالي تحديدها كطلب واحد.

ضغط الرأس

ربما واجهت العديد من الحالات التي تكون فيها رؤوس HTTP أكبر من الحمولة. و HTTP / 2 لديه إستراتيجية مثيرة للاهتمام تسمى HPack للتعامل مع ذلك.

أولاً ، كل شيء في HTTP / 2 يتم ترميزه قبل إرساله ، بما في ذلك الرؤوس. يساعد هذا في الأداء ، لكن هذا ليس أهم شيء في ضغط الرأس.

يقوم HTTP / 2 بتعيين الرأس على جانب العميل والخادم. من ذلك ، يمكن لـ HTTP / 2 معرفة ما إذا كان الرأس يحتوي على نفس القيمة ويرسل فقط قيمة الرأس إذا كانت مختلفة عن الرأس السابق.

كما هو موضح في الصورة أعلاه ، فإن الطلب رقم 2 سيرسل المسار فقط لأن القيم الأخرى هي نفسها تمامًا. ونعم ، هذا يقلل كثيرًا من حجم الحمولة ، وبالتالي يحسن أداء HTTP / 2 أكثر.

بروتوكول Buffer ، المعروف أيضًا باسم Protobuf

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

message Person { required string name = 1; required int32 id = 2; optional string email = 3; }

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

تمتلك Protobuf أيضًا آليات ، على عكس واجهة برمجة تطبيقات REST المعتادة التي ترسل فقط سلاسل من JSON على هيئة بايت. تسمح هذه الآليات للحمولة أن تكون أصغر بكثير وتمكن من أداء أسرع.

طريقة التشفير التي يستخدمها Protobuf معقدة للغاية. إذا كنت ترغب في التعمق في كيفية عمله ، فراجع هذه الوثائق الشاملة.

ماذا تقدم gRPC أيضًا؟

نجوم في السماء

الآن يجب أن يكون لديك فهم أساسي لبنية gRPC ، وكيف يعمل ، وما هو قادر عليه.

ولكن إليك بعض الأشياء الأخرى المثيرة للاهتمام التي تقدمها لنا gRPC.

البيانات الوصفية

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

Headerيمكن تعيين من جانب العميل، في حين يمكن للخوادم تعيين Headerو Trailersطالما انهم على حد سواء في شكل الفوقية.

تدفق

يعد البث أحد المفاهيم الأساسية لـ gRPC حيث يمكن أن تحدث العديد من الأشياء في طلب واحد. أصبح هذا ممكنًا من خلال إمكانية تعدد إرسال HTTP / 2 المذكورة سابقًا.

هناك عدة أنواع من البث:

  • Server Streaming RPC: حيث يرسل العميل طلبًا واحدًا ويمكن للخادم إرسال استجابات متعددة. على سبيل المثال ، عندما يرسل العميل طلبًا لصفحة رئيسية بها قائمة بالعناصر المتعددة ، يمكن للخادم إرسال الردود بشكل منفصل ، مما يمكّن العميل من استخدام التحميل البطيء.
  • العميل المتدفق RPC: حيث يرسل العميل طلبات متعددة ويرسل الخادم فقط استجابة واحدة. على سبيل المثال ، ملف مضغوط / مقطع تم تحميله بواسطة العميل.
  • دفق RPC ثنائي الاتجاه: حيث يرسل كل من العميل والخادم رسائل لبعضهما البعض في نفس الوقت دون انتظار استجابة.

المعترضون

يدعم gRPC استخدام المعترضات لطلبها / الاستجابة. المعترضون ، حسنًا ، يعترضون الرسائل ويسمحون لك بتعديلها.

هل هذا يبدو مألوفا؟ إذا كنت قد لعبت مع عمليات HTTP على واجهة برمجة تطبيقات REST ، فإن الاعتراضات تشبه إلى حد بعيد البرامج الوسيطة.

تدعم مكتبات gRPC عادةً المعترضات وتسمح بالتنفيذ السهل. تستخدم المعترضات عادة من أجل:

  • تعديل الطلب / الاستجابة قبل تمريرها. يمكن استخدامه لتقديم معلومات إلزامية قبل إرسالها إلى العميل / الخادم.
  • تسمح لك بمعالجة كل استدعاء وظيفة مثل إضافة تسجيل إضافي لتتبع وقت الاستجابة.

توزيع الحمل

إذا لم تكن معتادًا بالفعل على موازنة التحميل ، فهي آلية تسمح لطلبات العميل بالانتشار عبر خوادم متعددة.

لكن موازنة الحمل تتم عادةً على مستوى الوكيل (على سبيل المثال ، NGINX). فلماذا أتحدث عنها هنا؟

تبين أن gRPC يدعم طريقة موازنة الحمل بواسطة العميل. تم تنفيذه بالفعل في مكتبة Golang ، ويمكن استخدامه بسهولة.

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

إلغاء المكالمة

يمكن لعملاء gRPC إلغاء مكالمة gRPC عندما لا يحتاجون إلى استجابة بعد الآن. ومع ذلك ، فإن التراجع عن جانب الخادم غير ممكن.

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

تغليف

ضائع في المكان والزمان

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

آمل حقًا أن تساعدك هذه المقالة في فهم المزيد عن gRPC. ولكن لا يزال هناك الكثير من التعلم ، لذلك لا تتوقف هنا! استمر في الحفر.

شكرا للقراءة!