مقدمه ای برای مفاهیم کلیدی GRPC ، با مروری بر معماری GRPC و چرخه زندگی RPC.

مفاهیم اصلی ، معماری و چرخه عمر

مقدمه ای برای مفاهیم کلیدی GRPC ، با مروری بر معماری GRPC و چرخه زندگی RPC.

با GRPC آشنا نیستید؟ابتدا مقدمه GRPC را بخوانید. برای جزئیات خاص زبان ، مستندات سریع ، آموزش و مرجع را برای زبان مورد نظر خود مشاهده کنید.

بررسی اجمالی

تعریف خدمات

مانند بسیاری از سیستم های RPC ، GRPC حول ایده تعریف یک سرویس است ، روش هایی را که می توان از راه دور با پارامترهای آنها و انواع بازگشت آنها نامید ، مشخص می کند. به طور پیش فرض ، GRPC از بافرهای پروتکل به عنوان زبان تعریف رابط (IDL) برای توصیف رابط سرویس و ساختار پیام های بار استفاده می کند. در صورت تمایل می توان از گزینه های دیگر استفاده کرد.

سرویسخدمت جهنمی  RPCSayhello (Hellorequest)بازگرداندن(Helloresponse) ؛  >   پیام جهنم  رشتهاحوالپرسی= 1;  >   پیام جهش  رشتهپاسخ= 1;  > 

GRPC به شما امکان می دهد چهار نوع روش خدمات را تعریف کنید:

• Unary RPCS که در آن مشتری یک درخواست واحد را به سرور ارسال می کند و یک پاسخ واحد را به شما باز می گرداند ، دقیقاً مانند یک تماس عملکردی عادی.

   

RPCSayhello (Hellorequest)بازگرداندن(Helloresponse) ؛ 

RPCLotlofReplies (Hellorequest)بازگرداندن(جریان Helloresponse) ؛ 

RPCLotlofgreetings (جریان Hellorequest)بازگرداندن(Helloresponse) ؛ 

RPCBidiHello (جریان Hellorequest)بازگرداندن(جریان Helloresponse) ؛ 

در مورد انواع مختلف RPC در بخش چرخه زندگی RPC در زیر اطلاعات بیشتری کسب خواهید کرد.

با استفاده از API

GRPC با شروع از تعریف سرویس در یک پرونده . proto ، افزونه های کامپایلر بافر پروتکل را ارائه می دهد که باعث ایجاد کد سمت مشتری و سرور می شوند. کاربران GRPC به طور معمول با این API ها در سمت مشتری تماس می گیرند و API مربوطه را در سمت سرور پیاده سازی می کنند.

• در سمت سرور ، سرور روشهای اعلام شده توسط سرویس را پیاده سازی می کند و یک سرور GRPC را برای رسیدگی به تماس های مشتری اجرا می کند. زیرساخت GRPC درخواست های دریافتی را رمزگشایی می کند ، روش های سرویس را اجرا می کند و پاسخ های سرویس را رمزگذاری می کند.
• از طرف مشتری ، مشتری دارای یک شیء محلی است که به نام Stub (برای برخی از زبانها ، اصطلاح ارجح مشتری است) که همان روش های سرویس را پیاده سازی می کند. مشتری سپس می تواند فقط آن روش ها را روی شیء محلی فراخواند ، و روش ها پارامترهای تماس را در نوع پیام بافر پروتکل مناسب بسته بندی می کنند ، درخواست ها را به سرور ارسال می کنند و پاسخ های بافر پروتکل سرور را برگردانند.

همزمان در مقابل ناهمزمان

تماس های RPC همزمان که مسدود می شود تا زمانی که یک پاسخ از سرور وارد نشود ، نزدیکترین تقریب به انتزاع یک تماس روشی است که RPC به آن می خواهد. از طرف دیگر ، شبکه ها ذاتاً ناهمزمان هستند و در بسیاری از سناریوها مفید است که بتوانید RPC ها را بدون مسدود کردن موضوع فعلی شروع کنید.

API برنامه نویسی GRPC در اکثر زبانها در هر دو طعم همزمان و ناهمزمان قرار می گیرد. می توانید اطلاعات بیشتری را در مستندات آموزش و مرجع هر زبان کسب کنید (اسناد مرجع کامل به زودی می آیند).

چرخه زندگی RPC

در این بخش ، نگاهی دقیق تر به آنچه اتفاق می افتد هنگامی که مشتری GRPC با روش سرور GRPC تماس می گیرد. برای جزئیات کامل اجرای ، به صفحات خاص زبان مراجعه کنید.

Unary RPC

ابتدا ساده ترین نوع RPC را در نظر بگیرید که مشتری یک درخواست واحد را ارسال می کند و یک پاسخ واحد را باز می گرداند.

1. هنگامی که مشتری با روش خردمندانه تماس می گیرد ، به سرور اطلاع داده می شود که RPC با ابرداده مشتری برای این تماس ، نام روش و مهلت مشخص شده در صورت لزوم فراخوانی شده است.
2. سرور می تواند بلافاصله ابرداده اولیه خود (که باید قبل از هرگونه پاسخ ارسال شود) را ارسال کند ، یا منتظر پیام درخواست مشتری باشد. که در ابتدا اتفاق می افتد ، خاص برنامه است.
3. هنگامی که سرور پیام درخواست مشتری را داشته باشد ، هر کاری را که برای ایجاد و جمع آوری پاسخ لازم است انجام می دهد. سپس پاسخ (در صورت موفقیت) به همراه جزئیات وضعیت (کد وضعیت و پیام وضعیت اختیاری) و ابرداده دنباله ای اختیاری به مشتری بازگردانده می شود.
4. اگر وضعیت پاسخ خوب باشد ، مشتری پاسخ می دهد ، که تماس با طرف مشتری را تکمیل می کند.

