مشتاق هستید بدانید آیا gRPC تکنولوژی آینده است یا خیر؟ این مقاله قصد دارد دو سبک معماری API را توضیح دهد: REST و gRPC. قبل از اینکه به تفاوت های آنها بپردازیم ، ابتدا توضیح می دهیم که API چیست و چرا برای زیرساخت های مایکروسرویس ها ضروری است. پس از آن ، ما توضیح می دهیم که چگونه RPC اساس gRPC است و جنبه های مهم تمایز بین API های gRPC و REST را در نظر می گیریم. با توجه به مقایسه آنها ، ما در نهایت زمان استفاده از یک نوع معماری یا نوع دیگر را تجزیه و تحلیل خواهیم کرد.
کلمه API مخفف Application Programming Interfaces است. این رابط ها به عنوان یک واسطه نرم افزاری عمل می کنند که قوانین خاصی را برای برنامه های کاربردی و تعامل با یکدیگر ایجاد می کند. یک API مسئول ارسال پاسخ از یک کاربر به یک سیستم است که به نوبه خود از سیستم به کاربر ارسال می شود.
تصور کنید ما در حال رزرو هتل هستیم. ما روی صفحه رزرو هتل می رویم و آن صفحه داده ها (درخواست ما) را به سروری ارسال می کند. سرور داده ها را بازیابی می کند ، آنها را تفسیر می کند ، و پس از انجام اقدامات مورد نیاز ، پاسخی را با اطلاعات موجود در رابط کاربری برای ما ارسال می کند. این فرایند به لطف API ها اتفاق می افتد.
یک API انواع درخواست هایی را که یک برنامه (صفحه وب یا برنامه تلفن همراه) می تواند به دیگری بدهد ، مشخص می کند و در ادامه توضیح می دهد: چگونه این درخواست ها را انجام دهیم. کدام فرمت های داده را استفاده کنید و شیوه هایی که کاربران باید رعایت کنند.
در این مقاله قصد داریم دو معماری معروف gRPC (Google Remote Procedure Call) و REST (Representational State Transfer) را با هم مقایسه کنیم.
از یک سو ، در یک برنامه یکپارچه ، همه ویژگی های پروژه در یک واحد ، به طور دقیق تر ، در یک پایگاه کد واحد گنجانده شده است. از سوی دیگر ، معماری مایکروسرویس شامل چندین سرویس کوچکتر است که با یکدیگر از طریق پروتکل هایی مانند HTTP ارتباط برقرار می کنند. سرویس های کوچکتر که بخشی از معماری مایکروسرویس هستند از طریق API ها با یکدیگر ارتباط برقرار کرده و با یکدیگر تعامل دارند. به عبارت دیگر ، API ها به همه سرویس هایی که در یک برنامه مایکروسرویس ادغام شده اند امکان اتصال و ارتباط می دهند.
پرکاربردترین سبک معماری REST API است. با این حال ، هنگام ایجاد API سه مدل اصلی وجود دارد: RPC (فراخوانی از راه دور) ، REST (Representational State Transfer) و GraphQL. در این مقاله ، ما روی دو مورد اول تمرکز می کنیم.
تکنولوژی RPC از مدل client-server استفاده می کند. سرور درخواست کننده (به عبارت دیگر کلاینت) پیامی را درخواست می کند که توسط RPC ترجمه شده و به سرور دیگری ارسال می شود. هنگامی که سرور درخواست را دریافت می کند ، پاسخ را به مشتری ارسال می کند. در حالی که سرور در حال پردازش این درخواست است ، سرویس گیرنده مسدود شده و پیام داخلی که در سرورها ارسال می شود پنهان است.
علاوه بر این ، RPC به مشتری اجازه می دهد تا عملکردی را در قالب خاصی درخواست کند و پاسخ را در همان قالب دریافت کند. با این وجود ، روش ارسال درخواست با RPC API در URL یافت می شود. RPC از فراخوانی های از راه دور در محیط های محلی و توزیع شده پشتیبانی می کند.
هنگام استفاده از REST API ها ، پاسخ داده های بک اند از طریق قالب JSON یا XML به کاربران منتقل می شود. این مدل معماری از پروتکل HTTP پیروی می کند. با این حال ، غیر معمول نیست که طرح های RPC ضمن حفظ مدل RPC ، چند ایده از HTTP انتخاب کنند. در حقیقت ، اکثر API های مدرن با نگاشتن API ها به همان پروتکل HTTP ، علیرغم مدل مورد استفاده (RPC یا REST) پیاده سازی می شوند.
هنگامی که REST API به صورت عمومی در دسترس است ، هر سرویسی که از مایکروسرویس استفاده می کند می تواند به عنوان منبعی به کاربر ارائه شود که از طریق دستورات HTTP زیر قابل دسترسی است: GET ، DELETE ، POST و PUT.
تکنولوژی gRPC مخفف عبارت Google Remote Procedure Call و یک نوع مبتنی بر معماری RCP است. این فناوری پیاده سازی RPC API را دنبال می کند که از پروتکل HTTP 2.0 استفاده می کند ، اما HTTP نه به توسعه دهنده API و نه به سرور ارائه نمی شود. بنابراین ، نیازی به نگرانی در مورد چگونگی ترسیم مفاهیم RPC در HTTP نیست ، که از پیچیدگی آن می کاهد.
به طور کلی ، هدف gRPC این است که انتقال داده ها بین مایکروسرویس ها را سریعتر انجام دهد. این بر اساس رویکرد تعیین سرویس ها، ایجاد روشها و پارامترهای مربوطه برای فعال کردن انواع فراخوانی از راه دور و دریافت پاسخ است.
علاوه بر این ، مدل API RPC را در IDL (زبان توصیف رابط) بیان می کند ، که برای تعیین روشهای از راه دور سریعتر ارائه می دهد. به طور پیش فرض ، IDL از پروتکل بافر (اما جایگزین های دیگر نیز موجود است) برای توصیف رابط سرویس و همچنین ساختار پیام های ارسالی استفاده می کند.
اکنون که مروری کلی بر gRPC و REST داریم ، اجازه دهید تفاوت های اصلی آنها را بررسی کنیم.
HTTP 1.1 vs HTTP 2:
سرویس های REST از یک مدل درخواست و پاسخ ارتباطی استفاده می کنند که معمولاً بر روی HTTP 1.1 ساخته شده است. متأسفانه ، این بدان معناست که اگر یک مایکروسرویس درخواست های متعددی از چندین سرویس گیرنده دریافت کند ، مدل باید به هر درخواست در یک زمان رسیدگی کند ، در نتیجه کل سیستم را کند می کند. با این حال ، API های REST نیز می توانند بر روی HTTP 2 ساخته شوند ، اما مدل ارتباطی درخواست و پاسخ یکسان است ، که API های REST را از حداکثر استفاده از مزایای HTTP 2 ، مانند ارتباطات جاری و پشتیبانی دو طرفه منع می کند.
اما gRPC با مانع مشابهی روبرو نیست. این تکنولوژی برپایه HTTP2 ساخته شده است و در عوض از مدل ارتباطی client-response پیروی می کند. این شرایط به دلیل توانایی gRPC در دریافت درخواست های متعدد از چندین کلاینت و مدیریت همزمان این درخواست ها با جریان دادن مداوم اطلاعات ، از ارتباطات دو طرفه و ارتباطات streaming پشتیبانی می کند. به علاوه ، gRPC همچنین می تواند تعاملات "غیرمتعارف" مانند تعاملات ایجاد شده بر روی HTTP 1.1 را انجام دهد.
در مجموع ، gRPC قادر است تعاملات غیرمتعارف و انواع مختلف streaming را مدیریت کند:
Browser Support:
این جنبه احتمالاً یکی از مزایای اصلی REST نسبت به gRPC است. از یک طرف ، REST به طور کامل توسط همه مرورگرها پشتیبانی می شود. از سوی دیگر ، وقتی از پشتیبانی مرورگر صحبت می شود ، gRPC هنوز کاملاً محدود است. متأسفانه ، برای انجام تبدیل بین HTTP 1.1 و HTTP 2 به gRPC-web و یک لایه پروکسی نیاز است. بنابراین ، gRPC عمدتا برای سیستم های داخلی/خصوصی مورد استفاده قرار می گیرد.
Payload Data Structure:
همانطور که قبلاً ذکر شد ، gRPC به طور پیش فرض از Protocol Buffer برای سریالایز کردن داده ها استفاده می کند. این راه حل سبک تر است زیرا فرمت بسیار فشرده را فعال می کند و اندازه پیام ها را کاهش می دهد. علاوه بر این ، Protobuf (یا پروتکل بافر) باینری است. بنابراین ،داده های ساختار یافته را به منظور برقراری ارتباط و انتقال آنها ، سریالایز و دیسریالایز می کند. به عبارت دیگر ، پیامهای strongly-typed می توانند به طور خودکار از Protobuf به زبان برنامه نویسی سرویس گیرنده و سرور تبدیل شوند.
در مقابل ، REST عمدتا به فرمت های JSON یا XML برای ارسال و دریافت داده ها متکی است. در حقیقت ، JSON با وجود اینکه هیچ ساختاری را اجباری نمی کند ، به دلیل انعطاف پذیری و قابلیت ارسال داده های پویا بدون لزوم پیروی از یک ساختار دقیق ، محبوب ترین فرمت است. یکی دیگر از مزایای مهم استفاده از JSON سطح خوانایی آن از نظر انسانی است که Protobuf هنوز نمی تواند با آن رقابت کند.
با این وجود ، JSON هنگام انتقال داده ها ، سبک و سریع نیست. دلیل آن در این واقعیت نهفته است که هنگام استفاده از REST ، JSON (یا سایر فرمت ها) باید سریالایز شود و به زبان برنامه نویسی مورد استفاده در طرف مشتری و سرور تبدیل شود. این یک مرحله اضافی به روند انتقال داده ها می افزاید که در نتیجه می تواند به عملکرد آسیب برساند و احتمال خطاها را باز کند.
Code Generation Features:
برخلاف REST API ، gRPC ویژگی های تولید کد را ارائه نمی دهد ، به این معنی که توسعه دهندگان باید از یک ابزار third-party مانند Swagger یا Postman برای تولید کد برای درخواست های API استفاده کنند.
در مقابل ، gRPC به دلیل کامپایلر protoc دارای ویژگی های تولید کد native است که با چندین زبان برنامه نویسی سازگار است. این امر به ویژه برای سیستم های مایکروسرویس که خدمات مختلفی را که در زبان ها و سیستم عامل های مختلف توسعه یافته است ، ادغام می کند مفید است.
همانطور که گفته شد ، علی رغم مزایای بسیار زیادی که gRPC ارائه می دهد ، یک مانع عمده دارد: سازگاری کم مرورگر. در نتیجه ، gRPC کمی محدود به سیستم های داخلی/خصوصی است.
برعکس ، REST API ها ممکن است معایب خود را داشته باشند ، همانطور که گفتیم ، اما آنها شناخته شده ترین API ها برای اتصال سیستم های مبتنی بر مایکروسرویس ها هستند. بعلاوه ، REST از استانداردسازی پروتکل HTTP پیروی می کند و پشتیبانی جهانی را ارائه می دهد و این سبک معماری API را به گزینه ای برتر برای توسعه خدمات وب و همچنین ادغام برنامه ها و مایکروسرویس ها تبدیل می کند. با این حال ، این بدان معنا نیست که ما باید از تکنولوژی gRPC غافل شویم.
سبک معماری gRPC دارای ویژگی های امیدوارکننده ای است که می توان (و باید) آنها را یاد گرفت و توسعه داد. این تکنولوژی یک گزینه عالی برای کار با سیستم های چند زبانه ، real-time streaming و به عنوان مثال ، هنگام کار با یک سیستم اینترنت اشیاء است که نیاز به ارسال پیامهای سبک وزن دارد ، مانند پیامهای سری شده Protobuf. علاوه بر این ، gRPC همچنین باید برای برنامه های تلفن همراه در نظر گرفته شود زیرا آنها نیازی به مرورگر ندارند و می توانند از پیامهای کوچکتر بهره مند شوند و سرعت پردازنده های تلفن همراه را حفظ کنند.
تکنولوژی gRPC مزایای زیادی را ارائه می دهد. برخلاف REST ، می تواند با استفاده از جریان های چندگانه و پیروی از پروتکل باینری ، حداکثر استفاده را از HTTP 2 بکند. بعلاوه ، به دلیل ساختار پیام Protobuf ، مزایای عملکردی را ارائه می دهد ، و ویژگی های تولید کد داخلی که محیطی چند زبانه فعال می کند را فراموش نکنیم. این دلایل gRPC را به یک سبک معماری API امیدوار کننده تبدیل می کند.
با این وجود ، پشتیبانی کم مرورگر رقابت با پشتیبانی جهانی REST را دشوار می کند. REST به عنوان تکنولوژی ماندگاری در سیستم های مایکروسروییس باقی می ماند و محبوب ترین راه حل است. بنابراین ، بسیار محتمل است که این جایگاه را برای مدت طولانی داشته باشد.
