مقیاس‌پذیری نرم‌افزار با مدل Virtual Actor در سیستم‌های توزیع‌شده

آیا تا به حال به این فکر کرده‌اید که چگونه می‌توان یک نرم‌افزار پیچیده و توزیع‌شده را به شکلی ساده، سریع و مقیاس‌پذیر طراحی کرد؟
اگر با مفاهیمی مثل مدل بازیگر در نرم‌افزار، بازیگر مجازی (Virtual Actor) یا فریم‌ورک‌هایی مثل Proto.Actor آشنایی دارید یا می‌خواهید درک عمیق‌تری از آن‌ها پیدا کنید، این مقاله برای شما نوشته شده است.

امروزه بسیاری از سازمان‌ها برای ساخت سامانه‌هایی با معماری پیشرفته، به سمت استفاده از مدل بازیگر (Actor Model) در سیستم‌های خود حرکت کرده‌اند. به‌ویژه در زمینه‌هایی مانند توسعه نرم‌افزار مقیاس‌پذیر، پردازش بلادرنگ و سیستم‌های توزیع‌شده، استفاده از مدل بازیگر یک رویکرد قدرتمند و عملیاتی است. در این مقاله، با تمرکز بر مفاهیم کلیدی، مثال‌های واقعی و معرفی ابزارهایی مانند Proto.Actor، به بررسی این مدل جذاب می‌پردازیم.

در گذشته، بسیاری از برنامه‌ها بدون نیاز به مقیاس‌پذیری برای حجم‌های زیاد داده توسعه می‌یافتند. این وضعیت، فرآیند برنامه‌نویسی را نسبتاً ساده می‌کرد. کافی بود از یک مدل ساده‌ی شی‌گرا (Object-Oriented) استفاده کرده و داده‌ها را مستقیماً در حافظه پردازش کنید.

اما امروز، مقیاس‌پذیری و پردازش حجم عظیمی از داده‌ها—به‌خصوص در راهکارهای اینترنت اشیاء (IoT)—به عناصر کلیدی در عملکرد برنامه‌ها و همچنین مزیت رقابتی استراتژیک آن‌ها تبدیل شده‌اند.

مقیاس‌پذیری حالا خودش یک چالش واقعی است—و با خود، لایه‌ی کاملاً جدیدی از پیچیدگی را به همراه می‌آورد. در بسیاری از موارد، پشته‌ی فناوری (Tech Stack) مورد استفاده آن‌قدر پیچیده می‌شود که دیگر برای تیم‌های کوچک توسعه‌دهنده قابل مدیریت نیست.

آیا می‌توان مقیاس‌پذیر شد بدون اینکه سادگی برنامه‌نویسی را فدا کرد؟

با این حال، ممکن است راهی وجود داشته باشد تا بتوان در عین حفظ مدل برنامه‌نویسی ساده و رویدادمحور (event-driven)، برنامه را روی چند رشته (multi-threaded) و حتی چند ماشین (multi-machine) اجرا کرد.

و همه‌ی این‌ها در همان محیط آشنا و دلخواه برنامه‌نویسی که به آن عادت دارید!

اجازه دهید شما را با مفهومی آشنا کنم که این کار را ممکن می‌سازد:
مدل بازیگرهای مجازی (Virtual Actors).

مسأله چیست؟

بیایید با یک نمایش ساده شروع کنیم. نگاهی بیندازید به یک اپلیکیشن نمونه که به‌عنوان دموی فریم‌ورک Proto.Actor ساخته شده است. این برنامه، حرکت اتوبوس‌ها در شهر تهران را به‌صورت بلادرنگ (real-time) ردیابی می‌کند.

فرض کنیم می‌خواهیم اپلیکیشنی مشابه بسازیم، و این نیازها را داریم:

1. موقعیت لحظه‌ای هر اتوبوس را نمایش دهد.

2. مسیر طی‌شده‌ی اتوبوس در ۵ دقیقه گذشته را نشان دهد.

