تصميم الرقصات مقابل التنسيق: تصميم سير العمل الموزع في الخدمات الصغيرة

في البنية المتجانسة، يكون تنفيذ معاملة تجارية معقدة - مثل تلبية طلب التجارة الإلكترونية - أمرًا مباشرًا. توجد جميع البيانات في قاعدة بيانات علائقية واحدة، مما يسمح للمطورين بتضمين عمليات كتابة قاعدة بيانات متعددة عبر المخزون والمدفوعات والشحن داخل معاملة ACID واحدة. في حالة حدوث خطأ في أي وقت، يقوم SQL ROLLBACK باستعادة تناسق النظام على الفور.

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

نظرًا لأن بروتوكولات الالتزام على مرحلتين (2PC) بطيئة ومعيقة وهشة عبر الشبكات السحابية، يجب على الأنظمة الموزعة تنسيق سير العمل بشكل غير متزامن مع الحفاظ على التناسق النهائي.

وهذا يقود مهندسي البرمجيات إلى اتخاذ قرار تصميمي أساسي: هل يجب عليك استخدام تصميم الرقصات أو التنسيق لإدارة سير عمل الخدمات الصغيرة الموزعة؟

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

تشبيه من العالم الحقيقي: Flash Mob مقابل Symphony Orchestra

لبناء نموذج عقلي بديهي لكلا النموذجين، فكر في كيفية تنسيق مجموعات من الفنانين البشريين لأفعالهم:

تشبيه تصميم الرقصات: شبكة راقصات فلاش موب

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

• عندما يكمل الراقص “أ” الشقلبة، يتعرف الراقص “ب” على تلك الإشارة البصرية ويبدأ في الدوران.
• عندما ينتهي الراقصة B من الدوران، يتقدم الراقصة C للأمام.
• السمة الرئيسية: لامركزية، ومتفاعلة، ومستقلة. يفهم كل مشارك مسؤوليته الخاصة دون توجيه مركزي.

تشبيه الأوركسترا: أوركسترا سيمفونية

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

• يشير الموصل إلى آلات الكمان عند العزف على الأوتار الناعمة.
• يشير القائد إلى الطبول للإشارة إلى ضربة الإيقاع.
• إذا فات الموسيقي إيقاعًا، يقوم قائد الأوركسترا بتنسيق تعديل الإيقاع أو الإشارة إلى التوقف المؤقت.
• السمة الرئيسية: مركزية وصريحة وموجهة بالأوامر. قائد واحد يوجه جميع المشاركين.

1. تصميم الرقصات: لامركزي ومدفوع بالأحداث

في تصميم الرقصات، تتواصل الخدمات الصغيرة الموزعة بشكل تفاعلي بدون منسق رئيسي مركزي. تنشر الخدمات أحداث المجال إلى وسيط رسائل غير متزامن (مثل Apache Kafka أو RabbitMQ أو AWS EventBridge) عندما تتغير حالتها الداخلية. تشترك الخدمات المصغرة النهائية في موضوعات الأحداث ذات الصلة وتقرر بشكل مستقل الإجراء الذي يجب اتخاذه بعد ذلك.

تدفق التجارة الإلكترونية تحت تصميم الرقصات

فكر في عملية الدفع الخاصة بالتجارة الإلكترونية باستخدام تصميم الرقصات:

1. خدمة الطلب: تتلقى طلب الخروج HTTP POST، وتكتب الأمر المعلق إلى قاعدة البيانات الخاصة بها، وترسل حدث المجال OrderCreated إلى ناقل أحداث Kafka.
2. خدمة الدفع: الاشتراك في موضوع OrderCreated. عند استلام الحدث، يقوم بخصم المبلغ من بطاقة ائتمان العميل ويصدر حدث PaymentProcessed.
3. خدمة المخزون: الاشتراك في موضوع PaymentProcessed. يقوم بحجز عناصر المستودع وإصدار حدث InventoryReserved.
4. خدمة الشحن: الاشتراك في موضوع InventoryReserved. يقوم بإنشاء ملصق شحن ويصدر حدث OrderShipped.
5. خدمة الإشعارات: اشترك في OrderShipped وأرسل بريدًا إلكترونيًا للتتبع إلى العميل.

مزايا الكوريغرافيا