جریان سرور RPC

یک RPC با پخش سرور شبیه به یک RPC Unary است ، به جز اینکه سرور در پاسخ به درخواست مشتری ، جریان پیام ها را برمی گرداند. پس از ارسال تمام پیام های آن ، جزئیات وضعیت سرور (کد وضعیت و پیام وضعیت اختیاری) و ابرداده دنباله دار اختیاری به مشتری ارسال می شود. این کار پردازش را در سمت سرور انجام می دهد. مشتری هنگامی که تمام پیام های سرور را در اختیار دارد ، تکمیل می شود.

جریان مشتری RPC

یک RPC با جریان مشتری شبیه به یک RPC Unary است ، به جز اینکه مشتری به جای یک پیام واحد ، جریان پیام را به سرور ارسال می کند. سرور با یک پیام واحد (همراه با جزئیات وضعیت آن و ابرداده دنباله دار اختیاری) پاسخ می دهد ، به طور معمول اما نه لزوماً پس از دریافت تمام پیام های مشتری.

جریان دو طرفه RPC

در یک RPC جریان دو طرفه ، تماس توسط مشتری با استفاده از روش و سرور دریافت ابرداده مشتری ، نام روش و مهلت آغاز می شود. سرور می تواند ابرداده اولیه خود را ارسال کند یا منتظر بماند تا مشتری پیام های پخش را شروع کند.

پردازش جریان سمت مشتری و سرور خاص برنامه است. از آنجا که این دو جریان مستقل هستند ، مشتری و سرور می توانند به هر ترتیب پیام بخوانند و بنویسند. به عنوان مثال ، یک سرور می تواند صبر کند تا قبل از نوشتن پیام های خود ، تمام پیام های مشتری را دریافت کند ، یا سرور و مشتری می توانند "پینگ پنگ" را بازی کنند-سرور درخواست می کند ، سپس پاسخ می دهد ، سپس مشتری می فرستددرخواست دیگری بر اساس پاسخ و غیره.

مهلت ها/زمان بندی

GRPC به مشتریان این امکان را می دهد تا قبل از خاتمه RPC با خطای Deadline_Expeted ، مشخص کنند که چه مدت مایل به انتظار برای تکمیل RPC هستند. در سمت سرور ، سرور می تواند پرس و جو کند تا ببیند آیا یک RPC خاص به پایان رسیده است یا اینکه چقدر زمان برای تکمیل RPC باقی مانده است.

مشخص کردن مهلت یا زمان بندی خاص زبان است: برخی از API های زبان از نظر زمان بندی (مدت زمان) کار می کنند ، و برخی از API های زبانی از نظر مهلت (یک نقطه ثابت در زمان) کار می کنند و ممکن است مهلت پیش فرض نداشته باشند.

خاتمه RPC

در GRPC ، هر دو مشتری و سرور تعیین کننده های مستقل و محلی از موفقیت تماس را انجام می دهند و نتیجه گیری آنها ممکن است مطابقت نداشته باشد. این بدان معنی است که ، به عنوان مثال ، شما می توانید یک RPC داشته باشید که با موفقیت در سمت سرور به پایان برسد ("من تمام پاسخ های خود را ارسال کرده ام!") اما در سمت مشتری شکست می خورد ("پاسخ ها پس از مهلت من رسیدند!"). همچنین ممکن است یک سرور تصمیم بگیرد که قبل از ارسال مشتری تمام درخواست های خود را انجام دهد.

لغو RPC

یا مشتری یا سرور می توانند RPC را در هر زمان لغو کنند. لغو RPC بلافاصله خاتمه می یابد تا کار دیگری انجام نشود.

هشدار

تغییرات ایجاد شده قبل از فسخ به عقب برگردانده نشده است.

ابرداده

ابرداده اطلاعات مربوط به یک تماس خاص RPC (مانند جزئیات تأیید اعتبار) در قالب لیستی از جفت های ارزش کلیدی است ، جایی که کلیدها رشته ها هستند و مقادیر معمولاً رشته ها هستند ، اما می توانند داده های باینری باشند.

کلیدها بی حس هستند و از حروف ASCII ، رقم و شخصیت های خاص تشکیل شده اند - ، _ ،. و نباید با GRPC شروع شود (که برای خود GRPC محفوظ است). کلیدهای با ارزش باینری د ر-Bin به پایان می رسند در حالی که کلیدهای دارای ارزش ASCII انجام نمی دهند.

ابرداده تعریف شده توسط کاربر توسط GRPC استفاده نمی شود ، که به مشتری امکان می دهد اطلاعات مرتبط با تماس به سرور و بالعکس را ارائه دهد.

دسترسی به ابرداده وابسته به زبان است.

کانال

یک کانال GRPC اتصال به سرور GRPC در یک میزبان و درگاه مشخص را فراهم می کند. هنگام ایجاد خرد مشتری استفاده می شود. مشتریان می توانند آرگومان های کانال را برای تغییر رفتار پیش فرض GRPC ، مانند روشن کردن فشرده سازی پیام ، مشخص کنند. یک کانال دارای حالت ، از جمله متصل و بیکار است.

نحوه برخورد GRPC با بستن کانال وابسته به زبان است. برخی از زبانها همچنین اجازه می دهند از حالت کانال پرس و جو استفاده کنند.< Pan> ابرداده تعریف شده توسط کاربر توسط GRPC استفاده نمی شود ، که به مشتری امکان می دهد اطلاعات مرتبط با تماس به سرور را ارائه دهد و برعکس.