Technical Tutorials

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

في هذا المنشور، سنستكشف كيفية دمج بروتوكول grpc-health القياسي في خوادم Go الخاصة بك، وكيفية التعامل مع الإشارات لإيقاف التشغيل بشكل نظيف. سننتقل عبر التطبيقات الأساسية لمعالجة تحديات التزامن، مثل ظروف السباق أثناء الإيقاف.

تنفيذ خدمة فحص صحة gRPC

يحتوي نظام gRPC البيئي على بروتوكول فحص صحة موحد مُعرّف في grpc/health/v1. بدلاً من كتابة نقاط نهاية مخصصة للتحقق مما إذا كانت خدمتك جاهزة، يجب عليك تنفيذ هذا الواجهة القياسية. يسمح ذلك لموازنات الحمل وأدوات التنسيق باستعلام الخدمة دون الحاجة إلى معرفة المنطق الداخلي لنطاق عمل عملك.

للبدء، تحتاج إلى تثبيت حزمة الصحة. بافتراض أنك تستخدم وحدات Go، قم بتشغيل:

go get google.golang.org/grpc/health
go get google.golang.org/grpc/health/grpc_health_v1

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

إليك تنفيذ عملي لفاحص صحة يراقب الحالة العامة لتطبيقك:

package main

import (
    "log"
    "net"
    "time"

    "google.golang.org/grpc"
    health "google.golang.org/grpc/health/grpc_health_v1"
    "google.golang.org/grpc/health"
)

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }

    s := grpc.NewServer()
    
    // سجل خدمات الأعمال الخاصة بك هنا
    // pb.RegisterMyServiceServer(s, &myServer{})

    // تهيئة خدمة الصحة
    healthSvc := health.NewServer()
    
    // تعيين الحالة الافتراضية إلى SERVING
    // هذا يخبر أدوات التنسيق بأن الخادم جاهز
    healthSvc.SetServingStatus("", health.CheckResponse_SERVING)
    
    // تسجيل خدمة الصحة مع خادم gRPC
    health.RegisterHealthServer(s, healthSvc)

    log.Println("Starting gRPC server on 50051...")
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

يتيح هذا الإعداد لأي عميل استدعاء grpc.health.v1.Health.Check لتحديد ما إذا كان الخادم يقبل حركة المرور. بينما يكون التنفيذ الافتراضي بسيطاً، في السيناريوهات المعقدة، قد ترغب في تجاوز طريقة Check للتحقق من اتصال قاعدة البيانات أو توافر خدمات الطرف الآخر قبل الإبلاغ عن "SERVING".

التعامل مع الإيقاف التدريجي

يمكن أن يؤدي إيقاف خادم gRPC بشكل مفاجئ إلى طلبات معالجة نصف مكتملة، واتصالات مكسورة، وعدم اتساق في البيانات. يتضمن الإيقاف التدريجي إيقاف قبول طلبات RPC الجديدة، وتصريف الاتصالات الحالية، ثم إيقاف المستمع.

توفر المكتبة القياسية في Go os/signal للتعامل مع إشارات نظام التشغيل مثل SIGINT (Ctrl+C) و SIGTERM (يستخدمه Kubernetes). ومع ذلك، غالباً ما يعاني تدفق الإيقاف القياسي من حالة سباق: قد يحاول التطبيق إيقاف خدمة الصحة قبل أن يتوقف خادم gRPC تماماً، مما يؤدي إلى أخطاء أو اختناقات.

لحل هذه المشكلة، يجب علينا التأكد من إيقاف خدمة الصحة بعد أن يكون خادم gRPC الرئيسي قد انتهى من الإيقاف. إليك نمط قوي للتعامل مع ذلك:

package main

import (
    "context"
    "log"
    "net"
    "os"
    "os/signal"
    "syscall"
    "time"

    "google.golang.org/grpc"
    health "google.golang.org/grpc/health/grpc_health_v1"
    "google.golang.org/grpc/health"
)

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }

    s := grpc.NewServer()
    healthSvc := health.NewServer()
    healthSvc.SetServingStatus("", health.CheckResponse_SERVING)
    health.RegisterHealthServer(s, healthSvc)

    // بدء الخادم في روت (goroutine)
    go func() {
        if err := s.Serve(lis); err != nil {
            log.Fatalf("failed to serve: %v", err)
        }
    }()

    // إنشاء قناة للاستماع لإشارات المقاطعة
    stop := make(chan os.Signal, 1)
    signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)

    // الانتظار حتى يتم استقبال إشارة
    sig := <-stop
    log.Printf("Received signal: %v, initiating graceful shutdown...", sig)

    // إنشاء سياق مع مهلة لعملية الإيقاف
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    // 1. إيقاف قبول طلبات RPC الجديدة
    s.GracefulStop()
    
    // 2. تحديث حالة الصحة إلى NOT_SERVING على الفور
    // هذا يضمن توقف موازنات الحمل عن توجيه حركة المرور
    healthSvc.SetServingStatus("", health.CheckResponse_NOT_SERVING)
    
    // 3. إيقاف خدمة الصحة
    // ملاحظة: يجب أن يحدث هذا بعد s.GracefulStop() أو في روتين منفصل
    // لتجنب ظروف السباق.
    healthSvc.Shutdown()

    log.Println("Shutdown complete.")
}

أفضل الممارسات للإنتاج

عند تنفيذ هذه الأنماط، تذكر النقاط التالية:

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

الخاتمة

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