• الاستقلالية العالية والاقتران السائب: لا تعلم الخدمات بوجود معالجات المراحل النهائية. خدمة الطلب تعرف فقط أنه تم إنشاء الطلب؛ لا يهم من يستهلك تلك المعلومات.
• قابلية التوسع والسرعة المستقلة: يمكن للفرق إنشاء الخدمات الصغيرة ونشرها وتوسيع نطاقها بشكل مستقل. تتطلب إضافة ميزة جديدة (على سبيل المثال، خدمة Analytics لتتبع المبيعات) الاشتراك في الأحداث الحالية دون تعديل التعليمات البرمجية الأولية.
• لا توجد نقطة فشل واحدة (SPOF): نظرًا لعدم وجود منسق سير عمل مركزي، فإن فشل خدمة غير ذات صلة لا يؤدي إلى تعطيل محرك التنفيذ بأكمله.
• الأداء العالي والإنتاجية: يتعامل البث النشري/الفرعي المستند إلى الأحداث مع حجم الأحداث الهائل بشكل غير متزامن دون زمن استجابة متزامن لحظر HTTP/gRPC.

عيوب الكوريغرافيا

• منطق سير العمل الضمني: لا يوجد موقع رمز واحد يحدد عملية الأعمال الشاملة. يتطلب فهم سير العمل بالكامل تجميع معالجات الأحداث معًا عبر قواعد تعليمات برمجية متعددة.
• مخاطر التبعية الدورية: إذا قامت الخدمات المصغرة بنشر موضوعات متداخلة والاشتراك فيها دون تصميم دقيق للموضوع، فقد تؤدي حلقات الأحداث اللانهائية إلى تعطل قوائم انتظار رسائل النظام.
• إمكانية المراقبة المعقدة والتتبع الموزع: يتطلب تتبع معاملة طلب واحد عبر 10 موضوعات للأحداث بنية تحتية قوية للتتبع الموزع (على سبيل المثال، OpenTelemetry وJaeger وW3C Trace context).
• معالجة الأخطاء الصعبة والتعويضات: إذا فشلت خدمة المخزون بعد نجاح الدفع، فيجب أن تقوم خدمة المخزون بإصدار حدث InventoryFailed. يجب أن تستمع خدمة الدفع لهذا الحدث وتقوم باسترداد تعويض الاسترداد يدويًا.

2. هندسة التنسيق: مركزية وموجهة بالأوامر

في Orchestration، تقوم خدمة المنسق المخصصة (Saga Orchestrator) بتوجيه تسلسل التنفيذ بشكل واضح. يحتفظ المنسق بجهاز حالة سير العمل، ويرسل طلبات الأوامر (عبر gRPC، أو HTTP REST، أو قوائم انتظار الأوامر المخصصة) إلى الخدمات الصغيرة العاملة، وينتظر الاستجابات، ويحدد خطوة التنفيذ التالية.

تدفق التجارة الإلكترونية تحت التنسيق

1. Order Service / Saga Orchestrator: يتلقى طلب الخروج وينشئ مثيل سير عمل OrderSagaCoordinator في الحالة ORDER_PENDING.
2. الخطوة 1 (أمر الدفع): يستدعي المنسق PaymentService.ExecutePayment(). تقوم خدمة الدفع بمعالجة الدفع وإرجاع SUCCESS.
3. الخطوة 2 (أمر الجرد): يتلقى المنسق SUCCESS ويستدعي InventoryService.ReserveStock(). تقوم خدمة المخزون بحجز المخزون وإرجاعه SUCCESS.
4. الخطوة 3 (أمر الشحن): يستدعي المنسق ShippingService.CreateShipment(). تقوم خدمة الشحن بإرجاع تفاصيل التتبع.
5. الخطوة 4 (الإكمال): يقوم المُنسق بتحديث حالة الطلب في مخزن الحالة الخاص به إلى ORDER_COMPLETED.

إذا فشل InventoryService.ReserveStock() أثناء الخطوة 2، فسيقوم المنسق بتنفيذ أوامر التراجع بشكل تسلسلي:

• يستدعي PaymentService.RefundPayment() للتراجع عن الخطوة 1.
• يقوم بتحديث حالة Saga إلى ORDER_CANCELLED.

مزايا التنسيق

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

مساوئ التنسيق

