بقلم نافين م

خلفية

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

مقدمة

من خلال تنفيذ الدفق من جانب الخادم، يمكننا دفق البيانات بسلاسة إلى واجهة المستخدم، وتوفير معلومات محدثة دون الحاجة إلى التحديثات اليدوية أو استدعاءات واجهة برمجة التطبيقات المستمرة. يُحدث هذا النهج ثورة في تجربة المستخدم، مما يسمح للمستخدمين بتصور صحة وأداء أعباء العمل الخاصة بهم على الفور بطريقة موحدة ومبسطة. سواء أكان الأمر يتعلق بمراقبة استخدام الموارد، أو البقاء على اطلاع بأحداث Kubernetes، أو مراقبة حالة التطبيق، فإن حل التدفق من جانب الخادم الخاص بنا يجمع كل المعلومات المهمة في لوحة معلومات واحدة في الوقت الفعلي، ولكن هذا سيكون قابلاً للتطبيق على أي شخص يريد ذلك توفير بيانات البث المباشر لواجهة المستخدم.
لقد ولت أيام التنقل عبر الأدوات والأنظمة الأساسية المتعددة لجمع الأفكار الأساسية. من خلال نهجنا المبسط، يمكن للمستخدمين الوصول إلى نظرة عامة شاملة على بيئة Kubernetes الخاصة بهم بمجرد وصولهم إلى بوابة النظام الأساسي الخاص بنا. ومن خلال تسخير قوة البث من جانب الخادم، قمنا بتغيير الطريقة التي يتفاعل بها المستخدمون مع أعباء العمل الخاصة بهم ومراقبتها، مما يجعل تجربتهم أكثر كفاءة وبديهية وإنتاجية.
من خلال سلسلة المدونات الخاصة بنا، نهدف إلى إرشادك خلال تعقيدات إعداد البث من جانب الخادم باستخدام تقنيات مثل React.js وEnvoy وgRPC وGolang.

هناك ثلاثة مكونات رئيسية تشارك في هذا المشروع:
1. الواجهة الخلفية، التي تم تطويرها باستخدام Golang وتستخدم البث من جانب الخادم gRPC لنقل البيانات.
2. وكيل المبعوث، وهو المسؤول عن جعل الخدمة الخلفية في متناول العالم الخارجي.
3. الواجهة الأمامية، التي تم إنشاؤها باستخدام React.js وتستخدم grpc-web لإنشاء اتصال مع الواجهة الخلفية.
السلسلة مقسمة إلى أجزاء متعددة لاستيعاب التفضيلات اللغوية المتنوعة للمطورين. إذا كنت مهتمًا على وجه التحديد بدور Envoy في البث أو تريد التعرف على كيفية نشر وكيل Envoy في Kubernetes، فيمكنك الانتقال إلى الجزء الثاني (Envoy كوكيل للواجهة الأمامية في Kubernetes) واستكشاف هذا الجانب أو مهتم فقط بـ الجزء الأمامي، ثم يمكنك فقط التحقق من الجزء الأمامي من المدونة.
في هذا الجزء الأولي، سنركز على الجزء الأسهل من السلسلة: "كيفية إعداد البث من جانب خادم gRPC باستخدام Go." سنعرض نماذج من التطبيقات مع البث من جانب الخادم. لحسن الحظ، هناك قدر كبير من المحتوى المتاح على الإنترنت لهذا الموضوع، والمصمم خصيصًا للغة البرمجة المفضلة لديك.

الجزء 1: كيفية إعداد البث من جانب خادم gRPC باستخدام Go

حان الوقت لوضع خطتنا موضع التنفيذ! بافتراض أن لديك فهمًا أساسيًا للمفاهيم التالية، دعنا نتعمق في التنفيذ:

1. gRPC: إنه بروتوكول اتصال يسمح للعميل والخادم بتبادل البيانات بكفاءة.
2. البث من جانب الخادم: هذه الميزة مفيدة بشكل خاص عندما يحتاج الخادم إلى إرسال كمية كبيرة من البيانات إلى العميل. باستخدام الدفق من جانب الخادم، يمكن للخادم تقسيم البيانات إلى أجزاء أصغر وإرسالها واحدة تلو الأخرى. يمكن للعميل بعد ذلك اختيار إيقاف تلقي البيانات إذا كان قد تلقى ما يكفي أو إذا كان ينتظر لفترة طويلة.

الآن، لنبدأ بتنفيذ التعليمات البرمجية.

الخطوة 1: إنشاء ملف Proto
للبدء، نحتاج إلى تحديد ملف protobuf الذي سيتم استخدامه من قبل كل من العميل والخادم. إليك مثال بسيط:

syntax = "proto3";

package protobuf;

service StreamService {
  rpc FetchResponse (Request) returns (stream Response) {}
}

message Request {
  int32 id = 1;
}

message Response {
  string result = 1;
}

في هذا الملف الأولي، لدينا وظيفة واحدة تسمى FetchResponse والتي تأخذ معلمة الطلب وتقوم بإرجاع دفق من رسائل الاستجابة.

الخطوة 2: إنشاء ملف المخزن المؤقت للبروتوكول

قبل المتابعة، نحتاج إلى إنشاء ملف pb المقابل الذي سيتم استخدامه في برنامج Go الخاص بنا. كل لغة برمجة لها طريقتها الخاصة في إنشاء ملف المخزن المؤقت للبروتوكول. في Go، سنستخدم مكتبة البروتوكول.
إذا لم تكن قد قمت بتثبيته بعد، فيمكنك العثور على دليل التثبيت المقدم من Google.
لإنشاء ملف المخزن المؤقت للبروتوكول، قم بتشغيل الأمر التالي:

protoc --go_out=plugins=grpc:. *.proto

الآن، لدينا ملف data.pb.go جاهز للاستخدام في التنفيذ.

الخطوة 3: التنفيذ من جانب الخادم
لإنشاء ملف الخادم، اتبع مقتطف التعليمات البرمجية أدناه:

package main

import (
        "fmt"
        "log"
        "net"
        "sync"
        "time"

        pb "github.com/mnkg561/go-grpc-server-streaming-example/src/proto"
        "google.golang.org/grpc"
)

type server struct{}

func (s server) FetchResponse(in pb.Request, srv pb.StreamService_FetchResponseServer) error {

        log.Printf("Fetching response for ID: %d", in.Id)

        var wg sync.WaitGroup
        for i := 0; i 



 في ملف الخادم هذا، قمت بتنفيذ وظيفة FetchResponse، التي تتلقى طلبًا من العميل وترسل دفقًا من الردود مرة أخرى. يحاكي الخادم المعالجة المتزامنة باستخدام goroutines. ولكل طلب، يقوم بإرسال خمس ردود إلى العميل. يتم تأخير كل استجابة لمدة معينة لمحاكاة أوقات المعالجة المختلفة.

يستمع الخادم على المنفذ 50005 ويسجل StreamServiceServer مع الخادم الذي تم إنشاؤه. وأخيرًا، يبدأ في خدمة الطلبات ويسجل رسالة تشير إلى بدء تشغيل الخادم.

الآن لديك ملف الخادم جاهز للتعامل مع طلبات البث من العملاء.


  
  
  الجزء 2


ترقبوا الجزء الثاني حيث سنواصل التعمق في عالم تدفق البيانات المثير وكيف يمكن أن يحدث ثورة في واجهة المستخدم الخاصة بك.