در این پروژه قصد داریم معماری چندین محصول معروف از موفق ترین شرکت های دنیای امروز را بررسی کنیم . در ابتدا هدف و نیاز های محصول را بشناسیم و سپس تحلیل کنیم چه چالش هایی باعث شده این شرکت ها به سمت این معماری ها بروند؟ نقش این معماری ها موفقیت این شرکت چه بوده؟ در هر یک از این معماری ها چه نقاط قوت و ضعفی وجود دارد ؟ درنهایت کاربرد این معماری ها را نسبت به هم مقایسه کنیم.
ابتدا باید ببینیم نرم افزار چه نیازمندی هایی دارد :
ابتدا به آمار زیر نگاه کنید :
![number of Spotify monthly active users (MAUs) worldwide from 2015 to 2021(in millions) [source]](https://files.virgool.io/upload/users/960081/posts/jxiz0vfostyc/whxcyf8popjq.jpeg)
شکل بالا تعداد کابران فعال اسپاتیفای را از اول سال ۲۰۱۵ تا فصل سوم سال ۲۰۲۱ نمایش داده است . همانطور که میبینید در طول ۶ سال بیش از ۳۰۰ میلیون و فقط در فصل آخر سال ۲۰۲۱ بیش از ۲۵ میلیون کاربر فعال جدید اضافه شده است.[منبع] در هر روز بیش از ۶۰ هزار آهنگ جدید آپلود میشود یعنی تقریبا هر ثانیه یک آهنگ به اسپاتیفای اضافه میشود. (منبع)
همچنین برنامه هایی مانند اسپاتیفای برای گرفتن مجوز فعالیت در کشور های مختلف مجبورند از قوانین حق موسیقی این کشور ها تبعیت کنند. مثلا شاید یک موسیقی در آمریکا مجوز بگیرید اما در آلمان نیازمند اصلاح باشد و در نتیجه اسپاتیفای با توجه به موقعیت کاربر باید نسخه دارای مجوز آن کشور را نمایش دهد. بعد پرداخت هزینه برای آهنگ ها (به سازمان ها و به ناشر ها و ..) برای هر کشور قوانین خاص خود را دارد . در کنار همه اینها بازار پر طرفدار موسیقی با ورود شرکت های بزرگی همچون گوگل و اپل ، کوچکترین غفلت ممکن است با از دست دادن میلیون ها کاربر همراه شود . پس بطور خلاصه میتوان گفت معماری برنامه اسپایتفای باید نیازمندی های زیر را برآورده کند :
حالا باید پرسید چگونه نرم افزاری همزمان از کاربران جدید پشتیبانی کند و کشور های جدید و قوانین آن ها را را اضافه کند و در عین حال با امکانات و نوآوری های جدید مانع مهاجرت کاربرانش به برنامه های رقیب شود. همه این نیازمندی ها در تقابل هم هستند . شاید اپلیکیشن های زیادی را به خاطر بیاورید که با افزایش کاربران کارایی خود را از دست داده باشند یا به دلیل مشکلات حقوقی از ادامه مسیر باز مانده باشند هر یک از چالش ها آنقدر بزرگ هستند که بتواند یک برنامه را متوقف کند. بیایید ببینیم اسپاتیفای با چه معماری نرم افزاری توانست از این چالش ها با موفقیت عبور کند ؟
پاسخ معماری میکروسرویس است در این معماری برنامه به سرویس های کوچک شکسته میشود و هر یک از این بخش ها توسط یک تیم مستقل پیاده سازی میشود .بفرض کنید یک قابلیت در اسپاتیفای میخواهد اضافه شود.اسپاتیافی در پلتفرم های مختلفی عرضه میشود و همه اینها باید این قابلیت را اضافه کنند (تیم توسعه اندروید ، تیم توسعه IOS ، وب و دسکتاپ و ...) بنابراین تیم های توسعه هر پلتفرم از تیم هسته مرکزی درخواست API های لازم برای اون قابلیت را میکنند. تیم هسته مرکزی درخواست پیاده سازی در سمت سرور را خواهد داشت . همچنین ممکن است تیم سرور از تیم زیرساخت بخواهد تا امکانات لازم برای توسعه این قابلیت را فراهم کند (امکانات زیر ساختی یا ساخت دیتابیس های لازم و ...)
تیم هسته مرکزی تعیین کننده کتابخانه و API های مشترک را دارد و در نقش واسط عمل میکند. ممکن است تیم پلتفرم مستقیما با تیم سرور در ارتباط باشد.
چالش این نوع پیاده سازی چیست ؟ synchronization
همانطور که توضیح داده شد در این پیاده سازی توسعه پلتفرم وابسته به پیاده سازی library های تیم هسته و خود ان وابسته پیاده سازی سمت سرور و آن وابسته به پیاده سازی زیرساخت است. این باعث کند شدن شدید توسعه خواهد شد. راهکار چیست؟
پیاده سازی قابلیت توسط یک تیم Full Stack. یعنی تیم ها هر کدام افرادی با تخصص های زیر را دارند
front -end developer , back-end developer ، test , UI Designer , Product Owner
پس پیاده سازی هر قابلیت به یک تیم سپرده می شود. وابستگی تیم ها حدف نمیشود اما به کمترین سطح کاهش می یابد معماری ها بصورت زیر میشود
جالب است بدانید اسپایتفای بیش از ۹۰ تیم و ۶۰۰ توسعه دهنده دارد که در ۵ ساختمان در دو کشور مشغول توسعه این برنامه هستند.( آمار مربوط به سال ۲۰۱۵ است )
اسپاتیفای هدف خود را داشتن صپ ها میلیون کاربر قرار داده بود به همین دلیل نیاز بود تا هر بخش بصورت مستقل توسعه پیدا کند تا بتواند در صورت لزوم مقیاس پذیر باشد. یک سرویس ساخته میشود کارایی و سرعت ان اطمینان پیدامیکنیم و حال میتوانیم در صورت لزوم کپی کنیم و جای دیگر سال ها بدون نگرانی استفاده کنیم. برای نمونه نگاهی به مزیت جداسازی سرویس و بخش ها در معماری برای مقیاس پذیری بندازید:
بیاید نگاهی به مزیت های این معماری بندازیم :
مشکلات این معماری:
هر وقت هر ویژگی برنامه یک سرویس کوچک باشد برنامه بزرگی مثل اسپاتیفای امروز صد ها سرویس دارد. جالب است بدانید در سال ۲۰۱۵ اسپاتیفای فقط ۸۱۰ سرویس فعال داشته و به طور متوسط برای هر تیم (squad) ۱۰ سرویس وجود داشته است .در چنین سیستمی مستند سازی بسیار اهمیت پیدا میکند. چراکه تیم ها بعد از پیاده سازی ویژگی و تست و کامل ممکن سراغ سرویس دیگری بروند و اگر بعد از مدتی نیاز به تغییر سرویس باشد بدون مستند سازی خوب بسیار دشوار خواهد بود.
سرویس های زیاد و ارتباط میان آنها اگرچه پیچیدگی را کاهش میدهند اما تاخیر در اجرا را به همراه خواهد اورد .
شکل زیر بخشی از سرویس های اسپاتیفای را به نمایش گذاشته است :
جالب است بدانید شرکت اسپاتیفای ابتدا از فرهنگ اسکرام در شرکت خود استفاده میکرد اما با افزایش رشد سریع متوجه شد دیگر قواعد اسکرام به هدف و شرکت آن ها کمک شایانی نمی کند و لذا شروع به تغییر بخش هایی از اسکرام کردند امروز از متد بهینه شده ای استفاده می کنند که در پست های بعدی درباره آن خواهم نوشت .
مزایا و معایب معماری میکروسرویس را در اسپاتیفای دیدیم اجازه بدهید نگاهی به نتفلیکس بیندازیم.
نت فلیکس در واقع یک شرکت پشتیبانی از محصولات تصویری است که در سال ۱۹۹۸ در آمریکا بنیان گذاری شد. بیشترین کاربران نتفلیکس در کشور آمریکا هستند. این شرکت در اولین مرحله پیشرفت ، اقدام به کرایه دی وی دی از فیلم های مختلف نمود. بعد از آن شروع به تولید محصولات و فیلم های مختلف نمود و در نهایت، پای خود را به کشور های مختلف باز کرد و در حال حاضر در بیش از ۱۹۰ کشور دنیا، مجری فعالیت های رسانه ای است. [منبع]
نتفلیکس بیش از ۲۰۰ میلیون کاربر و بیش از ۱۲۵ میلیون ساعت برنامه ویدیویی دارد .برای زیرساخت خود از بستر AWS استفاده میکند .سرور های نتفلیکس بر روی AWS در سه ناحیه جغرافیایی قرار دارد (دو تا در آمریکای شمالی و یکی در اروپا) .[منبع] و در حال حاضر بیش از ۱۰۰ هزار ماشین مجازی (سرور ) بر روی AWS دارد.[منبع]
در آگوست سال ۲۰۰۸ نتفلیکس به مدت چهار روز از دسترس خارج شد. و این سراغازی برای مهاجرت از معماری یکپارچه به سمت معماری میکروسرویس بود. در این سال نتفلیکس زیر ساخت خود را به سمت کلود و پایگاه داده های خود را از RDBMS به Cassandra منتقل کرد. همه این تصمیم ها برای فراهم کردن محیط مقیاس پذیر بود.
در شکل زیر ارتباط میان سرویس های مختلف و ترافیک عبور ی از آنها را مشاهده میکنید.[منبع]
معماری میکروسرویس در نتفلیکس همانند اسپاتیفای تیم ها کوچک که شامل تخصص های مختلف بودند وظیفه پیاده سازی سرویس ها را بر عهده گرفتند. مزایای و معایب معماری میکروسرویس طبیعتا مشابه است.
دو برنامه بزرگ اسپاتیفای و نتفلیکس و معماری آن ها را مرور کردیم دیدیم نتفلیکس مجبور شد در سال ۲۰۰۸ معماری خود را برای پشتیانی از کاربران بیشتر و مقیاس پذیری و توسعه ساده تر به میکروسرویس تغییر دهد و اسپاتیفای که در همان سال متولد شد از همان ابتدا با رویای میلیون ها کاربر معماری میکروسرویس را انتخاب کرد.
پشتیبانی از میلیون ها کاربر و مقیاس پذیر بودن ، همواره در دسترس بودن ، امنیت بالا در برابر حملات و نوآوری و توسعه سریع از جمله نیازمندی های مشترک شرکت های بزرگ است. شرکت ها راه حل های مشابهی برای حل این نیازمندی ها دارند. استفاده از معماری میکروسرویس بجای monolithic ، متدولوژی توسعه آجایل (چابک) جایگزین RUP ، استفاده از سرویس های کلود بجای زیرساخت اختصاصی و استفاده از CI/CD و کانتینرزیشن (مثل داکر ) راه حل هایی هستند که در کنار هم این نیازمندی ها را برطرف کرده اند و امکان میلیون های کاربر و توسعه سریع را برای شرکت ها مهیا کرده اند.
«این مطلب، تحقیقی در درس مهندسی نرم افزار پیشرفته در دانشگاه شهیدبهشتی است»
[1] https://www.youtube.com/watch?v=7LGPeBgNFuU
[3] https://www.youtube.com/watch?v=CZ3wIuvmHeM
[4] Analysis of Netflix architecture and business model