• خطر الإفراط في المركزية (“خدمة الله”): إذا قام المطورون بدفع منطق أعمال المجال إلى المُنسق، فإن الخدمات الصغيرة العاملة تخاطر بالتحول إلى “خدمات CRUD غبية”، مما يؤدي إلى إعادة إنشاء نواة متجانسة.
• اقتران واجهة برمجة التطبيقات الأكثر إحكامًا: يجب أن يكون المنسق على دراية واضحة بعقود واجهة برمجة التطبيقات ونقاط النهاية لجميع الخدمات الصغيرة المشاركة.
• عنق الزجاجة المحتمل لقابلية التوسع: يعالج المنسق المركزي ثبات الحالة لكل معاملة نشطة. تتطلب أنظمة الإنتاجية العالية واجهات خلفية للمحرك ذات حالة قابلة للتطوير أفقيًا.

3. المقارنة المعمارية الشاملة

لتقييم تصميم الرقصات مقابل التوزيع الموسيقي جنبًا إلى جنب، ضع في اعتبارك خصائصهما التشغيلية الرئيسية:

4. النهج الهجين: تصميم الرقصات الكلية + التنسيق الجزئي

نادراً ما تفرض البنية المؤسسية الحديثة خيار “الكل أو لا شيء”. وبدلاً من ذلك، تستخدم الفرق الهندسية الرائدة هندسة هجينة:

• المستوى الكلي (تصميم الرقصات): تتواصل السياقات ذات المستوى العالي (على سبيل المثال، السياق المحدود للمبيعات، والسياق المحدود لسلسلة التوريد، ودعم العملاء) باستخدام تصميم الرقصات المبني على الأحداث عبر Kafka أو NATS.
• المستوى الجزئي (التنسيق): ضمن سياق محدد محدد (على سبيل المثال، داخل سياق الدفع المحدود الذي يتعامل مع إعادة المحاولات متعددة البوابات، والتحقق من الاحتيال، وإدخالات دفتر الأستاذ)، يقوم المنسق المحلي بتنسيق تنفيذ الخدمة الدقيقة.

                  [EVENT BROKER: KAFKA]
             /              |              \
   (OrderCreated)     (PaymentSuccess)   (StockReserved)
           /                |                \
  [Order Domain]   [Payment Domain]   [Inventory Domain]
         |                  |                 |
  (Local Saga        (Local Saga       (Local Saga
  Orchestrator)      Orchestrator)     Orchestrator)

ينتج عن هذا النمط المختلط اقتران فضفاض بين تصميم الرقصات عبر حدود المجال مع الحفاظ على رؤية حالة التنسيق داخل فرق الخدمة الفردية.

5. أمثلة على كود الإنتاج

دعونا نلقي نظرة على كيفية تنفيذ كلا النموذجين في بيئات الإنتاج باستخدام Go وJava (Spring Boot).

التنفيذ المباشر: المستهلك في حدث الكوريغرافيا مقابل Saga Orchestrator

1. تصميم الرقصات في Go (مستهلك حدث كافكا)

في تصميم الرقصات، تستمع خدمة الجرد بشكل تفاعلي إلى PaymentProcessedEvent من كافكا:

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"

	"github.com/segmentio/kafka-go"
)

type PaymentProcessedEvent struct {
	OrderID string  `json:"order_id"`
	Amount  float64 `json:"amount"`
	Status  string  `json:"status"`
}

type InventoryReservedEvent struct {
	OrderID string `json:"order_id"`
	Status  string `json:"status"`
}

func main() {
	reader := kafka.NewReader(kafka.ReaderConfig{
		Brokers: []string{"localhost:9092"},
		Topic:   "payment-events",
		GroupID: "inventory-service-group",
	})
	defer reader.Close()

	writer := kafka.NewWriter(kafka.WriterConfig{
		Brokers: []string{"localhost:9092"},
		Topic:   "inventory-events",
	})
	defer writer.Close()

	fmt.Println("Inventory Service listening for payment events...")

	for {
		msg, err := reader.ReadMessage(context.Background())
		if err != nil {
			log.Fatalf("Error reading message: %v", err)
		}

		var event PaymentProcessedEvent
		if err := json.Unmarshal(msg.Value, &event); err != nil {
			log.Printf("Invalid message payload: %v", err)
			continue
		}

		if event.Status == "SUCCESS" {
			log.Printf("[Choreography] Reserved stock for Order: %s", event.OrderID)
			
			// Publish downstream domain event reactively
			resEvent := InventoryReservedEvent{
				OrderID: event.OrderID,
				Status:  "RESERVED",
			}
			payload, _ := json.Marshal(resEvent)
			
			err = writer.WriteMessages(context.Background(), kafka.Message{
				Key:   []byte(event.OrderID),
				Value: payload,
			})
			if err != nil {
				log.Printf("Failed to publish inventory event: %v", err)
			}
		}
	}
}

