میکروسرویس ها و مونولیث ها در صنعت بازی سازی

• میکروسرویس:

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

همانطور که گفته شده میکروسرویس ها یک معماری هستند، نه یک تکنولوژی یا استک(stack). بنابراین با رعایت کردن ویژگی های این معماری با هر تکنولوژی یا استک(stack) میتوان یک میکروسرویس یا مجموعه ای از میکروسرویس ها ایجاد کرد. که این معماری در طی زمان و در صنعت تکنولوژی تکامل پیدا کرده است.

• مونولیث:

در مقابل معماری میکروسرویس ها, معماری یکپارچه یا مونولیث (Monolith) قرار دارد که به معنای یکپارچه بودن اپلیکیشن هست و بر خلاف میکروسرویس ها در آن اپلیکیشن تنها شامل یک بخش بسیار بزرگ است.

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

اما همانطور یک مهندس نرم افزار دانا گفت: “گاهی اوقات یک مونولیث بهتر از یک میکروسرویس هست!”

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

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

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

• ژانر
• اندازه بازی

در استودیو های بازی سازی کوچکتر مونولیث برای شروع میتواند گزینه بسیار عالی باشد، با توجه به اینکه در این استودیو ها اکثرا بازی ها کوچک، غیر پیچیده، تیم توسعه کوچکتر، در نتیجه به معنای کاست زمانی کمتر، قابلیت نگه داری راحتتر و از نظر سرمایه گذاری نیازمند هزینه کمتری می باشند.
اما در زمانی که حرفی از مقیاس پذیری، انعطاف پذیری، پیچیدگی، گسترش و یا افزودن ویژگی های (فیچر ها) جدید می شود حق کاملا با میکروسرویس ها است.

برای مثال بیاید یک لیدربورد که بر اساس مقدار کاپ بازیکن ها است را در دو معماری مختلف پیاده سازی کنیم و تفاوت هاشون رو ببینیم:

مونولیث:

یک کد بیس وجود دارد، پس با ایجاد ساختار (یا فایل جدید) در کد بیس اصلی پروژه شروع میکنیم، پس انعطاف پذیری در انتخاب تکنولوژی نداریم و مجبوریم از استک اصلی پروژه استفاده کنیم که ممکن هست برای اینکار بهینه نباشد.

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

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

میکروسرویس:

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

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

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

این ها تنها یک خلاصه ی کوچکی از معرفی معماری میکروسرویس ها و مونولیث ها و استفاده آن ها در صنعت بازی سازی بود.

نویسنده: محمد امین خواجه امینیان