https://virgool.io/feed/@mohammad7293 هم موسس کوییز آف کینگز - برنامه نویس و توسعه دهنده ارشد بکند - علاقه مند به تکنولوژی و مقالات علمی. fa 2026-04-14 17:56:00 https://files.virgool.io/upload/users/71517/avatar/6yDzSr.png?height=120&width=120 https://virgool.io/@mohammad7293 https://virgool.io/newdima/%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%D9%87%D8%A7%DB%8C-%D8%A8%D9%84%D8%A7%DA%A9%DA%86%DB%8C%D9%86-%D9%88-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D8%AF%D8%B1-%DA%A9%D8%B3%D8%A8-%D9%88%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A7%D9%85%D8%B1%D9%88%D8%B2%DB%8C-kmyk46w5pjbx کاربردهای هوش مصنوعی و بلاکچینسلام، من محمد هستم. سال‌ها در صنعت بازی‌سازی فعالیت داشته‌ام و به‌عنوان یکی از هم‌بنیان‌گذاران "کوییز آو کینگز"، تجربه‌ی گسترده‌ای در توسعه‌ی سیستم‌های دارای Gamification کسب کرده‌ام. در طول این سال‌ها، با چالش‌های بسیاری که کسب‌وکارها برای جذب و حفظ کاربران و همچنین cross-promotion ایجاد می‌کنند، آشنا شده‌ام.متأسفانه، در سال‌های اخیر شاهد تخلفاتی در برگزاری برخی از این چالش‌ها بوده‌ام که به‌جای ایجاد ارزش برای کاربران، صرفاً به‌عنوان ابزاری برای افزایش فروش برخی کسب‌وکارها مورداستفاده قرار گرفته‌اند. این نوع سوءاستفاده‌ها از اعتماد کاربران نه‌تنها غیر اخلاقی است، بلکه می‌تواند باعث از بین رفتن اعتبار برندها شود.اما در اینجا نقطه‌ای وجود دارد که شرکت‌هایی که قصد تخلف ندارند، می‌توانند از فناوری‌های Smart Contract در بلاکچین و همچنین AI به‌عنوان یک سیستم CRM استفاده کنند تا تجربه‌ای شفاف، صادقانه و قابل‌اعتماد برای کاربران فراهم کنند.نمونه‌هایی از تخلفات (خلف وعده های) رایجقبل از ورود به بحث اصلی، اجازه دهید چند نمونه از تخلفاتی که شخصاً مشاهده کرده‌ام را مطرح کنم. هدف از ذکر این مثال‌ها تخریب شرکت‌ها نیست، بلکه افزایش آگاهی و تشویق آن‌ها به اصلاح فرآیندهایشان است.مثال ۱: قرعه‌کشی‌های غیرواقعیسه سال پیش، در سفری به کیش، با قرعه‌کشی یک پاساژ مواجه شدم که جایزه‌ی آن یک خودروی Kia Cerato بود. تبلیغات اعلام می‌کرد که فقط دو هفته تا قرعه‌کشی باقی مانده است. بااین‌حال، فروشندگان پاساژ می‌گفتند که این قرعه‌کشی سال‌هاست به تعویق افتاده و حتی رنگ ماشین به دلیل آفتاب‌خوردگی تغییر کرده بود! سال بعد که دوباره به همان پاساژ رفتم، دیدم همان خودرو همچنان به‌عنوان جایزه تبلیغ می‌شود و قرعه‌کشی تمدید شده است. این نمونه‌ای بارز از کلاه‌برداری و فریب افکار عمومی برای ترغیب مردم به خرید بیشتر بود.مثال ۲: چالش گنج فیلیموبه‌دلیل علاقه‌ای که به این حوزه دارم، در چالش "گنج فیلیمو" شرکت کردم. این چالش شامل چندین مأموریت بود:۱. پاسخ به سؤالات سینمایی ۲. دریافت ۱ امتیاز به‌ازای هر دقیقه تماشای فیلم در فیلیمو ۳. دریافت ۷۰ امتیاز با خرید اشتراک ۴۴. دریافت ۳۰ امتیاز به‌ازای دعوت هر دوستاما در این چالش، چندین تخلف (خلف وعده، عدم شفافیت) رخ داد که هدف از آن، طولانی‌تر کردن رقابت و جلوگیری از دستیابی سریع افراد به رتبه‌های بالا بود:من لینک دعوت خود را تبلیغ کردم و چندین هزار کلیک دریافت شد، اما شمارنده امتیازات دعوت در عدد ۳۰۰۰ (۱۰۰ دعوت) متوقف شد، درحالی‌که آمار کلیک‌ها همچنان درحال افزایش بود. و در جایی در قوانین چالش هم به محدودیت اشاره نشده بود!پشتیبانی فیلیمو پاسخی جز این نداشت: "این چالش سیستمی است و ما اطلاعی نداریم.". اگر پشتیبانی فیلیمو به سوالات و مشکلات شمارش امتیازات پاسخ نمی دهد، پس چه کسی مسول پاسخگویی است؟بدون اطلاع قبلی، مدت چالش حدود یک ماه و نیم تمدید شد. این در حالی بود که اگر چالش در موعد مقرر به پایان می‌رسید، هم شرکت‌کنندگان با هزینه‌های کمتری مواجه می‌شدند و هم فردی که در تاریخ اعلام‌شده اولیه در صدر قرار داشت، به‌عنوان برنده جایزه معرفی می‌شد.چگونه بلاکچین و هوش مصنوعی می‌توانند مانع این تخلفات شوند؟متأسفانه، بسیاری از افراد هنگام شنیدن واژه‌ی "کریپتو" تنها به نوسانات بازار رمزارزها فکر می‌کنند، درحالی‌که بلاکچین کاربردهای گسترده‌ای دارد. یکی از این کاربردها، ایجاد شفافیت در فرآیندهای غیرقابل‌اعتماد مانند رأی‌گیری، قرعه‌کشی‌ها و چالش‌های آنلاین است.بلاکچین و شفافیت در کمپین‌های تبلیغاتیبه‌عنوان نمونه، PancakeSwap که یک صرافی غیرمتمرکز است، چالش‌های مبتنی بر بلاکچین برگزار می‌کند. چالش Lottery این پلتفرم از قراردادهای هوشمند استفاده می‌کند که به‌صورت عمومی در دسترس است. کاربران می‌توانند این قراردادها را بررسی کنند و اطمینان حاصل کنند که قرعه‌کشی‌ها به‌صورت کاملاً تصادفی و بدون مداخله‌ی برگزارکنندگان انجام می‌شود.اگر چالش‌هایی مانند گردونه‌های شانس که ادعای اعطای جوایز بزرگ مثل PS5 یا iPhone را دارند، روی بلاکچین اجرا شوند، می‌توان تضمین کرد که جوایز واقعی هستند. حتی فرآیند توزیع جوایز می‌تواند مانند PancakeSwap به‌صورت خودکار انجام شود، به‌گونه‌ای که حتی برگزارکننده نیز قادر به تغییر شرایط یا تمدید چالش نباشد.هوش مصنوعی و بهبود پشتیبانی مشتریانیکی از مشکلات اصلی چالش فیلیمو، ضعف در پاسخگویی پشتیبانی آن بود. امروزه بسیاری از پلتفرم‌های بین‌المللی مانند Revolut، از AI برای مدیریت بخش CRM استفاده می‌کنند. در این روش، سیستم‌های هوش مصنوعی می‌توانند پاسخگویی به درخواست‌های ساده را به‌عهده بگیرند و تنها در موارد خاص، درخواست را به اپراتور انسانی ارجاع دهند. این باعث بهبود تجربه‌ی کاربری و افزایش شفافیت در تعاملات شرکت‌ها با مشتریان می‌شود.جمع‌بندیاگر کسب‌وکارها تصمیم بگیرند که بلاکچین را در فرآیندهای خود به‌کار بگیرند و فرهنگ‌سازی لازم را انجام دهند، نه‌تنها شفافیت افزایش می‌یابد و احتمال تخلف‌های این‌چنینی کاهش پیدا می‌کند، بلکه این فناوری می‌تواند در سایر بخش‌های جامعه نیز گسترش یابد. امید است که روزی شاهد کاهش سوءاستفاده‌ها و فریب افکار عمومی در راستای کسب سود بیشتر باشیم.علاوه بر این، برای ایجاد یک محیط سالم و عادلانه، ضروری است که دولت‌ها قوانینی وضع کنند که برگزاری قرعه‌کشی‌ها و کمپین‌ها تحت شرایط عادلانه و شفاف صورت گیرد. این قوانین می‌توانند شامل موارد زیر باشند:وجود پشتیبانی پاسخگو: پشتیبانی باید قادر باشد به‌طور شفاف و کارآمد به تمامی سؤالات کاربران پاسخ دهد و از ارائه پاسخ‌های مبهم خودداری کند.نوشتن قوانین و محدودیت‌ها به‌صورت شفاف: تمامی قوانین، محدودیت‌ها و شرایط باید به‌صورت واضح و بدون ابهام در دسترس عموم قرار گیرند.تأمین جوایز قبل از شروع کمپین: جوایز یا وثیقه‌های مربوط به قرعه‌کشی یا کمپین‌ها باید پیش از آغاز فعالیت‌های مربوطه تأمین شده و تضمین‌های لازم به ارگان‌های ناظر ارائه گردد. محمد سلیمانی فر محمد سلیمانی فر Mon, 10 Feb 2025 16:55:57 +0330 https://virgool.io/@mohammad7293/%D9%86%D8%AD%D9%88%D9%87%DB%8C-%D8%AA%D8%B5%D9%85%DB%8C%D9%85%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D8%B2%D8%A8%D8%A7%D9%86-%D9%81%D8%B1%DB%8C%D9%85%D9%88%D8%B1%DA%A9-%DB%8C%D8%A7-%D8%AA%DA%A9%D9%86%D9%88%D9%84%D9%88%DA%98%DB%8C-%D8%A8%D8%A7%DB%8C%D8%AF%D9%87%D8%A7-%D9%88-%D9%86%D8%A8%D8%A7%DB%8C%D8%AF%D9%87%D8%A7-%D8%AF%D8%B1-%D8%AA%D8%B5%D9%85%DB%8C%D9%85%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%D8%AA%DA%A9%D9%86%D9%88%D9%84%D9%88%DA%98%DB%8C-la3rrveqvlqs وقتی قراره یه کار جدید شروع کنیم که احتیاج به سرور داره، همون اول کار، خریدن یا اجاره کردن یه سرور با بهترین کانفیگ، منطقی و اقتصادی نیست. اصلا معلوم نیست کار به جایی بکشه که ما نیازمند اون مقدار از Resource باشیم، اما باید طوری عمل کنیم که اگر روزی بیزینس Viral شد، برای تحمل کردن حجم زیاد درخواست‌ها سریعا بتونیم واکنش نشون بدیم و فرصت رو از دست ندیم.در صنعت ما باید واقع‌گرا باشیم، همیشه یک سری تمایلات درونی داریم که ما رو تحریک می‌کنن که تحت تاثیر fact هایی مثل «فلان زیرساخت خیلی خفنه»، «فلان زبان خیلی Benchmark خوبی داره» و «فلان فریم ورک خیلی قابلیت های ویژه‌ای داره» قرار بگیریم. خیلی از ما و حتی خود من خیلی جاها تحت تاثیر این موارد قرار گرفتیم.برای یک پروژه‌ی شخصی کوچیک که قرار نیست بزرگ بشه، تجربه کردن اصلا بد نیست بلکه شدیدا توصیه می‌کنم که با همه‌ی تکنولوژی‌های جدید آشنا بشید. اما برای یک شرکت بزرگ و به ویژه یک استارتاپ کوچک که پلن اش بزرگ شدنه خیلی باید دقت کرد.در زیر می خواهم تجاربی رو که طبق تلاش های چند ساله‌ام در Quiz of Kings (که به یکی از بزرگترین بازی‌های ایرانی دانستنی آنلاین در ایران بدل شده) به دست آوردم به طور خلاصه توضیح بدم.در انتخاب زبان، تکنولوژی، زیرساخت و … باید به موارد زیر توجه کرد:۱- نحوه‌ی توزیع نیروی انسانی متخصص به تکنولوژی مربوطه در کشور۲- سهولت کار کردن با تکنولوژی مورد نظر و داکیومنت با کیفیت داشتن آن تکنولوژی۳- فعال بودن Community برای تکنولوژی مورد نظر۴- قابل توسعه بودن تکنولوژی مد نظر با هزینه منطقی۵- دارا بودن Benchmark مناسب۶- دارا بودن شرایط Disaster Recoveryاکنون به بررسی خلاصه‌ای از شرح هر یک از موارد بپردازیم:۱- نحوه‌ی توزیع نیروی انسانی متخصص به تکنولوژی در کشورچه آینده‌ای برای کار خود متصورید، آیا به این فکر کردید که با پا گرفتن استارتاپ شما، احتمالا نیروهای فنی اولیه‌، دیگر به تنهایی قادر به اداره‌ی امور نخواهند بود و احتیاج به توسعه‌ی تیم فنی خود دارید؟خب، وقتی تیم فنی‌تون نیاز به توسعه پیدا کرد، اگر به این مورد توجه نکرده باشید، به این راحتی‌ها نیروی کار پیدا نخواهید کرد.فرض کنید که شما تکنولوژی‌ای را انتخاب کرده‌اید که تنها ۱۰ درصد اکوسیستم فنی به آن مسلط هستند، آیا فورا با گذاشتن آگهی ‌‌شغلی، این ۱۰ درصد از وجود شما مطلع می‌شوند؟ اگر مطلع شوند آیا تمایل به همکاری با شما دارند؟فرض بگیریم که نیروی کار هم پیدا شد، یکی از عوامل اصلی برای قیمت گذاری را می‌توان عرضه و تقاضا بر شمرد، وقتی که عرضه کم باشد، آیا به نظرتان با یک عدد حقوقی عرف بازار می‌توانید این افراد را جذب کنید؟ خیر!وقتی نیروی کار برای بخش کاری مد نظر شما کم باشد، به توافق رسیدن سخت می‌شود و شاید اگر متوسط حقوقی دریافتی بازار برای Position مورد نظر را X تومان در نظر بگیریم، شما برای راضی کردن آن افراد به پیوستن به شرکت خود مجبور به پرداخت 1.5X تا 2X تومان شوید. این تازه در شرایط خوشبینانه است که نیرو پیدا شود، اما شدیدا توصیه می‌کنم این عامل را اصلا نادیده نگیرید و همیشه به آن توجه کنید که در کشور شما چقدر نیروی کار متخصص برای آن نیرو وجود دارد؟شاید در ایران توسعه دهنده‌ی PHP خیلی زیاد باشد و در کشور دیگری خیلی کم، در ایران انتخاب زبان PHP برای توسعه از منظر این فاکتور معقول به نظر می‌رسد اما در آن یکی کشور یک انتخاب غیرمنطقی و پرخطر!۲- سهولت کار کردن با تکنولوژی مورد نظر و داکیومنت با کیفیت داشتنسهولت، یکی از مهم‌ترین عواملی است که باید در نظر بگیرید.سهولت کار کردن با تکنولوژی باعث میشه که نیروهایی که با این تکنولوژی کار نکردن به سرعت کار کردن باهاش رو یاد بگیرن. پس از طرفی اگر نیرویی استخدام کردید که کار با این تکنولوژی رو بلد نبود، به راحتی می‌تونه با خوندن داکیومنت‌ها، اون تکنولوژی رو یاد بگیره و از طرف دیگه سهولت باعث میشه که تعداد نیروهای آشنا با تکنولوژی در بازار هم زیاد بشه.وجود داکیومنتیشن با کیفیت برای تکنولوژی مورد نظر هم باعث افزایش سرعت در یادگیری میشه و باعث میشه در صورتی که در کار به مشکلی برخوردید به راحتی با استفاده از آن، مشکل را برطرف کنید.۳- فعال بودن Community برای تکنولوژی مورد نظراین نکته بسیار حائز اهمیته که تکنولوژی‌ای که قراره ازش استفاده کنید و باهاش کار کنید «زنده» باشه!یعنی وقتی به GitHub پروژه مراجعه کردید از آخرین Commitاش زمان زیادی نگذشته باشه و پیوسته در حال به روز شدن باشه.این باعث میشه وقتی به یک باگ در اون پروژه برخورد کردید، بتونید گزارشش کنید، با سایر افراد درباره‌اش گفتگو کنید که در نتیجه، هم یه راه حل موقت براش پیدا می‌کنید و هم اینکه مطمئن می‌شید در آپدیت های بعدی، اون مشکل اصلاح میشه.اخیرا می‌خواستیم از یک Library مشهور استفاده کنیم، با چک کردن Communityاش متوجه شدیم توسعه دهنده مدت زیادیه به مشکلات پاسخ نمیده! اون Library فقط توسط یک نفر ساپورت میشد که فوت کرده بود و دیگه روند توسعه‌اش متوقف شده بود، برای همین از خیر استفاده از این Library گذشتیم.یک نکته مهم که باید در این باره بهش توجه کنید اینه که اگر خواستید از یک Library استفاده کنید و چندین انتخاب داشتید که یکی از اونها مربوط به یک شرکت رسمی بود، Library مربوط به شرکت رسمی رو تو اولویت بگذارید.مثلا ما در Golang برای تست نوشتن از یک پروژه استفاده کرده بودیم که متعلق به خود Golang نبود ولی کار کردن باهاش راحت تر بود، بعد از مدتی پروژه کنسل شد و عملا تستهایی که باهاش نوشته بودیم دیگه با آپدیت کردن Go قابل استفاده نبودند!۴- قابل توسعه بودن تکنولوژی مد نظر با هزینه منطقیدر یک سری مواقع تکنولوژی مورد نظر فاکتورهای بالا رو داره، اما قابلیت Scale شدن رو نداره، یعنی می‌توان اون تکنولوژی رو تنها روی یک سرور پیاده کرد و نمی‌توان آن را روی چند سرور به صورت توزیع شده بالا آورد تا بار درخواست‌ها به آن بین چندین سرور تقسیم بشه.اگر یک تکنولوژی این قابلیت رو نداره همون اول از انتخابش صرف نظر کنید، چون وقتی تعداد کاربران شما و در نتیجه بار روی سرور حاوی این زیرساخت زیاد شد، باید در یک شرایط بحرانی و در یک مدت زمان کم اون زیرساخت رو تعویض کنید. پس بهتره از همون اول در انتخاب دقت کنید.گاهی اوقات یک زیرساخت Scale پذیر هست اما نه به صورت رایگان بلکه به صورت Enterprise.با توجه به قیمت ارز در کشور ما این شرایط اصلا نمی‌صرفه، پس توی این شرایط هم باید از انتخاب اون زیرساخت صرف نظر کرد.به عنوان مثال ما در کوییز می‌تونستیم ‌‌Mysql رو با استفاده از شرکتهایی که خدمات Enterprise می‌دادند Scale کنیم و به ازای هر Instance از Mysql مبلغ بالایی به دلار پرداخت می‌کردیم. الان نزدیک ۲۰۰ تا node از mysql داریم. اگر راه‌حل Enterprise رو انتخاب می‌کردیم الان شرکت کاملا در ضرر بود.۵- دارا بودن Benchmark مناسبوقتی می‌خواهید یک زیرساخت یا زبان رو برای کار خود انتخاب کنید باید پیش‌بینی کنید که حداکثر لود سیستم روی اون زیرساخت چقدر خواهد شد.این موارد با توجه به نوع کار شما قابل پیش‌بینی هستند.مثلا یک شرکت می‌خواهد یک فروشگاه اینترنتی راه بندازه، بار یک فروشگاه اینترنتی اصلا با یک بازی آنلاین قابل مقایسه نیست. پس اصلا نباید اولویت ما خیلی رو مباحث Performance ای متمرکز بشه که وقتی Load سیستم خیلی بالا میره تفاوتش حس میشه.به طور دقیق‌تر مثلا وقتی فکر می‌کنید که یک زبان نسبت به دیگری اولویت داره و Benchmark هاشون رو مقایسه‌ می‌کنید، دقت کنید که آیا اصلا این برتری برای کاربران شما محسوس هست یا نه؟به عنوان مثال در یک فروشگاه اینترنتی اگر شما برای باز کردن هر صفحه ۱ ثانیه منتظر بشید این مشکلی نداره و از دید کاربر چندان اهمیتی نداره، اما برای یک بازی این می‌تونه کاملا اعصاب کاربر رو خرد کنه.پس مسائل مربوط به Performance رو باید با توجه به جایگاهی که قرار هست ازش استفاده بشه در نظر گرفت.۶ - دارا بودن شرایط Disaster Recoveryهنگام انتخاب زیرساخت به این مورد دقت کنید که زیرساخت مورد نظر دارای قابلیت Replication هست یا خیر.وقتی برای یک زیرساخت، در چندین سرور Replica بالا بیاورید، در صورتی که سرور اصلی که Master Node روی آن است از دسترس خارج شود، به راحتی می‌توان Replica را جایگزین آن کرد و از Down شدن سیستم جلوگیری کرد.نکته دیگر اینکه فرض کنید هیچ Replica ای ندارید، اگر فرضا دیتابیس MySql شما کرش کرد و دیگر بالا نیامد باید بتوانید از روی فایل های binlog آن دیتاهای خود را برگردانید، در حالی که در MongoDB دیتاها به صورت فایل JSON ذخیره میشوند. در شرایط مشابه بین MySql و مانگو، بازیابی دیتای MongoDB آسان تر از MySQL است چون افراد زیادی با ساختار JSON آشنایی دارند در حالی که سر و کار افراد خیلی کم به فایل های binlog می‌افتد.این نوشته، یک چکیده از مواردی بود که به طور کلی برای انتخاب تکنولوژی‌های فنی بایستی آنها را در نظر گرفت.در آینده، با مثال هایی چندین زبان یا تکنولوژی را با معیارهای بالا با یکدیگر مقایسه خواهیم کرد.از شما بابت وقتی که برای خواندن این نوشته صرف کردید، متشکرم. محمد سلیمانی فر محمد سلیمانی فر Mon, 10 Feb 2020 18:41:33 +0330 https://virgool.io/@mohammad7293/%D8%B3%DB%8C%D8%B1-%D8%AA%D8%AD%D9%88%D9%84-%D9%81%D9%86%DB%8C-%DA%A9%D9%88%DB%8C%DB%8C%D8%B2-%D8%A2%D9%88-%DA%A9%DB%8C%D9%86%DA%AF%D8%B2-%D9%85%D8%B3%DB%8C%D8%B1%DB%8C-%DA%A9%D9%87-%D8%A8%D8%A7%D8%B9%D8%AB-%D8%AA%D8%B9%D8%AC%D8%A8-%D8%AA%DB%8C%D9%85-%DB%8C%D9%88%D8%AA%DB%8C%D9%88%D8%A8-%D8%B4%D8%AF-h8m7caqni6rg منبع تصویر: FNT Softwareوقتی تازه کوییز آو کینگز رو شروع کرده بودیم و تعداد کاربران بازی زیر ۱۰۰ هزار نفر بود، همیشه برای شخص خودم سوال بود که اگر تعداد کاربرها زیاد بشه چیکار باید بکنیم، چطور سیستم می‌تونه این بار رو تحمل بکنه و در عین حال، کاربران هم از بازی رضایت داشته باشند، یعنی مشکلی که باعث کندی در بازی یا مشکل در ذخیره‌ی اطلاعاتش بشه وجود نداشته باشه.توی اون مواقع شنیده بودم که مثلا فیس‌بوک از شاردینگ دیتا برای دیتابیس هاش استفاده می کنه و کم و تا حدودی با مفاهمیمش آشنا شده بودم، اما هیچ وقت فکر نمی کردم که در کمتر از یکسال، ما هم مجبور بشیم چنین راهکارهایی رو پیاده‌سازی کنیم!کوییز آو کینگز در کمتر از یکسال شدیدا وایرال شد. به نحوی که سرعت رشد کاربران از سرعت رشد زیرساخت و تکنولوژی‌های فنی ما بسیار بیشتر بود.در ابتدا کوییز آو کینگز کار خود را با ۲ سرور شروع کرده بود که روی یکی از آنها Load Balancer ای قرار داشت که ریکوئست‌ها رو بین هر دو سرور که هر دو Application Server بودند، تقسیم میکرد. روی یکی از سرورها یک Mysql نیز قرار داشت و روی هر دو سرور نیز دو عدد Redis بود.اندکی بعد با رشد کاربران، ترافیک بازی نیز بالا رفت و با این اتفاق در بازی کندی های غیر قابل تحملی برای کاربران به وجود آمد، به طوری که بازی از ساعت ۹ شب به بعد و با افزایش ترافیک باز نمیشد.اولین قدم در حل این مسئله زیاد کردن تعداد App Server ها بود.تعداد App server ها رو افزایش دادیم. افزایش تعداد App serverها باعث یک التیام مقطعی به کندی بازی شد و سبب شد باز هم با استقبال بیشتری مواجه بشیم و این بار با کندی‌های جدی تری مواجه شدیم!اما این کندی ها رو چطور باید حل می کردیم؟!اولین قدم این بود که بفهمیم اصلا کندی ها از کجاست تا بعد ببینیم برای هر مورد چه باید کرد. مهم‌ترین و اصلی‌ترین مرحله‌ی کار همین ریشه‌یابی مشکلات است.برای ریشه‌یابی مشکل، قدم اول راه انداختن یه سیستم مانیتورینگ بود، با راه اندازی مانیتورینگ و مانیتور کردن سیستم متوجه شدیم که App Server ها نمی‌توانستند بیشتر از یک تعداد کانکشن در لحظه رو پشتیبانی کنند. همین باعث شد متوجه بشیم که جدا از توسعه‌ی تعداد App Server ها، Tune کردن متغیرهای سیستم عاملی هم مهمه. نه فقط برای یک App Server بلکه برای هر نوع سروری ما باید یک سری محدودیت های پیش فرض سیستم عامل رو دستکاری کرده و تغییر بدیم. به عنوان مثال یکی از پیش پا افتاده‌ترین این محدودیت ها، تعداد Open Fileها در لحظه است که به طور پیش فرض مقدار محدودی داره.از اونجایی که برای Socketهای ارتباطی در Network از فایل استفاده میشه، بنابراین محدود تعداد فایل‌های باز در لحظه باعث محدودیت تعداد درخواست‌های همزمان کاربران در لحظه می‌شد که با رفع محدودیت تعداد Open File ها توانستیم تعداد ریکوئست‌هایی که هر سرور در لحظه تحمل میکرد رو افزایش چشم‌گیری بدیم.این یک مثال ساده از Tune کردن متغیرهای سیستم عاملی بود. متغیرهای زیاد دیگری وجود دارند که جهت جلوگیری از انحراف بحث از توضیح آنها میگذرم.دو مشکل اساسی دیگری که داشتیم، یکی مصرف غیر بهینه‌ی Resourceها (Memory و CPU) در App Serverها بود که تا حد قابل توجهی به زبانی که App Server ها با اون نوشته شده بودند، یعنی PHP مرتبط بود و یه بحث اصلی دیگه این بود که دیتابیس MySQL پروژه روی تنها یک Server بود که به تنهایی تعداد کوئری در لحظه‌ي آن (QPS یا Query Per Second) به ۴۰ هزار عدد در ثانیه می‌رسید، عددی سرسام آور که تحمل این بار، آن هم برای یک سرور به تنهایی سخت بود و در نتیجه باعث کندی بازی شده بود و مجددا در ساعات اوج ترافیک عملا بازی باز نمی‌شد.برای حل مشکل App Serverها می‌شد با افزایش دوباره‌ی تعداد اونها زمان خرید اما دیتابیس MySQL در اون زمان بدون صرف هزینه‌ی زمانی و ایجاد تغییرات زیرساختی در معماری، قابل Scale کردن نبود.در آن زمان، پلتفرم‌‌های کمی برای Scale کردن MySQL موجود بودند که اکثر آنها به دلیل Enterprise بودن، نیازمند صرف هزینه‌های بالایی بودند، مثلا برای هر Instance از MySQL در سال، ما باید چندین هزار دلار میدادیم.حساب کنید که در حال حاضر کوییز تعداد زیادی Instance از MySQL داره و اگر قرار بود از سرویس های Enterprise استفاده کنیم الان باید با درآمد ریالیمون در سال، هزینه‌ی گزافی بابت Scale دیتابیس‌ها میدادیم.با کمی تحقیق، انتخاب ما پلتفرم Opensource ای به نام Vitess شد که محصول شرکت Youtube بود و در آن زمان به جز Youtube، شرکت‌های کمی از آن استفاده می‌کردند.کوییز آو کینگز زمانی به سراغ Vitess رفت که بسیاری از شرکت‌های بزرگی که اکنون از Vitess استفاده می‌کنند، از آن استفاده نمی‌کردند، از جمله شرکت‌هایی که بعد از کوییز به استفاده از Vitess روی آوردند می‌توان به گیتهاب، پینترست و کمپانی بازی سازی peak اشاره کرد.در آغاز پیاده‌سازی Vitess، دو مشکل اساسی پیش روی ما بود:- داکیومنتیشن های زیادی برای آن وجود نداشت و مجبور بودیم با خواندن Source کد Vitess بفهمیم که باید چه کنیم. یا از چندین سایت چینی کمک بگیریم که آنها در آن زمان Vitess را با موفقیت پیاده سازی کرده بودند.- کدهای Application Server پروژه در آن زمان، شدیدا وابسته به Doctrine بودند، اما Vitess در آن زمان اصلا از Doctrine پشتیبانی نمی‌کرد.پیاده‌سازی Vitess برای ما حدود ۶ ماه زمان گرفت.در این ۶ ماه ما کارهای زیر رو انجام دادیم:- قدم ۱ : بازکردن راه رشد تعداد کاربران و جلوگیری از سرکوب شدن موج Virality‌: با توجه به اینکه پیاده‌سازی Vitess با توجه به مشکلاتی که گفته شد، زمان‌بر به نظر می‌رسید، ما تصمیم گرفتیم برای رشد کوییز زمان بخریم، بخشی از بازی کوییز رو که شدیدا به Mysql وابسته بود به Redis منتقل کردیم تا هم سریع تر بشه و Scalable باشه و هم فرصت کافی داشته باشیم که بتوانیم Vitess رو پیاده‌سازی کنیم.درسته از Redis نباید به عنوان یک دیتابیس استفاده کرد، اما ما با این تصمیم سرعت بازی رو به بهای کاهش نسبتا کم Consistency (یکپارچگی دیتا) افزایش چشمگیری دادیم و تونستیم شیب رشد کاربران رو حفظ کنیم.الان که به گذشته نگاه میکنم واقعا به این تصمیم افتخار می‌کنم.- قدم ۲ : پیاده‌سازی زیرساخت Vitess : پیاده‌سازی این زیرساخت برای ما واقعا جذاب بود، استفاده از ابزارهایی چون ZooKeeper، Etcd، الگوریتم های توافق یا Consensus برای ما دریایی از تجربه بود.این پیاده سازی در عین جذابیت بسیار سخت بود، به قدری سخت که وقتی کار تمام شد و کوییز رو به زیرساخت دیتابیسی Vitess مجهز کردیم، تیم Vitess در YouTube تعجب کرده بودند و می‌خواستند یه Skype میتینگ با ما بگذارند و ببینند ما چه‌طور تونستیم محصول اونها رو با توجه به اون حجم کم داکیومنتیشن به کار بگیریم و لوگوی Quiz of Kings رو به عنوان یکی دیگر از استفاده‌کنندگان از Vitess روی سایتشان قرار دادند.تصویری که مدت‌ها پای ثابت ارائه‌های اعضای vitess.io بوده است- قدم ۳ : حذف Doctrine که بسیار کار وقت گیر و دشواری بود. چون Vitess در آن زمان از Connection مربوط به Doctrine پشتیبانی نمی‌کرد.برای حذف Doctrine، مجبور شدیم خودمان یک شبه ORM بنویسیم که مستقیما از طریق تولید کوئری های خام با PDO مربوط به Vitess ارتباط برقرار می‌کرد و کلیه‌ بخش‌های بازی رو با این ORM بازنویسی کنیم، این کار هم دقت زیادی می‌طلبید و هم‌ زمانی نزدیک حدود ۱ ماه صرف آن شد.نهایتا با بالا آمدن Vitess و اتصال آن به ORM خودساخته، جداسازی اولین بخش بازی از دیتابیس single-node سابق را جشن گرفتیم و راهی رو باز کردیم که بتوانیم سیل کاربران روزافزون رو تحمل کنیم.بخش‌هایی از بازی رو که به Redis منتقل کرده‌ بودیم رو هم به دیتابیس‌های جداسازی شده‌ی Vitess منتقل کردیم.اکنون کوییز آو کینگز بیش از ۴۰ سرور دارد و بیش از ۲۰۰ عدد از Node های Mysql آن با استفاده از Vitess شارد شده و مدیریت می‌شوند.پس از اینکه Migration به Vitess با موفقیت انجام شد. برای اینکه سرعت App Server ها افزایش یابد و همچنین مصرف منابع توسط آنها بهینه شود به سراغ زبان Go رفتیم و از بخش‌هایی از بازی که کندتر از بقیه‌ بودند، شروع به Migrate کردن کدها از زبان PHP به زبان Go کردیم، همچنین سعی کردیم تا بخش‌های جدید بازی رو با این زبان بنویسیم که حجم کدهای قدیمی زیاد نشود.امروز بعد از گذشت ۳ سال از این تحولات، بخش زیادی از کدهای بازی به Go منتقل شده است، App Server هایی که به زبان Golang نوشته شده‌اند، Dockerize شده و روی محیط Kubernetes قرارگرفته اند به طوری که به راحتی و با چشم به هم‌زدنی می‌توان تعداد ‌App Server های مورد نیاز برای یک بخش را زیاد یا کم کرد.بعد از مهاجرت به زبان Go به دلیل اهمیت سرعت توسعه، به معماری میکروسرویس روی آوردیم و بخش‌های زیادی از بازی رو به صورت میکروسرویس های مبتنی بر زبان Go نوشتیم به نحوی که هم معماری جدید و بهینه‌ ای برای این میکروسرویس‌ها در نظر گرفتیم و هم اینکه به دلیل جدا شدن این پروژه‌ها از یک پروژه‌ی Monolithic، سرعت توسعه به شکل چشم‌گیری افزایش یافت و تیم فنی بکند در کوییز به میکروتیم‌هایی تبدیل شد که هریک مسئول اداره‌ی بخش خاصی از بازی، بدون وابستگی زیاد به سایز بخش‌ها باشد.همچنین یکی دیگر از کارهایی که شروع به انجام آن کردیم، محدود کردن زیرساخت‌های هر سرویس‌ (دیتابیس‌ها، …) تا حد امکان به خودش بود تا اگر فشار روی یک سرویس زیاد شد، تاثیر این فشار تنها روی زیرساخت مربوط به خودش باشد و روی سایر بخش‌های بازی تاثیری نگذارد.ما به انتخاب‌هایی که کردیم و مسیری که رفتیم افتخار‌ می‌کنیم و امیدواریم روزی در خدمت شما عزیزان برای انتقال تجربیات بیشتری باشیم. محمد سلیمانی فر محمد سلیمانی فر Wed, 25 Dec 2019 20:13:43 +0330 https://virgool.io/@mohammad7293/%D9%86%D8%AC%D8%A7%D8%AA-business-%D8%A8%D9%87-%DA%A9%D9%85%DA%A9-%D8%B3%DB%8C%D8%A7%D9%87%DA%86%D8%A7%D9%84%D9%87-dp2upwtrelrc سیاه چالهامروز می‌خوام در قالب یه پست خیلی کوتاه، شما رو با یه قابلیت کاربردی MySQL آشنا کنم که شاید یه زمانی وقتی اوضاع زیرساخت شما طوفانی شد به کارتون بیاد.یک ناو باربری رو وسط دریا تصور کنید که داره غرق میشه. اولین کاری که باید بکنه چیه؟بله همونطور که خیلی هاتون حدس زدید، اولین کار خالی کردن بار تو دریاست، تا جایی که دیگه ریسکی وجود نداشته باشه.خب مثال بالا گویا هست. تو Business های IT هم خیلی این شرایط پیش میاد و به ویژه توی کشور ما که از نظر زیرساختی نوپا هستیم و مشکلات زیرساختی جزء جدایی ناپذیری از همه‌ی استارتاپ‌ها هستند. در چنین شرایطی، ما باید هرکاری می‌تونیم بکنیم که سیستم بالا بمونه و بتونه به کاربران سرویس بده.به عنوان مثال فرض کنید شما یک فروشگاه آنلاین دارید که علاوه بر بحث های مربوط به خرید کالا و ...، یک سری جدول هم برای آمارگیری در دیتابیس دارید که آمار مختلفی را در آن ذخیره می‌کنید.سیستم دچار بحران زیرساختی می‌شود و فشار روی دیتابیس MySQL شما زیاد می‌شود. باید هرچیزی که غیر از عملکرد عادی فروشگاه لازم است رو از کار بندازید تا فشارها روی دیتابیس کمتر بشه و از دسترس خارج نشه. یکی از اولین کارهایی که به ذهن میرسه خاموش کردن موقت این آمارگیری هاست اما فرض کنید که کد شما monolithic زده شده و اصلاح کردن کد نیازمند ادیت‌های بسیاری است که زمان بر هست.اینجاست که سیاه‌چاله به کمک شما میاد. سیاه‌چاله یا Black Hole که یکی از Engine های جدول های MySQL هست، اینطور رفتار می‌کنه که هر کوئری Write ای که روش زده بشه میگه OK و کاری انجام نمیده و جدول هم یک جدول خالی هست که دیتایی توش نیست.در واقع شما باید جدول آماری فعلیتون رو rename کنید به یه اسم دیگه، بعد یه جدول جدید با همون Schema ولی با Engine ای از جنس Black Hole بسازید و اسمش رو بگذارید همون اسم جدول اولی.با این کار شما فشار رو روی MySQL کمتر کردید بدون اینکه لازم باشه کدتون رو اصلاح کنید.نکته بسیار مهم: هیچ وقت Engine مربوط به یک جدول رو که حاوی دیتا هست، به Black Hole تغییر ندید چون کل دیتاهاش می‌ پره، برای همین گفتم که جدول اصلی رو Rename کرده و یک جدول جدید با همون اسم سابق و با Engine ای از نوع Black Hole بسازید. محمد سلیمانی فر محمد سلیمانی فر Thu, 19 Dec 2019 01:45:19 +0330 https://virgool.io/@mohammad7293/%D8%AE%D8%B7%D8%B1%DB%8C-%DA%A9%D9%87-%D8%A7%D8%B2-%D8%A8%DB%8C%D8%AE-%DA%AF%D9%88%D8%B4-%DB%B1%DB%B0%DB%B0%D9%87%D8%A7-%D9%87%D8%B2%D8%A7%D8%B1-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D9%92quiz-of-kings-%D8%B1%D8%AF-%D8%B4%D8%AF-owfxvnqbddp7 در لینوکس، Root سیستم عامل یکی از حساس‌ترین بخش‌هاییه که نباید پر بشه و باید همیشه حواسمون بهش باشه.ما هم نسبت به این مساله بی‌توجه نبودیم و یه Cronjob داشتیم که هر روز Root رو چک و خالی می‌کرد؛ اما یه چیز رو در نظر گرفته بودیم که یه روز کار دستمون داد.برای یک مسئله‌ای مجبور شدیم تعدادی Command تو سیستم Run کنیم و از قضا اون روز در زمان اجرای اون کامندها مشکلی خارجی برای سیستم پیش اومد که باعث شده بود کامندها Failed بشن و لاگشون رو بریزن تو /var/log/ .نتیجه این شد که Root سیستم ۹۹.۹٪ پر شد؛ دیگه توی اون سرور نمی‌شد هیچ کاری کرد، ولی با این حال داشت به Requestها پاسخ می‌داد و در واقع هنوز ۱۰۰ درصد Root پر نشده بود که به Down شدن منجر بشه. با این حال هیچ کامند Bashای دیگه نمی‌شد به صورت Manual توی اون سرور زد و همه چیز Freeze شده‌ بود.بحران اصلی این بود که این سرور، سرورِ Endpoint مربوط به DNS هم بود که با Down شدنش کل بازی Down می‌شد و یک Redis که Authentication انجام می‌داد هم روی این سرور Run بود که اگر اون هم لطمه می‌خورد، حجم قابل توجهی از کاربران نمی‌تونستن بازی کنن.دیگه نمی‌شد به اون سرور SSH هم زد؛ حتی با ILO هم نمی شد با Shell رفت توش و کاری کرد، چون همون اول Error میداد که Root پر شده و اجازه تایپ هیچ کامندی نمی‌داد.تنها راهی که به ذهنمون می‌رسید، این بود که یه زمانی که ترافیک کمه سرور رو دستی خاموش کنیم و هارد رو بیرون بکشیم و به یه سیستمی وصل کنیم و از طریق اون Root رو خالی کنیم؛ اما دیتاسنتر تو تعطیلات عید بودند و فردای اون روز هم نبودند و ما تا چند ساعت آینده قطعا Down می‌شدیم و Down شدن همانا و ۲ روز از دسترس خارج شدن کوییز همان.اما ناگهان یک اتفاقی افتاد! Cron job تخلیه Root اجرا شد و تونست یک اپسیلون از حجم چیزهایی که توی Root بود کم کنه. همین باعث شد حداقل بتونیم فقط یک کامند رو با موفقیت Run کنیم. فقط یک کامند! که با زدن همون کامند دوباره ترمینال Freeze می‌شد.هنوز نمی‌شد SSH زد و یا با ILO وصل شد؛ اما همون یک کامند دلگرمی بزرگی بود. به علاوه این‌که خوشبختانه من یه tmux تو یه سرور دیگه داشتم که توش چهار پنج تا تب ساختم بودم و چهار پنج تا SSH زده بودم به این سرور.تنها کامندی که گفتیم ریسک کنیم و بزنیم و مارو نجات داد این بود rm -rf /var/log و با زدن همین کامند نجات پیدا کردیم!نتایج اخلاقی:- همیشه یک Cronjob داشته باشید که root رو تمیز کنه و اگرچه /var/log/ غالبا اون‌قدر پر نمیشه که اذیت کنه؛ ولی تا جایی که میشه اون هم به صورت منظم پاک کنید.- چندین Endpoint برای DNSتون داشته باشید و سعی کنید از هر Resourceای حتما Replication داشته باشید (در این مورد ما به دلایلی نمی‌تونستیم از یه سری چیزهای حیاتی Replication داشته باشیم! ولی اگر می‌داشتیم، اصلا برامون جای نگرانی نبود).- همیشه تو چندین سرور tmux session داشته باشید و توش به همه‌ی سرورهایی که باهاشون کار می‌کنید SSH فعال داشته باشید. محمد سلیمانی فر محمد سلیمانی فر Thu, 19 Sep 2019 12:36:26 +0430