2. التنسيق في Go (منسق آلة الدولة المركزية)

في التزامن، تقوم آلة الحالة الصريحة بتنفيذ الخطوات ومعالجة التعويضات:

package main

import (
	"context"
	"errors"
	"fmt"
	"log"
)

type OrderSagaOrchestrator struct {
	paymentClient *PaymentClient
	stockClient   *StockClient
}

func NewOrderSagaOrchestrator(p *PaymentClient, s *StockClient) *OrderSagaOrchestrator {
	return &OrderSagaOrchestrator{paymentClient: p, stockClient: s}
}

func (o *OrderSagaOrchestrator) ExecuteSaga(ctx context.Context, orderID string, amount float64) error {
	log.Printf("[Orchestrator] Starting Saga execution for Order ID: %s", orderID)

	// Step 1: Charge Payment
	if err := o.paymentClient.Charge(ctx, orderID, amount); err != nil {
		log.Printf("[Orchestrator] Payment failed for Order %s: %v", orderID, err)
		return err
	}
	log.Printf("[Orchestrator] Step 1 Complete: Payment Charged")

	// Step 2: Reserve Inventory
	if err := o.stockClient.Reserve(ctx, orderID); err != nil {
		log.Printf("[Orchestrator] Inventory reservation failed: %v. Initiating Compensation...", err)
		
		// Compensation Step: Refund Payment
		if refundErr := o.paymentClient.Refund(ctx, orderID, amount); refundErr != nil {
			log.Printf("[CRITICAL] Compensation failed! Manual intervention required for Order %s", orderID)
		}
		return errors.New("saga aborted: inventory unavailable")
	}

	log.Printf("[Orchestrator] Saga Completed Successfully for Order ID: %s", orderID)
	return nil
}

type PaymentClient struct{}
func (p *PaymentClient) Charge(ctx context.Context, id string, amt float64) error { return nil }
func (p *PaymentClient) Refund(ctx context.Context, id string, amt float64) error { return nil }

type StockClient struct{}
func (s *StockClient) Reserve(ctx context.Context, id string) error { return errors.New("out of stock") }

func main() {
	saga := NewOrderSagaOrchestrator(&PaymentClient{}, &StockClient{})
	_ = saga.ExecuteSaga(context.Background(), "ORD-9982", 149.99)
}

تنفيذ جافا (التمهيد الربيعي).

1. تصميم الرقصات بلغة Java (Spring Cloud Stream / Kafka Lister)

package com.ghaznix.microservices.choreography;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.function.Function;

public record PaymentProcessedEvent(String orderId, String status, double amount) {}
public record InventoryReservedEvent(String orderId, String status) {}

@Configuration
public class InventoryChoreographyProcessor {

    @Bean
    public Function<PaymentProcessedEvent, InventoryReservedEvent> processPaymentEvent() {
        return paymentEvent -> {
            System.out.println("[Choreography Java] Processing payment event for order: " + paymentEvent.orderId());

            if ("SUCCESS".equals(paymentEvent.status())) {
                // Reserve stock in database...
                System.out.println("[Choreography Java] Reserved inventory for: " + paymentEvent.orderId());
                return new InventoryReservedEvent(paymentEvent.orderId(), "SUCCESS");
            } else {
                return new InventoryReservedEvent(paymentEvent.orderId(), "FAILED");
            }
        };
    }
}

2. التنسيق في Java (منسق الحالة التعريفية)

package com.ghaznix.microservices.orchestration;

import org.springframework.stereotype.Service;

@Service
public class OrderSagaOrchestratorService {

    private final PaymentServiceClient paymentClient;
    private final InventoryServiceClient inventoryClient;
    private final ShippingServiceClient shippingClient;

    public OrderSagaOrchestratorService(PaymentServiceClient p, InventoryServiceClient i, ShippingServiceClient s) {
        this.paymentClient = p;
        this.inventoryClient = i;
        this.shippingClient = s;
    }