3. نقشه را به‌صورت بلادرنگ (real-time) به‌روزرسانی کند، ولی فقط بخش‌هایی که برای کاربر قابل مشاهده هستند.

4. موقعیت اتوبوس‌هایی که خارج از دید کاربر هستند، اصلاً از طریق شبکه منتقل نشود.

تا اینجا چیز پیچیده‌ای نداریم. اما بیایید کمی چالش‌برانگیزترش کنیم و نیازهای زمانی و مکانی بیشتری اضافه کنیم:

• اگر یک اتوبوس بیش از ۱۰ دقیقه در جایی متوقف شده باشد و درب‌های آن بسته باشد، برای کاربر نوتیفیکیشن ارسال شود.

• سازمان صاحب اتوبوس‌ها می‌تواند محدوده‌های جغرافیایی (Geofence) تعریف کند. هر زمان که یک اتوبوس وارد یا خارج از این محدوده شد، به کاربر اطلاع داده شود.

شاید بگویید که تهران با بیش از ۴۰۰۰ وسیله‌ی نقلیه‌ی عمومی فعال به‌صورت هم‌زمان، خیلی مقیاس بزرگی نیست. پس بیایید سناریو را بزرگ‌تر کنیم:

برنامه باید قابلیت مقیاس‌پذیری برای تمام شهرهای بزرگ ایران را داشته باشد.

حالا سؤال اینجاست:

چگونه می‌توان اپلیکیشنی با چنین نیازهایی طراحی کرد؟

رویکرد سنتی

برای حل این مسئله، روش‌های متعددی وجود دارد. یکی از آن‌ها به‌صورت زیر است:

در این رویکرد سنتی، با مشکلات متعددی مواجه هستیم:

• در این مدل، هیچ تطابقی با دنیای واقعی وجود ندارد. نه مفهومی به نام "اتوبوس" داریم، نه "سازمان‌ها". در عوض، فقط با "جریان موقعیت‌ها (stream of positions)" سروکار داریم که باید پردازش شود.

• برای پردازش داده‌ها، باید روی پایگاه‌داده‌ی موقعیت‌ها، کوئری‌های سنگین و هزینه‌بر اجرا کنیم—و البته باید آن‌ها را کش (cache) کنیم تا عملکرد بهتری داشته باشیم.

• باید به مقیاس‌پذیری پایگاه‌داده نیز فکر کنیم: چگونه آن را توزیع کنیم؟ چگونه بار ترافیک را تقسیم کنیم؟

• باید تاخیر شبکه و پیچیدگی‌های ارتباطات توزیع‌شده را در طراحی در نظر بگیریم.

• با مشکلات همروندی (concurrency) دست‌و‌پنجه نرم می‌کنیم. اگر دو عملیات همزمان روی یک موقعیت اعمال شود چه؟ چه کسی مسئول هماهنگی است؟

• باید از یک پشته‌ی فناوری (tech stack) مقاوم و پیچیده استفاده کنیم—که البته این هم به توسعه‌دهندگانی با مهارت‌های گسترده و متنوع نیاز دارد.

در کل، این معماری به‌مراتب پیچیده‌تر از چیزی است که برای این مسئله‌ی نسبتاً ساده لازم است. پیچیدگی موجود، ناشی از نیاز به مقیاس‌پذیری است.

آیا راه ساده‌تری وجود دارد؟

قطعاً خیلی خوب می‌شد اگر می‌توانستیم همه‌ی مفاهیم دنیای واقعی را به‌عنوان اشیاء (objects) در یک اپلیکیشن واحد مدل کنیم، و تمام الگوریتم‌ها را مستقیماً در حافظه اجرا کنیم.

در این مدل، ما هر اتوبوس، سازمان، و محدوده‌ی قابل‌مشاهده روی نقشه (viewport) را به‌عنوان یک شیء منحصربه‌فرد در نظر می‌گیریم و تعامل بین آن‌ها را نیز به‌شکل شی‌گرا مدل‌سازی می‌کنیم.

هر شیء دارای وضعیت داخلی (state) است، و می‌تواند آن را در واکنش به سیگنال‌هایی از دنیای بیرون یا سایر اشیاء، تغییر دهد.

نتیجه چیست؟
این برنامه بسیار آسان‌تر برای ساخت است نسبت به معماری سنتی قبلی، و به‌مراتب قابل‌فهم‌تر برای توسعه‌دهندگان.

اما آیا چنین اپلیکیشن شی‌گرایی واقعاً مقیاس‌پذیر است؟

ایرادی که می‌توان وارد کرد این است که:

یک برنامه‌ی شی‌گرا و ساده، احتمالاً طبق نیاز ما قابل مقیاس‌پذیری نیست.

ما نمی‌توانیم همه‌ی این اشیاء را روی یک ماشین واحد جای دهیم.
و از طرفی راهی برای گسترش آن به چند ماشین هم وجود ندارد—حداقل نه در معماری شی‌گرای سنتی.

یه جور دیگه بزار بگم:

"ای کاش می‌شد همه چیز رو مثل دنیای واقعی، به‌صورت شی‌ء (object) در نظر بگیریم. هر اتوبوس، هر سازمان، هر محدوده‌ی نقشه → یک object مجزا، با وضعیت خاص خودش."

و بعد، تمام منطق برنامه (مثل بررسی توقف ۱۰ دقیقه‌ای، عبور از geofence و...) رو داخل حافظه اجرا کنیم.

نتیجه‌اش چی می‌شه؟

برنامه ساده‌تر نوشته می‌شه

راحت‌تر فهمیده می‌شه

کمتر نیاز به هماهنگی بین اجزاء پیچیده داره

🛑 اما مشکل کجاست؟

مشکل اینه که:

این مدل ساده فقط روی یک ماشین جواب می‌ده و اگر بخوای ده‌ها هزار شیء (اتوبوس و...) رو همزمان مدیریت کنی، حافظه و پردازنده‌ی یک سیستم جواب نمی‌ده.

از طرف دیگه، معماری شی‌گرا به‌صورت سنتی، برای توزیع روی چند ماشین طراحی نشده.

پاسخ: بله، راهی وجود دارد—"بازیگرهای مجازی" (Virtual Actors)

مدلی به نام بازیگران مجازی (Virtual Actors)—که گاهی با نام "غله‌ها" (Grains) نیز شناخته می‌شوند—این امکان را فراهم می‌کنند که:

• مدل شی‌گرای ساده‌ی شما همچنان حفظ شود

• در عین حال بتوان آن را به خوشه‌های بزرگی از ماشین‌ها گسترش داد

• به‌طوری که هر ماشین، بخشی از اشیاء یا بازیگران را مدیریت کند

این یعنی می‌توانیم سادگی مدل برنامه‌نویسی شی‌گرا را با مقیاس‌پذیری افقی واقعی ترکیب کنیم—بدون پیچیدگی‌های معماری مرسوم!

یعنی اینجوری بگم که:

این مدل به ما اجازه می‌ده که:

همون سبک ساده‌ی شی‌گرا رو حفظ کنیم

اما اشیاء (اتوبوس‌ها، سازمان‌ها، و...) در پشت صحنه روی چندین سرور پخش (توزیع) بشن

هر سرور، فقط بخشی از اشیاء رو نگه‌داری و مدیریت می‌کنه

و ما به‌عنوان توسعه‌دهنده، نیازی نداریم بدونیم شیء موردنظر کجاست یا کی بارگذاری می‌شه—همه چیز اتوماتیکه

مدل بازیگر (Actor Model)

بیایید ابتدا در مورد بازیگرهای معمولی و مدل اصلی Actor که در سال ۱۹۷۳ معرفی شد صحبت کنیم.
این مدل به‌عنوان یک «مدل ریاضی برای محاسبات همروند (concurrent computation)» تعریف شده است،
اما اجازه بده ساده‌تر توضیحش دهیم.

🎭 بازیگر چیست؟

یک Actor را مثل یک شیء تصور کن که:

• پیام‌ها را از یک صف (Queue) دریافت می‌کند

• یک وضعیت داخلی (In-Memory State) در حافظه نگه می‌دارد

مثلاً:

• بازیگر اتوبوس (BusActor) می‌تواند تاریخچه‌ی موقعیت‌های اخیر یک اتوبوس را در خودش ذخیره کند.

• بازیگر Geofence می‌تواند لیستی از اتوبوس‌هایی که در محدوده‌ی خاصی قرار دارند را نگه دارد.

هر پیام جدیدی که دریافت می‌شود ممکن است این وضعیت را تغییر دهد (mutate).
و چون همه چیز در حافظه اتفاق می‌افتد، این کار بسیار سریع‌تر از تعامل با دیتابیس انجام می‌شود.

بعضی بازیگرها حتی می‌توانند روی دنیای بیرون اثر بگذارند (مثلاً چیزی در کنسول چاپ کنند، نوتیف بفرستند، یا به سیستم خارجی پاسخ دهند).

وضعیت اجرا چگونه است؟

• پیام‌ها یکی‌یکی پردازش می‌شوند، آن هم روی یک Thread.

• وضعیت داخلی Actor فقط برای خودش است و از بیرون غیرقابل دسترسی.

• بنابراین:

  • هیچ مشکل همروندی (Concurrency) نداریم.

  • کدها ساده‌تر، قابل تست‌تر و بدون نیاز به قفل‌گذاری هستند.

آیا این مدل واقعاً مقیاس‌پذیر است؟

با وجود اینکه هر Actor فقط روی یک Thread اجرا می‌شود،
پاسخ بله است.

با ایجاد تعداد زیادی Actor و اجرای همزمان آن‌ها، می‌توانید به موازی‌سازی (Massive Parallelism) برسید.

مثلاً:
برای هر اتوبوس در شهر تهران، یک بازیگر جداگانه داشته باشید.
این بازیگرها می‌توانند با هم کار کنند، بدون اینکه به وضعیت همدیگر دست بزنند.

این چیزهایی که گفتیم خیلی انتزاعی بود، بگذارید یک نگاهی به کد داشته باشیم:

public class HelloActor : IActor
{

    public Task ReceiveAsync(IContext context)

    {

        if (context.Message is Hello helloMsg)

            Console.WriteLine($"Hello {helloMsg.Who}");

        return Task.CompletedTask;

    }

}

توضیح کد

public class HelloActor : IActor

• تعریف یک Actor با نام HelloActor

• این کلاس از اینترفیس IActor پیروی می‌کند که نشان می‌دهد این کلاس می‌تواند پیام دریافت و پردازش کند.

public Task ReceiveAsync(IContext context)

• متدی که در زمان دریافت پیام، توسط سیستم فریم‌ورک Proto.Actor فراخوانی می‌شود.

• آرگومان context اطلاعات مربوط به پیام و وضعیت فعلی بازیگر را در خود دارد.

if (context.Message is Hello helloMsg)

• بررسی می‌کند که آیا پیام دریافتی از نوع Hello است یا نه.

• اگر بود، آن را به متغیر helloMsg تبدیل می‌کند که به داده‌های داخلش دسترسی داریم.

Console.WriteLine($"Hello {helloMsg.Who}");

• خروجی چاپ می‌کند به صورت:

Hello <نام ارسال‌کننده>

• مثلاً اگر Who = "Ali" باشد، خروجی می‌شود:
  Hello Ali

return Task.CompletedTask;

• نشان می‌دهد که بازیگر بعد از دریافت و پردازش این پیام، کاری ندارد.

• این متد باید Task برگرداند، و CompletedTask یعنی عملیات تموم شده.

کاربرد در واقعیت چیه؟

این کد می‌تونه بخشی از یک سیستم بزرگ باشه که در آن، بازیگرها به عنوان موجودیت‌هایی مستقل، هر کدام فقط مسئول یک نوع خاص از رفتار هستند—در اینجا مثلاً بازیگر سلام‌دهنده.

حالا کد بعدی رو هم نگاه کنیم:

public class BusActor : IActor
{
    List<Position> _positionHistory = new();

    public Task ReceiveAsync(IContext context)
    {
        switch (context.Message)
        {
            case Position position:
                _positionHistory = _positionHistory
                    .Where(p => DateTimeOffset.UtcNow - p.Timestamp < TimeSpan.FromMinutes(5))
                    .ToList();

                _positionHistory.Add(position);
                break;

            case GetPositionsHistoryRequest:
                context.Respond(new PositionBatch { Positions = _positionHistory });
                break;
        }

        return Task.CompletedTask;
    }
}

توضیح BusActor

public class BusActor : IActor

• تعریف یک کلاس Actor به نام BusActor

• از رابط IActor پیروی می‌کند، یعنی یک Actor استاندارد در Proto.Actor است

List<Position> _positionHistory = new();

• تعریف یک لیست از نوع Position برای نگه‌داری تاریخچه‌ی موقعیت‌های اتوبوس

• این لیست فقط آخرین ۵ دقیقه‌ی موقعیت‌ها را ذخیره می‌کند

• مثل حافظه‌ی داخلی یک GPS که فقط حرکات اخیر را نگه می‌دارد

public Task ReceiveAsync(IContext context)

• متدی که در زمان دریافت پیام، اجرا می‌شود

• context.Message حاوی پیام دریافتی است

• با استفاده از switch نوع پیام بررسی می‌شود

حالت اول: دریافت موقعیت جدید

case Position position:

اگر پیام دریافتی از نوع Position بود:

_positionHistory = _positionHistory
    .Where(p => DateTimeOffset.UtcNow - p.Timestamp < TimeSpan.FromMinutes(5))
    .ToList();

• این خط، فیلتر می‌کند که فقط موقعیت‌هایی که در ۵ دقیقه‌ی گذشته ثبت شده‌اند باقی بمانند

• موقعیت‌های قدیمی‌تر از لیست حذف می‌شوند.

_positionHistory.Add(position);

• موقعیت جدید دریافتی به لیست اضافه می‌شود

حالت دوم: درخواست برای دریافت تاریخچه موقعیت‌ها

case GetPositionsHistoryRequest:
    context.Respond(new PositionBatch { Positions = _positionHistory });
    break;

• اگر پیام دریافتی از نوع GetPositionsHistoryRequest بود:

  • Actor به درخواست پاسخ می‌دهد

  • پاسخ شامل شیئی از نوع PositionBatch است که شامل کل تاریخچه موقعیت‌هاست

return Task.CompletedTask;

• این متد async است و باید یک Task برگرداند

• چون عملیات ما ساده و کوتاه است، یک CompletedTask کفایت می‌کند

جمع‌بندی کارکرد کلی BusActor به صورت متنی

• وقتی یک پیام موقعیت جدید (Position) دریافت می‌شود، بازیگر لیست موقعیت‌های قبلی را بررسی می‌کند و فقط موقعیت‌هایی که در ۵ دقیقه‌ی گذشته ثبت شده‌اند را نگه می‌دارد. سپس، موقعیت جدید را به این لیست اضافه می‌کند.

• وقتی یک پیام درخواست تاریخچه (GetPositionsHistoryRequest) دریافت می‌شود، بازیگر به آن پاسخ می‌دهد و لیست موقعیت‌های فعلی را به‌صورت یک شیء جدید از نوع PositionBatch ارسال می‌کند.

• تمام ذخیره‌سازی داده‌ها فقط در حافظه انجام می‌شود. هیچ دیتابیسی در کار نیست، بنابراین خواندن و نوشتن اطلاعات بسیار سریع انجام می‌شود.

