این پست توضیح میده که چطور پی‌پال با فقط 8 تا ماشین مجازی به یه میلیارد تراکنش روزانه رسید.

دسامبر 1998 - کالیفرنیا، آمریکا

تیمی از مهندسان نرم افزار امنیتی برای دستگاه های hand-held درست کردن. ولی مدل کسب‌وکارشون شکست خورد.

پس تصمیم گرفتن یه سرویس پرداخت آنلاین درست کنن و اسمش رو گذاشتن پی‌پال.

تو اوایل، با افزایش تعداد کاربرا، سخت‌افزار جدیدتر می‌خریدن تا بتونن مقیاس‌بندی کنن.

این نمودار قانون مور عه

ولی ترانزیستورهای یه مدار مجتمع** (IC)** هر دو سال یه بار دو برابر نمی‌شد. با این حال، رشدشون انفجاری بود.

و تو دو سال آینده به 1 میلیون تراکنش روزانه رسید.

پس تصمیم گرفتن با اجرای سرویس‌ها تو بیش از 1000 تا ماشین مجازی مقیاس‌دهی کنن.

Horizontal Scaling

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

بخشی از مشکلاتی که براشون بوجود اومد:

1- زیرساخت شبکه (Network Infrastructure)

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

2- هزینه‌های نگهداری

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

3- استفاده از منابع

CPU هر سرور رو تا آخر استفاده نمی‌کردند. یعنی سرورها خیلی کم‌کار می‌کردند. این باعث می‌شد که منابع هدر برود و هزینه‌های اضافی بشود.

اکتور مدل (Actor Model)

برای آشنایی بیشتر با اکتور مدل میتونید به این مقاله linkedin مراجعه کنید

اگه کد رو همزمان اجرا نکنی، نمی تونه از سخت افزار به طور کامل استفاده کنه.

علاوه بر این، اونها می خواستن کد رو ساده و مقیاس پذیر نگه دارن.

بنابراین، اونها به اکتور مدل مبتنی بر چارچوب Akka (Java) تغییر دادن.

این امکان رو بهشون داد تا با** تنها 8 ماشین مجازی** از یک میلیارد تراکنش روزانه پشتیبانی کنن.

اکتور مدل یه مدل محاسبه همزمان مفهومیه.

و یه اکتور واحد اصلی محاسبه است.

اینجاست که اکتور مدل مقیاس پذیری شدیدی رو ارائه میده:

1- استفاده از منابع

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

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

2- اطلاعات حالت (State Information)

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

اکتورها از طریق پیام ها ارتباط برقرار می کنند

اکتورها از طریق پیام ها ارتباط برقرار می کنند هر اکتور یه صندوق پستی داره. مثل صف پیامه. اکتورها پیام ها رو توی صندوق پستی خودشون تا پردازش شدنشون در ترتیب اولویت اول **(FIFO) **ذخیره می کنن. همچنین، اکتورها به سیستم اجازه می دن از تماس های شبکه اضافی به حافظه نهان توزیع شده یا پایگاه داده جلوگیری کنن. چون آنها وضعیت محلی رو توی سرور برنامه ذخیره می کنن.

سرور برنامه درخواست ها رو بدون پرس و جو از پایگاه داده مدیریت می کند به عبارت دیگه، یه سرور برنامه حالت دار عملکرد رو بهبود می بخشه. چون داده ها رو به صورت محلی ذخیره می کنه. علاوه بر این، PayPal از  consistent hashing برای مسیریابی کلاینت به همون سرور استفاده می کنه.

3- همزمانی (Concurrency)

چند تا اکتور می تونن همزمان کار کنن، ولی هر اکتور پیام ها رو به ترتیب پردازش می کنه.

پردازش پیام های اکتور به ترتیب متوالی (Sequential Order)

یعنی یه اکتور فقط می تونه یه پیام رو تو یه زمان پردازش کنه.

پس برای پردازش 3 پیام به صورت موازی، باید 3 اکتور داشته باشیم.

همچنین اکتورها به صورت غیر همزمان کار می کنن. یعنی منتظر جواب اکتور دیگه نمی مونن.

پس مدل اکتور همزمانی رو راحت تر می کنه.

علاوه بر این، پی پال از سبک برنامه نویسی تابعی Akka برای مقیاس پذیری استفاده می کنه.

این از عوارض جانبی جلوگیری می کنه و تست کردن رو راحت تر می کنه.

همچنین از قطعات کد قابل جدا شدن با برنامه نویسی تابعی برای مقیاس پذیری آسون استفاده می کنن.

اکتور ها می تونن محلی(locally) یا از راه دور(remotely) تو یه ماشین دیگه اجرا بشن.

با این حال، این برای سیستم شفافه.

4- قابلیت تحمل خرابی (Fault Tolerance)

یه اکتور می تونه اکتور های بیشتری ایجاد کنه و اون ها رو تحت نظارت قرار بده.

قابلیت تحمل خرابی در مدل اکتور

اکتور ناظر در صورت خرابی، اکتور تحت نظارت رو دوباره راه اندازی می کنه. همچنین پیام می تونه به اکتور دیگه ای ارسال بشه.

علاوه بر این، خطاها به اکتور ناظر propagate می شن.

پس می‌تونیم بدون شلوغ کردن کد، خطاها رو به صورت تمیزی مدیریت کنیم.

اکتور مدل (Actor Model) راه حلی قاطع برای مقیاس‌پذیری نیست و برای توسعه دهندگان learning curve عه

اکتور مدل به پی‌پل اجازه داد تا مقیاس‌های شدید را با منابع کمتر مدیریت کند.

با تشکر از شما که تا آخر مقاله همراه من بودید :)

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

• https://medium.com/paypal-tech/squbs-a-new-reactive-way-for-paypal-to-build-applications-127126bf684b

• https://en.wikipedia.org/wiki/PayPal

• https://akka.io/

• https://finematics.com/actor-model-explained/

• https://www.brianstorti.com/the-actor-model/

• https://newsletter.systemdesign.one/p/actor-model