أضافت Google Cloud API Gateway البث: ما الذي ينبغي التحقق منه قبل الترحيل؟

يبقي النظام الخلفي المتدفق الاتصال مفتوحًا ويرسل البيانات على دفعات: فمثلًا، يمكن لـSSE إرسال نص إجابة النموذج أثناء إنشائها، بينما تتيح WebSocket تبادل البيانات في الاتجاهين. في 22 أكتوبر 2026، أعلنت Google عن المعاينة العامة للبث في Cloud API Gateway. تستطيع البوابة تمرير هذه الاستجابات وتطبيق قواعد المصادقة المعتادة وأدوات المراقبة على الطلبات؛ ويتطلب الاختبار إنشاء بوابة جديدة مع تفعيل وضع البث.

يسرد إعلان Google بروتوكولات SSE وبث استجابات HTTP وترميز النقل المجزأ، وWebSockets، فضلًا عن البث من جهة الخادم والبث ثنائي الاتجاه في gRPC. تُرسل استجابات HTTP إلى العميل فور ورودها من النظام الخلفي، بما في ذلك NDJSON. وهذا يتيح إبقاء المسارات المتدفقة خلف بوابة API نفسها التي تخدم الطلبات العادية بالفعل.

ما الذي يتغير في API والبنية التحتية؟

لا تتطلب العمليات المتدفقة وصفًا منفصلًا لـAPI أو إضافات خاصة في المواصفات. في المعاينة، يُفعّل وضع البث عند إنشاء البوابة باستخدام الخيار --enable-streaming. وتشير Google إلى استمرار دعم التحقق من API key وJWT، ومصادقة النظام الخلفي عبر service account، والتوجيه، والتكامل مع Cloud Logging وCloud Monitoring.

تقدم المعاينة أيضًا اسم مضيف متوقعًا يستند إلى معرّف البوابة ورقم المشروع والمنطقة. على سبيل المثال، يكون تنسيق العنوان GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. ويمكن إدراجه مسبقًا في إعدادات العميل أو CI. ويظل هذا العنوان نفسه عند إعادة إنشاء البوابة باستخدام المعرّف والمشروع والمنطقة ذاتها.

الاختبار من دون تحويل حركة الإنتاج

1. اختر نظامًا خلفيًا موجودًا. ابدأ بنقطة نهاية ترسل SSE أو استجابة HTTP متدفقة بالفعل؛ فهذا يساعد على عزل سلوك البوابة عن تغييرات التطبيق.
2. أنشئ بوابة منفصلة. يُحدَّد تفعيل البث عند الإنشاء؛ ولا يمكن تغيير وضع بوابة موجودة. استخدم معرّفًا للاختبار ومنطقة مناسبة.
3. اضبط مهلة النظام الخلفي. تبلغ مهلة الطلب الافتراضية لـSSE وبث HTTP 15 ثانية؛ ويُغلق التدفق عند انتهاء المهلة المحددة. في إعدادات OpenAPI، عيّن قيمة deadline للنظام الخلفي بما يناسب حالتك: تسمح الوثائق لبوابة البث بقيمة تصل إلى 3600 ثانية. وانتبه أيضًا إلى المهلة الخاصة بالنظام الخلفي نفسه؛ فقد يغلق Cloud Run الاتصال قبل ذلك، مثلًا.
4. تحقق من بروتوكول النظام الخلفي. يتطلب gRPC استخدام HTTP/2 (h2)، بينما تتطلب WebSockets استخدام HTTP/1.1. يعمل SSE وبث HTTP عبر HTTP/1.1 أو HTTP/2؛ وتوصي Google باستخدام HTTP/2 لهاتين الحالتين.
5. تحقق من وصول البيانات. تأكد من تلقي العميل الأحداث الأولى قبل اكتمال الاستجابة بأكملها. وفي WebSocket، اختبر تبادل البيانات في الاتجاهين، وخطط لإعادة اتصال العملاء بعد انتهاء الاتصال.
6. راجع السياسات والمقاييس. تحقق من المصادقة والسجلات وحدود الطلبات على المسار المتدفق. يعكس مقياس زمن استجابة الطلب المدة الكاملة للتدفق، لذا قِس على العميل بصورة منفصلة الوقت حتى ظهور الحدث الأول والفواصل الزمنية بين الأحداث.

تحدد الوثائق فترة خمول افتراضية قدرها 300 ثانية من دون رسائل لكل من WebSockets وgRPC؛ وبالنسبة إلى WebSocket، لا تُطبّق مهلة تقل عن 300 ثانية، وينتهي الاتصال على أي حال في موعد أقصاه 3600 ثانية. أما SSE وبث HTTP فتسري عليهما مهلة الجدار الزمني المحددة. لذلك، لا يوضح ارتفاع زمن استجابة الطلب وحده مدى سرعة ظهور الجزء الأول للمستخدم.

قيود المعاينة العامة

عند الإطلاق، لا يمكن تفعيل وضع البث عبر Cloud Console أو Terraform. كما أن البوابات التي يكون البث مفعّلًا فيها غير متوافقة مع HTTP(S) Load Balancing وServerless NEG، ولذلك لا تتاح النطاقات المخصصة التي تعتمد على هذا الترتيب. وتدرج Google هذه الإمكانات ضمن الإضافات المستقبلية خلال فترة المعاينة. قبل التخطيط لتوجيه حركة الإنتاج والأتمتة، راجع وثائق إعداد البث.

تتمثل الخطوة العملية الأولى في توجيه بوابة جديدة إلى نظام خلفي متدفق موجود، وضبط المهلة صراحةً، ثم مقارنة الاتصال المباشر بالمسار عبر البوابة. وهكذا يستطيع الفريق اختبار توافق البروتوكول والمصادقة والوقت الفعلي حتى ظهور الحدث الأول، من دون تغيير عقد API أو حركة الإنتاج.