رقص در مقابل ارکستراسیون: طراحی گردش کار توزیع شده در میکروسرویس ها

در یک معماری یکپارچه، اجرای یک معامله تجاری پیچیده - مانند انجام یک سفارش تجارت الکترونیک - ساده است. همه داده ها در یک پایگاه داده رابطه ای واحد قرار دارند و به توسعه دهندگان این امکان را می دهند که چندین نوشته پایگاه داده را در بین موجودی، پرداخت ها و حمل و نقل در یک تراکنش ACID قرار دهند. اگر در هر نقطه ای خطایی رخ دهد، یک SQL ROLLBACK فورا سازگاری سیستم را بازیابی می کند.

با این حال، سیستم‌های بومی ابری مدرن از معماری میکروسرویس‌ها استفاده می‌کنند، که در آن هر سرویس دارای داده‌های خود است و مرزهای API متمایز را نشان می‌دهد. در این پارادایم توزیع شده، یک عملیات تجاری سرتاسری، چندین میکروسرویس مستقل و موتورهای پایگاه داده را در بر می گیرد.

از آنجایی که پروتکل‌های تعهد دو فازی (2PC) در شبکه‌های ابری کند، مسدودکننده و شکننده هستند، سیستم‌های توزیع‌شده باید جریان‌های کاری را به صورت ناهمزمان هماهنگ کنند و در عین حال ثبات نهایی را حفظ کنند.

این امر معماران نرم‌افزار را به یک تصمیم اساسی برای طراحی می‌رساند: ** آیا باید از رقص یا ارکستراسیون برای مدیریت گردش‌های کاری میکروسرویس توزیع شده استفاده کنید؟**

در این راهنمای جامع، هر دو الگوی معماری را تجزیه می‌کنیم، قیاس‌های دنیای واقعی را بررسی می‌کنیم، معاوضه‌های معماری را تجزیه و تحلیل می‌کنیم، پیاده‌سازی کد تولید جزئیات در Go و Java، و ایجاد چارچوبی برای انتخاب الگوی مناسب برای زیرساخت شما.

قیاس دنیای واقعی: فلش موب در مقابل ارکستر سمفونیک

برای ایجاد یک مدل ذهنی شهودی برای هر دو الگو، در نظر بگیرید که چگونه گروه‌های مجری انسانی اعمال خود را هماهنگ می‌کنند:

تشبیه رقص: شبکه رقصندگان فلش موب

گروهی از رقصندگان خیابانی حرفه ای را تصور کنید که در حال اجرای برنامه فلش ماب هستند. هیچ مربی روی صحنه ایستاده نیست که به تک تک رقصندگان اشاره کند تا حرکت بعدی آنها را فرمان دهد. در عوض، هر رقصنده به آهنگ مرکزی موسیقی گوش می دهد و به حرکات رقصنده در کنار آنها واکنش پویا نشان می دهد.

• وقتی رقصنده A یک تلنگر را کامل می کند، رقصنده B آن نشانه بصری را تشخیص می دهد و شروع به چرخیدن می کند.
• وقتی رقصنده B چرخیدن را تمام می کند، رقصنده C جلو می رود.
• ویژگی کلیدی: غیرمتمرکز، واکنشی و مستقل. هر شرکت کننده مسئولیت خود را بدون جهت گیری مرکزی درک می کند.

تشبیه ارکستراسیون: یک ارکستر سمفونیک

حالا یک ارکستر سمفونیک کلاسیک 70 قطعه ای را تصور کنید. نوازندگان ویولن، سازهای کوبه‌ای و ویولن سل با تماشای دست‌های یکدیگر در سراسر صحنه، نشانه نمی‌گیرند. در عوض، همه مستقیماً به ** هادی ** نگاه می کنند.

• هادی به ویولن ها علامت می دهد که چه زمانی تارهای نرم بنوازند.
• هادی به درام اشاره می کند تا نشانه ضربه کوبه ای باشد.
• اگر یک نوازنده یک سرعت را از دست بدهد، رهبر تنظیم سرعت را هماهنگ می کند یا سیگنال مکث می دهد.
• ویژگی کلیدی: متمرکز، صریح و فرمان محور. یک رهبر واحد همه شرکت کنندگان را هدایت می کند.

1. معماری رقص: غیرمتمرکز و رویداد محور

در رقص، میکروسرویس های توزیع شده به صورت واکنشی بدون هماهنگ کننده اصلی مرکزی ارتباط برقرار می کنند. سرویس‌ها رویدادهای دامنه را برای یک واسطه پیام ناهمزمان (مانند Apache Kafka، RabbitMQ یا AWS EventBridge) هر زمان که وضعیت داخلی آنها تغییر کند، منتشر می‌کنند. ریزسرویس‌های پایین‌دست در موضوعات رویدادهای مرتبط مشترک می‌شوند و به‌طور مستقل تصمیم می‌گیرند که در آینده چه اقدامی انجام دهند.

جریان تجارت الکترونیک تحت رقص

فرآیند پرداخت تجارت الکترونیک را با استفاده از رقص در نظر بگیرید:

