gRPC وProtobuf في خدمات Go الإنتاجية: المقايضات والدروس التشغيلية

gRPC وProtobuf يوفران عقوداً مكتوبة بدقة بين الخدمات، وترميزاً ثنائياً مضغوطاً، ودعماً أصلياً للبث. لكنهما يضيفان أيضاً تعقيداً تشغيلياً واحتكاكاً في التطوير المحلي وتحديات في التصحيح يتجنبها REST بطبيعة تصميمه. هذا ما تعلمناه من تشغيل gRPC في خدمات Go الإنتاجية لمنصات SaaS في لبنان والمنطقة.

متى يكون gRPC مجدياً فعلاً؟

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

التواصل بين الخدمات الداخلية حيث يستخدم الطرفان Go (أو لغة أخرى ذات دعم gRPC ناضج). الـ stubs المُولَّدة تلقائياً تلغي فئة كاملة من أخطاء التكامل الناجمة عن أسماء حقول غير متطابقة أو أنواع بيانات خاطئة. في نظام يضم 8 خدمات داخلية، إلغاء هذه الفئة من الأخطاء يستحق تعقيد إدارة المخطط.

واجهات برمجة التطبيقات الداخلية عالية الإنتاجية. لنقاط النهاية الداخلية التي تستقبل آلاف الاستدعاءات في الثانية، يقلل ترميز Protobuf الثنائي حجم الحمولة بنسبة 30 إلى 60 بالمئة مقارنة بـ JSON المكافئ، ويقلل وحدة المعالجة المركزية للخادم بنسبة مماثلة. في بيئات ECS حيث كل مهمة تكلف مالاً، يتراكم هذا الاختصار في الحوسبة لكل طلب.

حالات البث. بث تحديثات المخزون من نظام مركزي إلى جهاز نقطة بيع، أو بث أحداث الطلبات إلى شاشة المطبخ. دعم gRPC الأصلي للبث أنظف بكثير من الحلول البديلة مثل long-poll أو WebSocket على طبقة HTTP.

gRPC لا يؤتي ثماره لواجهات برمجة التطبيقات العامة التي تستهلكها المتصفحات أو تطبيقات الجوال. إضافة gRPC-Web proxy أو طبقة REST transcoding تلغي البساطة التشغيلية التي جعلت gRPC جذاباً في البداية. احتفظ بـ REST للواجهات العامة، واستخدم gRPC خلف البوابة.

قواعد تصميم مخطط Protobuf التي لا يمكن التراجع عنها لاحقاً

أغلى الأخطاء في أنظمة Protobuf تحدث قبل كتابة أول سطر في كود Go.

لا تُعيد استخدام رقم حقل أبداً. أرقام حقول Protobuf جزء من تنسيق السلك. إذا كان في رسالة ما حقل string customer_email = 3; تم حذفه، وأضاف مطور لاحق int32 customer_tier = 3;، فإن العملاء القدامى الذين ما زالوا يستخدمون المخطط القديم سيفسّرون حقل int32 الجديد كـ string. الفساد صامت وقد لا يُكتشف حتى يفشل نظام تدفق البيانات بطريقة محيّرة. ضع علامة reserved على الحقول المُزالة فوراً:

message OrderRequest {
  reserved 3;
  reserved "customer_email";
  string customer_id = 1;
  repeated LineItem items = 2;
  PaymentInfo payment = 4;
}

استخدم الرسائل المتداخلة لتجميع الحقول المترابطة. رسالة مسطحة بـ 40 حقلاً تصبح مخططاً يصعب صيانته في غضون أشهر. استخدم google.protobuf.Timestamp لجميع الطوابع الزمنية، وليس أعداداً صحيحة Unix.

Interceptors للاهتمامات المشتركة

في خوادم gRPC Go، تعمل الـ interceptors بنفس طريقة middleware في HTTP. ربط هذه الـ interceptors لكل خادم gRPC إنتاجي:

Auth interceptor: التحقق من JWT في كل استدعاء وارد، استخراج هوية المستأجر، حقنها في context.

Logging interceptor: تسجيل كل استدعاء RPC مع اسم الطريقة، المدة، رمز الحالة، ومعرف المستأجر.

Recovery interceptor: اصطياد الـ panics في كود المعالج وإعادتها كأخطاء codes.Internal بدلاً من تعطل الخادم.

الفجوة التشغيلية في التصحيح

أكبر تكلفة تشغيلية لـ gRPC مقارنة بـ REST هي تجربة التصحيح في الإنتاج. أمر curl يختبر أي نقطة نهاية REST في ثوانٍ. اختبار نقطة نهاية gRPC يتطلب grpcurl وخادماً يعمل والملفات الـ proto أو تفعيل server reflection.

الحلول العملية:

تفعيل server reflection في البيئات غير الإنتاجية. تسجيل ملخصات الطلبات والاستجابات كـ JSON باستخدام protojson.Marshal قبل الكتابة في السجل المنظم. استخدام distributed tracing من اليوم الأول. إضافة OpenTelemetry مع plugin gRPC لنشر سياق التتبع عبر استدعاءات الخدمة.

REST gateway للواجهات العامة

معظم أنظمة SaaS في المنطقة تخدم متصفحات وتطبيقات جوال (تحتاج REST) وخدمات داخلية (يمكنها استخدام gRPC). الهيكل الأنظف يحتفظ بالاثنين معاً.

بوابة API العامة تخدم REST/JSON. الخدمات الداخلية تتواصل عبر gRPC. البوابة تترجم طلبات REST إلى استدعاءات gRPC داخلية عند الحاجة. هذا الفصل يتجنب تعقيد gRPC-Web proxy للمتصفحات مع الحصول على كفاءة gRPC للمسارات الداخلية عالية الإنتاجية.