رهبر گروه کانتینرها‌ (بخش سوم)

خبر خوب: برای بخش فرانت اند پروژه، یکی از دوستای خوبم، پویا، که جدیدا Vue JS رو شروع کرده قراره بهم تو پیاده سازی کمک کنه و بخش فرانت رو هندل کنه 🙂


بریم سراغ تحلیل همه بخش ها، در گام اول تکنولوژی هایی که استفاده خواهیم کرد شامل این ها خواهد بود:

Lumen 5.8 / PHP 7.3 / Socket IO 2.0 / NodeJS 10.16 / MySQL 8.0 / VueJS 2 / NginX (ingress)

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


بریم سراغ معماری خیلی ساده نرم افزاریمون. اول خیلی ساده از بک اند شروع میکنیم و میرسیم به فرانت اند:

سه تا سرویس داریم یا اصطلاحا سه تا نرم افزار جدا داریم، نرم افزار اولمون رو اسمش رو میزاریم A و نرم افزار دوممون رو هم اسمشو میزاریم B و منطقا بعدی رو هم C.

وظایف نرم افزار A:

  • دریافت Post های کاربران (validation و …)
  • ذخیره Post ها در پایگاه داده

وظایف نرم افزار B:

  • ارسال Post ها به صورت real time روی کلاینت ها (سنگین ترین بخش کل این نرم افزار همین سرویسه، پس تا حد ممکن مستقل باید بسازیمش که خیلی راحت بشه هرجوری که خواستیم scale اش کنیم. منظورم این هست که وابستگی کمی به دنیای اطرافش باید داشته باشه و وظیفه خیلی کوچیک ولی مهمی داره.)

وظایف نرم افزار C:

  • چک کردن وضعیت پست های ارسالی و تحویل پست های آماده نمایش، به سرویس B (اصطلاحا این سرویس، شبیه یک کران جاب معمولی لینوکسیه که تو کلاسترمون اجرا میشه)

اما دیگر بخش ها:

وظایف Database:

  • ذخیره سازی دائمی Post های ارسال شده توسط کاربران

وظایف Web Server:

  • ارسال درخواست های HTTP به نرم افزار A
  • سرو کردن فایل های استاتیک

خب؛ حالا همه این ها یعنی چی؟!

وب سرور، درخواست هایی که کاربران میفرستن رو میگیره و میده به نرم افزار A، که همون بخش PHP یا دقیقترش، Lumen هست. Lumen شروع میکنه به تحلیل پستی که دریافت کرده و اگر همه چیزش اکی باشه؛ مثلا طولش و متنش (کاراکتر مخرب نداشته باشه و …)، اونوقت میفرسته برای پایگاه داده یا همون MySQL و رسما دیگه کارش تموم میشه.

حالا نرم افزار C یا همون کران جابمون، میاد و از پایگاه داده هر N بار وضعیت رو میگیره. یعنی اولین بار میره ببینه تا حالا پستی ارسال کرده یا نه. اگر ارسال نکرده بود، قدیمی ترین پست رو به نرم افزار B تحویل میده و نرم افزار B هم شروع میکنه به push کردن روی سوکت همه کلاینت ها. حالا اگر مثلا پستی که تحویل B داده بود مدت زمان نمایشش ۲ دقیقه بوده باشه، کران جاب ما هر N ثانیه از پایگاه داده میپرسه آیا قدیمی ترین پستی که من ازت تو تاریخ فلان گرفتم و دادمش به B، از مدت زمان نمایشش که ۲ دقیقه بود رد شده یا نه؟ اگر رد شده بود، قدیمی ترین پستی که هنوز ارسال نشده رو میگیره و میده به ‌‌B و اگر هم هنوز رد نشده باشه که هیچی منتظر میمونه، و الی آخر …

در نهایت اطلاعات یا همون پست ها، روی بستر Web Socket به کمک SocketIO به کلاینت هایی که بهش متصل شدن نمایش داده میشه و هر کلاینت یک رویداد داره به اسم newPost و هر بار که فراخوانی بشه، باید خیلی شیک و قشنگ، پست جدیدی که براش ارسال شده رو نمایش بده!


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


من روش های دیگه ای هم به ذهنم رسید و البته از چند تا از بچه های شرکت هم که پرسیدم نظرات مختلفی وجود داشت (از استفاده از Redis و RabbitMQ تا Thread های زمان دار و …) ولی فکر کنم روشی که بالا من توضیحش دادم در عین سادگی درک شدن، پرفورمنس خیلی بدی هم نداشته باشه. چون عملن سنگین ترین بخش نرم افزار ما، به سادگی قابل رویته! یعنی Socket Server، دقیقا جایی که ممکنه میلیون ها کاربر بخوان بهش وصل بشن و داده ها رو بگیرن و عملا ما زیاد کاری با پایگاه داده و دیگر بخش ها نداریم. پس Scale ما روی Socket Server مون خواهد بود.


ممکنه شما هم ایده خوبی به ذهنتون رسیده باشه. اگر حوصله داشتین تو همین مطلب کامنت بزارین برام یا تو گیت هاب که کم کم کامیت رو شروع میکنم، issues بزنین یا هر روش دیگه ای که دوست داشتین.


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


یکی از دوستان ازم پرسید برای چی این پست طولانی رو داری مینویسی؟ گفتم بهش چون منبع خوب فارسی برای کوبرنتیز ندیدم، دارم شروع میکنم به نوشتن این سلسله مقاله تا هر چیزی که دارم یاد میگیرم رو اینجا به صورت مستند شده و جمع جور ثبت بکنمش در قالب یک پروژه کوچیک! شماره این مطلب ۳ بود. احتمالا شماره بعدی یعنی ۴ به تحلیل فنی و کامیت های دایکیومنت میرسه. و مطلب شماره ۵، شامل توضیح پیاده سازی همه سیستم ها و تست های اولیه شون باید باشه (که طولانی میشه احتمالا مطلبش!) و مطلب شماره ۶ هم باید درباره داکرایز کردن پروژه و تست docker-compose و این چیزا باشه. و از مطلب شماره ۷ رسما وارد توضیحات اولیه k8s یا همون کوبرنتیز میشیم و تمام مفاهیم مهمشو شروع میکنیم به مرور کردن و فهمیدن. و از مطلب شماره ۸ یا ۹، راه اندازی یک کلاستر لوکال با minikube داریم و میریم جلو که سه تا سرور بخریم و یک کلاستر واقعی راه بندازیم (شاید هم از فندق استفاده کردیم ولی خب چون نصب کوبرنتیز هم خودش یک پروسه ایه،شاید vps معمولی بگیریم و کلاستر رو خودمون راه بندازیم و تست کنیم.)


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

بازدیدها: 20

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *