https://virgool.ir/feed/@mohammad.trb75fa2026-11-11 04:01:49https://files.virgool.ir/upload/users/762535/avatar/avatar.pnghttps://virgool.ir/@mohammad.trb75https://virgool.ir/@mohammad.trb75/بررسی-معماری-نتفلیکس-و-اسپاتیفای-jalgmjfdc2mmپروژه پایانی درس معماری نرم‌افزارعلیرضا حیدری و محمد ترابی‌پورمقدمهمعماری کامپیوتر ابعاد مختلفی دارد که ما در این مطلب به بررسی پیاده‌سازی معماری در شرکت‌های بزرگ می‌پردازیم. هدفجهت انجام پروژه بررسی معماری شرکت‌های مطرح تکنولوژی در دنیای امروزی مدنظر قرار داده شد. شرکت‌هایی که در بررسی‌های جهت دقیق شدن در آن‌ها انتخاب شدند شرکت‌های زیر هستند:NetflixSpotifyدلیل انتخاب شرکت‌ها تعداد کاربران گسترده و مشابه، کد توسعه‌یافته، درنظر داشتن دغدغه‌هایی جهت پیاده‌سازی معماری صحیح، منابع و داکیومنت‌های متعدد و مناسب جهت بررسی دلایل معماری‌های انتخاب شده، امکان بررسی قسمتی از کدها به دلیل متن‌باز ( open-source ) بودن آن‌ها است.در نهایت پس از بررسی کامل مسائل معماری و راه‌حل‌هایی که ارائه داده‌اند، نحوه تفکر و حل مسئله شرکت‌ها را بررسی می‌کنیم و نقاط قوت و ضعف‌ها را لیست کرده و به مقایسه آن‌ها نیز می‌پردازیم.جهت یک توضیح کوتاه به اهداف شرکت‌ها از نظر کسب و کاری و ارزشی که برای کاربر خلق می‌کنند می‌پردازیم.نتفلیکس:این شرکت به استریم آنلاین محتوای ویدیویی ( فیلم یا سریال ) از طریق کلاینت‌های مختلف ( گوشی تلفن‌همراه، کامپیوتر شخصی، تلویزیون ) و در بستر اینترنت در سرتاسر جهان می پردازد.اسپاتیفای:این شرکت به استریم و دانلود آهنگ‌ها با داشتن حق کپی‌رایت از طریق کلاینت‌های مختلف ( گوشی تلفن‌همراه، کامپیوتر شخصی، تلویزیون ) و در بستر اینترنت و به صورت آفلاین از طریق دیتای ذخیره شده در دستگاه کاربر در سرتاسر جهان می‌پردازد.معماری نتفلیکس و دغدغه‌های اخیر نتفلیکس در مسائل معماری:نتفلیکس به عنوان یک سرویس استریم در ابعاد جهانی لازم دارد تا الزامات عملکردی ( functional requirements ) های زیادی را برطرف کند.برای اینکه با دید بهتری به انتخابات معماری و چالش‌های معماری این شرکت بپردازیم بهتر است با چندین functional requirement و non-functional requirement این شرکت آشنا شویم:Functional requirements:کاربران می‌توانند بین کیفیت‌های مختلف ویدیو تصمیم‌گیری کنند.کاربران باید بتوانند حساب کاربری بسازند و با حساب کاربری خود وارد سامانه شوند.کاربران باید بتوانند بین محتواهای ویدیو به روش‌های مختلف جستجو کرده و لیست محتواها را بدون جستجو نیز مشاهده کنند و محتوای خود را جهت تماشا انتخاب کنند.کاربران باید بتوانند حساب کاربری خود را حذف کنند.کاربران ادمین باید بتوانند محتوای جدید به سامانه اضافه کنند یا محتوای قبلی را ویرایش ( و حذف ) کنند.کاربران می‌توانند بین پلن‌های مختلف جهت انتقال به عضویت با دسترسی‌های بیشتر اقدام کنند و براساس این ثبت‌نام به محتواها برحسب نوع حساب کاربری دسترسی داشته باشند.Non-Functional requirements:تمامی کاربران در سطح اینترنت و نقاط مختلف جغرافیایی ( برای کشوران مجاز جهت استفاده از سرویس ) با کمترین میزان تاخیر ویدیو را تماشا کنند.سرویس باید در ۹۹.۹ درصد اوقات قابل دسترسی باشد.برحسب دستگاهی که از سرویس استفاده می‌کند فرمت محتواها باید متناسب با دستگاه جهت نمایش باشد.سرویس باید بتواند توسعه‌پذیر باشد تا بدون مشکلی تعداد کاربران بیشتر را پشتیبانی کند ( این توسعه‌پذیری می‌تواند در حد چند میلیون کاربر جدید باشد، به این دلیل که نتفلیکس می‌تواند در آن واحد از کشور جدیدی پشتیبانی کند و کاربران زیادی در آن واحد به سرویس اضافه شوند)با توجه به موارد بالا متوجه می‌شویم که نتفلیکس سه قسمت اصلی را پوشش می‌دهد:حساب کاربری و موارد مرتبط با آناطلاعات محتواهاپخش ویدیونتفلیکس برای هر کدام از این موارد یک سرویس مجزا در نظر می‌گیرد. به این صورت افراد می‌توانند در تیم‌های مجزا بر روی هر سرویس کار کنند و در صورت لزوم خود نیز این سیستم‌ها را به سیستم‌ها و تیم‌های مجزا تقسیم کنند. با این تقسیم سرویس، امکان کار بر روی کل محصول با افراد بیشتر با سهولت بیشتری صورت می‌گیرد.در کنار این تقسیم سرویس معماری مد نظر نتفلیکس نیز میکروسرویس است و سرویس‌ها از طریق api gateway مدنظر با یکدیگر در تماس هستند.تصویر زیر نمای کلی از معماری نرم‌افزار نتفلیکس را نمایش می‌دهد:این معماری باز هم قسمت ریزتری از تصمیمات را نمایش می‌دهد. از دید بزرگتر می‌توان گفت نتفلیکس سه قسمت اصلی زیر را در نظر گرفته است:OC یا CDNBack-endclientOpen Connect ویدیوی Netflix را در مکان‌های مختلف در سراسر جهان ذخیره می‌کند. دقیقا همان کاری که از یک CDN انتظار می‌رود. وقتی پخش ویدیو را فشار می‌دهید، محتوا از Open Connect به ریکوئست ارسالی پاسخ داده می‌شود و برای نمایش از آن استفاده می‌شود تا سرعت بالاتری برای دسترسی وجود داشته باشد. در کل CDN به صورت زیر می‌تواند تعریف شود:شبکه تحویل محتوا (CDN) سیستمی از سرورهای توزیع شده (شبکه) است که صفحات و سایر محتوای وب را بر اساس موقعیت جغرافیایی کاربر، مبدا صفحه وب و سرور تحویل محتوا، به کاربر تحویل می دهد.مشخصاتی از OC:Open Connect ویدیوی Netflix را در مکان‌های مختلف در سراسر جهان ذخیره می‌کند. وقتی پخش جریان‌های ویدیویی را از Open Connect در دستگاه خود فشار می‌دهید.نتفلیکس با ارائه دهندگان خدمات اینترنت (ISP) و نقاط تبادل اینترنت (IX یا IXP) در سراسر جهان برای استقرار دستگاه های تخصصی به نام Open Connect Appliances (OCAs) در داخل شبکه خود مشارکت داشته است.این سرورها به‌طور دوره‌ای مسیرهای بهینه معیارهای سلامتی را که از شبکه‌های IXP/ISP آموخته‌اند و ویدیوهایی را که روی دیسک‌های SSD ذخیره می‌کنند گزارش می‌کنند تا خدمات Open Connect Control Plane در AWS را گزارش کنند.هنگامی که فایل‌های ویدیویی جدید با موفقیت رمزگذاری شدند و در AWS S3 ذخیره شدند، سرویس‌های صفحه کنترل در AWS این فایل‌ها را به سرورهای OCAs در سایت‌های IXP منتقل می‌کنند. این سرورهای OCA، حافظه پنهان را برای انتقال این فایل‌ها به سرورهای OCA در سایت‌های ISP تحت شبکه‌های فرعی خود اعمال می‌کنند.هنگامی که یک سرور OCA با موفقیت فایل‌های ویدیویی را ذخیره کرد، می‌تواند در صورت نیاز، فایل‌های همتا را برای کپی کردن این فایل‌ها در سایر سرورهای OCA در همان سایت شروع کند.بین 2 سایت مختلف که می توانند آدرس IP یکدیگر را ببینند، OCA ها می توانند فرآیند پر کردن ردیف را به جای پر کردن کش معمولی اعمال کنند.قبل از اینکه محتواهای ویدیویی در دسترس کاربران قرار گیرد، نتفلیکس باید ویدیو را به فرمتی تبدیل کند که برای دستگاه شما بهترین کارایی را داشته باشد. این فرآیند transcoding نامیده می شود.Transcoding فرآیندی است که یک فایل ویدئویی را از یک فرمت به فرمت دیگر تبدیل می کند تا فیلم ها در پلتفرم ها و دستگاه های مختلف قابل مشاهده باشند.فیلم/ویدئو اصلی در قالبی با کیفیت بالا ارائه می‌شود که اندازه آن در حوزه ترابایت است. همچنین نتفلیکس از 2200 دستگاه مختلف پشتیبانی می کند. هر دستگاه دارای یک فرمت ویدیویی است که در آن دستگاه خاص بهترین وضوح را دارد. اگر در حال تماشای نتفلیکس در آیفون هستید، ویدیویی خواهید دید که بهترین تجربه مشاهده را در آیفون به شما ارائه می دهد.نمایی کلی از عملیات transcoding را در زیر می‌توانید مشاهده کنید:این تصمیم که از یک transcoder استفاده شود باعث می‌شود تا هم response time بالا باشد هم بهترین رضایت کاربران را در بربگیرد.همچنین اینکه این عملیات در چه مرحله‌ای صورت بگیرد نیز یک انتخاب است:عملیات transcode در لحظه و بعد از درخواست کاربر انجام شودعملیات بعد از هر اضافه شدن ویدیو صورت گیرددر صورتی که از تصمیم اول پیروی شود برای هر فیلم ( حتی اگر برای فیلمی قبلا درخواستی آمده باشد ) باید transcode انجام شود و این می‌تواند سربار زیادی برای سیستم داشته باشد.البته می‌توان بعد از هر درخواست transcode محتواهای ویدیویی را برای دیگر کاربران ذخیره کرد. اما این مورد نیز edge case هایی مثل فیلم‌هایی که طرفداران زیادی دارند و در لحظه به سامانه اضافه شده‌اند داشته باشد. ممکن است در لحظات ابتدایی آنقدر درخواست‌ها زیاد شود که منابع بسیاری از سیستم استفاده شود.در نهایت نتفلیکس تصمیم گرفته است با در نظر گرفتن مزایا و معایب بیان شده عملیات transcode را بعد از اضافه شدن هر ویدیو انجام دهد.نتفلیکس همچنین فایل های بهینه سازی شده برای سرعت های مختلف شبکه ایجاد می کند. اگر در شبکه‌ای با سرعت بالا محتوای ویدیو را تماشا می‌کنید، ویدیوی با کیفیت بالاتری را نسبت به زمانی که از طریق شبکه کند تماشا می‌کنید، خواهید دید. و همچنین به برنامه نتفلیکس شما بستگی دارد. نتفلیکس برای هر فیلم تقریبا 1200 فایل ایجاد می کند !!!!این تعداد زیادی فایل و پردازش برای انجام transcoding است. اکنون همه فایل‌هایی را که برای پخش stream نیاز داریم در اختیار داریم. OC در واقع CDN خود نتفلیکس است و CDN شخص ثالث و یا شرکت دیگری نیست. با اینکار می‌تواند با توجه به نیازهای خود بهینه‌سازی‌های مشخصی را در CDN ها انجام دهد.مزایای OC:ارزان ترکیفیت بهترمقیاس پذیرتراستفاده از load balancer:نتفلیکس از سرویس load balancer الاستیک آمازون (ELB) برای هدایت ترافیک به سرویس های front-end استفاده می کند. ELB ها به گونه ای تنظیم شده اند که بار ابتدا در zone ها و سپس instanceها متعادل شود. این به این دلیل است که ELB یک طرح load balancer دو لایه است:اولین لایه شامل load balancer پایه مبتنی بر DNS است. این یک کلاینت را به یک نقطه پایانی ELB در ابر می برد که در یکی از مناطقی است که ELB شما برای استفاده از آن پیکربندی شده است.ردیف دوم سرویس ELB آرایه ای از نمونه های متعادل کننده بار است (مستقیماً توسط AWS ارائه می شود)، که تعادل بار دورگرد را بر روی نمونه های خودمان که پشت آن در همان منطقه قرار دارند، انجام می دهد.ZUUL:کنترلرهای Netty در جلو و پشت فیلترها عمدتاً مسئولیت رسیدگی به پروتکل شبکه، وب سرور، مدیریت اتصال و کار پروکسی را بر عهده دارند. با انتزاع این کار درونی، فیلترها تمام کارهای سنگین را انجام می دهند.فیلترهای ورودی قبل از پروکسی درخواست اجرا می شوند و می توانند برای احراز هویت، مسیریابی یا decorate درخواست استفاده شوند.از فیلترهای نقطه پایانی می توان برای بازگرداندن یک پاسخ ثابت یا پروکسی درخواست به سرویس back-end(یا به قولی origin) استفاده کرد.فیلترهای خروجی پس از بازگرداندن پاسخ اجرا می شوند و می توانند برای مواردی مانند gzipping، معیارها، یا افزودن/حذف هدرهای سفارشی استفاده شوند. ( از gzipping برای کاهش حجم استفاده می‌شود. )ویژگی‌ها:پشتیبانی از http2TLS متقابلتلاش های مجدد تطبیقیداشتن همزمانی یا concurrencyمزایا:سرویس هایی که نیاز به تقسیم کردن ترافیک خود دارند قوانین مسیریابی را ایجاد می کنند که مسیرها یا پیشوندهای خاصی را برای مبداهای جداگانه ترسیم می کند.توسعه دهندگان با ایجاد مسیری که یک نام host جدید را به مبدأ جدید آنها ترسیم می کند، سرویس های جدید را وارد می کنندتوسعه دهندگان تست های بار را با مسیریابی درصدی از ترافیک موجود به یک خوشه کوچک انجام می دهند و اطمینان حاصل می کنند که برنامه ها به خوبی تحت بارگذاری کاهش می یابند.تیم‌هایی که برنامه‌ها را بازسازی می‌کنند با ایجاد قوانین نقشه‌برداری ترافیک به تدریج، یک مسیر در یک زمان، به یک مبدا جدید مهاجرت می‌کنند.تیم‌ها تغییرات را آزمایش می‌کنند (تست canary) با ارسال درصد کمی از ترافیک به یک خوشه ابزاری که ساخت جدید را اجرا می‌کند. ( برای مطالعه تست قناری می‌توانید این لینک را دنبال کنید : https://www.optimizely.com/optimization-glossary/canary-testing/#:~:text=Canary%20Testing%20is%20a%20way,a%20small%20percentage%20of%20users.&text=The%20origin%20of%20the%20phrase,toxic%20gas%20was%20too%20high. )اگر تیم‌ها نیاز به آزمایش تغییراتی داشته باشند که به چندین درخواست متوالی در ساخت جدیدشان نیاز دارند، تست‌هایcanary را اجرا می‌کنند که همان کاربران را برای مدت کوتاهی به ساخت جدیدشان هدایت می‌کند.تیم‌های امنیتی قوانینی را ایجاد می‌کنند که درخواست‌های «بد» را بر اساس قوانین مسیر یا سرصفحه در همه خوشه‌های Zuul رد می‌کنند.استفاده از Hystrix:Hystrix یک کتابخانه تأخیر و تحمل خطا است که برای جداسازی نقاط دسترسی به سیستم‌های راه دور، خدمات و کتابخانه‌های شخص ثالث طراحی شده است.از این کتابخانه در این موارد می‌توان استفاده کرد:شکست های آبشاری را متوقف کنیدنظارت بر زمان واقعی تغییرات پیکربندیذخیره سازی درخواست آگاه از همزمانیدسته‌بندی خودکار از طریق جمع‌کردن درخواستاسپاتیفایدر این بخش قصد داریم معماری فنی و ساختار سازمانی و فرهنگی شرکت اسپاتیفای را مورد بررسی قرار دهیم. در ابتدای این مطلب لازم است ذکر شود که منبع مطالعه انجام شده مربوط به سال ۲۰۱۶ است و ممکن است در برخی جزئیات با وضعیت کنونی همخوانی نداشته باشد اما به صورت کلی اطلاعات مفید و قابل استناد است.اسپاتیفای یک اپلیکیشن بزرگ است. منظور از بزرگ بودن این است که:۱- این اپ حدود ۱۰۰ میلیون کاربر فعال دارد۲- لزوم به پشتیبانی از انواع و اقسام پلتفرم‌ها و دیوایس ها با نسخه های مختلف سیستم عامل و firmware۳- لزوم به پیاده سازی بیزینس لاجیک های پیچیده۴- نیاز به واکنش نشان دادن به تغییرات مارکت در اسرع وقت۵- به عنوان لیدر مارکت نیازمند نوآوری است و فرایند ایده تا پیاده سازی باید بسیار سریع باشدبرخی از نیازمندی های فانکشنال:۱- دانلود موسیقی۲- جستجوی موسیقی۳- خبردار شدن از فعالیت دوستان. اینکه چه گوش میدهند و چه پلی لیست هایی ساختند و …۴- به اشتراک گذاشتن موسیقی۵- امکان دیدن متن شعر آهنگ ها۶- ایجاد پلی لیست۷- رادیو۸- میکس های دیلی۹- مشاهده سابقه آهنگ های گوش داده شده۱۰- شافل پلی۱۱- فالو کردن هنرمندان۱۲- کنسرت ها۱۳- و غیره …شایان ذکر است که نیازمندی های ذکر شده تنها برخی از نیازمندی های تنها یک اکتور (اکتور آهنگ گوش کن!) اسپاتیفای هستند.کوالیتی اتریبیوت ها:۱- تجربه کاربری ۱۰۰ میلیون کاربر از ۵۸ کشور مختلف باید سریع و روان باشد۲- پشتیبانی از افزوده شدن حداقل ۲۰۰۰۰ آهنگ به صورت روزانه۳- امکان ذخیره سازی ۲ بیلیون پلی لیست ساخته شده توسط کاربران۴- هر کدام از تیم ها باید بتوانند به صورت End-to-end فرایند توسعه و دلیوری سرویسشان را انجام دهند۵- و تعداد بسیار زیادی کوالیتی اتریبیوت دیگر …چالش های عمده ای که اسپاتیفای با آنها درگیر است عبارتند از:۱- جدی بودن و سرسخت بودن رقبا که عبارتند از Apple Music، Google، Pandora، Deezer۲- مقیاس پذیری سرویس ها به علت سرعت بالای رشد بیزینس۳- ایجاد بستر مناسب برای نوآوری و خلاقیتساختار تیم ها در اسپاتیفای:برای توضیح ساختار تیم ها در اسپاتیفای اول از یک سناریو برای افزودن فیچر شروع می‌کنیم و در حین بررسی این سناریو استدلال میکنیم که چرا ساختار به این صورت، ساختار چابک و قابل اعتمادی است.پیش از این ذکر کردیم که اسپاتیفای از پلتفرم های گوناگونی پشتیبانی میکند. حال برای افزودن یک فیچر برای یک پلتفرم، در ابتدا با تیم پلتفرم تغییرات را ایجاد کند، سپس تیم لایبرری اصلی، سپس تیم سرور و در نهایت تیم زیرساخت. چنین زنجیره دیپندنسی میان تیم ها بسیار کار را کند میکند و به هیچ وجه این فرایند فرایند پربازده ای نیست.به جای اینکه تیم ها به این صورت پخش شوند، بهتر است که هر تیم به صورت End-to-end مسئولیت دلیوری فیچر ها را به عهده بگیرد.در این حالت هیچ تیم منتظر تیم دیگر برای توسعه یک فیچر قرار نمیگیرد. برای هر تیم ویژن و میشن به صورت جدا و خوش تعریف قرار داده شده و میشن ها به هیچ عنوان با یکدیگر تلاقی ندارند.تعداد این تیم ها در اسپاتیفای تا سال ۲۰۱۷ بالغ بر صد تیم بوده که هر کدام از این تیم ها به صورت متوسط ۱۰ سرویس را توسعه و نگهداری میکنند. تیم ها در حیطه سرویس هایی که توسعه می‌دهند اختیار و مسئولیت کامل دارند.بررسی مقیاس پذیری:ساختار یک وب اپلیکیشن ساده که تشکیل شده از یک کلاینت، سرویس مونولیت بکند و یک دیتا استور است.اولین سناریو که برای اسکیل مطرح می‌شود، اسکیل دیتا استور است چون اولین چیزی که به صورت طبیعی در چنین سیستمی باتل نک میشود دیتا استور است.برای حل این مشکل کافی است که دیتابیس رپلیکیت بشود مثلا راه حل مستر اسلیو در این سناریو پاسخگو است. پس از مدتی خود سرویس بک اند باتل نک می‌شود.که این هم با اضافه شدن یک لود بالانسر حل می شود. شایان ذکر است که اکثر شرکت های آی تی ایرانی چنین معماری دارند. اما پس از مدتی دیستریبیوت کردن یک باینری مونولیت بزرگ بسیار سخت و پرهزینه می‌شود. برای همین یک بعد جدیدی از مقیاس پذیری لازم است و آن هم مقیاس پذیری فانکشنال است.چنین سیستمی می‌تواند به تناسب لود روی هر سرویس اسکیل شود.حالا در اسپاتیفای تیم ها حول این سرویس ها تشکیل می‌شوند. هر تیم مسئولیت تعدادی از این سرویس ها را بر عهده دارد (به طور میانگین ۱۰ سرویس) از مزایای استفاده از معماری مایکروسرویس می‌توان به این موارد اشاره کرد:۱- تست راحت تر۲- دیپلوی راحت تر۳- مانیتورینگ راحت تر۴- شعاع انفجار کاهش می یابد۵- سرویس ها به صورت مستقل از یکدیگر قابلیت نسخه زدن دارند. این قابلیت زمانی به درد میخورد که نیاز به پشتیبانی از ای پی آی دستگاه های امبددی وجود دارد که دیگر نسخه اسپاتیفای آنها قابلیت آپدیت ندارد.از معایب استفاده از این معماری هم می‌توان به این موارد اشاره کرد:۱- نیاز به دیسکاوری و داکیومنت شدن سرویس ها مخصوصا برای انبردینگ ممکن است که نیروی تازه وارد گیج بشود. برای حل این مشکل اسپاتیفای سرویس system-z را توسعه داد که در آن نام تمامی سرویس ها و لینک ریپازیتوری آنها قابل دسترس برای همه است.۲- افزایش latency که برای حل این مشکل، اسپاتیفای از نتفلیکس تقلید کرد و از سرویس View Aggregation استفاده کرد.هر پلتفرم برای گرفتن ویو و نشان دادن آن تا قبل از این به چند سرویس ریکوئست میزد تا دیتای مورد نیاز برای نمایش را فچ کند. اما این شکلی کلاینت به اگریگیشن سرویس ریکوئست را میزند و این سرویس خودش سرویس های لازمه رو صدا میکنه و دقیقا دیتای مربوط به ویو را تولید میکند و برمیگرداند.۳- پیچیده تر شدن مانیتورینگ. طبیعتا مانیتورینگ ۱۲۰۰ تا سرویس سخت تر از مانیتورینگ یک سرویس استچپتر ها:همانطور که پیش از این گفته شد تیم ها در اسپاتیفای (که به آنها اسکواد گفته میشود) مسئولیت End-to-end دارند پس طبیعتا از آدم های با تخصص های مختلف تشکیل شده است. چپتر ها مکانیسم ارتباطی افراد با تخصص های مشترک در یک سازمان است و لیدر یک چپتر وظیفه مدیریت و جهت دهی فنی و کمک به مسیر رشد اعضای چپتر است. البته چپتر با گیلد نباید اشتباه گرفته شود. گیلد یک موجودیت ارگانیک است که افراد با علایق مشترک را دور هم جمع میکند مثلا گیلد گیتار الکتریک زن های یک شرکت. البته گیلد میتواند تاپیک فنی هم داشته باشد.نکته دیگری که وجود دارد این است که اگرچه هر کدام از تیم ها در فرایند توسعه و دلیوری از یک دیگر کالا جدا هستند، استاندارد های فنی نیز در میان تیم ها وجود دارد. مثلا اینگونه نیست که هر سرویسی امکان توسعه به هر زبانی را داشته باشد و همه سرویس ها به صورت یونی فرم و به زبان جاوا و با فریم ورک آپولو که توسط خود اسپاتیفای توسعه داده شده توسعه داده میشوند. دلیل این هم این است که اولا توسعه دهنده ها مرج ریکوئست های یکدیگر را از تیم های مختلف ریویو می کنند و ثانیا اینکه توسعه دهنده ها بین تیم ها جابجا می شوند. اگر هر تیم از تکنولوژی خودش استفاده کند این فرایند بسیار سخت و کند و پیچیده می شود.بررسی مایگریشن به گوگل کلود:اسپاتیفای تا سال ۲۰۱۶، چهار دیتاسنتر داشت که دوتای آنها در آمریکا و دوتای دیگر در اروپا بودند. در همین سال تصمیم گرفته شد تا طی توافقی که با Google Cloud انجام شد سرویس ها به صورت تدریجی از دیتاسنتر های دیدیکیتد اسپاتیفای به گوگل کلود مهاجرت کنند. دلیل این تصمیم این بود که هزینه عملیاتی نگهداری و توسعه دیتاسنتر های اسپاتیفای بسیار زیاد شده بود و با توجه به هدف اصلی اسپاتیفای که توسعه بهترین اپ موسیقی جهان است، نگهداری و توسعه دیتاسنتر کار زیاد و جدای از میشنی است که میتواند outsource بشود. علاوه بر این استفاده از اکوسیستم سرویس های گوگل و کامپوننت های آماده آن در کانکست های مختلف باعث جلوگیری از فرایند اختراع مجدد چرخ و نوآوری حداکثری می شود.در نتیجه طی برنامه ای که چیده شد در وهله اول تیمی مشترک برای مدیریت مایگریشن متشکل از مهندسین گوگل و اسپاتیفای تشکیل شد و سپس گوگل قابلیت VPC را مختص اسپاتیفای به گوگل کلود اضافه کرد. سپس امکان VPN به VPC ایجاد شد تا دیتاسنتر های دیگر بتوانند به VPC متصل شوند. این کار برای هندل کردن دیپندنسی های سرویس ها لازم بود (سرویس هایی که به سرویس هایی که هنوز مایگریت نشده بودند و در دیتاسنتر اسپاتیفای بودند دیپندنسی داشتند).این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.Mohammad TorabipourMohammad TorabipourFri, 11 Feb 2022 23:04:03 +0330