• پردازش پیام‌ها به‌صورت تک‌ریسمانی (single-threaded) انجام می‌شود، به همین دلیل هیچ مشکلی از نوع رقابت هم‌زمانی (concurrency) وجود ندارد. این یعنی نیازی به قفل‌گذاری یا مدیریت حالت پیچیده نیست.

• هر نمونه از BusActor فقط نماینده‌ی یک اتوبوس خاص است و کاملاً ایزوله عمل می‌کند. بازیگرها به‌طور مستقل رفتار می‌کنند و وضعیت‌شان را فقط خودشان تغییر می‌دهند.

• این بازیگرها می‌توانند در سیستم‌های توزیع‌شده روی نودهای مختلف یک خوشه (cluster) توزیع شوند، بدون اینکه تغییری در کد نیاز باشد.

• این ساختار به راحتی امکان مدیریت هزاران یا حتی میلیون‌ها بازیگر (مثل اتوبوس‌های مختلف) را فراهم می‌کند، درحالی‌که معماری ساده، قابل فهم و توسعه‌پذیر باقی می‌ماند.

ماندگاری (Persistence)

در بسیاری از موارد، اینکه فقط وضعیت بازیگر (Actor) در حافظه نگه‌داری شود، قابل‌قبول نیست.
ما نیاز داریم که وضعیت بازیگر در برابر اتفاقاتی مثل ری‌استارت شدن ماشین، ارتقاء نرم‌افزار یا خاموشی‌ها، حفظ شود.

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

پاسخ: خیر، تضادی نیست. راه‌حل، ذخیره‌سازی هوشمند است.

در عمل، بسیار رایج است که وضعیت بازیگرها در نوعی ذخیره‌ساز پایدار (persistent storage) نگهداری شود.
ترجیحاً باید از دیتابیس‌هایی با عملکرد بالا استفاده شود، مثل:

• Redis

• Azure Table Storage

• Google Bigtable

اما نکته‌ی مهم اینجاست:

باید به وضعیت ذخیره‌شده، به‌چشم یک "تصویر لحظه‌ای (snapshot)" یا "بک‌آپ" نگاه کرد، نه به‌عنوان داده‌ی عملیاتی اصلی.

نحوه‌ی استفاده:

• وضعیت بازیگر فقط زمانی بارگذاری می‌شود که بازیگر برای اولین‌بار در حافظه ایجاد می‌شود.

• نیازی نیست قبل از پردازش هر پیام، دوباره داده را از دیتابیس بخوانیم (برخلاف برنامه‌های stateless معمول).

• همین ویژگی به‌تنهایی می‌تواند تا ۵۰٪ از زمان صرف‌شده برای عملیات I/O را حذف کند.

ضمناً:

وضعیت موجود در حافظه، مرجع اصلی (source of truth) است، نه فقط یک cache موقت.
بنابراین مشکلی به نام "همگام‌سازی کش (cache invalidation)" نخواهیم داشت.

نوشتن وضعیت (Write Strategy):

شما در ذخیره‌سازی وضعیت، انعطاف زیادی دارید. می‌تونید تصمیم بگیرید که:

• بعد از هر پیام، یک نسخه‌ی پشتیبان از وضعیت گرفته شود.

• یا پس از دریافت تعداد مشخصی پیام

• یا مثلاً هر چند دقیقه یک‌بار (بک‌آپ دوره‌ای)

انتخاب این روش بستگی به نیازهای برنامه‌ی شما دارد.

ارتباط (Communication)

ارتباط در مدل Actor بسیار ساده اما قدرتمند است.

شما می‌توانید از:

• کلاینت

• یا یک Actor دیگر

به یک بازیگر پیام بفرستید، صرفاً با قرار دادن پیام در صف پیام‌های آن (message queue).

این ارتباط به‌صورت ذاتی ناهمزمان (asynchronous) است.