    public boolean processCheckoutSaga(String orderId, double totalAmount) {
        System.out.println("[Orchestrator Java] Initiating Saga Workflow for Order: " + orderId);

        // Step 1: Execute Payment
        boolean paymentSuccess = paymentClient.processPayment(orderId, totalAmount);
        if (!paymentSuccess) {
            System.err.println("[Orchestrator Java] Step 1 Failed: Aborting Saga.");
            return false;
        }

        // Step 2: Reserve Inventory
        boolean inventorySuccess = inventoryClient.reserveStock(orderId);
        if (!inventorySuccess) {
            System.err.println("[Orchestrator Java] Step 2 Failed: Triggering Compensation.");
            paymentClient.refundPayment(orderId, totalAmount);
            return false;
        }

        // Step 3: Trigger Shipping
        boolean shippingSuccess = shippingClient.createShipment(orderId);
        if (!shippingSuccess) {
            System.err.println("[Orchestrator Java] Step 3 Failed: Compensating Step 2 & Step 1.");
            inventoryClient.releaseStock(orderId);
            paymentClient.refundPayment(orderId, totalAmount);
            return false;
        }

        System.out.println("[Orchestrator Java] Saga Executed Successfully.");
        return true;
    }
}

6. المشهد العام لأدوات الصناعة

اعتمادًا على الاتجاه المعماري الذي تختاره، يوفر النظام البيئي السحابي مفتوح المصدر محركات بنية تحتية مخصصة:

النظام البيئي الكوريغرافيا

• تدفق الرسائل: Apache Kafka، وApache Pulsar، وRabbitMQ، وNATS JetStream.
• موجهات الأحداث السحابية: AWS EventBridge، وAzure Event Grid، وGoogle Cloud Eventarc.
• سجلات المخططات: سجل المخططات المتموجة (لإدارة Avro/Protobuf).

النظام البيئي المنسق

• محركات التعليمات البرمجية لسير العمل: Temporal.io (محرك التنفيذ الدائم Go/Java/TypeScript)، Cadence.
• المنسقون المُدارون عبر السحابة: وظائف AWS Step، وتطبيقات Azure Logic، وسير عمل GCP.
• BPMN ومحركات Enterprise: Camunda 8 (Zeebe)، موصل Netflix.

7. مصفوفة القرار: كيف تختار؟

عند الاختيار بين تصميم الرقصات والتنسيق لمنصة الخدمات الصغيرة الخاصة بك، استخدم مصفوفة قاعدة القرار هذه:

                              [Start: System Architecture Assessment]
                                                |
                              Is the workflow complex with >4 steps 
                              or strict business auditing rules?
                                           /         \
                                     (YES)             (NO)
                                     /                   \
               [Choose: Saga Orchestration]    Does the system require 
               (e.g., Temporal / Camunda)      ultra-high event streaming velocity?
                                                   /              \
                                             (YES)                  (NO)
                                             /                        \
                            [Choose: Event Choreography]      [Choose: Simple Choreography]
                            (e.g., Apache Kafka / NATS)       (e.g., RabbitMQ Pub/Sub)

اختر تصميم الرقصات إذا:

1. يتكون سير عملك من 2-4 خطوات خطية بسيطة.
2. تعتبر الإنتاجية العالية لتدفق الأحداث وزمن الوصول للتسليم أقل من مللي ثانية من أهم الأولويات.
3. يتم تنظيم فريقك الهندسي في فرق مجال مستقلة تقوم ببناء الخدمات ونشرها بشكل مستقل.
4. أنت تمتلك بالفعل أدوات قوية للتتبع الموزع وأدوات APM (OpenTelemetry، Datadog).

اختر التنسيق إذا:

1. تتضمن عمليات عملك تحولات حالة معقدة، أو منطقًا شرطيًا متعدد الفروع، أو تأخيرات زمنية (على سبيل المثال، “انتظر 3 أيام للحصول على موافقة العميل”).
2. تتطلب متطلبات الامتثال والتدقيق الخاصة بك وجود سجل مركزي للحالة الدقيقة لكل معاملة.
3. أنت بحاجة إلى عمليات التراجع عن التعويض القوية والآلية للخطوات الفاشلة دون كتابة منطق تسلسل الأحداث المخصص.
4. أنت تدير المعاملات المالية للمؤسسة (مثل المعاملات المصرفية ومعالجة مطالبات التأمين).

خاتمة

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

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