1. سرویس سفارش: درخواست پرداخت HTTP POST را دریافت می کند، سفارش در حال انتظار را در پایگاه داده خود می نویسد و یک رویداد دامنه OrderCreated را به گذرگاه رویداد کافکا ارسال می کند.
2. خدمات پرداخت: در مبحث OrderCreated مشترک می شود. پس از دریافت رویداد، کارت اعتباری مشتری را شارژ می کند و یک رویداد PaymentProcessed را منتشر می کند.
3. سرویس موجودی: در مبحث PaymentProcessed مشترک می شود. اقلام انبار را رزرو می کند و یک رویداد InventoryReserved را منتشر می کند.
4. خدمات حمل و نقل: در مبحث InventoryReserved مشترک می شود. این یک برچسب حمل و نقل ایجاد می کند و یک رویداد OrderShipped را منتشر می کند.
5. خدمات اطلاع رسانی: در OrderShipped مشترک می شود و یک ایمیل پیگیری برای مشتری ارسال می کند.

مزایای رقص

• اتحادیه بالا و اتصال شل: سرویس ها از وجود کنترل کننده های پایین دست اطلاعی ندارند. سرویس سفارش فقط می داند که یک سفارش ایجاد شده است. مهم نیست چه کسی آن اطلاعات را مصرف می کند.
• ** مقیاس پذیری و سرعت مستقل **: تیم ها می توانند میکروسرویس ها را به طور مستقل بسازند، مستقر کنند و مقیاس کنند. افزودن یک ویژگی جدید (به عنوان مثال، سرویس تجزیه و تحلیل ردیابی فروش) مستلزم اشتراک در رویدادهای موجود بدون تغییر کد بالادستی است.
• بدون نقطه شکست (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 گنگ” هستند که هسته ای یکپارچه را بازسازی می کنند.
• اتصال API فشرده: ارکستراتور باید به صراحت از قراردادهای API و نقاط پایانی همه ریزسرویس های شرکت کننده آگاه باشد.
• ** گلوگاه مقیاس پذیری بالقوه **: ارکستراتور مرکزی تداوم حالت را برای هر تراکنش فعال کنترل می کند. سیستم‌های توان عملیاتی بالا به پشتوانه‌های موتور حالت قابل مقیاس‌پذیری افقی نیاز دارند.

3. مقایسه جامع معماری

برای ارزیابی رقص در مقابل ارکستراسیون در کنار یکدیگر، ویژگی های عملیاتی کلیدی آنها را در نظر بگیرید:

4. رویکرد ترکیبی: رقص ماکرو + ارکستراسیون میکرو

معماری سازمانی مدرن به ندرت انتخاب همه یا هیچ را مجبور می کند. در عوض، تیم های مهندسی پیشرو از معماری ترکیبی ** استفاده می کنند:

• سطح کلان (رقص): زمینه های محدود سطح بالا (به عنوان مثال، زمینه محدود فروش، زمینه محدود زنجیره تامین، پشتیبانی مشتری) با استفاده از رقص رقص محور رویداد از طریق کافکا یا 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) بررسی کنیم.

برو پیاده سازی: رویداد رقص مصرف کننده در مقابل ارکستراتور ساگا

1. رقص در گو (مصرف کننده رویداد کافکا)

در رقص، سرویس Inventory به صورت واکنشی به 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)
}

پیاده سازی جاوا (Spring Boot).

1. رقص در جاوا (Spring Cloud Stream / Kafka Listener)

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. ارکستراسیون در جاوا (هماهنگ کننده حالت اعلامی)

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. چشم انداز محبوب صنعت ابزار

بسته به اینکه کدام جهت معماری را انتخاب می کنید، اکوسیستم منبع باز و ابر موتورهای زیرساخت اختصاصی را ارائه می دهد:

اکوسیستم رقص

• جریان پیام: آپاچی کافکا، آپاچی پالسار، RabbitMQ، NATS JetStream.
• روترهای رویداد Cloud: AWS EventBridge، Azure Event Grid، Google Cloud Eventarc.
• ** ثبت طرحواره**: ثبت طرحواره متجانس (برای حاکمیت Avro/Protobuf).

اکوسیستم ارکستراسیون

• موتورهای کد گردش کار: Temporal.io (موتور اجرای بادوام Go/Java/TypeScript)، Cadence.
• ** هماهنگ کننده های مدیریت شده در ابر**: توابع مرحله AWS، برنامه های منطقی Azure، گردش های کاری GCP.
• BPMN & Enterprise Engines: Camunda 8 (Zeebe)، رهبر نتفلیکس.

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. شما تراکنش‌های مالی شرکت را مدیریت می‌کنید (به عنوان مثال، بانکداری، پردازش ادعای بیمه).

نتیجه گیری

نه رقص و نه ارکستراسیون برتری جهانی ندارند. رقص رقص اتصال شل، توان عملیاتی رویداد و استقلال سرویس را به قیمت دید ضمنی جریان کار و ردیابی پیچیده توزیع شده به حداکثر می رساند. Orchestration مدیریت وضعیت صریح، قابلیت حسابرسی متمرکز، و بازیابی قطعی شکست را به هزینه جفت API سخت‌تر و مدیریت زیرساخت ارکستر ارائه می‌کند.

با درک نقاط قوت هر دو الگو - و استفاده از رقص ماکرو ترکیبی با میکرو ارکستراسیون در صورت لزوم- می توانید معماری های میکروسرویس انعطاف پذیر و مقیاس پذیری بسازید که تراکنش های توزیع شده را در محیط های ابری به خوبی مدیریت می کند.