اما بعضی فریم‌ورک‌ها این ارتباط را با استفاده از APIهایی بر پایه‌ی:

• Task در .NET

• یا Promise در JavaScript و سایر زبان‌ها

ساده‌تر می‌کنند، به‌طوری‌که می‌توانید منتظر پاسخ بمانید، بدون اینکه ساختار برنامه‌تان پیچیده شود.

در کد، ارتباط با بازیگر چطور انجام می‌شود؟

شما معمولاً یک ارجاع (handle) به بازیگر موردنظر دارید و از طریق آن پیام می‌فرستید.
مثلاً: ارسال پیام به بازیگر یک سازمان خاص.

context.Send(OrganizationActorePid, position);

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

سلسله‌مراتب بازیگرها (Actor Hierarchies)

اگه مدل بازیگر (Actor Model) رو در گوگل یا هر موتور جستجو جستجو کنی،
خیلی زود با نمودارهای پیچیده‌ای از سلسله‌مراتب بازیگرها مواجه می‌شی.

مثلاً مثل این تصویر:

چرا این نمودارها پیچیده هستند؟

در مدل سنتی Actor:

• بازیگرها می‌تونند بازیگرهای فرزند (child actors) ایجاد کنند.

• مسئولیت چرخه‌ی عمر (lifecycle) بازیگرهای فرزند به عهده‌ی والد است.

• در صورت بروز خطا در زنجیره، Actor پدر مسئول رسیدگی به خطاهاست.

• اغلب استراتژی‌های خاصی برای مدیریت خطا (مثل بازنشانی، نادیده گرفتن یا جایگزینی) اعمال می‌شود.

اما:

ارتباط بین این سلسله‌مراتب‌ها، اگر روی ماشین‌های مختلف اجرا شوند، ساده و مستقیم نیست.

خبر خوب

در بسیاری از برنامه‌های واقعی و مدرن،
نیازی به این سطح از پیچیدگی وجود ندارد.

مدل ساده‌تری هم هست که همان مزایا را دارد، ولی پیچیدگی‌ها را حذف می‌کند.

ادامه مقاله: مدل بازیگرهای مجازی (Virtual Actor Model)

در بخش بعدی مقاله، وارد دنیای بازیگرهای مجازی می‌شویم—جایی که:

• نیازی به مدیریت ارجاع مستقیم به Actorها نیست

• مدیریت حافظه، ماندگاری، مقیاس‌پذیری و ساختار Actorها به‌طور کامل خودکار و ساده‌سازی شده است

بازیگرهای مجازی (Virtual Actors)

بازیگرهای مجازی یا همان Grains این‌طور فرض می‌شوند که همیشه وجود دارند.
شما هیچ‌گاه لازم نیست آن‌ها را به‌طور دستی ایجاد (create) یا حذف (destroy) کنید.

این بازیگرها ممکن است در لحظه:

• در حافظه فعال باشند،

• یا غیرفعال شده باشند (مثلاً برای صرفه‌جویی در منابع).

اما از دید کلاینتی که می‌خواهد با آن ارتباط برقرار کند، این تفاوت هیچ اهمیتی ندارد.

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

شناسایی Actor چگونه انجام می‌شود؟

در این مدل:

• نیازی به نگه‌داشتن اشاره‌گر (handle) یا ریفرنس مستقیم به Actor ندارید.

• به‌جای آن، مقصد پیام را بر اساس "نوع (type)" و "شناسه (id)" مشخص می‌کنید.

یعنی می‌گویید:

"می‌خوام با Actor نوع OrganizationActor با شناسه 42 صحبت کنم"
نه اینکه یک متغیر به‌خصوص از اون Actor رو از قبل داشته باشید.

خوشه‌بندی (Clustering)

ویژگی‌هایی که در بالا توضیح دادیم باعث می‌شن مدل Actor مجازی به‌صورت شفاف (transparent) در سراسر چندین ماشین مقیاس‌پذیر باشد.

