در این مطلب سعی شده معماری نرم افزار در چهار شرکت بزرگ یعنی امازون و نتفلیکس و اوبر و اسپاتیفای را بررسی کرده و بفهمیم که شرکت های بزرگ فناوری چگونه معماری نرم افزار خود را طوری طراحی کرده و توسعه دادند که بیتوانند در مقیاس بالا عملکرد مناسب و سیستمی پایدار ، توسعه پذیر واسان تغییر پذیر را داشته باشند؟
هرشرکت مسیر خود را با توجه به موضوع و کاری که انجام میدهد انتخاب کرده و هی آن را توسعه میدهد. این مطلب تلاش میکند تا تجربیات و کارهای این غول های فناوری را بررسی و برای استفاده در پروژه های دیگر تحلیل کند . در ابتدا معماری های مهم را بررسی و سپس معماری هر شرکت را بررسی میکنیم.
معماری Monolithic یا یکپارچه یکی از رایج ترین و قدیمی ترین روش ها برای طراحی نرم افزار است. در این رویکرد، بخش های اصلی سیستم مانند رابط کاربری، منطق کسب و کار، دسترسی به داده و ارتباط با سرویس‌های بیرونی، در قالب یک برنامه واحد توسعه و استقرار داده می شوند. این معماری مونولیتیک برای پروژه های کوچک تا متوسط، محصولات اولیه و تیم هایی که به توسعه سریع و زیر ساخت ساده نیاز دارند، انتخاب مناسبی است.
واژه‌ی Monolithic به ساختاری اشاره دارد که مانند یک بلوک واحد عمل می کند. در یک نرم‌افزار مونولیتیک، اجزا معمولا در یک کدبیس قرار دارند، به صورت هماهنگ ساخته می شوند و اغلب به شکل یک فایل اجرایی، یک سرویس وب یا یک بسته ی قابل استقرار منتشر می شوند.
برای مثال، در یک فروشگاه اینترنتی مونولیتیک، قابلیت های ثبت نام کاربران، نمایش محصولات، سبد خرید، پرداخت، مدیریت سفارش و پنل مدیریت ممکن است همگی در یک برنامه واحد پیاده سازی شده باشند.
محدودیت مهم Monolithic این است که با بزرگ شدن سامانه، وابستگی بین بخش ها زیاد می شود. در نتیجه، یک تغییر کوچک ممکن است باعث نیاز به تست و استقرار مجدد کل برنامه شود. همچنین، اگر فقط بخش پرداخت یا جست‌وجو تحت فشار قرار گیرد، ممکن است مجبور شویم کل سیستم را مقیاس دهیم.
معماری Microservices یک رویکرد برای توسعه نرم افزار است که در آن یک برنامه بزرگ به مجموعه ای از سرویس های کوچک، مستقل و قابل استقرار جدا گانه تقسیم می شود. هر میکروسرویس مسئول یک قابلیت مشخص کسب و کار است. برای مثال، مدیریت کاربران، پرداخت، سفارش ها یا ارسال اعلان ها.
مزایای معماری میکروسرویس
استقلال سرویس ها: تغییر، توسعه یا استقرار یک سرویس معمولا نیازمند تغییر در کل سیستم نیست.
مقیاس پذیری بهتر: فقط سرویس هایی که بار بیشتری دارند، مانند پرداخت یا جست و جو، به صورت جداگانه مقیاس بندی می شوند.
افزایش سرعت توسعه: تیم های مختلف می توانند هم زمان روی سرویس های متفاوت کار کنند.
کاهش اثر خرابی: خرابی یک سرویس لزوما باعث از کار افتادن کل سامانه نمی شود البته این موضوع به طراحی صحیح وابسته است.
انعطاف در فناوری: هر سرویس می تواند در صورت نیاز از زبان برنامه نویسی، پایگاه داده یا ابزار مناسب خود استفاده کند.
پشتیبانی از CI/CD: انتشار نسخه های کوچک و مکرر اسان تر می شود و تحویل مستمر بهتر انجام می گیرد.
نگهداری ساده تر کد: چون هر سرویس محدوده مسئولیت مشخص و کدبیس کوچک تری دارد، درک و تغییر ان معمولا راحت تر است.
معایب معماری میکروسرویس
پیچیدگی عملیاتی: مدیریت چندین سرویس، سرور، کانتینر، پایگاه داده و ارتباط شبکه ای دشوارتر از یک برنامه مونولیتیک است.
چالش ارتباطات شبکه ای: ارتباط بین سرویس ها ممکن است باعث افزایش تاخیر، خطا های شبکه و پیچیدگی در مدیریت درخواست ها شود.
مانیتورینگ و ردیابی دشوارتر: برای بررسی یک درخواست که از چند سرویس عبور میکند، به لاگ گیری متمرکز، Trace ID و ابزارهای مشاهده پذیری نیاز است.
امنیت گسترده تر: افزایش تعداد APIها و ارتباطات بین سرویس ها، سطح حمله را بیشتر می کند و نیازمند احراز هویت، مجوز دهی و رمزنگاری دقیق است.
مدیریت داده پیچیده: هر سرویس ممکن است پایگاه داده مستقل داشته باشد بنابراین هماهنگی داده‌ها و تراکنش های توزیع شده دشوار می شود.
هزینه بیشتر: زیرساخت، ابزار های DevOps، مانیتورینگ، تیم متخصص و نگهداری سرویس های متعدد میتواند هزینه را افزایش دهد.
نیاز به بلوغ تیم: این معماری به طراحی دقیق API، تست خودکار، CI/CD، مدیریت خطا و فرهنگ DevOps نیاز دارد.
معماری میکروسرویس برای سامانه های بزرگ، پیچیده و در حال رشد که تیم های متعدد روی ان کار می کنند، گزینه مناسبی است. این معماری امکان توسعه مستقل، مقیاس پذیری هدفمند و انتشار سریع تر قابلیت ها را فراهم میکند. با این حال، برای پروژه های کوچک یا تیم های کم تجربه، پیچیدگی و هزینه آن ممکن است بیشتر از مزایایش باشد.
معماری مونولیتیک و میکروسرویس دو رویکرد متفاوت برای طراحی و توسعه نرم افزار هستند. تفاوت اصلی ان ها در نحوه تقسیم بندی اجزای سیستم، استقرار، مقیاس پذیری و مدیریت تغییرات است.
در معماری مونولیتیک، تمام قابلیت های سیستم مانند رابط کاربری، منطق کسب وکار، دسترسی به داده و احراز هویت، در قالب یک برنامه واحد توسعه و مستقر می شوند. در مقابل، معماری میکروسرویس برنامه را به سرویس های کوچک تر و مستقل تقسیم می کند که هر سرویس مسئول یک قابلیت مشخص، مانند پرداخت، مدیریت کاربران یا سفارش ها است.
معماری مونولیتیک به دلیل سادگی، هزینه کمتر و سرعت توسعه اولیه، برای پروژه های کوچک تا متوسط و محصولات اولیه مناسب است. اما با افزایش پیچیدگی و تعداد قابلیت ها، نگهداری و تغییر آن دشوار تر می شود.
معماری میکروسرویس برای سامانه های بزرگ، در حال رشد و دارای تیم های توسعه متعدد مناسب تر است. این معماری انعطاف پذیری، مقیاس پذیری و استقلال بیشتری فراهم می کند، اما پیاده سازی و نگهداری ان به تجربه فنی، زیرساخت مناسب و فرایند های DevOps نیاز دارد.
معماری رایانش ابری (Cloud Computing Architecture) به مجموعه ای از اجزای سخت افزاری، نرم افزاری، شبکه ای و سرویس ها گفته می شود که امکان ارائه منابع فناوری اطلاعات از طریق اینترنت را فراهم می کنند. این منابع می‌توانند شامل سرور، توان پردازشی، فضای ذخیره سازی، پایگاه داده، شبکه و نرم افزار باشند.
در این معماری، کاربران بدون نیاز به خرید و نگهداری مستقیم تجهیزات فیزیکی، می توانند منابع مورد نیاز خود را از یک ارائه دهنده خدمات ابری دریافت کنند. کاربران از طریق بخش Front-End مانند مرورگر یا نرم افزار به خدمات دسترسی دارند و پردازش، ذخیره سازی و مدیریت منابع در بخش Back-End و مراکز داده ارائه دهنده انجام می شود.
مدل‌های اصلی خدمات ابری
SaaS (Software as a Service): ارائه نرم افزار اماده از طریق اینترنت. مانند نرم‌افزارهای حسابداری یا ایمیل ابری.
PaaS (Platform as a Service): ارائه بستر مورد نیاز برای توسعه، تست و استقرار نرم افزار.
IaaS (Infrastructure as a Service): ارائه زیر ساخت هایی مانند ماشین مجازی، شبکه و فضای ذخیره سازی.
Serverless: اجرای کد بر اساس درخواست و پرداخت هزینه متناسب با میزان مصرف، بدون مدیریت مستقیم سرور توسط کاربر.
همچنین از نظر نحوه استقرار، ابر میتواند به شکل عمومی (Public)، خصوصی (Private) یا ترکیبی (Hybrid) باشد.
مزایای معماری ابری
کاهش هزینه اولیه: نیازی به خرید سرور، تجهیزات شبکه و فضای ذخیره سازی فیزیکی نیست.
مقیاس پذیری: منابع پردازشی و ذخیره سازی را میتوان متناسب با میزان نیاز افزایش یا کاهش داد.
دسترسی از راه دور: کاربران می توانند از هر مکان و با اتصال اینترنت به سرویس ها و داده ها دسترسی داشته باشند.
نگهداری ساده تر: به‌روزرسانی زیرساخت، تعمیرات و بسیاری از امور عملیاتی توسط ارائه دهنده انجام می شود.
پشتیبان گیری و بازیابی: اغلب سرویس های ابری امکان Backup و بازیابی داده ها را فراهم می کنند.
بهبود همکاری تیمی: اعضای تیم می توانند به‌صورت هم زمان به داده ها و نرم افزار های مشترک دسترسی داشته باشند.
انعطاف در انتخاب سرویس: سازمان می تواند بر اساس نیاز خود از خدمات و مدل‌های مختلف ابری استفاده کند.
معایب معماری ابری
وابستگی به اینترنت: کیفیت پایین یا قطع اینترنت می تواند دسترسی به سرویس ها را مختل کند.
نگرانی های امنیت و حریم خصوصی: ذخیره داده ها نزد ارائه دهنده ابری نیازمند کنترل های امنیتی، رمزنگاری و مدیریت دقیق دسترسی ها است.
کنترل کمتر بر زیرساخت: در مدل های عمومی، کاربر کنترل کاملی بر سخت افزار و تنظیمات زیر ساختی ندارد.
هزینه های پیش بینی نشده: اگر مصرف منابع به درستی مدیریت نشود، هزینه سرویس می تواند افزایش یابد.
وابستگی به ارائه دهنده: انتقال داده ها و سرویس ها به ارائه دهنده دیگر ممکن است دشوار و زمان بر باشد.
چالش های انطباق و مقررات: برخی داده های حساس ممکن است مشمول قوانین محل نگهداری داده یا الزامات امنیتی خاص باشند.
تاخیر شبکه: در برنامه‌های بلادرنگ یا حساس به تاخیر، فاصله شبکه ای با مرکز داده می تواند بر عملکرد اثر بگذارد.
معماری ابری روشی انعطاف پذیر برای استفاده از منابع فناوری اطلاعات است که هزینه تهیه و نگهداری زیر ساخت های فیزیکی را کاهش می دهد. این معماری برای بسیاری از کسب وکار ها، به ویژه سازمان هایی که به مقیاس پذیری، دسترسی اسان و توسعه سریع نیاز دارند، مناسب است. با این حال، انتخاب مدل ابری باید با توجه به نیاز های امنیتی، هزینه، حساسیت داده ها و وابستگی به اینترنت انجام شود.
مهم‌ترین ریسک Cloud Architecture، وابستگی به ارائه دهنده‌ی خدمات ابری یا است. علاوه بر ان، کنترل هزینه در صورت نبود نظارت مالی و فنی مناسب میتواند دشوار شود. امنیت Cloud نیز مسئولیت مشترک میان ارائه دهنده و شرکت استفاده کننده است. بنابراین، پیکربندی نادرست میتواند منجر به اسیب پذیری شود.
AWS یا Amazon Web Services یک معماری رایانش ابری مبتنی بر مجموعه ای از سرویس های مستقل و قابل اتصال است. این پلتفرم به سازمان ها و توسعه دهندگان اجازه می دهد منابعی مانند سرور، فضای ذخیره سازی، پایگاه داده، شبکه و ابزارهای امنیتی را از طریق اینترنت دریافت کنند؛ بدون ان که نیاز به خرید و نگهداری مستقیم تجهیزات فیزیکی داشته باشند.
در معماری AWS، هر سرویس وظیفه مشخصی دارد و از طریق API با سرویس های دیگر ارتباط برقرار می کند.
AWS بر پایه مراکز داده توزیع شده در مناطق جغرافیایی مختلف طراحی شده است. این ساختار باعث افزایش دسترس پذیری، تحمل خطا، امنیت و مقیاس پذیری می شود. برای نمونه، اگر میزان درخواست های یک برنامه افزایش یابد، میتوان منابع پردازشی را به صورت خودکار افزایش داد، بدون اینکه نیاز به خرید سرور جدید باشد.
مدل هزینه در AWS کاربر تنها براساس میزان استفاده از منابع هزینه پرداخت می کند. در نتیجه، AWS به کسب وکارها کمک میکند زیرساخت فناوری خود را با انعطاف بیشتر، هزینه اولیه کمتر و امکان توسعه سریع تر مدیریت کنند.
به‌طور کلی، Monolithic بهترین گزینه برای شروع سریع، محصولات اولیه و شرکت های کوچک است.
Microservices برای شرکت های بزرگ‌تر، سامانه های پیچیده، ترافیک بالا و تیم های متعدد مناسب است؛ اما فقط زمانی باید انتخاب شود که سازمان توان مدیریت پیچیدگی فنی و عملیاتی ان را داشته باشد.
Cloud Architecture نیز برای شرکت هایی که به انعطاف پذیری، راه اندازی سریع، مقیاس پذیری و کاهش هزینه‌ی اولیه ی زیرساخت نیاز دارند، مناسب است. هرچند در سازمان‌های دارای محدودیت‌های شدید امنیتی، حاکمیت داده یا نیازهای latency پایین، استفاده از Private Cloud، Hybrid Cloud یا Edge Computing باید بررسی شود.
امازون کارش را در سال 1994 با این ایده شروع کرد که یک فروشگاه اینترنتی برای فروش کتاب باشد. در ابتدای کار ساختار برنامه امازون ساده بود و از معماری یکپارچه استفاده میکرد. یعنی همه ی قسمت ها به هم وصل بودند و داخل یکی سیستم کار میکردند. اما این مدل به درد شرکت های کوچک میخورد و با رشد سریع شرکت و افزایش کالا و کاربر دیگر جوابگو نبود. اگر یک بخش از سیستم مشکل پیدا میکرد کل سیستم بهم میریخت و تغییر دادن یه قسمت از برنامه خیلی سخت بود و همه چی بهم وابسته بود.
به همین دلیل امازون تصمیم گرفت روش خود را عوض کند. به جای اینکه همه چیز داخل یک برنامه بزرگ بماند، بخش های مختلف را از هم جدا کرد. مثلا یک قسمت برای جستجو، یک قسمت برای سفارش، یک قسمت برای سبد خرید و بخش های دیگر. اینگونه سیستم از حالت یکپارچه به سمت سرویس های کوچک جدا جدا رفت. هر بخش می توانست مستقل تر کار کند و لازم نبود کل برنامه برای یک تغییر کوچک دست بخورد. اینگونه اگر بخشی دچار مشکل میشد بخش های دیگر به کار خود بدون خرابی ادامه میدادند. این مدل معماری باعث شد شرکت رشد سریع تر و راحت تری داشته باشد. هر بخش می توانست مستقل تر کار کند و لازم نبود کل برنامه برای یک تغییر کوچک دست بخورد.
بعد از اینکه امازون به سمت میکروسرویس‌ها رفت، در کنار این تغییر معماری، خود امازون هم از یک فروشگاه کتاب ساده به یک پلتفرم خیلی بزرگ تبدیل شد. یعنی فقط فروشنده کالا نبود، بلکه بعدا فروشندگان دیگر هم وارد شدند، سرویس های جدید اضافه شدند، انبارداری و ارسال کالا هم جدی تر شد برای همین شروع به استفاده معماری مختلف مناسب با هر بخش کرد.
مثلا دربخش امازون موزیک از معماری رویداد محور استفاده شد. در این مدل، سیستم منتظر نمی ماند تا یک دستور مستقیم صادر شود، بلکه به محض اینکه یک اتفاق می افتد. یک پیام در کل سیستم پخش می شود. حالا هر بخش دیگری که به ان پیام نیاز داشته باشد پیام را می گیرد و کار خودش را انجام می دهد. این کار باعث می شود سیستم خیلی سریع و بدون اینکه بخش ها منتظر هم بمانند واکنش نشان دهد.
یا دربخش امازون ویدیو که در ان حجم عظیمی از فایل های سنگین وجود دارد ، از معماری محتوا محور استفاده میکند. در این مدل، تمرکز اصلی روی خودِ فایل یا همان محتواست. یعنی معماری اینجا طوری چیده شده که هدف اصلی‌اش مدیریت و رساندن سریع محتوا به دست کاربر باشد.
در اوایل تغییر معماری یکپارچه به میکروسرویس هر تیم که میخواست سرویس جدید بسازد باید ماه ها وقت صرف می کرد تا سرورها و پایگاه داده ها را اماده کند. این کار باعث می شد سرعت نواوری خیلی پایین بیاید. به همین دلیل مهندسان امازون به این نتیجه رسیدند که باید یک زیرساخت مشترک و استاندارد برای همه تیم ها بسازند.
بخش دیگری که به امازون اضافه شد بخش سرویس های ابری یا همان AWS. در AWS هزاران شرکت از یک زیرساخت استفاده می کنند، اما داده ها و کارهای هر شرکت کاملا از بقیه جدا و امن است. این کار باعث می شود امازون هم هزینه را پایین بیاورد و هم بتواند به همه سرویس بدهد.این بخش در ابتدا مخصوص خود امازون بود یعنی اول برای اینکه خود امازون بتواند سیستمش را بهتر مدیریت کند ساخته شد، ولی بعد فهمیدند این زیرساخت برای بقیه شرکت ها هم خیلی ارزش دارد. برای همین ان را به یک سرویس بزرگ عمومی تبدیل کردند.
معماری AWS باعث شد که دنیای نرم‌افزار عوض شود. قبل از ان، ساختن یک اپلیکیشن بزرگ نیاز به سرمایه میلیاردی برای خرید سرور و استخدام متخصص سخت افزار داشت. اما با AWS، الان یک تیم کوچک دو نفره در یک گاراژ میتواند اپلیکیشنی بسازد که میلیون ها کاربر همزمان داشته باشد، چون تمام ان پیچیدگی های فنی و زیرساختی را امازون برایشان حل کرده است. این معماری نه تنها باعث موفقیت خود امازون شد، بلکه الان ستون فقرات اینترنت مدرن محسوب می شود.
از کار های دیگری که امازون کرد ، برای مدیریت سرویس های پیچیده یک فرهنگ خاص هم برای مهندس هایش درست کرد. ان ها از قانون تیم های دو پیتزایی استفاده کردند. یعنی تیم ها باید انقدر کوچک باشند که با دو تا پیتزا سیر شوند.
وقتی تعداد ادم ها زیاد میشود تصمیم گیری و هماهنگی سخت میشود اما وقتی تیم کوچک باشد، هر کسی نقش مشخصی دارد و همه دقیقا میدانند مسئول چه چیزی هستند. این کار باعث شد تیم ها مستقل شوند، خیلی سریع تصمیم بگیرند و چون هر تیم مسئول یک بخش کوچک و مشخص بود، دیگر ان اشفتگی و کندی دوران قدیمی را نداشتند. نواوری بیشتر شد، تیم کوچک راحت تر ایده جدید را امتحان میکند. و مسئولیت پذیری بالا رفت.
موفقیت امازون در این است که توانست سیستم های پیچیده را به واحد های ساده و قابل مدیریت تبدیل کند. ان ها معماری نرم افزار را از حالت یکپارچه و متمرکز به توزیع شده و خود مختار تغییر دادند و در کنار ان، فرهنگی را بنا نهادند که در ان تیم های کوچک قدرت انجام کارهای بسیار بزرگ را دارند. این ترکیب، امازون را از یک کتاب فروشی کوچک به ستون فقرات اینترنت مدرن تبدیل کرد.
قبل از اسپاتیفای خیلی از ادم ها موسیقی را از راه های غیر قانونی دانلود میکردند، یا باید برای خرید هر اهنگ و البوم پول جدا میدادند. این کار هم برای کاربر سخت بود، هم برای هنرمند ها و شرکت های موسیقی مشکل درست میکرد، چون درامد واقعی موسیقی به دست صاحب اثر نمیرسید. اسپاتیفای تلاش کرد بین این دو طرف یک راه میانه بسازد. یعنی کاربر بتواند راحت و سریع به موسیقی برسد، و از طرف دیگر هنرمندها هم از پخش شدن اهنگ هایشان درامد داشته باشند.
ایده اصلی اسپاتیفای این بود که کاربر لازم نباشد موسیقی را دانلود کند و فایل ها را جدا جدا نگه دارد. کاربر فقط برنامه را باز میکرد، اهنگ مورد نظرش را سرچ میکرد و همان لحظه گوش میداد. این کار تجربه گوش دادن به موسیقی را خیلی ساده تر کرد. همه چیز داخل یک برنامه قرار گرفت: جستجوی آهنگ، ساخت پلی لیست، دنبال کردن خواننده ها، دیدن آلبوم ها، ذخیره آهنگ های مورد علاقه و گرفتن پیشنهادهای جدید.
اسپاتیفای بیشتر روی موسیقی تمرکز داشت اما به مرور زمان پادکست، محتوای صوتی، پلی لیست های هوشمند، پیشنهادهای شخصی سازی شده و امکانات اجتماعی هم به ان اضافه شد. اما چیزی که اسپاتیفای را واقعا موفق کرد فقط زیاد بودن آهنگ ها یا ظاهر خوب برنامه نبود بلکه معماری قوی ان بود.
اسپاتیفای برای اینکه بتواند این حجم بزرگ از کاربر، آهنگ، درخواست و داده را مدیریت کند، از معماری میکرو سرویس استفاده کرد. یعنی به بخش های کوچک کوچک تقسیم شد. هر بخش یک کار مشخص و محدود دارد. مثلا یک سرویس مسئول ورود کاربر است ویک سرویس مسئول جستجوی آهنگ هاست و سرویس های دیگر هرکدام مسئول کار مخصوص خود هستند. اگر همه قابلیت ها در یک سیستم بزرگ قرار میگرفتند اگر برای قسمتی مشکل پیش میامد کل سیستم از کار میافتاد چون همه چیز به هم وصل بود. به همین دلیل برای برنامه ای مثل اسپاتیفای، معماری یک تکه در بلند مدت مناسب نبود.
این معماری اجازه میداد برنامه مرحله به مرحله بزرگ شود. هر قابلیت جدید میتوانست به شکل یک سرویس جدید یا توسعه یک سرویس موجود اضافه شود. تیم ها میتوانستند مستقل روی بخش های مختلف کار کنند. خطاها محدود تر میشدند. مقیاس پذیری راحت تر میشد. تست و انتشار هر بخش ساده تر میشد. در نهایت این معماری به اسپاتیفای کمک کرد هم از نظر فنی رشد کند، هم از نظر محصولی سریع تر تغییر کند.
میکروسرویس مزیت های زیادی دارد، اما مشکلات خودش را هم دارد. وقتی تعداد سرویس ها زیاد میشود، نظارت روی انها سخت تر میشود. یکی دیگر از مشکلات میکروسرویس این است که ارتباط بین سرویس ها ممکن است تاخیر ایجاد کند. در یک برنامه یک تکه، بخش های مختلف داخل یک برنامه با هم ارتباط دارند، اما در میکروسرویس ممکن است یک درخواست از چند سرویس عبور کند. هر ارتباط شبکه ای کمی زمان میگیرد. اگر این ارتباط ها زیاد و تو در تو شوند، سرعت سیستم پایین می آید. برای همین طراحی درست مرز سرویس ها خیلی مهم است. اسپاتیفای باید مراقب میبود که سرویس ها انقدر کوچک و زیاد نشوند که ارتباط بین انها خودش تبدیل به مشکل شود.
اما اسپاتیفای فقط از نظر نرم افزاری به بخش های کوچک تقسیم نشد. ساختار تیم هایش هم شبیه همین معماری بود. انها تیم های کوچک و مستقل ساختند که هر کدام مسئول یک بخش از محصول بودند. معماری نرم افزار و ساختار تیمی باید با هم هماهنگ باشند. وقتی سیستم از میکروسرویس ساخته شده، بهتر است تیم ها هم کوچک و مستقل باشند. اگر تیم ها خیلی بزرگ و وابسته باشند، مزیت میکروسرویس از بین میرود. چون هر تغییر باز هم نیاز به هماهنگی زیاد پیدا میکند اسپاتیفای با کوچک کردن و مستقل کردن تیم ها تلاش کرد کاری کند که هر تیم بتواند سریع تصمیم بگیرد، سریع بسازد، سریع تست کند و سریع منتشر کند.
ساختار سازمانی چابک اسپاتیفای ساختار سازمانی چابک اسپاتیفای به گونه‌ای طراحی شده است که با معماری میکروسرویس ان هماهنگ باشد. چون سیستم اسپاتیفای از سرویس های کوچک و مستقل تشکیل شده است. تیم های کاری نیز باید کوچک و مستقل و مسئول یک بخش مشخص از محصول باشند. مهم ترین واحد در این ساختار، Squad است. یک تیم چند تخصصی که مسئولیت کامل یک قابلیت است.
چند Squad که در یک حوزه نزدیک فعالیت دارند، یک Tribe را تشکیل می دهند. Tribe باعث میشود تیم های مستقل در یک مسیر محصولی مشترک حرکت کنند و از انجام کارهای تکراری یا ناسازگار جلوگیری شود. برای حفظ استاندارد های فنی نیز از Chapter استفاده میشود؛. Chapter شامل افراد با تخصص مشابه است که ممکن است درSquad های مختلف باشند، اما درباره استاندارد های کد نویسی، تست، امنیت و ابزارهای مشترک با هم هماهنگ می شوند. همچنین Guild ها گروه های داوطلبانه ای هستند که افراد علاقه مند از تیم های مختلف در ان ها دانش و تجربه خود را درباره موضوعاتی مختلف دربارهی نرم افزار به اشتراک می گذارند.
در مجموع، مدل اسپاتیفای تلاش میکند میان استقلال و هماهنگی تعادل برقرار کند. Squad ها ازادی دارند سریع تصمیم بگیرند و قابلیت های جدید را توسعه دهند، اما Tribe ، Chapter و Guild مانع می شوند که این استقلال به بی نظمی فنی و سازمانی تبدیل شود. این ساختار به اسپاتیفای کمک کرده است تا هم زمان با رشد تعداد کاربران و پیچیده تر شدن محصول، سرعت نواوری، مسئولیت پذیری تیم ها و کیفیت فنی سیستم را حفظ کند.
میکروسرویس مزیت های زیادی دارد، اما مشکلات خودش را هم دارد. وقتی تعداد سرویس ها زیاد میشود، نظارت روی انها سخت تر میشود. یکی دیگر از مشکلات میکروسرویس این است که ارتباط بین سرویس ها ممکن است تاخیر ایجاد کند. در یک برنامه یک تکه، بخش های مختلف داخل یک برنامه با هم ارتباط دارند، اما در میکروسرویس ممکن است یک درخواست از چند سرویس عبور کند. هر ارتباط شبکه ای کمی زمان میگیرد. اگر این ارتباط ها زیاد و تو در تو شوند، سرعت سیستم پایین می آید. برای همین طراحی درست مرز سرویس ها خیلی مهم است. اسپاتیفای باید مراقب میبود که سرویس ها انقدر کوچک و زیاد نشوند که ارتباط بین انها خودش تبدیل به مشکل شود.
نتفلیکس در ابتدا فقط یک سرویس اجاره DVD بود. در ابتدای کار از معماری مونولیتیک استفاده میکرد. در سال 2008 دیتابیس ان خراب شد و کل سرویس چند روز از کار افتاد .به همین دلیل معماران ان تصمیم گرفتند که به سمت معماری میکروسرویس بروند. اینگونه اگر برای مثل سرویس جستجوی فیلم خراب بشود، کل نتفلیکس از کار نمیفتدهنوز میتوان فیلم دید، فقط شاید نتوانی فیلم جدید جستجو کنی. این یعنی پایداری سیستم خیلی بیشتر می شود.
نتفلیکس بعد از این تغییر، سیستم خود را به دو بخش اصلی تقسیم کرد. بخش اول Control Plane بود که روی AWS اجرا میشد و کارهایی مثل ورود کاربر، مدیریت حساب، جستجو و پیشنهاد محتوا را انجام میداد. این بخش قبل از شروع پخش ویدیو فعال است و بیشتر با اطلاعات کاربر و منطق برنامه سروکار دارد. بخش دوم Data Plane بود که وظیفه اصلی ان پخش ویدیو است. برای این بخش، نتفلیکس سیستم Open Connect را طراحی کردذ. Open Connect شبکه ای از سخت افزارهای اختصاصی است که در مراکز شرکت های اینترنتی یا ISP ها قرار می گیرد تا محتوا از نزدیک ترین نقطه ممکن به کاربر ارسال شود. این کار باعث میشد ویدیو سریع تر شروع شود، کیفیت پخش بهتر باشد و فشار کمتری به شبکه وارد شود.
یکی از مهم ترین ویژگی های نتفلیکس این بود که سیستم خود را طوری طراحی کرد که در برابر خرابی مقاوم باشد. این شرکت ابزارهایی مثل Chaos Monkey را به کار گرفت تا به صورت عمدی و تصادفی بعضی از سرورها را از کار بیندازد و سیستم را در شرایط واقعی خرابی ازمایش کند. هدف این بود که سرویس ها یاد بگیرند بدون وابستگی شدید به یک سرور خاص، همچنان به کار خود ادامه دهند.
تفلیکس برای ذخیره و مدیریت داده ها از چند ابزار مختلف متناسب با نیاز هر بخش استفاده کرده است. برای داده های حساس و دقیق مانند اطلاعات حساب کاربر و پرداخت ها از MySQL استفاده کرد و برای داده های بسیار حجیم مانند سابقه تماشا ی کاربران از Cassandra استفاده کرده است. همچنین برای بالا بردن سرعت پاسخ دهی، کش اختصاصی خود به نام EV Cache را توسعه داد تا داده های پرتکرار را سریع تر در اختیار سرویس ها قرار دهد.
دلیل موفقیت نتفلیک این بود که فهمید سیستم باید منعطف باشد و به همین دلیل معماری خود را از یک سیستم یکپارچه و آسیب پذیر به یک ساختار تکه تکه، مستقل و مقاوم تغییر داد. همین تغییر باعث شد وقتی کاربر دکمه Play را میزند، پشت صحنه تعداد زیادی سرویس مختلف در چند میلی ثانیه با هم ارتباط برقرار کنند، هویت کاربر بررسی شود، کیفیت اینترنت سنجیده شود، بهترین سرور انتخاب شود و ویدیو بدون تاخیر شروع به پخش کند. تمام این روند ساده ای که کاربر میبیند، نتیجه سال ها طراحی دقیق، آزمون و خطا و استفاده از معماری میکروسرویس در نتفلیکس است. به همین خاطر، نتفلیکس از یک سرویس ساده اجاره دی وی دی پستی به یکی از بزرگ ترین پلتفرم های استریم جهان تبدیل شد.
اوبر (Uber) یک پلتفرم دیجیتال مسافربری است. اوبر در ابتدا به عنوان یک سرویس درخواست خودرو فعالیت خود را اغاز کرد، اما به مرور به یک پلتفرم گسترده تر تبدیل شد. با افزایش کاربران، تعداد رانندگان و حجم سفرها، اوبر از یک استارتاپ کوچک به یک پلتفرم جهانی تبدیل شد. این رشد سریع باعث شد نیازهای فنی ان نیز پیچیده تر شود. زیرا سیستم باید بتواند موقعیت تعداد زیادی راننده را به صورت لحظه ای پردازش کند، مسافر و راننده را سریع تطبیق دهد، پرداخت را مدیریت کند و در عین حال همیشه در دسترس باقی بماند.
اوبر در ابتدا از معماری یکپارچه استفاده میکرد یعنی بیشتر قابلیت ها در یک برنامه اصلی قرار داشتند. با افزایش تعداد کاربران و گسترش خدمات، این ساختاردیگر پاسخ گو نبود.
معماری اوبر مجموعه ای از سرویس ها، پایگاه های داده و زیرساخت های ارتباطی است که با همکاری یکدیگر فرایند درخواست تا پایان سفر را مدیریت می کنند. این معماری به صورت توزیع شده و سرویس محور طراحی شده است. یعنی به جای ان که همه قابلیت ها در یک برنامه بزرگ قرار بگیرند، هر بخش به شکل یک سرویس مستقل مسئول وظیفه مشخصی است. این نوع طراحی به اوبر کمک می کند تا در مقیاس بزرگ کار کند و در زمان افزایش تقاضا، فقط بخش های مورد نیاز را گسترش دهد. در نتیجه، معماری فعلی اوبر میتواند داده‌های مکانی و درخواست‌های سفر را به صورت بلادرنگ پردازش کند و خدمات پایدار و سریع ارائه دهد.
توییتر یه برنامه ساده بودکه در ابتدای کار فقط قرار بود در ان مردم حرف هاشون رو بگویند . در ابتدا محدودیت داشت که بیشتر از 140 کارکتر نمیشد در ان نوشت. عملکرد ان اینگونه بود که توچیزی مینوشتی و بقیه میدیدند یا دنبالت میکردند. اما با گسترش کاربرا توییتر باچالش مواجه شد.
در اوایل کار توییتر با معماری یکپارچه ساخته شد. بسیاری از این پردازش ها به صورت مستقیم و هم زمان انجام میشد. یعنی هنگام انتشار یک توییت، سیستم باید فهرست دنبال کنندههای نویسنده را پیدا میکرد و سپس توییت را برای تایم لاین هر کدام از انها اماده میکرد. این روش برای افراد با دنبال کننده کم مشکل نداشت اما هرگاه که شخص مهمی توییت میزد به دلیل دنبال کننده های زیاد ان شخص سایت دچار مشکل میشد و از کار میافتاد.
برای حل این مشکل، توییتر معماریش رو کاملا تغییر داد و به سراغ میکروسرویس رفت. مثلا یه سرویس فقط مسئول ذخیره توییت بود و دیگری مسئول جست و جو. مزیت این روش ان بود که هر سرویس میتوانست جداگانه توسعه پیدا کند، مقیاس خود را افزایش دهد و در صورت نیاز با فناوری مناسب همان کار پیاده سازی شود.
توییتر در بعضی بخش های حساس از زبان هایی مانند Java و Scala نیز استفاده کرد. هدف از این کار، افزایش سرعت، توان پردازش و پایداری سرویس هایی بود که باید تعداد زیادی درخواست را در مدت کوتاه پاسخ دهند. البته تغییر زبان برنامه نویسی به تنهایی مشکل را حل نمیکرد بلکه این تغییر در کنار تقسیم برنامه به سرویس های مستقل، استفاده از کش، صف های پیام و طراحی توزیع شده، باعث بهتر شدن عملکرد سیستم شد.
مهم ترین تغییر در این مسیر، مربوط به نحوه ساخت تایم لاین کاربران بود. توییتر برای این کار از یک مدل ترکیبی یا Hybrid استفاده کرد. این مدل ترکیبی، دو روش اصلی به نام های Push و Pull را با هم ترکیب میکند.
در روش اول، یعنی Push ، اماده سازی تایم لاین در زمان انتشار توییت انجام میشود. فرض کنید یک کاربر معمولی حدود ۱۰۰ یا ۲۰۰ فالوور دارد. وقتی این کاربر توییتی منتشر میکند، سیستم فهرست فالوورهای او را پیدا میکند و اطلاعات توییت را در محل مناسب برای تایم لاین آانها قرار میدهد. این اطلاعات معمولا در حافظه Cache نگهداری میشود.
در این حالت، وقتی یکی از فالوورها برنامه را باز میکند، سیستم مجبور نیست دوباره همه توییت های افراد دنبال شده را از پایگاه داده اصلی پیدا کند. بخش زیادی از تایم لاین از قبل اماده شده است و فقط از کش خوانده میشود. به همین دلیل، نمایش تایم لاین سریع انجام میشود و تعداد درخواست های مستقیم به پایگاه داده کاهش پیدا میکند.
روش Push برای کاربران عادی مناسب است، چون تعداد فالوورهای انها معمولا محدود است. اگر یک کاربر ۱۰۰ فالوور داشته باشد، اماده کردن تایم لاین برای این ۱۰۰ نفر فشار زیادی به سیستم وارد نمیکند. اما همین روش برای یک کاربر مشهور مناسب نیست. اگر یک فرد میلیون ها فالوور داشته باشد، انتشار یک توییت میتواند باعث ایجاد میلیون ها عملیات جداگانه شود. در چنین شرایطی، مشکل اصلی در زمان نوشتن توییت ایجاد میشود.
برای حل این مسئله، توییتر برای کاربران بسیار معروف از روش دوم، یعنی Pull یا استفاده کرد. در این روش، هنگام انتشار توییت، سیستم تلاش نمیکند ان را برای تمام فالوورها کپی کند. توییت فقط یک بار در محل اصلی ذخیره میشود و اطلاعات مربوط به ان کاربر در کش یا سیستم ذخیره سازی مناسب قرار میگیرد.
سپس زمانی که یکی از فالوورها تایم لاین خود را باز میکند، سیستم بررسی میکند که ایا ان کاربر مشهور توییت جدیدی منتشر کرده است یا نه. اگر چنین توییتی وجود داشته باشد، سیستم ان را در همان لحظه دریافت میکند و با سایر توییت های موجود در تایم لاین ترکیب میکند. به این ترتیب، هزینه پردازش از زمان انتشار به زمان مشاهده تایم لاین منتقل میشود. به همین دلیل، این معماری را Hybrid Fan-out مینامند. هدف اصلی ان، ایجاد تعادل میان سرعت نمایش تایم لاین و کاهش فشار هنگام انتشار توییت است.
ستفاده از کش نیز نقش مهمی در این معماری داشت. کش یک فضای ذخیره سازی سریع است که اطلاعات پر استفاده را برای مدت مشخص نگهداری میکند. اگر تایم لاین کاربران هر بار مستقیما از پایگاه داده اصلی خوانده شود، تعداد درخواست ها بسیار زیاد خواهد شد. اما وقتی اطلاعات پرکاربرد در کش قرار میگیرد، سیستم میتواند انها را با سرعت بیشتری در اختیار کاربران بگذارد.
توییتر برای جدا کردن وظایف مختلف از صف های پیام و معماری رویداد محور نیز استفاده کرد. برای مثال، بعد از انتشار یک توییت، لازم نیست تمام کارهای مربوط به آن در همان لحظه و در یک درخواست انجام شود. سیستم میتواند ابتدا توییت را ذخیره کند و سپس رویدادهایی مانند به روزرسانی تایم لاین، ارسال اعلان، ایجاد اطلاعات جستجو و تحلیل داده را از طریق صف پیام به سرویس های دیگر بسپارد. این کار باعث میشود کاربر سریع تر پاسخ بگیرد و پردازش های سنگین در پس زمینه انجام شوند.
رای جستجو نیز استفاده از موتورهای تخصصی مانند Apache Lucene میتواند سرعت پیدا کردن توییت ها را افزایش دهد. چنین موتورهایی برای جستجوی متنی و ایجاد ایندکس طراحی شده اند و معمولا برای این کار مناسب تر از جستجوی ساده در یک پایگاه داده رابطه ای هستند. ستفاده از شناسه هایی مانند Snowflake ID نیز برای مدیریت توییت ها در محیط توزیع شده اهمیت داشت.
معماری جدید با جدا کردن سرویس ها، استفاده از کش، پردازش های غیر هم زمان، صف های پیام و مدل ترکیبی Push و Pull، این مشکل را تا حد زیادی کنترل کرد. در این مدل، توییت های کاربران عادی از قبل برای فالوورها آماده میشوند تا تایم لاین سریع نمایش داده شود. در مقابل، توییت های کاربران مشهور هنگام مشاهده تایم لاین دریافت و ترکیب میشوند تا انتشار یک توییت باعث ایجاد میلیون ها عملیات هم زمان نشود.
به همین دلیل، معماری جدید توییتر نسبت به معماری قبلی مقیاس پذیرتر، انعطاف پذیرتر و مقاوم تر بود. اگر یک سرویس مانند جستجو با مشکل روبرو میشد، لزوما تمام بخش های توییتر از کار نمی افتادند. همچنین، هر سرویس میتوانست جداگانه توسعه پیدا کند و در صورت افزایش بار، منابع بیشتری دریافت کند. در واقع، توییتر از یک برنامه ساده و یکپارچه به یک پلتفرم توزیع شده تبدیل شد که هر بخش آن برای انجام یک وظیفه مشخص طراحی شده بود.
میهن وب‌هوست (MihanWebHost): بررسی و تحلیل معماری مونولیتیک (Monolithic Architecture)
هم‌روش (Hamravesh): مفاهیم پایه و ویژگی‌های معماری مونولیتیک
مبین هاست (MobinHost): مزایا و معایب معماری مونولیتیک
۷ لرن (7Learn): مفاهیم و ساختار معماری مونولیتیک
فرادرس (Faradars): آشنایی با معماری میکروسرویس (Microservices)
نیک‌آموز (NikAmooz): بررسی تخصصی میکروسرویس
ویرگول (Virgool): تحلیل معماری و الگوهای نتفلیکس و اسپاتیفای
کار و کسب (KaroKasb): بررسی مدل چابک (Agile) در سازمان اسپاتیفای
مارکیتو (Markito): بررسی تاریخچه و ساختار آمازون
زومیت (Zoomit): بررسی تاریخچه و تکامل برند آمازون
سپیدار سیستم (Sepidar System): مفاهیم معماری رایانش ابری (Cloud Computing)
پارس‌دو (ParsDev): مبانی معماری رایانش ابری
سیستم‌گروپ (SystemGroup): معرفی معماری رایانش ابری
سبزلرن (SabzLearn): معرفی سرویس‌های AWS و نقش آن‌ها در معماری ابری
HighScalability: تحلیل مقیاس‌پذیری و فرآیندهای توسعه نرم‌افزار در آمازون
AWS (Amazon Web Services): مستندات رسمی و الگوهای طراحی معماری آمازون
Medium: تحلیل‌های فنی پیرامون طراحی سیستم (نتفلیکس و آمازون)
GitHub: مخازن و مستندات مربوط به معماری مرجع اسپاتیفای
Spotify (وب‌سایت رسمی): بلاگ فنی و مستندات پلتفرم اسپاتیفای
DevLane: بررسی تکنولوژی‌های مورد استفاده در اسپاتیفای
TechAhead: نقش میکروسرویس‌ها در معماری اسپاتیفای
System Design Handbook: راهنمای جامع طراحی سیستم‌های اسپاتیفای و توییتر
ByteByteGo: بررسی و راهنمای معماری کلی نتفلیکس
GeeksforGeeks: تحلیل طراحی سیستم‌های اوبر و نتفلیکس
LinkedIn: بررسی و تحلیل طراحی سیستم توییتر (Twitter System Design)
Talent500: بررسی معماری استریمینگ نتفلیکس
ScienceDirect: مقالات علمی و پژوهشی در حوزه معماری نرم‌افزار
این مطلب پروژه های درس معماری نرم افزار دانشگاه شهید بهشتی میباشد
