gRPC في C++: أداة قوية للخدمات المصغرة وأكثر

gRPC في C++: متى يكون ضروريًا حقًا (ومتى يكون الهروب منه أفضل)

تخيل: أنت تكتب خلفية عالية التحميل بلغة C++. الخادم يعالج آلاف الطلبات في الثانية، البيانات تتدفق على دفعات، والعملاء يطلبون استجابة فورية. REST API مع JSON يبدأ في التباطؤ — التحليل يستهلك وحدة المعالجة المركزية، الحزم منتفخة، ولنقل البيانات المتدفقة عليك اختراع حلول بدائية. هل هذا مألوف؟

هنا يظهر gRPC على الساحة — إطار عمل حديث لاستدعاء الإجراءات عن بُعد من Google. يستخدم بروتوكولًا ثنائيًا (Protobuf)، ويدعم التدفق، والاتصال ثنائي الاتجاه، ويعمل أسرع بعدة مرات من REST التقليدي. ولكن، مثل أي أداة قوية، يتطلب gRPC في C++ نهجًا واعيًا. في هذه المقالة، سنناقش متى يكون تطبيقه منجم ذهب، ومتى يكون صداعًا إضافيًا.

المقالة مكتوبة لمطوري C++ الذين سمعوا بالفعل عن gRPC، لكنهم يريدون فهم: «هل أحتاجه؟». لا ماء — فقط ممارسة، كود وتوصيات صادقة.

ما هو gRPC ولماذا C++ هو أفضل صديق له؟

gRPC مبني على ركيزتين: Protocol Buffers (Protobuf) لتسلسل البيانات و HTTP/2 للنقل. Protobuf يحول البيانات المنظمة إلى تنسيق ثنائي مضغوط، يتم تحليله أسرع بكثير من JSON. HTTP/2، بدوره، يسمح بتعدد الإرسال للطلبات عبر اتصال واحد وإجراء تدفق من الخادم/العميل.

C++ هنا في عنصره: تحكم منخفض المستوى في الذاكرة، تكاليف إضافية ضئيلة، تكامل مثالي مع Protobuf (توليد الكود من ملفات .proto). النتيجة هي أن gRPC على C++ يعطي أداءً قريبًا من التبادل عبر المقابس الأصلي، ولكن مع سهولة إطار عمل RPC جاهز.

باختصار عن Protobuf (لتوضيح الفكرة)

تخيل أنك تصف بنية البيانات في ملف user.proto:

syntax = "proto3";

message User {  int32 id = 1;  string name = 2;  string email = 3;}

service UserService {  rpc GetUser (UserRequest) returns (User);}

message UserRequest {  int32 user_id = 1;}

ثم يقوم المترجم protoc بتوليد فئات C++ مع طرق التسلسل/إلغاء التسلسل. أنت فقط تستدعي user.name()، وتحتها حزمة ثنائية بحجم 20 بايت بدلاً من 100+ بايت من JSON.

متى تختار gRPC في C++: 5 سيناريوهات حديدية

1. بنية الخدمات المصغرة ذات التحميل العالي

إذا كان لديك 10–50 خدمة مصغرة بلغة C++ تتواصل باستمرار مع بعضها البعض، فإن gRPC أمر لا بد منه. السبب: زمن انتقال منخفض و كتابة صارمة للعقود.

مثال: خدمة الدفع وخدمة الإشعارات. بدون gRPC، كنت سترسل JSON بحقول مثل "user_id": 123. خطأ مطبعي في اسم الحقل — وسيذهب الخلل إلى الإنتاج. مع gRPC، يتم تحديد العقد بشكل صارم في ملف .proto، وسيتم اكتشاف خطأ الترجمة في مرحلة البناء.

كود حقيقي: جزء الخادم بلغة C++ (مبسط):

#include <grpcpp/grpcpp.h>#include "user.grpc.pb.h"

class UserServiceImpl final : public UserService::Service {  grpc::Status GetUser(grpc::ServerContext* context,                       const UserRequest* request,                       User* reply) override {    // محاكاة البحث في قاعدة البيانات    reply->set_id(request->user_id());    reply->set_name("Alice");    reply->set_email("alice@example.com");    return grpc::Status::OK;  }};

void RunServer() {  std::string server_address("0.0.0.0:50051");  UserServiceImpl service;

  grpc::ServerBuilder builder;  builder.AddListeningPort(server_address, grpc::InsecureServerCredentials());  builder.RegisterService(&service);

  std::unique_ptr<grpc::Server> server(builder.BuildAndStart());  std::cout << "Server listening on " << server_address << std::endl;  server->Wait();}

استدعاء العميل — أسهل