gRPC هو إطار عمل مفتوح المصدر لاستدعاء الإجراء عن بُعد. في Yandex.Market ، يتم استخدام gRPC كبديل أكثر ملاءمة لـ REST. شارك سيرجي فيدوسينكوف ، الذي يدير خدمة تطوير الأدوات لشركاء السوق ، تجربته في استخدام gRPC كبروتوكول لبناء تكامل بين خدمات Java و C ++. ستتعلم من التقرير كيفية تجنب المشكلات الشائعة إذا بدأت في استخدام gRPC بعد REST ، وكيفية إرجاع الأخطاء ، وتنفيذ التتبع ، واستعلامات تصحيح الأخطاء ، واختبار مكالمات العميل.
في النهاية ، هناك سجل غير رسمي للتقرير.
- أولاً ، أود أن أقدم لكم بعض الحقائق حول Yandex.Market ، وستكون مفيدة كجزء من التقرير. الحقيقة الأولى: نكتب الخدمات بلغات مختلفة. هذا يفرض متطلبات العملاء للخدمات.
وإذا كانت لدينا خدمة في Java ، فسيكون من الرائع أن يكون العميل لها ، على سبيل المثال ، زائد أو صغير.
جميع الخدمات التي لدينا مستقلة ، لا توجد إصدارات كبيرة مخططة للسوق بالكامل. سيتم إصدار Microservices بشكل مستقل ، والتوافق مع الإصدارات السابقة مهم بالنسبة لنا هنا ، بحيث يدعمه البروتوكول.
الحقيقة الثالثة: لدينا كل من التكامل المتزامن وغير المتزامن. في التقرير ، سأتحدث بشكل رئيسي عن متزامن.
ماذا استخدمنا؟ الآن ، بالطبع ، أساس تكاملنا هو خدمات REST أو REST المشابهة التي تتبادل XML / JSON عبر HTTP 1.1. يوجد أيضًا XML-RPC - نستخدمه بشكل أساسي عند الدمج مع كود Python ، أي أن Python لديه خادم XML-RPC مدمج. أنها مريحة بما يكفي لنشرها هناك ، ونحن ندعمها.
كان لدينا مرة واحدة كوربا. لحسن الحظ ، لقد تخلينا عنها. الآن معظمها REST و XML / JSON عبر HTTP.
تكامل متزامن لديك مشاكل مع البروتوكولات الموجودة. نواجه مثل هذه المشاكل ونحاول علاجها باستخدام gRPC. ما هي هذه المشاكل؟ كما قلت ، أريد أن يكون لدي عملاء بلغات مختلفة. من المستحسن أن لا يزال يتعين علينا أن نكتبها بأنفسنا. وبشكل عام ، سيكون من الرائع أن يكون العميل متزامنًا وغير متزامن - وفقًا لأهداف مستخدم الخدمة.
أود أيضًا أن يكون البروتوكول الذي نستخدمه لدعم التوافق مع الإصدارات السابقة جيدًا بما يكفي: هذا مهم جدًا مع الإصدارات المستقلة الموازية. جميع إصداراتنا متوافقة مع الإصدارات السابقة ، ونحن لا نكسر ردود الفعل. إذا كسرتها ، فهذا خطأ ، وتحتاج فقط إلى إصلاحه في أسرع وقت ممكن.
من الضروري اتباع نهج متسق لمعالجة الأخطاء: يعرف كل من قام بتقديم خدمات REST أنه لا يمكنك استخدام حالة HTTP فقط. عادةً لا يسمحوا بوصف تفصيلي للمشكلة ، يجب عليك إدخال بعض حالاتهم وتفاصيلهم. في خدمات REST ، يقدم الجميع تطبيقهم الخاص لهذه الأخطاء ، في كل مرة يتعين عليك العمل بشكل مختلف مع هذا. هذا ليس دائما مريحة.
أود أيضًا أن يكون لدي إدارة مهلة من جانب العميل. مرة أخرى ، يدرك أولئك الذين يعملون مع HTTP أنه إذا حددنا مهلة من جانب العميل وانتهت صلاحيتها ، فسيتوقف العميل عن انتظار إكمال الطلب ، لكن الخادم لن يعرف أي شيء عنه وسيواصل تنفيذه. علاوة على ذلك ، في الوسط هناك العديد من الوكلاء الذين يحددون مهلات عالمية. والعميل ببساطة قد لا يعرف أي شيء عنها وتكوينها ليست دائما تافهة.
وأخيرا ، مشكلة التوثيق. ليس من الواضح دائمًا مكان الحصول على الوثائق الخاصة بموارد REST أو لبعض الطرق ، والمعلمات التي يقبلونها ، والجهة التي يمكن نقلها ، وكيفية توصيل هذه الوثائق مع مستهلكي الخدمة. من الواضح أن هناك Swagger ، ولكن معها أيضًا ، ليس كل شيء تافهًا.
gRPC. نظرية
أود التحدث عن الجزء النظري من gRPC - ما هو عليه ، ما هي الأفكار. ثم سننتقل إلى الممارسة.
بشكل عام ، gRPC هي مواصفات مجردة. يصف RPC مجردة (استدعاء إجراء عن بُعد) ، أي استدعاء إجراء بعيد يحتوي على خصائص معينة. الآن سوف نذكرهم. الخاصية الأولى هي دعم كل من المكالمات الفردية والبث. أي أن جميع الخدمات التي تنفذ هذه المواصفات تدعم كلا الخيارين. العنصر التالي هو توفر البيانات الوصفية ، أي أنه مع الحمولة الصافية ، يمكنك تمرير نوع ما من البيانات الوصفية - برؤوس مشروطة. و - دعم لإلغاء طلب ومهلة خارج المربع.
كما يفترض أن يتم تنفيذ وصف الرسائل والخدمات نفسها من خلال لغة تعريف واجهة معينة أو IDL. توضح المواصفة أيضًا بروتوكول السلك عبر HTTP / 2 ، أي ، gRPC تفترض أنه يعمل فقط عبر HTTP / 2.
يوجد تطبيق gRPC نموذجي يُستخدم في معظم الحالات. نستخدمها أيضًا ، والآن سنراها. يتم استخدام تنسيق proto كـ IDL. يتيح لك المكوّن الإضافي gRPC لبرنامج التحويل البرمجي proto الحصول على مصادر الخدمات المولدة من وصف proto. وهناك مكتبات وقت التشغيل بلغات مختلفة - Java و C ++ و Python. بشكل عام ، يتم دعم جميع اللغات الشائعة تقريبًا ، وتوجد مكتبات وقت التشغيل لها. وكما يتم تبادل الرسائل بين الخدمات ، يتم استخدام رسالة proto ، ورسائل منمقة وفقًا لنظام protobuf.
أريد أن أغوص قليلاً في بعض الميزات المحددة. ها هم. الكتابة القوية ، أي رسالة بروتو ، هي رسالة مطبوعة بشدة. أولئك الذين عملوا مع protobuf مرة واحدة يعرفون أنه يمكنك وصف الحقول في رسالتك بأنواعها. توجد الأنواع على حد سواء صفائف البايت والسلسلة. يمكن أن تكون عددية ، يمكن أن تكون ناقلات. وفي الواقع ، يمكن للرسائل ، كحقل ، أن تحتوي على رسائل أخرى ، وهي ملائمة تمامًا ، بشكل عام ، يمكن تمثيل أي نموذج.
حول التوافق مع الإصدارات السابقة. أود أن أشير إلى أن proto IDL عبارة عن تنسيق يتم فيه وضع التوافق مع الإصدارات السابقة من الصندوق ، أي أنه تم تصميمه مع تراكم من التوافق مع الإصدارات السابقة ، وأن Google أصدرت إصدارًا من proto3 ، والذي ، مقارنةً بـ proto2 ، يعمل على تحسين التوافق مع الإصدارات السابقة. هناك ، بالإضافة إلى ذلك ، هناك كل أنواع المواصفات ، وكيف وماذا يمكن تغييرها بحيث يتم الحفاظ على التوافق مع الإصدارات السابقة في بعض الحالات غير التافهة.
هناك إمكانية للقيم الافتراضية ، يمكنك إضافة حقول جديدة والمستهلك لا يحتاج إلى تغيير أي شيء ، في الواقع. جميع الحقول في proto3 اختيارية ، على سبيل المثال ، يمكن حذفها ، ولا يؤدي الوصول إلى الحقل البعيد إلى حدوث أخطاء على العميل.
ميزة أخرى لـ gRPC هي أنه يتم إنشاء العميل والخادم باستخدام برنامج التحويل البرمجي proto ومكون البرنامج الإضافي gRPC استنادًا إلى وصف proto. هناك احتمال في الوقت الذي تتم فيه كتابة الكود لاختيار العميل الذي سيتم استخدامه. هذا هو ، اختيار عميل غير متزامن أو متزامن ، وهذا يتوقف على نوع التعليمات البرمجية التي تكتبها. على سبيل المثال ، العميل غير المتزامن مناسب جدًا للرمز التفاعلي. وهذه الفرصة لأي لغة. أي بمجرد قيامك بكتابة وصف أولي ، يمكنك بعد ذلك إنشاء عميل لأي لغة ، ولن تحتاج إلى تطويره بشكل منفصل بطريقة أو بأخرى. يمكنك توزيع الواجهة لخدمتك ببساطة كتوصيف أولي. يمكن لأي مستهلك إنشاء عميل لنفسه.
حول إلغاء الطلب والمواعيد النهائية ، أود أن أشير إلى أنه يمكن إلغاء الطلب على الخادم وعلى العميل. إذا فهمنا أن كل شيء ، لسنا بحاجة إلى تلبية الطلب بشكل أكبر ، فيمكننا إلغاؤه. من الممكن تعيين مهلة عند الطلب. في gRPC ، تستخدم معظم مكتبات وقت التشغيل موعدًا نهائيًا كمفهوم للمهلة. ولكن في الواقع هو نفسه. وهذا هو ، هذا هو الوقت الذي يجب فيه إكمال الطلب.
والأكثر إثارة للاهتمام هو أن الخادم يمكنه معرفة كل من إلغاء الطلب وانتهاء المهلة والتوقف عن تنفيذ الطلب من جانبه. هذا رائع جدًا ، يبدو لي أنه لا يوجد أي مكان آخر.
حول الوثائق ، أردت أن أشير إلى أنه نظرًا لاستخدام تنسيق proto في IDL لـ gRPC ، فهذا رمز عادي. هناك يمكنك كتابة التعليقات ، بما في ذلك التعليقات التفصيلية للغاية. وعليك أن تدرك أنه من أجل الاندماج مع خدمتك ، يحتاج المستخدمون لديك إلى هذا التنسيق الأولي في موطنهم ، وسوف يصلون إلى جانب التعليقات ، فلن يمكثوا في مكان آخر. انها مريحة جدا. ويمكنك توسيع هذا الوصف ، أي أنها ميزة ملائمة أن الوثائق تأتي بجوار الكود ، مثلها يمكن أن تكمن بجوار الطرق في شكل javadoc أو أي تعليقات أخرى.
دعوة أحادية gRPC. ممارسة
دعنا ننتقل ، ننظر إلى القليل من الممارسة. والمثال الأساسي لاستخدام gRPC هو ما يسمى المكالمة الأحادية أو المكالمة الفردية. هذا مخطط كلاسيكي - نرسل طلبًا إلى الخادم ونحصل على استجابة واحدة من الخادم. يبدو أن هذا يعمل في HTTP.
النظر في مثال خدمة الصدى التي نقوم بها. سيتم كتابة الخادم في الإيجابيات ، العميل في جافا. تم استخدام دائرة الموازنة الكلاسيكية هنا. بمعنى ، يقوم العميل بمعالجة الموازن ، ثم يحدد الموازن بالفعل واجهة خلفية معينة لمعالجة الطلب.
أردت الانتباه - نظرًا لأن gRPC يعمل عبر HTTP / 2 ، يتم استخدام اتصال TCP واحد. وعلاوة على ذلك ، تمر تيارات مختلفة من خلال ذلك. هنا يمكنك أن ترى أن الاتصال بين العميل والموازن يتم تأسيسه مرة واحدة ويظل ثابتًا ، ثم يقوم الموازن بموازنة التحميل على واجهات خلفية مختلفة لكل مكالمة. إذا نظرت ، يحدث مثل هذا وما شابه إذا تم توزيع الرسائل.
إليك نموذج التعليمات البرمجية لملف proto الخاص بنا. يمكنك ملاحظة أننا نصف الرسالة أولاً ، أي أن لدينا EchoRequest و EchoResponse. أنه يحتوي على حقل سلسلة واحدة فقط يخزن الرسالة.
الخطوة الثانية وصفنا الإجراء لدينا. يقبل إجراء الإدخال EchoRequest ، ويعيد EchoResponse كنتيجة ، كل شيء تافه تمامًا. هذا هو وصف خدمة gRPC والرسائل التي سيتم ملاحقتها.
دعونا نرى كيف يحدث هذا في حالة الإيجابيات ، على سبيل المثال. يتم تجميعها في ثلاث مراحل. في المرحلة الأولى ، تتمثل مهمتنا في إنشاء مصادر الرسائل. نحن هنا نفعل هذا مع هذا الفريق. نحن ندعو مترجم proto ، وننقل ملف proto إلى الإدخال ، ونشير إلى مكان وضع ملفات الإخراج.
الفريق الثاني. نحن أيضا إنشاء الخدمات بنفس الطريقة. الاختلاف الوحيد مع الأمر السابق هو أننا نجتاز المكوّن الإضافي ، وبناءً على الوصف ، الذي هو في تنسيق بروتو ، فإنه يولد خدمات.
الخطوة الثالثة - نجمع كل هذا في بينار واحد بحيث يمكن إطلاق خادمنا.
يتم تمرير علامة إضافية إلى الرابط ، ويسمى grpc ++ _ انعكاس. أريد أن أشير - خادم gRPC لديه مثل هذه الميزة ، انعكاس الخادم. يتيح لك استكشاف نوع الخدمات ومكالمات RPC ورسائل الخدمة. بشكل افتراضي ، يتم إيقاف تشغيله ، ولا يمكنك الوصول إلى الخدمة إلا إذا كان لديك تنسيق بروتو في متناول اليد. ولكن ، على سبيل المثال ، بالنسبة للتصحيح ، فإنه مريح للغاية ، وبدون تنسيق proto في متناول اليد ، ما عليك سوى تشغيل الخادم بميزة الانعكاس وتلقي المعلومات على الفور.
الآن دعونا نلقي نظرة على التنفيذ. التنفيذ هو أيضا أضيق الحدود. وهذا هو ، مهمتنا الرئيسية هي تنفيذ خدمة الصدى التي تم إنشاؤها. لديها طريقة واحدة getEcho. يقوم فقط بإنشاء رسائل وإرسالها مرة أخرى. الحالة موافق - حالة النجاح.
بعد ذلك ، ننشئ ServerBuilder ، نسجل خدمتنا فيه ، والذي بنينا أعلى قليلاً.
الآن نبدأ وننتظر الطلبات الواردة.
الآن دعونا نرى العميل في جافا. نحن نجمع المهد. مهمتنا هي توصيل البرنامج المساعد protobuf أولا.
هناك مجموعة أساسية من التبعيات التي نحتاج إلى سحبها لخدمتنا ، فهي مطلوبة في مرحلة الترجمة.
أريد أيضًا أن أشير إلى وجود مكتبة وقت تشغيل. بالنسبة لجافا ، يستخدم netty كخادم وعميل ، وهو يدعم HTTP / 2 ، وهو مناسب للغاية وعالي الأداء.
التالي نحن تكوين المترجم بروتو. لا يلزم تثبيت المترجم نفسه محليًا لجافا ، بل يمكن أن يؤخذ من الأعمال الفنية.
نفس الشيء مع الإضافات. محليا لجافا ، ليس من الضروري. يمكنك سحب قطعة أثرية. ومن المهم أن تقوم ببساطة بتكوينه بحيث يطلق عليه أيضًا خلط ورق اللعب ، بحيث يتم إنشاء أجزاء الروتين.
دعنا ننتقل إلى رمز جافا. نحن هنا أول من خلق كعب خدمتنا. هذه هي مهمتنا لـ Java لتوفير القناة. يوجد ChannelBuilder في مكتبة وقت التشغيل التي يمكننا من خلالها بناء هذه القناة. هنا قمنا بتشغيل النص العادي يدويًا للبساطة ، لكن HTTP2 و gRPC يشفران كل شيء افتراضيًا ويستخدمان TLS.
لدينا كعب عميل لدينا ، يتم إنشاء عميل متزامن هنا. بنفس الطريقة ، يمكنك إنشاء عميل غير متزامن ، وهناك خيارات أخرى.
بعد ذلك ، نقوم بإنشاء طلب protobuff ، بمعنى أننا نقوم بإنشاء رسالة protobuff.
هذا كل شيء ، وإرساله ، على عملائنا ندعو getEcho وطباعة النتيجة. كل شيء بسيط. كما ترون ، هناك حاجة إلى الكثير من التعليمات البرمجية ، ويتم بناء التكامل.
تدفق gRPC. ممارسة
الآن دعونا نلقي نظرة على شيء أكثر تقدمًا ، هذا تدفق. سأخبرك بكيفية عمله ، وسأخبرك لاحقًا بكيفية استخدامه.
يتدفق خادم الخادم الدائر معمارياً حول نفسه. هذا هو ، لدينا اتصال مستمر بين العميل والموازن. ثم تبدأ الاختلافات. جوهر الدفق هو أن العميل مرتبط ببعض الخلفية النهائية ، ويتم حفظ الاتصال من خلال. وهذا هو ، ويمضي مثل هذا. و كذلك. أود هنا أن أشير بشكل منفصل إلى أن استخدام الموازن ليس نموذجيًا للتدفق ، أي أنك تحتاج إلى فهم أن طلبات البث يمكن أن تكون طويلة جدًا. وهذا هو ، يمكنك فتحها وتبادل الرسائل لفترة طويلة. وسوف تمر هذه الرسائل من خلال الموازن ، ولكن في الواقع ، انتقل دائمًا إلى نفس الخلفية. وليس من الواضح سبب الحاجة إليها على الإطلاق.
الممارسة الشائعة هي عندما تكون الخدمة ، على سبيل المثال ، تتدفق بحتة ، أو تتدفق بشكل أساسي ، ثم يتم استخدام اكتشاف الخدمة. لدى GRPC نقطة امتداد حيث يمكن دمج اكتشاف الخدمة.
ما الذي نحتاجه من أجل تنفيذ خدمات البث؟ لدينا نفس تنسيق proto. نقوم بإضافة RPC آخر ، وهنا يمكنك ملاحظة أننا أضفنا كلمتين رئيسيتين قبل الطلب وقبل الرد. وبالتالي ، نعلن عن تدفقات EchoRequest و EchoResponse.
يبدأ أكثر إثارة للاهتمام. لا يتغير التجميع الخاص بنا بأي طريقة من أجل القيام بخدمات البث. مهمتنا التالية هي تجاوز أسلوبنا الجديد في خدمة الارتداد الخاصة بنا ، والتي ستعمل مع التدفقات. في حالة الخادم ، كل هذا أسهل إلى حد ما. وهذا هو ، يمكننا أن نقرأ باستمرار من تيار ويمكن الإجابة على شيء. يمكننا الرد بشكل غير متزامن. وهذا هو ، فهي مستقلة ، تيار للكتابة ودفق للقراءة ، وهنا كل شيء بسيط لسيناريو بسيط.
ها هي القراءة الآن ، إليك التسجيل.
في عملاء Java ، الأمور معقدة بعض الشيء. لا يمكنك استخدام أي واجهة برمجة تطبيقات متزامنة ، أي أنها لا تعمل فقط مع التدفقات. وهناك يستخدم API غير المتزامن. وهذا هو ، مهمتنا هي تنفيذ قالب المراقب. هناك واجهة StreamObserver هناك. يحتوي على ثلاث طرق: onNext و onCompleted و onError. هنا ، للبساطة ، لقد نفذت فقط على التالي. تشنجات فقط عندما يأتي الجواب لنا من الخادم.
أنا هنا فقط وضعت في طابور للرسائل بين المواضيع.
ما هو الفرق؟ بدلاً من blockingStub ، نحن فقط نجعل newStub. هذا هو تطبيق غير متزامن يمكن أن تعمل فقط مع المراقب. في الواقع ، يمكنك إجراء مكالمات أحادية على الأوبزرفر ، وليس فقط مريحة للغاية. نحن ، على الأقل ، لا نستخدمها بنشاط.
التالي نبني المراقب لدينا.
ونحن نجعل دعوة RPC لدينا. نقوم بتمرير ResponseObserver إلى المدخلات ، وفي الإخراج ، يصدر RequestObserver لنا. علاوة على ذلك ، يمكننا إجراء مكالمات على RequestObserver ، وبالتالي نقل الرسائل إلى الخادم. و ResponseObserver لدينا سوف نشل ومعالجة الرسائل.
هنا مثال. نحن فقط نجري مكالمة. اتصل على الرقم التالي ، واجعل الطلب هناك.
علاوة على ذلك ، ننتظر حتى يستجيب الخادم ويطبع.
أريد أن أسترعي الانتباه إلى حقيقة أن مهمتنا هنا ، بصفتنا الأشخاص المسؤولين عن تنفيذ البث ، هي التعامل مع إغلاق RequestObserver هذا بشكل صحيح. هذا هو ، في حالة وجود خطأ ، يجب علينا استدعاء أسلوب onError عليه ، وفي حالة الانتهاء بنجاح ، عندما نعتقد أنه يمكن إغلاق الدفق ، يجب علينا استدعاء الأسلوب onCompleted.
نحن نمضي قدما. ما هي تطبيقات التدفق؟ هذا شيء أكثر تقدماً ، وليس حقيقة أنه مفيد بشكل مباشر للجميع ، ولكنه يستخدم أحيانًا. وهذا هو ، الأول هو تنزيل وتحميل بعض كميات كبيرة من البيانات. يمكن للخادم أو العميل إنتاج بيانات في بعض الأجزاء. قد يتم بالفعل تجميع هذه الأجزاء بطريقة أو بأخرى على العميل أو على الخادم. وهذا يعني أنه يمكنك بالفعل إجراء تحسينات إضافية هنا.
كما أن مخطط التدفق مناسب تمامًا لدفع الخادم. يجب أن تفهم أنني قد نظرت إلى الخيار الأكثر تطرفًا عندما يكون لدينا بث ثنائي الاتجاه. وربما يتدفقون في اتجاه واحد. على سبيل المثال ، من عميل إلى خادم أو من خادم إلى عميل. في حالة وجود خادم إلى عميل ، يمكننا الاتصال ببعض الخوادم ، وسوف نرسل رسائل دفع إلينا ، ولهذا لن نحتاج إلى الاستقصاء بانتظام.
الميزة التالية للبث مرتبطة بجهاز واحد. كما قلت ، سيتم إنشاء اتصال واحد إلى طرف لجميع الرسائل داخل الدفق ، وسيتم ربط هذا الاتصال بجهاز واحد ، وبالتأكيد لن يتم التبديل في أي مكان. لذلك ، من الممكن ، أولاً ، تبسيط شيء ما ، نوع من التزامن بين الخوادم ، بالإضافة إلى ذلك ، يمكنك القيام بأشياء معاملات.
والتدفق ثنائي الاتجاه ، مجرد مثال أظهرته ، هو القدرة على بناء بعض البروتوكولات الخاصة بي. شيء مثير للاهتمام بما فيه الكفاية. لدينا طوابير داخلية في ياندكس تستخدم فقط التدفق ثنائي الاتجاه. وإذا كان شخص ما فجأة لديه مثل هذه المهام ، ثم فرصة جيدة بما فيه الكفاية لاستخدامها.
كما أنني أود الانتباه ، تحدثت عن البيانات الوصفية في وقت سابق. ومع الدفق ، يتم إرسال بيانات التعريف فقط في بداية الدفق وفي نهاية الدفق. وهذا هو ، قبل كل رسالة وبعد كل رسالة لا يتم إرسالها. لذلك ، إذا كان لديك أي مهام تتعلق بالبيانات الوصفية التي يجب أن تطير مع كل رسالة ، فأنت بحاجة بالفعل إلى حلها بنفسك. ولكن هذه ليست سوى البروتوكولات. هنا يمكن استخدام gRPC كوسيلة نقل.المهام النموذجية
, gRPC.
, . - . gRPC . , , , , , . , runtime- . , . , OK, runtime- .
, Java . . google.rpc.Status 3 : , . , . , . — , , .
error details, , . : , , , stack traces, . , .
— , HTTP , ? . BadRequest . , , error details, .
. , , BadRequest - ( ), - error detail. , , , - . , .
. . , , , . - - , - - , , . . , , Zipkin. , HTTP , — metadata. .
, . , - , , , .
runtime-, - , . Java ClientInterceptor ServerInterceptor. , , . , , , , , - . , - API - . , , , , - . , gRPC, , - . , , - , , , .
- . -. Java . , , - . - , .
. gRPC — . HTTP/2 . - , ? : , . . , gRPC grpc_cli, curl. , . , -, . , gRPC , .
, evans. , CLI: , , , . , . - , , , , , .
- UI — , Postman, — BloomRPC. Postman . Postman, , , . , BloomRPC , .
- , . , , grpc_cli. . , . , , . , . , - - . — .
, , gRPC. . - , - , . Swagger. , HTTP/1 . OpenAPI , . . , HTTP/2, Swagger — .
WSDL — , . . Swagger, , . . -.
, , , , JAX-RS, Java . .
Twirp. ? Go, . . , , Go , gRPC Twirp. ? , gRPC — , , , IDL . proto- , gRPC-. protoc, , .
Twirp . proto- , HTTP/1.1 , JSON. , Twirp Go. , , Java Jetty. , .
? gRPC — REST . , , , , HTTP/2 balancer. service discovery, . gRPC , . .
gRPC — , . CLI, UI. , .
, gRPC. inter-process-. , sidecar pattern. , . , . , -. - , , -. . , , , , - .
, . gRPC . , . , unary-. , .
:
—
C gRPC — , . , , , .
—
Awesome gRPC — GitHub . , , , . . — , .
يمكنك العثور على العديد من الموارد الأخرى على الإنترنت ، على عدد قليل من الشرائح. لكني أحببت هذه أكثر. الرمز المعدل قليلاً من العرض التقديمي هنا . شكرا لك
تسجيل تقرير غير رسمي