یعنی:

• مکان Actor مهم نیست.
  تا زمانی که نوع و شناسه‌ی آن را بدانید، می‌توانید پیام بفرستید.

• فریم‌ورک به‌صورت خودکار پیام را به مکان درست مسیریابی (route) می‌کند.

• حتی اگر Actor به دلیل مثلا خاموش شدن نود، به مکان جدیدی منتقل شود (migrate)،
  کلاینت همچنان می‌تواند با آن بدون هیچ مشکلی ارتباط برقرار کند.

نتیجه این رویکرد چیست؟

این مدل، در عین اینکه ساده و قابل درک است،
انعطاف‌پذیری و قدرت بالایی در مقیاس‌پذیری و توزیع‌شدگی در اختیار شما می‌گذارد—
بدون اینکه مدل برنامه‌نویسی پیچیده شود.

ابزارها و فریم‌ورک‌ها

در دنیای .NET، چند فریم‌ورک محبوب برای پیاده‌سازی مدل Actor مجازی وجود دارند:

• Orleans

• Proto.Actor

• Akka.NET

• همچنین بخش‌هایی از Dapr

موارد استفاده (Use Cases)

به‌طور کلی، زمانی که برنامه‌ی شما با تعداد زیادی موجودیت کوچک (small entities) سروکار دارد که:

• هرکدام منطق خودش را اجرا می‌کند

• و وضعیت خودش را به‌صورت ایزوله مدیریت می‌کند

مدل Actor می‌تواند انتخاب بسیار مناسبی باشد.

برای مثال‌های مشخص‌تر، اینجا چند مورد از کاربردهای متداول آورده شده است:

• مدل‌سازی یک دستگاه به‌عنوان Actor با منطق آلارم، قوانین و آستانه‌ها

• دوقلوهای دیجیتال (Digital Twins) برای اشیاء فیزیکی

• مدیریت تعاملات کاربران به‌صورت پیام بین Actorها

• جمع‌آوری و تحلیل جریان‌های داده به‌صورت نقشه‌کاهش (MapReduce)

• پیگیری وضعیت بازی‌ها، بازیکنان، اشیاء، منابع و امتیازها

• سیستم‌های Matchmaking (مانند بازی‌های آنلاین)

• توزیع وظایف میان نودهای پردازشی مختلف

• وظایفی که به اجرای مستقل نیاز دارند و باید با هم تبادل اطلاعات داشته باشند

نتیجه‌گیری

مدل بازیگرهای مجازی (Virtual Actor Model)
یک رویکرد قدرتمند و اثبات‌شده برای ساخت برنامه‌های توزیع‌شده است.

با این مدل می‌توانید برنامه‌هایی بسازید که:

• کارایی بالا داشته باشند

• در مقیاس بزرگ توزیع‌شده اجرا شوند

• و با همان ابزارهایی که هم‌اکنون با آن‌ها آشنایی دارید، توسعه پیدا کنند

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

در آینده، به‌ویژه با رشد ابزارهایی مانند Proto.Actor در دنیای دات‌نت، استفاده از مفاهیمی مانند مدل بازیگر در نرم‌افزار به یکی از استانداردهای طراحی سیستم‌های بزرگ تبدیل خواهد شد. اگر به دنبال یادگیری عمیق‌تر، مشاوره یا اجرای پروژه‌هایی در این حوزه هستید، خوشحال می‌شویم در شرکت راهکار نگار هوشمند (آرکان) همراه شما باشیم.

این مقاله با هدف آگاهی‌بخشی توسط تیم توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.

#سیستم_توزیع_شده
#بازیگر_مجازی
#توسعه_نرم_افزار
#مشاوره_نرم_افزار
#معماری_میکروسرویس
#برنامه_نویسی
#دات_نت
#proto_actor
#Orleans
#cloud_native
#IoT
#real_time
#نرم_افزار_سفارشی
#شرکت_راهکار_نگار_هوشمند
#arcanco