https://virgool.io/feed/@fatemehrafiee fa 2026-04-15 06:45:53 https://files.virgool.io/upload/users/3963315/avatar/mvpKb1.png?height=120&width=120 https://virgool.io/@fatemehrafiee https://virgool.io/@fatemehrafiee/%D8%B4%D8%A8%DB%8C%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D8%A7%D9%86%D8%AA%D8%B4%D8%A7%D8%B1-%D8%B1%D9%81%D8%AA%D8%A7%D8%B1-%D9%88-%D8%A8%D9%87%DB%8C%D9%86%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%86%D9%81%D9%88%D8%B0-%D8%AF%D8%B1-%D8%B4%D8%A8%DA%A9%D9%87-%D9%87%D8%A7%DB%8C-%D9%88%D8%A7%D9%82%D8%B9%DB%8C-yvnio88uip6d فاطمه رفیعیچکیدهامروزه شبکه‌های اجتماعی به بستر اصلی برای انتشار اطلاعات، فناوری‌ها و رفتارها تبدیل شده‌اند. با این حال، دیده می‌شود که خیلی از پویش‌ها، محصولات جدید یا تغییرات رفتاری، علی‌رغم پتانسیل اولیه، در قدم اول شکست می‌خورند و هرگز فراگیر نمی‌شوند. در مقابل، بعضی دیگر با سرعت زیاد در شبکه منتشر می‌شوند. این مطالعه با هدف بررسی این موضوع و پاسخ به این پرسش که «چه ساختارهایی مانع انتشار می‌شوند و چگونه می‌توان بر آن‌ها غلبه کرد؟» انجام شده است.در این راستا، فرآیند انتشار با استفاده از مدل آستانه خطی (Linear Threshold Model - LTM) شبیه‌سازی شده است. برخلاف مدل‌های ساده‌سازی شده، در این پژوهش از فرض آستانه‌های ناهمگن استفاده شد تا تفاوت‌های فردی در پذیرش مدل‌سازی شود و شبیه‌سازی واقع‌گرایانه باشد. آزمایش‌ها بر روی دو مجموعه داده واقعی از شبکه فیسبوک، شامل شبکه دانشگاه رایس (با حدود ۴ هزار گره) و دانشگاه میشیگان (با بیش از ۳۰ هزار گره) پیاده‌سازی شد.در ابتدا تحلیل نقطه اوج در گسترش آبشار، وجود یک گذار فاز شدید و غیرخطی را در هر دو شبکه نشان می‌دهد. مشخص شد که شبکه بزرگتر با میانگین درجه پایین‌تر، دارای نقطه اوج بالاتری نسبت به شبکه کوچکتر است که نشان‌دهنده آسیب‌پذیری ساختاری بیشتر در شبکه‌های بزرگتر است. دوم، بررسی علت توقف انتشار در آستانه‌های متوسط، وجود خوشه‌های مسدودکننده اثبات شد؛ به طوری که نشان داده شد گره‌های غیرفعال تشکیل‌دهنده ساختارهایی با تراکم داخلی بسیار بالا هستند که نفوذ به آن‌ها نیازمند استراتژی‌های خاص است. در گام سوم، آزمایش قدرت پیوندهای ضعیف برای رفتارهای پرهزینه نشان داد که برخلاف انتشار اطلاعات ساده، برای سرایت پیچیده، شروع انتشار از درون خوشه‌های متراکم به دلیل ایجاد تقویت اجتماعی، عملکردی بهتر نسبت به گره‌هایی که پل هستند دارد.در نهایت، برای حل مسئله NP-Hard بهینه‌سازی نفوذ (Influence Maximization)، الگوریتم حریصانه (Greedy) پیاده‌سازی و با استراتژی‌های هیوریستیک متداول (بیشترین درجه، مرکزیت بینابینی و PageRank) مقایسه شد. نتایج نشان داد که الگوریتم حریصانه نفوذی ۱۱ برابر بیشتر از روش‌های سنتی ایجاد می‌کند. همچنین، برای غلبه بر چالش زمان اجرا در مقیاس بزرگتر، نسخه بهینه‌شده الگوریتم با نام CELF پیاده‌سازی شد.واژگان کلیدی: تحلیل شبکه‌های اجتماعی، مدل آستانه خطی، خوشه‌های مسدودکننده، بهینه‌سازی نفوذ، الگوریتم حریصانه، الگوریتم CELF، سرایت پیچیده۱. مقدمهدر دهه‌های اخیر، گسترش شبکه‌های اجتماعی، ساختار تعاملات انسانی را به کلی تغییر داده است. پلتفرم‌هایی مثل فیسبوک، توییتر و لینکدین، فقط ابزاری برای حفظ ارتباطات نیستند؛ بلکه به بستری برای جریان اطلاعات، شکل‌گیری افکار عمومی، و گسترش نوآوری‌ها تبدیل شده‌اند. از بازاریابی برای یک محصول جدید گرفته تا کمپین‌های بهداشت عمومی (مانند واکسیناسیون) و حتی جنبش‌های سیاسی، موفقیت یا شکست یک پویش تا حد زیادی به نحوه انتشار آن در شبکه بستگی دارد.با این حال، مشاهده تجربی رفتارهای اجتماعی نشان می‌دهد که انتشار، فرآیندی تصادفی نیست. بسیاری از ایده‌ها یا محصولات، علی‌رغم کیفیت بالا، در گوشه‌ای از شبکه گیر می‌افتند و هیچوقت فراگیر نمی‌شوند. این پدیده، باعث شده که پژوهشگران به دنبال این باشند که کشف کنند مکانیسم دقیق تصمیم‌گیری افراد برای پذیرش یک رفتار جدید چیست؟ ساختار شبکه (مانند گروه‌های دوستی متراکم) چه نقشی در تسریع یا توقف این فرآیند دارد؟ و مهم‌تر اینکه اگر بخواهیم با کمترین هزینه بیشترین تأثیر را بر شبکه بگذاریم، باید چه کسانی را هدف قرار دهیم؟۱-۱. سرایت ساده و پیچیدهبرای درک انتشار، ابتدا باید بین دو نوع سرایت تمایز قائل شویم: سرایت ساده (Simple Contagion) و سرایت پیچیده (Complex Contagion).در سرایت ساده (مانند انتشار ویروس آنفولانزا یا یک خبر)، تنها یک تماس با فرد آلوده کافی است تا ویروس یا خبر منتقل شود. در چنین حالتی، پیوندهای ضعیف (Weak Ties) یا همان آشنایان دور که گروه‌های مختلف را به هم وصل می‌کنند، نقش شاهراه‌های انتقال را بازی می‌کنند.اما بسیاری از رفتارهای اجتماعی، از جنس سرایت ساده نیستند. پذیرش یک تکنولوژی، تغییر سبک زندگی، یا پیوستن به یک جنبش اجتماعی پرریسک، با رفتارهایی مانند گسترش ویروس متفاوت هستند. در این حالت، فرد با دیدن تنها یک نفر، قانع نمی‌شود؛ بلکه نیازمند تقویت اجتماعی (Social Reinforcement) است. شخص باید ببیند که چندین نفر از دوستان و اطرافیان مورد اعتمادش آن رفتار را انجام داده‌اند تا بر مقاومت ذهنی یا هزینه ریسک غلبه کند. این مطالعه بر روی این نوع از انتشار تمرکز دارد که دینامیک پیچیده‌تری نسبت به مدل‌های ویروسی دارد.۱-۲. مدل آستانه خطی (LTM)برای شبیه‌سازی دقیق این فرآیند تصمیم‌گیری، از یکی از شناخته‌شده‌ترین مدل‌های انتشار به نام مدل آستانه خطی (Linear Threshold Model) استفاده می‌شود. در این مدل، شبکه به صورت گرافی نمایش داده می‌شود که در آن گره‌ها نمایانگر افراد و یال‌ها نشان‌دهنده روابط اجتماعی هستند. برای هر گره v، یک آستانه مقاومت (theta_v) تعریف می‌شود که عددی بین ۰ و ۱ است. این عدد نشان‌دهنده میزان سرسختی یا محافظه‌کاری فرد در برابر تغییر است.یک گره v که در ابتدا غیرفعال است، تنها زمانی فعال می‌شود (رفتار جدید را می‌پذیرد) که مجموع وزن تأثیر همسایگان فعالش، از آستانه theta_v عبور کند. اگر فرض کنیم همسایگان تأثیر برابری دارند، شرط فعال‌سازی به صورت زیر است:active neighbors/all neighbors >= theta_vنکته کلیدی در اینجا، استفاده از آستانه‌های ناهمگن (نابرابر) است. برخلاف برخی مطالعات که یک آستانه ثابت برای کل شبکه در نظر می‌گیرند، اینجا فرض شده است که جامعه ترکیبی از افراد زودباور (با آستانه پایین) و افراد سرسخت (با آستانه بالا) است تا شبیه‌سازی به واقعیت نزدیک‌تر باشد.۱-۳. مسئله بهینه‌سازی نفوذصورت مسئله‌ای که با آن رو به رو هستیم این است که «اگر بودجه داشته باشیم که تنها k نفر را در شبکه فعال کنیم، کدام k نفر را انتخاب کنیم تا اندازه نهایی آبشار (تعداد کل افراد فعال شده) بیشینه شود؟»این مسئله از نظر محاسباتی دشوار است. برای یک شبکه با ۳۰,۰۰۰ گره، تعداد حالاتی که می‌توان k نفر را انتخاب کرد، عدد بسیار بزرگی می‌شود. کمپ، کلاینبرگ و تاردوس (۲۰۰۳) اثبات کردند که این مسئله NP-Hard است.بنابراین این پژوهش دو وجه دارد. اول درک اینکه چرا انتشار در برخی شرایط متوقف می‌شود (نقش ساختار شبکه). دوم پیاده‌سازی الگوریتم‌هایی (مانند Greedy و CELF) که بتوانند با دقتی بسیار بالا و در زمانی کوتاه، این گره‌های طلایی را در میان ده‌ها هزار گره شناسایی کنند.۲. ادبیات موضوع و کارهای پیشیندر این بخش، به بررسی دو موضوع می‌پردازیم که زیربنای مدل‌سازی‌های این پژوهش را تشکیل می‌دهند. نخست، نظریه کلاسیک قدرت پیوندهای ضعیف که بر نقش ساختاری روابط تمرکز دارد، و دوم، مدل‌های آستانه و آبشار که دینامیک گذار فاز در سیستم‌های پیچیده را نشان می‌دهند.۲-۱. نظریه قدرت پیوندهای ضعیف (Mark Granovetter, 1973)یکی از تأثیرگذارترین مقالات در زمینه جامعه‌شناسی، مقاله مارک گرانووتر با عنوان "The Strength of Weak Ties" است. گرانووتر با تحلیل شبکه‌های اجتماعی انسانی، روابط میان افراد را به دو دسته کلی تقسیم کرد:پیوندهای قوی: روابطی که با صرف زمان زیاد، شدت عاطفی بالا و صمیمیت همراه هستند (مانند دوستان نزدیک و خانواده).پیوندهای ضعیف: روابطی سطحی‌تر و کم‌هزینه‌تر (مانند آشنایان دور یا همکاران).استدلال مرکزی گرانووتر بر پایه مفهوم Triadic Closure استوار است. او بیان می‌کند که اگر فرد A با B و C پیوند قوی داشته باشد، احتمال بسیار زیادی وجود دارد که B و C نیز با یکدیگر پیوند داشته باشند (دوستان صمیمی ما، معمولاً یکدیگر را می‌شناسند). این پدیده باعث می‌شود که پیوندهای قوی منجر به تشکیل خوشه‌های متراکم و جزایر جدا افتاده در شبکه شوند. در درون این خوشه‌ها، اطلاعات به سرعت می‌چرخد اما راهی به بیرون پیدا نمی‌کند.در مقابل، پیوندهای ضعیف معمولاً نقش پل را ایفا می‌کنند. آن‌ها تنها مسیرهای ارتباطی هستند که خوشه‌های متراکم و مجزا را به یکدیگر متصل می‌کنند. گرانووتر نتیجه گرفت که برای انتشار اطلاعات جدید (مانند فرصت‌های شغلی یا اخبار)، پیوندهای ضعیف بسیار کارآمدتر از پیوندهای قوی هستند، زیرا دسترسی به بخش‌های غیرتکراری و دوردست شبکه را فراهم می‌کنند.در ادامه خواهیم دید، اگرچه فرضیه گرانووتر برای انتشار اطلاعات (سرایت ساده) صحیح است، اما آزمایش‌های ما نشان می‌دهد که برای انتشار رفتار (سرایت پیچیده)، این پیوندهای ضعیف دچار ناکارآمدی می‌شوند.۲-۲. آبشارهای سراسری و پایداری شبکه (Duncan Watts, 2002)در حالی که گرانووتر بر ساختار تمرکز داشت، واتس در مقاله کلیدی خود "A Simple Model of Global Cascades on Random Networks"، دینامیک تغییر وضعیت شبکه را مدل‌سازی کرد. این مقاله، پایه‌ی اصلی مدل‌سازی ریاضی (LTM) در این مطالعه است.واتس نشان داد که شبکه‌های اجتماعی دارای خاصیتی دوگانه هستند: مقاوم و در عین حال شکننده. او با معرفی مدل آستانه، پدیده‌ای به نام آبشارهای سراسری (Global Cascades) را تحلیل کرد. طبق این مدل، یک شوک اولیه کوچک (فعال‌سازی چند گره بذر)، معمولاً به سرعت میرا می‌شود و تأثیر محدودی دارد. اما اگر پارامترهای شبکه (مانند میانگین درجه یا توزیع آستانه‌ها) از یک حد بحرانی عبور کنند، شبکه دچار گذار فاز (Phase Transition) می‌شود.واتس دو مفهوم کلیدی را برای توضیح این پدیده معرفی کرد. اولین مفهوم خوشه‌های آسیب‌پذیر (Vulnerable Clusters) است. انتشار سراسری تنها زمانی رخ می‌دهد که گره‌های آسیب‌پذیر یعنی گره هایی که با فعال شدن تنها یک همسایه، فعال می‌شوند، تشکیل یک خوشه همبند و نفوذکننده در سراسر شبکه بدهند.مفهوم دوم خوشه‌های مسدودکننده (Blocking Clusters) هستند. در مقابل، واتس توضیح می‌دهد که عامل اصلی توقف انتشار، برخورد با خوشه‌هایی است که تراکم داخلی آن‌ها بسیار بالاست. اگر تراکم داخلی یک گروه از آستانه مقاومت بیشتر باشد (p > 1-q)، هیچ فشار بیرونی نمی‌تواند به درون آن نفوذ کند.این چارچوب نظری واتس، همان ابزاری است که در بخش ارزیابی‌ها برای تفسیر نمودارهای نقطه اوج و تحلیل علت توقف انتشار در شبکه دانشگاه‌های رایس و میشیگان از آن استفاده می‌کنیم.۲-۳. نظریه سرایت پیچیده (Centola & Macy, 2007)در حالی که نظریه قدرت پیوندهای ضعیف برای دهه‌ها روش غالب در تحلیل انتشار بود، سنتولا و میسی در سال ۲۰۰۷ با انتشار مقاله‌ای، این باور را به چالش کشیدند. آن‌ها استدلال کردند که تعمیم یافته‌های گرانووتر (که برای انتشار اطلاعات بود) به انتشار رفتارها، یک خطای بنیادی است.آن‌ها مفهوم سرایت پیچیده (Complex Contagion) را معرفی کردند؛ رفتارهایی که پذیرش آن‌ها نیازمند تأیید یا تقویت از جانب چندین منبع است. برخلاف ویروس یا شایعه که با یک تماس منتقل می‌شود، رفتارهای پرهزینه (مانند پذیرش یک تکنولوژی جدید یا پیوستن به یک اعتراض) دارای آستانه پذیرش هستند.سنتولا و میسی نشان دادند که برای سرایت پیچیده، پل‌های طولانی و پیوندهای ضعیف که صرفاً فواصل را کوتاه می‌کنند، ناکارآمدند. دلیل این امر نبود Social Bandwidth است؛ یک پیوند ضعیف نمی‌تواند سیگنال تقویت‌کننده لازم را منتقل کند. در مقابل، آن‌ها مفهوم پل‌های عریض (Wide Bridges) را پیشنهاد کردند؛ ساختارهایی که اگرچه ممکن است کوتاه باشند، اما دارای چندین یال موازی هستند که امکان عبور همزمان تأثیر از چند همسایه به یک فرد را فراهم می‌کنند. این نظریه، توجیه‌گر آزمایش مقایسه خوشه پل در این پژوهش است، که نشان داده می‌شود چرا شروع انتشار از درون خوشه‌های متراکم، استراتژی موفق‌تری است.۲-۴. مسئله بهینه‌سازی نفوذ و الگوریتم حریصانه (Kempe, Kleinberg, & Tardos, 2003)کمپ، کلاینبرگ و تاردوس در مقاله خود مسئله بهینه‌سازی نفوذ را به عنوان یک مسئله بهینه‌سازی گسسته فرمول‌بندی کردند. صورت مسئله یافتن مجموعه S با اندازه k است که تابع نفوذ sigma(S) را بیشینه کند. آن‌ها اثبات کردند که این مسئله در مدل‌های LTM و ICM، در کلاس پیچیدگی NP-Hard قرار دارد. با این حال، دستاورد بزرگ آن‌ها اثبات دو ویژگی ریاضی کلیدی برای تابع نفوذ بود.اولین ویژگی یکنوایی ست، یعنی افزودن گره جدید به مجموعه بذر، هرگز باعث کاهش نفوذ نمی‌شود.دوم زیرپیمانه‌ای بودن (Submodularity)، این ویژگی که معادل گسسته Convexity یا قانون بازده نزولی در اقتصاد است، بیان می‌کند که ارزش افزوده‌ی یک گره خاص، با بزرگتر شدن مجموعه بذر کاهش می‌یابد.بر اساس این ویژگی‌ها، آن‌ها نشان دادند که یک الگوریتم حریصانه ساده که در هر مرحله گره‌ای با بیشترین Marginal Gain را انتخاب می‌کند، تضمین می‌کند که به جوابی نزدیک به جواب بهینه سراسری دست یابد.۲-۵. تسریع الگوریتم: روش CELF (Leskovec et al., 2007)هرچند الگوریتم حریصانه دقت بالایی دارد، اما از نظر محاسباتی بسیار کند است. برای انتخاب k گره در گراف با N گره، الگوریتم باید k * N بار تابع شبیه‌ساز (Monte Carlo) را اجرا کند که برای شبکه‌های بزرگ (مانند شبکه میشیگان در این پژوهش) ساعت‌ها طول می‌کشد.برای حل این چالش، Leskovec در سال ۲۰۰۷ الگوریتم CELF (Cost-Effective Lazy Forward) را معرفی کرد. این الگوریتم با بهره‌گیری از خاصیت Submodularity، از محاسبات غیرضروری جلوگیری می‌کند. ایده اصلی Lazy Evaluation است: از آنجا که سود نهایی یک گره در طول زمان فقط می‌تواند کاهش یابد (و هرگز افزایش نمی‌یابد)، اگر گره‌ای در دور قبل سود نهایی کمی داشته است، نیازی نیست در دور فعلی بلافاصله محاسبه شود، مگر اینکه کاندیدهای بهتر همگی بررسی و رد شوند. آزمایش‌ها نشان داده‌اند که CELF می‌تواند تا ۷۰۰ برابر سریع‌تر از الگوریتم حریصانه عمل کند، در حالی که همان مجموعه جواب را تولید می‌کند. در فاز نهایی این پژوهش، با پیاده‌سازی CELF زمان اجرا به طرز قابل توجهی کاهش یافت.۳. روش‌شناسی پژوهشبرای بررسی تجربی نظریات مطرح شده و ارزیابی کارایی الگوریتم‌های پیشنهادی، این پژوهش بر پایه شبیه‌سازی‌های گسترده بر روی داده‌های واقعی شبکه‌های اجتماعی پیش می‌رود. در این بخش، به معرفی مجموعه داده‌های مورد استفاده، ابزارهای محاسباتی و فرآیند آماده‌سازی داده‌ها پرداخته می‌شود.۳-۱. مجموعه Datasetبرای اطمینان از تعمیم‌پذیری نتایج، آزمایش‌ها بر روی دو شبکه اجتماعی متفاوت از لحاظ مقیاس اجرا شدند. هر دو مجموعه داده از مخزن داده‌های شبکه و زیرمجموعه socfb انتخاب شده‌اند که شبکه دوستی کاربران فیسبوک در دانشگاه‌های آمریکا در سال ۲۰۰۵ است. انتخاب این شبکه‌ها به دلیل ساختار واقعی، تراکم بالا و وجود خوشه‌های اجتماعی طبیعی (مانند خوابگاه‌ها، دانشکده‌ها و سال ورودی) است که باعث می‌شود برای مطالعه پدیده انتشار مناسب باشند.شبکه کوچک (socfb-Rice31): این گراف مربوط به شبکه دوستی دانشجویان دانشگاه رایس است. با داشتن حدود ۴ هزار گره، این شبکه به عنوان محیط آزمایش اولیه مورد استفاده قرار گرفت.شبکه بزرگ (socfb-Michigan23): این گراف مربوط به دانشگاه میشیگان است و با داشتن بیش از ۳۰ هزار گره و ۱.۱ میلیون یال، مقیاس وسیع‌تری دارد. استفاده از این شبکه برای بررسی مقیاس‌پذیری الگوریتم‌ها و تایید نتایج در ابعاد بزرگ ضروری بود.جدول ۱، خلاصه آماری این دو شبکه را مقایسه می‌کند. نکته حائز اهمیت، تفاوت در میانگین درجه است. شبکه کوچکتر (Rice) دارای میانگین درجه ۹۰.۴ است، در حالی که شبکه بزرگتر (Michigan) میانگین درجه ۷۸.۱ دارد. همان‌طور که در بخش نتایج نشان خواهیم داد، همین تفاوت آماری به ظاهر ساده، تأثیر عمیقی بر موقعیت نقطه اوج و آسیب‌پذیری شبکه در برابر انتشار دارد.جدول ۱: ویژگی‌های آماری مجموعه داده‌های مورد استفاده۳-۲. ابزارها و پیش‌پردازش داده‌هاپیاده‌سازی با استفاده از پایتون انجام شده است. کتابخانه‌های کلیدی مورد استفاده عبارتند از NetworkX جهت ایجاد، دستکاری و تحلیل ساختاری گراف‌ها (محاسبه درجه، خوشه‌بندی، مرکزیت‌ها)؛ SciPy جهت بارگذاری بهینه ماتریس‌های Sparse از فایل‌های mtx. که برای مدیریت حافظه در شبکه بزرگ میشیگان حیاتی بود؛ NumPy برای محاسبات برداری و تولید اعداد تصادفی؛ Matplotlib جهت مصورسازی نتایج و رسم نمودارهای فاز.فرآیند پیش‌پردازش: داده‌های خام به صورت ماتریس‌های مجاورت در فرمت mtx. بودند. در گام نخست، این ماتریس‌ها بارگذاری و به گراف‌های NetworkX تبدیل شدند. از آنجا که رابطه دوستی در فیسبوک دوطرفه است، گراف‌ها به صورت بدون جهت در نظر گرفته شدند. همچنین، برای حذف نویزهای احتمالی، مولفه‌های همبند (Connected Components) بررسی شدند؛ هرچند به دلیل ماهیت Small World شبکه‌های اجتماعی، هر دو گراف دارای یک Giant Component بودند که تقریباً تمامی گره‌ها را در بر می‌گرفت و شبیه‌سازی‌ها بر روی کل گراف اجرا شد.۳-۳. پیاده‌سازی شبیه‌ساز انتشاربخش مرکزی این پژوهش، یک شبیه‌ساز است که دینامیک مدل آستانه خطی را بر روی گراف اجرا می‌کند. تابع ltm_simulator سه ورودی اصلی دریافت می‌کند: ساختار گراف (G)، مجموعه گره‌های بذر اولیه (S) و توزیع آستانه‌ها (Theta).الگوریتم شبیه‌سازی طی مراحل زیر اجرا می‌شود:مقداردهی اولیه: تمام گره‌های موجود در مجموعه بذر S به عنوان فعال علامت‌گذاری می‌شوند. سایر گره‌ها در وضعیت غیرفعال قرار دارند.فرآیند تکرار (Cascade Loop): شبیه‌سازی وارد یک حلقه تکرار می‌شود که معادل گام‌های زمانی (t=1, 2, ...) است.ارزیابی همسایگان: در هر گام، برای هر گره غیرفعال v که حداقل یک همسایه فعال دارد، کسر نفوذ محاسبه می‌شود:f_v = N_active(v) / N_total(v)که در آن N_active(v) مجموعه همسایگان فعال گره v است.شرط فعال‌سازی: مقدار f_v با آستانه گره (v_threshold) مقایسه می‌شود. اگر f_v بیشتر یا مساوی v_threshold باشد، گره v به لیست فعال‌های جدید اضافه می‌شود.توقف: این حلقه تا زمانی ادامه می‌یابد که در یک گام کامل، هیچ گره جدیدی فعال نشود (وضعیت پایدار). خروجی نهایی، تعداد کل گره‌های فعال شده (sigma(S)) است.برخلاف پیاده‌سازی‌های عادی که از یک آستانه ثابت سراسری استفاده می‌کنند، این شبیه‌ساز از آستانه‌های ناهمگن پشتیبانی می‌کند.۳-۴. الگوریتم‌های بهینه‌سازی نفوذهدف نهایی، یافتن مجموعه بذر با اندازه k است که خروجی شبیه‌ساز را بیشینه کند. برای این منظور، دو الگوریتم پیاده‌سازی و مقایسه شدند:الف) الگوریتم حریصانه: این الگوریتم بر اساس اثبات کمپ و کلاینبرگ (۲۰۰۳) مبنی بر تضمین تقریب (1 - 1/e) عمل می‌کند. منطق آن به شرح زیر است:مجموعه بذر S در ابتدا تهی است.برای k مرحله تکرار می‌کنیم:برای تمامی گره‌های v که در S نیستند (گره‌های کاندید)، نفوذ حاشیه‌ای (Marginal Gain) را محاسبه می‌کنیم.گره‌ای که بیشترین Delta(v) را دارد انتخاب کرده و به S اضافه می‌کنیم.اگر گراف N گره داشته باشد، برای انتخاب بذر اول N بار، بذر دوم N-1 بار و ... شبیه‌سازی اجرا می‌شود. پیچیدگی نهایی از مرتبه O(k .N . M) است که M هزینه یک بار اجرای شبیه‌سازی است. این روش برای گراف‌های بزرگ کند است.ب) الگوریتم CELF (Cost-Effective Lazy Forward): برای غلبه بر کندی الگوریتم حریصانه در شبکه ۳۰ هزار گره‌ای میشیگان، از الگوریتم بهینه CELF استفاده شد. این الگوریتم از خاصیت Submodularity تابع نفوذ استفاده می‌کند یعنی سود نهایی افزودن یک گره، با گذشت زمان و شلوغ‌تر شدن شبکه، همواره کاهش می‌یابد.مکانیسم Lazy Evaluation در CELF به این صورت پیاده‌سازی شد:گام اول: نفوذ تمامی گره‌ها محاسبه شده و آن‌ها در یک صف اولویت بر اساس میزان نفوذشان مرتب می‌شوند.انتخاب هوشمند: در هر مرحله، گره بالای صف (u) برداشته می‌شود.بررسی اعتبار: بررسی می‌کنیم که نفوذ این گره مربوط به کدام دور است. اگر نفوذ مربوط به دور فعلی باشد (یعنی با توجه به بذرهای انتخاب شده‌ی قبلی آپدیت شده باشد)، این گره قطعاً بهترین گزینه است و انتخاب می‌شود. اگر نفوذ مربوط به دورهای قبل باشد (Stale)، نفوذ حاشیه‌ای آن دوباره محاسبه می‌شود (Delta_new(u)) و با مقدار جدید به صف بازگردانده می‌شود تا با سایرین رقابت کند.این مکانیزم باعث می‌شود به جای چک کردن همه N گره در هر دور، تنها تعداد کمی از گره‌های بالای صف بررسی شوند. نتایج نشان داد که این روش تعداد فراخوانی‌های شبیه‌ساز را تا حد زیادی کاهش می‌دهد.۴. ارزیابی‌ها و تحلیل نتایجدر این بخش، نتایج حاصل از چهار سناریوی آزمایشی بر روی هر دو مجموعه داده Rice و Michigan تحلیل می‌شود. هدف از این آزمایش‌ها، نه تنها سنجش کارایی الگوریتم‌ها، بلکه درک دینامیک حاکم بر انتشار در شبکه‌های اجتماعی واقعی است.۴-۱. تحلیل نقطه اوج و گذار فازاولین پرسش در مطالعه انتشار این است که یک جامعه تا چه حد می‌تواند در برابر یک رفتار جدید مقاومت کند قبل از اینکه تسلیم شود؟ برای پاسخ به این پرسش، پدیده نقطه اوج (Tipping Point) بررسی شد. در این آزمایش، یک مجموعه بذر اولیه ثابت شامل ۲۰ گره انتخاب شده به صورت تصادفی در نظر گرفته شد. سپس شبیه‌ساز LTM با آستانه متغیر q از ۰.۰۱ تا ۰.۵۰ با گام ۰.۰۱ اجرا شد تا اندازه نهایی آبشار (sigma(S)) سنجیده شود.نمودار حاصل از تغییرات پارامتر q در برابر اندازه آبشار، رفتاری به‌شدت غیرخطی را در هر دو شبکه نشان می‌دهد. به عبارتی شبکه رفتاری دوگانه (All-or-Nothing) دارد:Rice31در شبکه Rice31، برای مقادیر آستانه q <= 0.06، سیستم در حالت فوق بحرانی قرار دارد. در این ناحیه، حتی یک تحریک کوچک (۲۰ بذر اولیه معادل ۰.۵٪ شبکه) منجر به فعال‌سازی بیش از ۹۹٪ گره‌ها یعنی ۴۰۸۳ نفر می‌شود. اما به محض اینکه آستانه به q=0.07 می‌رسد، سیستم دچار یک گذار فاز می‌شود. اندازه آبشار با یک سقوط شدید، از ۴۰۸۳ گره به ۲۷ گره کاهش می‌یابد. این یعنی نقطه اوج بحرانی این شبکه در بازه q_c <= 0.07 و q_c > 0.06 قرار دارد.دیتاست میشیگانآزمایش مشابه بر روی شبکه ۳۰ هزار گره‌ای میشیگان، الگوی مشابه اما با پارامترهای متفاوت را نشان داد. در این شبکه، آبشار سراسری تا آستانه q=0.11 ادامه می‌یابد (فعال‌سازی ۳۰,۱۰۶ گره). اما در q=0.12، انتشار متوقف شده و به ۳۷ گره محدود می‌شود. بنابراین، نقطه اوج در این شبکه در بازه 0.11 < q_c و q_c <= 0.12 قرار دارد.تفاوت قابل توجه در نقطه اوج دو شبکه یعنی ۰.۰۷ برای رایس در مقابل ۰.۱۱ برای میشیگان ممکن است در نگاه اول عجیب به نظر برسد که شبکه بزرگتر (میشیگان)، در برابر انتشار آسیب‌پذیرتر است و می‌تواند رفتارهای سخت‌تر (با هزینه بیشتر) را نیز منتشر کند.این پدیده را می‌توان با ارجاع به مدل واتس (۲۰۰۲) و تفاوت در میانگین درجه دو شبکه توضیح داد. میانگین درجه در شبکه Rice برابر با ۹۰.۴ است. میانگین درجه در شبکه Michigan برابر با ۷۸.۱ است. در مدل آستانه کسری، شرط فعال‌سازی یک گره v به صورت k_active/ k_total >= q است.برای برقراری یک آستانه ثابت (مثلاً q=0.10) یک گره در شبکه Rice (با ۹۰ دوست) نیاز دارد که حدود ۹ دوست فعال داشته باشد. و یک گره در شبکه Michigan (با ۷۸ دوست) نیاز دارد که حدود ۷.۸ (یعنی ۸) دوست فعال داشته باشد.از آنجا که فعال کردن ۸ نفر آسان‌تر از فعال کردن ۹ نفر است، گره‌های شبکه میشیگان با احتمال بیشتری فعال می‌شوند. این مسئله باعث می‌شود که خوشه‌های آسیب‌پذیر در شبکه میشیگان راحت‌تر شکل بگیرند و به یکدیگر متصل شوند. این موضوع ثابت می‌کند که در شبکه‌های اجتماعی متراکم، کاهش تعداد همسایگان (درجه پایین‌تر) می‌تواند به طور متناقضی منجر به تسهیل انتشار رفتارهای پرهزینه شود، زیرا مخرج کسر در فرمول آستانه کوچکتر شده و وزن نسبی هر همسایه افزایش می‌یابد.این آزمایش نشان داد که استراتژی بذردهی تصادفی فقط برای رفتارهایی با هزینه بسیار پایین (کمتر از ۷٪ در رایس و ۱۱٪ در میشیگان) کارآمد است. برای هر رفتاری که آستانه آن بالاتر از این مقادیر باشد (که شامل اکثر نوآوری‌های تجاری و اجتماعی می‌شود)، شبکه در حالت زیر بحرانی قرار دارد و انتشار به سرعت می‌میرد. این واقعیت، ضرورت بررسی موانع ساختاری و استفاده از الگوریتم‌های هوشمند که در ادامه بررسی می‌شوند را توجیه می‌کند.۴-۲. بررسی علت توقف و نقش خوشه‌های مسدودکنندهدر آزمایش قبلی مشخص شد هرگاه آستانه مقاومت (q) از حد بحرانی فراتر می‌رود، انتشار سراسری حتی با وجود ۲۰ بذر اولیه متوقف می‌شود. به عنوان مثال، در سناریوی q=0.3، در هر دو شبکه تقریباً هیچ پیشرفتی حاصل نشد و بیش از ۹۹٪ شبکه غیرفعال باقی ماند.بر اساس قضایای اثبات شده در نظریه شبکه‌ها، یک آبشار با آستانه q، فقط در صورتی متوقف می‌شود که گره‌های باقی‌مانده (غیرفعال)، تشکیل یک خوشه مسدودکننده بدهند. یک خوشه مسدودکننده، مجموعه‌ای از گره‌هاست که هر عضو آن، بخش عمده‌ای از همسایگانش در درون همان مجموعه قرار دارند.در این آزمایش با q=0.3، شرط مقاومت برابر با 1 - 0.3 = 0.7 است. این یعنی انتشار تنها زمانی متوقف می‌شود که تمامی گره‌های غیرفعال، در حلقه‌های دوستی متراکمی قرار گرفته باشند که بیش از ۷۰٪ دوستانشان هم غیرفعال باشند. در چنین حالتی، فشار اجتماعی از بیرون (که حداکثر ۳۰٪ است) برای شکستن مقاومت آن‌ها کافی نیست.برای راستی‌آزمایی این تئوری، الگوریتمی توسعه داده شد که پس از توقف شبیه‌سازی، گراف باقی‌مانده‌ی گره‌های غیرفعال را استخراج و برای تک‌تک گره‌ها، تراکم همسایگان داخلی را محاسبه می‌کند. در شبکه Rice31 از مجموع ۴۰۶۵ گره غیرفعال، تعداد گره‌هایی که شرط تراکم بالا (p > 0.7) را نقض کردند، دقیقاً صفر بود. در شبکه Michigan23 نیز از مجموع ۳۰,۱۲۴ گره غیرفعال، تعداد موارد نقض شرط نیز دقیقاً صفر بود.نتیجه‌ نشان می‌دهد که هیچ یک از دو شبکه، این تئوری را نقض نکردند. این موضوع دو واقعیت مهم را درباره ساختار شبکه‌های اجتماعی واقعی نشان می‌دهد.موضوع اول High Modularity است، شبکه‌های اجتماعی یک توده‌ی همگن نیستند؛ بلکه از بخش‌های مستحکمی تشکیل شده‌اند (احتمالا منطبق بر ساختارهای دانشکده‌ای، خوابگاهی یا گروه‌های ورزشی). این خوشه‌ها چسبندگی داخلی بالایی دارند که نفوذ به آن‌ها از طریق انتشار طبیعی تقریباً غیرممکن است.دومین مسئله، ناکارآمدی بذردهی پراکنده ست، وقتی ما بذرها را به صورت تصادفی در شبکه پخش می‌کنیم، آن‌ها به صورت انفرادی یا در گروه‌های کوچک در پشت دیوارهای این خوشه‌های مسدودکننده قرار می‌گیرند. از آنجا که تراکم داخلی خوشه بالای ۷۰٪ است، یک یا دو دوست فعال در بیرون دیوار، نمی‌توانند کسر نفوذ لازم (۳۰٪) را برای هیچ‌یک از اعضای داخل خوشه تأمین کنند.این موضوع اثبات می‌کند که توقف انتشار در این شبکه‌ها، ناشی از بدشانسی در انتخاب بذرها نیست، بلکه ناشی از موانع ساختاری است. بنابراین، برای موفقیت در انتشار رفتارهای با هزینه متوسط و بالا (q >=0.3)، استراتژی ما باید از پخش تصادفی به سمت تمرکز در بخش خاصی تغییر کند؛ یعنی باید تلاش کنیم تا با انتخاب هوشمندانه بذرها، از این خوشه‌های مسدودکننده عبور کنیم.۴-۳. آزمایش فرضیه پیوندهای ضعیف در مقایسه با سرایت پیچیدهپس از اثبات نقش بازدارنده‌ی خوشه‌های مسدودکننده، قدم بعدی یافتن استراتژی مناسب برای نفوذ به این ساختارهاست. در ادبیات کلاسیک شبکه (Granovetter, 1973)، همیشه بر اهمیت پیوندهای ضعیف یا همان پل‌های ارتباطی که گروه‌های دور از هم را به یکدیگر وصل می‌کنند، تأکید می‌شود. استدلال این است که این پل‌ها، اطلاعات را از بخش‌های تکراری شبکه خارج کرده و به مناطق جدید می‌برند. سوال این است که آیا این اصل برای انتشار رفتارهای پرهزینه با آستانه بالا همچنان صادق است؟برای پاسخ به این مسئله، یک آزمایش طراحی شد تا کارایی دو استراتژی آغازین متفاوت را در شرایطی که رفتار نیازمند تقویت اجتماعی است (q=0.26)، مقایسه کنیم.استراتژی خوشه‌محور (Cluster Strategy): انتخاب یک گروه ۵ نفره در مرکز یک خوشه متراکم (گره مرکزی با ضریب خوشه‌بندی بالا، CC = 1.0). در این گروه، اعضای بذر با یکدیگر پیوند دوستی دارند.استراتژی پل‌محور (Bridge Strategy): انتخاب یک گروه ۵ نفره بر روی یک پل ارتباطی (گره مرکزی با ضریب خوشه‌بندی پایین، CC = 0.0). در این گروه، اعضای بذر همدیگر را نمی‌شناسند و هرکدام به بخش متفاوتی از شبکه متصل‌اند.در شبکه Rice31 نتایج نشان داد که استراتژی خوشه‌محور موفق به فعال‌سازی نهایی ۸ گره شد (افزایش ۳ گره جدید)، در حالی که استراتژی پل‌محور تنها به ۷ گره رسید (افزایش ۲ گره جدید). اگرچه تفاوت کمی به نظر می‌رسد، اما جهت‌گیری آن خلاف پیش‌بینی‌های کلاسیک گرانووتر است. در شبکه Michigan23 برای حذف اثرات تصادفی و دستیابی به نتیجه‌ای قطعی، این آزمایش ۱۰۰ بار به صورت مستقل بر روی شبکه میشیگان تکرار شد. نتایج میانگین به این صورت است که میانگین نفوذ گروه پل ۵.۰۰ گره و میانگین نفوذ گروه خوشه ۵.۸۴ گره است.از آنجا که اندازه بذر اولیه ۵ نفر بود، میانگین ۵.۰۰ به معنای شکست است. یعنی در ۱۰۰ بار آزمایش، استراتژی پل تقریباً هیچ‌گاه نتوانست حتی یک نفر جدید را در خارج از گروه اولیه فعال کند. دلیل شکست پل‌ها به ماهیت سرایت پیچیده برمی‌گردد. برای فعال‌سازی یک گره با آستانه q=0.26، فرد نیاز دارد که حدود ۲۶٪ از دوستانش فعال باشند.در ساختار پل ۵ نفر بذر اولیه از هم دور هستند و همسایگان مشترک ندارند. وقتی سیگنال انتشار از طریق این پل‌ها به بیرون ارسال می‌شود، هر همسایه‌ی بیرونی تنها یک پیام دریافت می‌کند. یک پیام واحد برای غلبه بر آستانه ۲۶٪ کافی نیست.در ساختار خوشه ۵ نفر بذر اولیه، دارای همسایگان مشترک زیادی هستند (ساختار مثلثی). این همسایگان مشترک، به جای دریافت یک سیگنال ضعیف، همزمان از جانب ۲ یا ۳ عضو بذر تحت فشار قرار می‌گیرند. این هم‌افزایی محلی (Local Synergy) باعث می‌شود آستانه مقاومت شکسته شده و افراد جدید فعال شوند.این آزمایش نظریه سنتولا و میسی (۲۰۰۷) را تأیید می‌کند که برای انتشار رفتارهای پرهزینه، ما به پل‌های طولانی نیاز نداریم، بلکه به پل‌های عریض نیاز داریم؛ و خوشه‌های متراکم با فراهم کردن مسیرهای موازی، نقش همین پل‌های عریض را ایفا می‌کنند.۴-۴. ارزیابی الگوریتم‌های بهینه‌سازی نفوذپس از شناخت موانع ساختاری (خوشه‌های مسدودکننده) و ناکارآمدی استراتژی‌های کلاسیک (پیوندهای ضعیف)، گام نهایی این پژوهش، حل مسئله ماکزیمم‌سازی نفوذ است. هدف در این مرحله، شناسایی مجموعه‌ای بهینه از k=10 گره شروع‌کننده ست که بتوانند در شرایط q=0.2، بیشترین گستره انتشار را در شبکه ۳۰ هزار گره‌ای میشیگان ایجاد کنند.به منظور ارزیابی کارایی، الگوریتم بهینه‌سازی حریصانه در برابر سه استراتژی Heuristic متداول مبتنی بر مرکزیت مقایسه شد:بیشترین درجه (High Degree): انتخاب ۱۰ گره محبوب شبکه.مرکزیت بینابینی (Betweenness): انتخاب ۱۰ گره که بیشترین نقش پل ارتباطی را دارند.رتبه صفحه (PageRank): انتخاب ۱۰ گره با بیشترین اعتبار ساختاری.نتایج حاصل از شبیه‌سازی نهایی نشان‌دهنده یک شکاف عملکردی میان روش پیشنهادی و روش‌های سنتی است.جدول ۲: مقایسه نفوذ نهایی استراتژی‌های مختلف (k=10, q=0.2) در شبکه Michigan23همان‌طور که مشاهده می‌شود، الگوریتم حریصانه با فعال‌سازی ۶۰۲ گره، عملکردی فراتر از انتظار داشته است. این میزان، بیش از ۱۱ برابر بهتر از استراتژی درجه (۵۴ گره) و تقریبا ۸ برابر بهتر از بهترین هیوریستیک یعنی مرکزیت بینابینی با ۷۴ گره است.شکست روش‌های مبتنی بر درجه و PageRank، یک واقعیت را درباره ساختار شبکه‌های اجتماعی بیان می‌کند، اینکه پدیده افزونگی ساختاری (Structural Redundancy). گره‌هایی که بیشترین درجه را دارند (مثلا محبوب‌ترین دانشجویان)، معمولاً با یکدیگر دوست هستند و تشکیل یک Rich Club را می‌دهند. وقتی ما ۱۰ نفر اول لیست درجه را انتخاب می‌کنیم، عملاً تمامی منابع خود را در یک ناحیه متراکم از شبکه متمرکز کرده‌ایم. این بذرها، همسایگان مشترک زیادی دارند و نفوذ آن‌ها هم‌پوشانی شدیدی دارد. در نتیجه، انرژی انتشار صرف فعال‌سازی مجدد گره‌هایی می‌شود که قبلاً توسط بذر دیگری فعال شده‌اند و آبشار نمی‌تواند از مرزهای آن خوشه خارج شود.کشف مکمل‌های استراتژیک موفقیت الگوریتم حریصانه ناشی از توانایی آن در مدیریت این هم‌پوشانی‌هاست. بررسی لاگ اجرایی الگوریتم پدیده‌ای به نام انفجارهای تأخیری را نشان می‌دهد. در گام‌های اول و دوم، الگوریتم گره‌هایی را انتخاب کرد که نفوذ متوسطی داشتند (+۲۲ و +۴۲). اما در گام سوم، الگوریتم گرهی را انتخاب کرد که ناگهان منجر به فعال‌سازی ۲۷۱ گره جدید شد. مجدداً در گام هشتم، انتخاب گرهی دیگر منجر به جهش ۱۶۴ نفری شد.این رفتار نشان می‌دهد که الگوریتم حریصانه به دنبال قوی‌ترین فرد نمی‌گردد، بلکه به دنبال بهترین مکمل می‌گردد. گره انتخاب شده ممکن است به تنهایی قدرتمند نباشد، اما در ترکیب با بذرهای انتخاب شده در مراحل قبل، توانسته است آستانه مقاومت یک خوشه مسدودکننده بزرگ را بشکند. این هم‌افزایی میان بذرها، ویژگی منحصر‌به‌فردی است که هیچ‌یک از معیارهای مرکزیت ایستا قادر به درک آن نیستند و فقط از طریق شبیه‌سازی دینامیک (روش حریصانه) قابل شناسایی است.۴-۵. حل چالش زمان با الگوریتم CELFاگرچه نتایج بخش قبل برتری الگوریتم حریصانه را در کیفیت نفوذ اثبات کرد، اما یک چالش مربوط به زمان و هزینه محاسباتی هنوز وجود دارد.الگوریتم حریصانه کلاسیک برای یافتن ۱۰ گره بذر در شبکه ۳۰ هزار گره‌ای میشیگان، نیازمند ارزیابی نفوذ حاشیه‌ای تمام گره‌ها در تمام دورها بود. این فرآیند منجر به زمان اجرای بسیار طولانی (بیش از ۴.۵ ساعت) شد. چنین هزینه زمانی برای شبکه‌های واقعی امروزی یا برای سناریوهایی که نیاز به تعداد بذر بیشتر (k=50 یا k=100) دارند، قابل پذیرش نیست.برای حل این موضوع، نسخه بهینه‌سازی شده‌ای از الگوریتم با نام CELF (Cost-Effective Lazy Forward) پیاده‌سازی شد. این الگوریتم بدون آنکه از دقت الگوریتم حریصانه کم کند، با بهره‌گیری هوشمندانه از ویژگی‌های ریاضی تابع نفوذ، زمان اجرا را به طرز چشمگیری کاهش می‌دهد.ویژگی Submodularity بیان می‌کند که Marginal Gain افزودن یک گره خاص به مجموعه بذر، با بزرگتر شدن مجموعه بذر، هرگز افزایش نمی‌یابد.بنابراین، اگر گره u در دور اول سود حاشیه‌ای ۱۰۰ داشته باشد و گره v سود ۹۰، در دور دوم سود u ممکن است به ۸۰ کاهش یابد، اما هرگز ۱۰۱ نخواهد شد. CELF از این واقعیت برای Lazy Evaluation استفاده می‌کند. گره‌ها در یک صف اولویت نگهداری می‌شوند و در هر دور، تنها نفوذ گره‌های بالای صف به‌روزرسانی می‌شود. اگر گره بالای صف پس از به‌روزرسانی همچنان از نفر دوم (که مقدارش مربوط به دور قبل است) بالاتر باشد، بدون نیاز به محاسبه سایرین، به عنوان برنده انتخاب می‌شود.جدول ۳: مقایسه کارایی الگوریتم حریصانه ساده و CELF (k=10 در شبکه Michigan23)تفاوت جزئی در تعداد گره‌های فعال ناشی از ماهیت احتمالاتی شبیه‌سازی مونت‌کارلو است و به معنای تفاوت در منطق انتخاب نیست. پیاده‌سازی CELF توانست زمان اجرا را از حدود ۵ ساعت به کمتر از ۴۰ ثانیه کاهش دهد. تحلیل لاگ سیستم نشان می‌دهد که پس از محاسبه اولیه، الگوریتم CELF برای انتخاب ۱۰ بذر نهایی، تنها ۱۸ بار شبیه‌ساز را فراخوانی کرده است (در مقایسه با حدود ۳۰۰,۰۰۰ فراخوانی در روش حریصانه).بررسی مجموعه بذر خروجی نشان می‌دهد که CELF موفق به شناسایی دقیق همان گره‌ها شده است. گره‌های کلیدی مانند 16995 (عامل جهش اول) و 14040 (عامل جهش دوم) دقیقاً در خروجی CELF نیز حضور دارند.۵. جمع‌بندیاین پژوهش با هدف بررسی دینامیک انتشار در شبکه‌های اجتماعی و بهینه‌سازی نفوذ انجام شد. با عبور از مدل‌های ویروسی و پیاده‌سازی مدل آستانه خطی با پارامترهای ناهمگن بر روی دو مجموعه داده واقعی (Rice31 و Michigan23)، نتایجی حاصل شد که هم از دید نظری و هم از منظر کاربردی حائز اهمیت است.دستاوردهای کلیدی:اثبات مقاومت ساختاری: تحلیل نقطه اوج نشان داد که شبکه‌های اجتماعی دارای رفتار گذار فاز هستند. دیدیم که عامل اصلی توقف انتشار در این شبکه‌ها، تصادفی نیست؛ بلکه ناشی از وجود خوشه‌های مسدودکننده با تراکم داخلی بالا است. آزمایش با نشان دادن خطای صفر در تشخیص این خوشه‌ها، استحکام ماژولار شبکه‌های اجتماعی را اثبات کرد.آزمون‌های مقایسه‌ای نشان داد که برای سرایت پیچیده که یک رفتار پرهزینه محسوب می‌شود، تئوری کلاسیک قدرت پیوندهای ضعیف کارایی ندارد. در عوض، شروع انتشار از درون خوشه‌های متراکم به دلیل ایجاد تقویت اجتماعی و هم‌افزایی بین بذرها، استراتژی موفق‌تری است.در بخش بهینه‌سازی، نشان داده شد که معیارهای سنتی مانند بیشترین درجه یا PageRank به دلیل نادیده گرفتن هم‌پوشانی نفوذ، عملکرد ضعیفی دارند. در مقابل، الگوریتم حریصانه با شبیه‌سازی دینامیک شبکه و کشف مکمل‌های استراتژیک، توانست نفوذی ۱۱ برابر بیشتر ایجاد کند.با پیاده‌سازی الگوریتم CELF، نشان داده شد که می‌توان بر چالش NP-Hard بودن مسئله غلبه کرد. کاهش زمان اجرا از ۴.۵ ساعت به کمتر از ۴۰ ثانیه بدون افت دقت، امکان پیاده‌سازی این راهکار را در شبکه‌هایی با مقیاس بزرگ فراهم می‌کند.این پژوهش می‌تواند در چند جهت توسعه یابد که به برخی از آن‌ها اشاره می‌کنیم:در نظر گرفتن بُعد زمان: مدل فعلی تنها نفوذ نهایی را می‌سنجد. می‌توان با افزودن پارامتر زمان، سرعت انتشار را نیز بهینه کرد.Adaptive Seeding: به جای انتخاب تمام k بذر در ابتدا، می‌توان بذرها را در چند مرحله انتخاب کرد تا از وضعیت جدید شبکه پس از موج اول انتشار بهره‌برداری شود.Competitive Diffusion: بررسی حالتی که دو رفتار متضاد (مثلاً شایعه و تکذیبیه) همزمان در شبکه منتشر می‌شوند و برای گرفتن گره‌ها رقابت می‌کنند.منابع:[1] Centola, D., & Macy, M. (2007). Complex Contagion and the Weakness of Long Ties. American Journal of Sociology, 113(3), 702-734.[2] Easley, D., & Kleinberg, J. (2010). Networks, Crowds, and Markets: Reasoning About a Highly Connected World. Cambridge University Press. (Chapter 19: Cascading Behavior in Networks).[3] Granovetter, M. S. (1973). The Strength of Weak Ties. American Journal of Sociology, 78(6), 1360-1380.[4] Kempe, D., Kleinberg, J., & Tardos, É. (2003). Maximizing the spread of influence through a social network. Proceedings of the ninth ACM SIGKDD international conference on Knowledge discovery and data mining (KDD '03), 137-146.[5] Leskovec, J., Krause, A., Guestrin, C., Faloutsos, C., VanBriesen, J., & Glance, N. (2007). Cost-effective outbreak detection in networks. Proceedings of the 13th ACM SIGKDD international conference on Knowledge discovery and data mining (KDD '07), 420-429.[6] Rossi, R., & Ahmed, N. (2015). The Network Data Repository with Interactive Graph Analytics and Visualization. Proceedings of the Twenty-Ninth AAAI Conference on Artificial Intelligence.[7] Watts, D. J. (2002). A Simple Model of Global Cascades on Random Networks. Proceedings of the National Academy of Sciences (PNAS), 99(9), 5766-5771. Fatemeh Rafiee Fatemeh Rafiee Sat, 07 Feb 2026 14:49:51 +0330 https://virgool.io/@fatemehrafiee/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-cjucs36ahuiv ۱. تاریخچه نتفلیکسنتفلیکس در سال ۲۰۰۷ خدمات استریم ویدیو را راه‌اندازی کرد که به کاربران اجازه می داد محتوا را بدون نیاز به دانلود مستقیماً مشاهده کنند. در ابتدا محتوای غیر اوریجینال در آن عرضه می شد ولی به تدریج شروع به تولید محتوای اختصاصی خود مثل سریال ها و فیلم ها کردند. تا سال ۲۰۱۰، نتفلیکس به ۲۰ میلیون مشترک در سراسر جهان دست یافت. در طی سال‌های بعدی نیز به رشد خود ادامه داد و در حال حاضر بیش از 302 میلیون مشترک، بزرگترین سرویس استریم ویدیو در جهان محسوب می شود.نتفلیکس به یکی از محبوب‌ترین پلتفرم‌های استریم فیلم و سریال در جهان تبدیل شده است و به طور مداوم در حال رشد و توسعه است. این شرکت که به غول استریمینگ شهرت دارد، به دلیل معماری ابری پیچیده خود که قابلیت اطمینان، مقیاس‌پذیری و عملکرد را برای کاربران در سراسر جهان تضمین می‌کند، شناخته شده است. نتفلیکس روی دو ابر AWS و Open Connect کار می‌کند. این دو سرویس ابری به عنوان ستون فقرات Netflix با هم کار می کنند و هر دو مسئولیت اساسی در ارائه ویدیو به کاربران دارند.۲. اجزای اصلی معماری نتفلیکسنگاهی بر معماری نتفلیکس در سطح کلانالف) کلاینت: دستگاه‌ها و رابط کاربری که برای پخش ویدیوهای Netflix استفاده می‌شود. مانند تلویزیون، XBOX، لپ‌تاپ یا تلفن همراه.ب) زیرساخت اختصاصی Open Connect یا CDN نتفلیکس:تعریف CDN: شبکه تحویل محتوا (content delivery network) سیستمی از سرورهای توزیع شده (شبکه) است که صفحات و سایر محتوای وب را بر اساس موقعیت جغرافیایی کاربر، مبدا صفحه وب و سرور تحویل محتوا، به کاربر تحویل می‌دهد.Open Connect ویدیوی Netflix را در مکان‌های مختلف در سراسر جهان ذخیره می‌کند. دقیقاً همان کاری که از یک CDN انتظار می‌رود.وقتی پخش ویدیو را فشار می‌دهیم، محتوا از Open Connect به ریکوئست ارسالی پاسخ داده می‌شود و برای نمایش از آن استفاده می‌شود تا سرعت بالاتری برای دسترسی وجود داشته باشد.سیستم شبکه تحویل محتوا (CDN)، شبکه‌ای از سرورهای توزیع شده در نقاط مختلف جهان است. در واقع OC همان CDN اختصاصی و سفارشی‌سازی شده خود Netflix است که همه چیزهایی را که مستلزم پخش ویدئو است را مدیریت می‌کند. سرورهای Open Connect در سراسر جهان توزیع شده‌اند.سناریوی اجرایی مراحل OC‌ها و درخواست کاربران به سایت Netflix از طریق CDN‌های اختصاصی:کاربر درخواستی برای یک ویدیو به وب سایت یا برنامه نتفلیکس ارسال می‌کند.درخواست به CDN مسیریابی می‌شود.سرویس CDN بررسی می‌کند که آیا نسخه ذخیره شده محلی از ویدیو در دسترس است یا خیر.اگر نسخه محلی موجود باشد، CDN آن را به کاربر تحویل می‌دهد.اگر نسخه محلی در دسترس نباشد، CDN درخواست را به یکی از سرورهای اصلی هدایت می‌کند.سرور اصلی پس از مسیریابی، نسخه‌ای از ویدیو را برای CDN ارسال می‌کند.سرویس CDN، نسخه درخواستی را برای کاربر ارسال می‌کند، همچنین آن را در edge شبکه خود برای درخواست‌های بعدی ذخیره می‌کند.کاربر ویدیو را تماشا می‌کند و به همین شکل سایر درخواست‌ها نیز مدیریت می‌شوند.مزایای AWS و CDN:مقیاس‌پذیری AWS و CDN: به نتفلیکس اجازه می‌دهند تا به راحتی با افزایش تقاضا برای خدمات خود سازگار شود.عملکرد بهتر: CDN با کاهش زمان تاخیر و بهبود کیفیت پخش، تجربه بهتری برای کاربران ایجاد می‌کند.کاهش هزینه: استفاده از خدمات ابری به نتفلیکس اجازه می‌دهد تا هزینه‌های زیرساخت را به صورت pay as you go پرداخت کند، که می‌تواند به صرفه‌جویی در هزینه‌های کلی منجر شود.Reliability: استفاده از چندین منطقه AWS و CDN به نتفلیکس امکان می‌دهد تا در صورت خرابی در یک منطقه، به ارائه سرویس خود ادامه دهد.OCA‌ها در ISP‌ها:OCA‌ها در ISP‌ها نصب می‌شوند که باعث می‌شود آن‌ها نزدیک کاربر باشند و در نهایت باعث کاهش تأخیر و بهبود کیفیت استریم می‌شود.نتفلیکس پیش‌بینی می‌کند که کاربران احتمالاً ویدیوهایی را تماشا می‌کنند و آن‌ها را در OCA در ساعات غیر اوج مصرف ذخیره می‌کنند، که استفاده از پهنای باند را کاهش می‌دهد و سرعت پخش را بهبود می‌بخشد.نقش CDN در عملکرد:کاهش تأخیر و بهبود زمان loading:سرورهای توزیع شده جغرافیایی: CDN نتفلیکس سرورهایی دارد که به صورت استراتژیک در سراسر جهان قرار گرفته‌اند و آن‌ها را بدون توجه به مکان کاربران به آن‌ها نزدیک‌تر می‌کند. این امر به طور قابل توجهی فاصله فیزیکی که داده‌ها باید طی کنند را کاهش می‌دهد و تأخیر را به حداقل می‌رساند و در نتیجه منجر به loading سریع‌تر برای ویدیوها و محتوای مرتبط می‌شود.پخش با نرخ بیت تطبیقی (ABR) و بافرینگ:ذخیره‌سازی سرورهای لبه: محتوای پربازدید، از جمله نسخه‌های مختلف نرخ بیت جریان‌های ویدیویی، در سرورهای لبه نزدیک‌تر به کاربران ذخیره می‌شود. این امکان دسترسی فوری به محتوا را بدون نیاز به دریافت آن از سرورهای اصلی می‌دهد و در نتیجه تأخیر را بیشتر کاهش می‌دهد و وقفه‌های بافرینگ را به حداقل می‌رساند.کاهش تراکم شبکه:همکاری‌های Open Connect: نتفلیکس از طریق Open Connect با ارائه‌دهندگان خدمات اینترنتی (ISP) همکاری می‌کند و اتصالات اختصاصی را ایجاد می‌کند که اولویت را به ترافیک نتفلیکس می‌دهند. این امر از مسیرهای شلوغ اینترنت عمومی عبور می‌کند و مسیر مستقیم‌تر و کم‌بارتری برای انتقال داده ارائه می‌کند که منجر به پخش روان‌تر و بافرینگ کمتر می‌شود.مقیاس‌پذیری و انعطاف‌پذیری:تعادل بار پویا: CDN به طور هوشمندانه ترافیک را در شبکه بزرگ سرورهای خود توزیع می‌کند و اطمینان می‌یابد که هیچ سروری بیش از حد تحت بار نباشد و گلوگاه‌ها به حداقل برسند. این به نتفلیکس امکان می‌دهد جلسات (Session) پخش همزمان را بدون افت عملکرد مدیریت کند.مقیاس‌گذاری خودکار بر اساس تقاضا: نتفلیکس از ابزارهایی برای مقیاس‌گذاری خودکار زیرساخت CDN خود بر اساس تقاضای لحظه‌ای استفاده می‌کند. این امر ظرفیت کافی را در ساعات اوج تضمین می‌کند و از تأمین بیش از حد منابع در دوره‌های خلوت‌تر جلوگیری می‌کند و هزینه و عملکرد را بهینه می‌کند.مزایای دیگر:کاهش بار سرور: با ارائه محتوا مستقیماً از سرورهای لبه، CDN به طور قابل توجهی بار سرورهای اصلی نتفلیکس را کاهش می‌دهد و به آن‌ها اجازه می‌دهد تا بر پردازش محتوا و مدیریت تحویل تمرکز کنند.قابلیت اطمینان بهبود یافته: ماهیت توزیع شده CDN افزونگی و تحمل خطا را فراهم می‌کند. اگر یک سرور با مشکلی مواجه شود، سایر سرورها می‌توانند ترافیک را مدیریت کنند و حتی در صورت قطع برق موضعی، توقف کار را به حداقل رسانده و پخش بدون وقفه را تضمین کنند.پ) زیرساخت و توسعه بک‌اند: این بخش تمام کارهایی را که مربوط به پخش ویدئویی نباشد (مانند محتوای جدید، پردازش ویدئوها، توزیع ویدئوها روی سرورهای مختلف در نقاط مختلف جهان و مدیریت ترافیک شبکه) انجام می‌دهد. مؤلفه Backend شامل پایگاه‌داده‌ها، سرورها، monitoring، موتور recommendation، سرویس‌های background و غیره می‌باشد. بیشتر این فرآیندها مانند login، recommendation، تاریخچه‌ی کاربران، صورتحساب‌ها، و پشتیبانی مشتری توسط سرویس‌های وب آمازون (AWS) مدیریت می‌شوند. به عبارت دیگر، وقتی ما یک فیلم یا سریال را در نتفلیکس انتخاب می‌کنیم، ابتدا "بک‌اند" کارهای لازم برای آماده‌سازی آن را انجام می‌دهد. سپس ویدئو بر روی شبکه CDN توزیع می‌شود و نزدیک‌ترین سرور Open Connect آن را با بالاترین کیفیت و سرعت ممکن برای شما پخش می‌کند. AWS EC2، AWS S3، Cassandra، Hadoop و Kafka نمونه‌هایی از سرویس‌های Backend هستند.نتفلیکس از طیف وسیعی از خدمات AWS برای پشتیبانی از عملیات خود استفاده می‌کند، از جمله:سرویس Amazon EC2 برای میزبانی مایکروسرویس‌ها و سایر برنامه‌های کاربردی.سرویس Amazon S3 برای ذخیره‌سازی محتوای ویدیویی.سرویس Amazon DynamoDB برای ذخیره‌سازی meta data و داده‌های کاربر.سرویس Amazon CloudFront برای توزیع محتوای استاتیک مانند تصاویر و کد جاوا اسکریپت.سرویس ELB که به تنظیم بار کاربران روی نمونه‌های مختلف نرم‌افزاری و محتوای ویدئویی کمک می‌کند.ت) رابط کاربری نتفلیکس: نتفلیکس بخش فرانت‌اند را به سه دلیل اصلی با ReactJS ساخته است:سرعت راه‌اندازی: ReactJS به توسعه‌دهندگان اجازه می‌دهد اجزای مستقل بسازند که می‌توان آن‌ها را به راحتی تست و به‌روزرسانی کرد. این امر به راه‌اندازی سریع ویژگی‌های جدید و بهبود تجربه کاربری کمک می‌کند.کارایی در زمان اجرا: ReactJS از یک DOM مجازی استفاده می‌کند که کارآیی رندر را بهبود می‌بخشد و منجر به تجربه روان‌تری برای کاربران می‌شود، به خصوص روی دستگاه‌های کم‌توان.ماژولار بودن: اجزای ReactJS کاملاً مستقل هستند که باعث می‌شود کد تمیزتر، سازمان‌یافته‌تر و قابل نگهداری‌تر شود. این امر به همکاری تیمی مؤثر و توسعه سریع نرم‌افزار کمک می‌کند.گلوگاه (سرویس عضویت): به عنوان یک سرویس پخش آنلاین مبتنی بر اشتراک مانند نتفلیکس، منبع اصلی درآمد آن، پلن عضویت است. بنابراین نتفلیکس باید بیش از 250 میلیون عضویت در سراسر جهان را مدیریت کند. پلتفرم عضویت در نتفلیکس نقش حیاتی در مدیریت کل چرخه عمر اشتراک کاربر دارد، مانند ثبت نام، تغییرات طرح، تمدید، مشکلات پرداخت، توقف یا لغو عضویت.معماری عضویت در نتفلیکسنکات کلیدی در مورد معماری سرویس عضویت:پلتفرم عضویت، کاتالوگ طرح عضویت و قیمت‌گذاری را به صورت جهانی و با تغییرات در مناطق مختلف مدیریت می‌کند.سرویس کاتالوگ قیمت‌گذاری طرح، مدیریت قوانین را بر اساس پیشنهادات خاص هر مکان انجام می‌دهد.دو پایگاه داده CockroachDB برای ذخیره اطلاعات قیمت‌گذاری طرح و بازخرید استفاده می‌شوند.سرویس قیمت‌گذاری اعضا از اقدامات اعضا، مانند تغییر طرح‌ها یا اضافه کردن اعضای اضافی، پشتیبانی می‌کند.یک میکروسرویس اختصاصی، تعاملات شرکا، از جمله فعال‌سازی بسته‌ها، ثبت‌نام‌ها و ادغام با پلتفرم‌هایی مانند اپ استور اپل را مدیریت می‌کند.داده‌های عضویت در پایگاه‌های داده Cassandra ذخیره می‌شوند که از سرویس اشتراک و سرویس ردیابی تاریخچه پشتیبانی می‌کنند.داده‌های تولید شده توسط پلتفرم برای استخراج insight در مورد ثبت‌نام‌ها و پیش‌بینی‌های درآمد، به مصرف‌کنندگان پایین‌دست ارسال می‌شود.در مراحل اولیه پلتفرم عضویت نتفلیکس، تاریخچه و داده‌های اعضا از طریق رویدادهای سطح برنامه ردیابی می‌شدند. برای دستیابی به راهکار ردیابی داده‌های جزئی‌تر و پایدارتر، نتفلیکس روشی مبتنی بر الگوی تغییر داده‌ها (CDC) توسعه داد. CDC یک الگوی طراحی است که مستقیماً تغییرات ایجاد شده در یک پایگاه داده را ثبت می‌کند و آن تغییرات را برای پردازش یا تجزیه و تحلیل بیشتر به سیستم‌های پایین‌دستی منتقل می‌کند. اتخاذ رویکردی شبیه به CDC تضمین می‌کند که تمام تغییرات ایجاد شده در منابع داده عضویت در یک سیستم ثبت وقایع append-only ثبت شوند، که توسط یک پایگاه داده Cassandra پشتیبانی می‌شود.نحوه عملکرد CDCبهینه‌سازییکی از بهینه‌سازی‌های اصلی انجام شده توسط نتفلیکس، اولویت‌بندی حذف بار است. اولویت‌بندی حذف بار در لایه Zuul API Gateway پیاده‌سازی شده است. این سیستم به طور مؤثر انواع مختلف ترافیک شبکه را مدیریت می‌کند و تضمین می‌کند که درخواست‌های پخش حیاتی نسبت به ترافیک تله‌متری کم‌اهمیت‌تر در اولویت قرار گیرند.سرویس PlayAPI: یک سرویس backend حیاتی در صفحه کنترل پخش ویدئو است که مسئول رسیدگی به پخش آغاز شده توسط دستگاه و درخواست‌های مجوز لازم برای شروع پخش است. PlayAPI این درخواست‌ها را بر اساس اهمیت آن‌ها دسته‌بندی می‌کند:درخواست‌های آغاز شده توسط کاربر (حیاتی): این درخواست‌ها زمانی انجام می‌شوند که کاربر دکمه پخش را می‌زند و مستقیماً بر توانایی کاربر برای شروع تماشای یک نمایش یا فیلم تأثیر می‌گذارند.درخواست‌های pre-fetch (غیرحیاتی): این درخواست‌ها به صورت خوش‌بینانه زمانی انجام می‌شوند که کاربر بدون زدن دکمه پخش، محتوا را مرور می‌کند تا در صورت تصمیم کاربر برای تماشای یک عنوان خاص، تأخیر کاهش یابد.این شرکت یک محدودکننده همزمانی را در PlayAPI پیاده‌سازی کرده است که درخواست‌های آغاز شده توسط کاربر را نسبت به درخواست‌های pre-fetch اولویت‌بندی می‌کند، بدون اینکه دو کنترل‌کننده درخواست را به صورت فیزیکی تقسیم‌بندی کند. مکانیزم اولویت‌بندی فقط زمانی فعال می‌شود که سرور به محدودیت همزمانی رسیده باشد و نیاز به رد درخواست‌ها داشته باشد.پردازش افزایشی برای داده‌های جدید یا تغییر یافته در گردش‌های کاری: مزیت کلیدی این روش این است که فقط داده‌هایی را که به تازگی به مجموعه داده‌ها اضافه یا به‌روزرسانی شده‌اند، به صورت افزایشی پردازش می‌کند، به جای اینکه کل مجموعه داده‌ها را دوباره پردازش کند. این روش هزینه منابع محاسباتی را کاهش می‌دهد، و زمان اجرا را نیز به میزان قابل توجهی کاهش می‌دهد. برای پشتیبانی از پردازش افزایشی، باید تغییرات افزایشی داده‌ها را ثبت و وضعیت آن‌ها را پیگیری کند. باید از تغییر آگاه باشد و بتواند تغییرات را از جدول(های) منبع ثبت کند و سپس به ردیابی آن تغییرات ادامه دهد. اطلاعات تغییر ثبت شده باید شامل تمام داده‌های مرتبط، از جمله ردیف‌های تغییر نیافته در جدول منبع نیز باشد. پس از ثبت اطلاعات تغییر (داده یا محدوده)، یک گردش کاری باید داده‌ها را به روشی کمی پیچیده‌تر در جدول هدف بنویسد. نتفلیکس از نوشتن فقط با اضافه کردن (مثلاً INSERT INTO) برای اضافه کردن داده‌های جدید به مجموعه داده‌های موجود استفاده می‌کند. پس از اتمام پردازش، داده‌های اضافه شده به جدول ارسال می‌شوند.مقاومت در برابر خرابی‌ها: نتفلیکس برای مقاوم‌سازی سرویس‌ها در برابر هر نوع خرابی، هنگام فراخوانی سایر سرویس‌ها، مدیریت خطاها، تلاش‌های مجدد و زمان‌های از دست رفته را انجام می‌دهد.پروتکل ارتباط با پایگاه داده: پروتکل RTMP (Real-Time Messaging Protocol) برای ارتباط با پایگاه داده استفاده می‌شود. این پروتکل که توسط Macromedia (اکنون متعلق به Adobe) برای پخش صدا، تصویر و داده‌ها از طریق اینترنت توسعه یافته است، به دلیل قابلیت‌ تأخیر کم، به طور گسترده برای پخش زنده استفاده می‌شود. RTMP با تجزیه داده‌ها به قطعات کوچکتر و انتقال آن‌ها از طریق یک اتصال مداوم، تحویل روان و مداوم را تضمین می‌کند.قابلیت مشاهده و نظارت: نتفلیکس تأکید زیادی بر قابلیت مشاهده و نظارت دارد تا عملکرد روان پلتفرم عضویت خود را تضمین کند.ثبت وقایع گسترده، داشبوردها و مکانیسم‌های ردیابی توزیع‌شده، امکان تشخیص و رفع سریع خطا را فراهم می‌کنند. در معماری میکروسرویس نتفلیکس، این ابزارها برای شناسایی و عیب‌یابی مشکلات ضروری هستند.داده‌های عملیاتی برای تقویت مدل‌های یادگیری ماشینی که تشخیص ناهنجاری را افزایش می‌دهند و فرآیندهای حل خودکار مشکل را فعال می‌کنند، به کار گرفته می‌شوند. همه این کارها برای تلاش و حفظ یک تجربه پخش بدون وقفه برای کاربران انجام می‌شود.نتفلیکس از ابزارهایی مانند کیبانا و الاستیک‌سرچ برای ایجاد داشبورد و تجزیه و تحلیل داده‌های لاگ استفاده می‌کند. در صورت افزایش ناگهانی نرخ خطا، این داشبوردها به تیم اجازه می‌دهند تا به سرعت endpoint خاص ایجادکننده مشکل را شناسایی کرده و اقدامات اصلاحی را انجام دهند.روند تولید و استقرار ویدئوها در نتفلیکس: در قدم اول ویدیوهایی با کیفیت بالا از شرکت‌های فیلمسازی دریافت می‌شوند، اما پیش از آنکه بر صفحه نمایش ظاهر شوند، نیاز به چندین مرحله آماده‌سازی دارند. قبل از اینکه محتواهای ویدیویی در دسترس کاربران قرار گیرد، نتفلیکس باید ویدیو را به فرمتی تبدیل کند که برای دستگاه هر شخص بهترین کارایی را داشته باشد. این فرآیند Transcoding نامیده می‌شود. Transcoding فرآیندی است که یک فایل ویدئویی را از یک فرمت به فرمت دیگر تبدیل می‌کند تا فیلم‌ها در پلتفرم‌ها و دستگاه‌های مختلف قابل مشاهده باشند.مراحل ترنسکدینگ:تجزیه و تحلیل ویدئوی اصلی: ابتدا، ویدئوی اصلی تجزیه و تحلیل می‌شود تا خطاهای احتمالی شناسایی و اصلاح شوند.انتخاب فرمت‌ها و رزولوشن‌ها: بر اساس دستگاه‌های پشتیبانی شده، نتفلیکس فرمت‌ها و رزولوشن‌های مختلفی را برای ویدئو تعیین می‌کند. این انتخاب شامل فرمت‌های استاندارد برای تلویزیون‌ها، رایانه‌های شخصی، تبلت‌ها و تلفن‌های همراه است.انکودینگ ویدئو: سپس، ویدئوی اصلی به فرمت‌ها و رزولوشن‌های مختلف انکود می‌شود. این فرآیند شامل فشرده‌سازی ویدئو برای اطمینان از کاهش حجم داده‌ها بدون از دست دادن کیفیت قابل توجه است.ذخیره‌سازی و توزیع: پس از انکودینگ، ورژن‌های مختلف ویدئو در سرورهای نتفلیکس ذخیره می‌شوند. این سرورها بخشی از شبکه تحویل محتوای (CDN) نتفلیکس هستند، که توزیع موثر ویدئوها به کاربران در سراسر جهان را تضمین می‌کند.پخش بهینه: هنگامی که کاربر درخواست پخش ویدئویی را می‌دهد، نتفلیکس به طور خودکار بهترین ورژن ویدئو را بر اساس پهنای باند و دستگاه کاربر انتخاب می‌کند. این اطمینان حاصل می‌کند که کاربران تجربه پخش بهینه‌ای داشته باشند، حتی در شرایط پهنای باند محدود.پشتیبانی از Adaptive Bitrate Streaming: همچنین هر ویدیو به بخش‌های زیادی تقسیم می‌شود تا از جریان نرخ بیت تطبیقی ​​(adaptive bitrate streaming) پشتیبانی کند. پخش با نرخ بیت تطبیقی ​​امکان تغییر کیفیت ویدیو را با تغییر شرایط شبکه فراهم می‌کند. در صورتی که شرایط شبکه ضعیف باشد، وضوح استریم هم پایین تر می آید.مدیریت حقوق دیجیتال (DRM): علاوه بر این، یک کد ویژه برای جلوگیری از دزدی به فایل‌ها اضافه می‌شود. به آن مدیریت حقوق دیجیتال (DRM) می‌گویند. محتوای ویدیو را رمزگذاری می‌کند و از دسترسی غیرمجاز جلوگیری می‌کند.بهینه‌سازی فایل‌ها در نتفلیکس: نتفلیکس از بیش از ۲۲۰۰ دستگاه پشتیبانی می‌کند و هر کدام از آن‌ها وضوح و فرمت متفاوتی را می‌طلبند. برای برآوردن این نیاز، فرآیند کدگذاری ویدئو وارد صحنه می‌شود. مهندسان ابتدا خطاهای موجود را یافته و سپس ویدیوی اصلی را به فرمت‌ها و وضوح‌های مختلفی تقسیم می‌کنند. سرعت اینترنت نیز در کیفیت تماشا نقش مهمی دارد. به همین دلیل، برای هر فیلم، نتفلیکس حدود ۱۱۰۰ تا ۱۲۰۰ نسخه با رزولوشن‌های متفاوت (مانند 4k و 1080p) ایجاد می‌کند. نتفلیکس چندین کپی برای یک فیلم با وضوح‌های مختلف ایجاد می‌کند. این کپی‌ها نیاز به رمزگذاری و پیش‌پردازش زیادی دارند. نتفلیکس ویدیوی اصلی را به تکه‌های کوچک‌تر تقسیم می‌کند و با استفاده از پردازش‌های موازی در AWS، این تکه‌ها را به فرمت‌های مختلف (مانند mp4، 3gp و غیره) در وضوح‌های تصویر مختلف (مانند 4k، 1080p و غیره) تبدیل می‌کند. پس از رمزگذاری، فایل‌های کپی ساخته شده، به تمام سرورهای مختلف که در مکان‌های جغرافیایی متفاوت توزیع شده‌اند منتقل می‌شوند.پخش با نرخ بیت تطبیقی (ABR): نتفلیکس به صورت لحظه‌ای وضعیت شبکه را تجزیه و تحلیل می‌کند و کیفیت (نرخ بیت) جریان ویدیو را بر اساس آن تنظیم می‌کند. این کار با اجتناب از وقفه‌های بافرینگ، حتی با اتصالات کندتر، پخش روان را تضمین می‌کند. نسخه‌های با نرخ بیت پایین‌تر از همان محتوا نیز در دسترس هستند که با فدا کردن مقداری از کیفیت ویدیو، عملکرد بهتری در پهنای باند محدود ارائه می‌دهند.پیش‌نمایش و بافرینگ: نتفلیکس اقدامات کاربر را پیش‌بینی می‌کند و داده‌های فیلم‌ها یا نمایش‌های آینده را در پس‌زمینه پیش‌نشان می‌دهد. این کار یک بافر ایجاد می‌کند که حتی در صورت نوسانات لحظه‌ای شرایط شبکه، پخش بدون وقفه را تضمین می‌کند.کدک‌های HEVC و VP9: نتفلیکس از کدک‌های ویدیویی پیشرفته مانند HEVC و VP9 استفاده می‌کند که در عین حفظ کیفیت تصویر عالی، فشرده‌سازی بالایی انجام می دهند. این میزان داده مورد نیاز برای ارسال ویدیو را کاهش می‌دهد و نیاز به پهنای باند و پتانسیل بافرینگ را به حداقل می‌رساند.قالب‌های کانتینر کارآمد: آن‌ها از قالب‌های کانتینر کارآمدی مانند MP4 استفاده می‌کنند که سربار را به حداقل می‌رساند و پخش روان را تضمین می‌کند.فرآیند گام به گام نحوه اطمینان نتفلیکس از کیفیت پخش بهینه:زمانی که کاربر اپلیکیشن نتفلیکس را بر روی دستگاه خود بارگذاری می‌کند، ابتدا نمونه‌های AWS وارد عمل می‌شوند و برخی وظایف مانند ورود به سیستم، توصیه‌ها، جستجو، تاریخچه کاربر، صفحه اصلی، صورت‌حساب، پشتیبانی مشتری و غیره را انجام می‌دهند.پس از آن، زمانی که کاربر دکمه پخش را بر روی یک ویدئو فشار می‌دهد، نتفلیکس سرعت شبکه یا ثبات اتصال را تجزیه و تحلیل می‌کند و سپس بهترین سرور Open Connect نزدیک به کاربر را پیدا می‌کند.بسته به دستگاه و اندازه صفحه نمایش، فرمت ویدئوی مناسب به دستگاه کاربر پخش می‌شود.هنگام تماشای ویدئو، ممکن است ویدئو به صورت کیفیت پایین ظاهر شود و پس از مدتی دوباره به HD بازگردد. این اتفاق به این دلیل می‌افتد که برنامه به طور مداوم بهترین سرور Open Connect را برای پخش چک می‌کند و در صورت نیاز بین فرمت‌ها (برای بهترین تجربه تماشا) جابجا می‌شود. به این قابلیت نتفلیکس، پخش تطبیقی (Adaptive) ویدئو گفته می‌شود.داده‌های کاربر مانند جستجوها، تماشاها، مکان، دستگاه، نظرات و پسندها در AWS ذخیره می‌شوند، و نتفلیکس از این داده‌ها برای ساخت توصیه‌های فیلم برای کاربران با استفاده از مدل یادگیری ماشینی یا هادوپ استفاده می‌کند.انتخاب زمان Transcoding: تصمیم اینکه transcoding در چه مرحله‌ای صورت بگیرد نیز یک انتخاب است:عملیات transcode در لحظه و بعد از درخواست کاربر انجام شود.عملیات بعد از هر اضافه شدن ویدیو صورت گیرد.در صورتی که از تصمیم اول پیروی شود برای هر فیلم (حتی اگر برای فیلمی قبلا درخواستی آمده باشد) باید transcode انجام شود و این می‌تواند سربار زیادی برای سیستم داشته باشد. البته می‌توان بعد از هر درخواست transcode محتواهای ویدیویی را برای دیگر کاربران ذخیره کرد. اما این مورد نیز edge case‌هایی مثل فیلم‌هایی که طرفداران زیادی دارند و در لحظه به سامانه اضافه شده‌اند داشته باشد. ممکن است در لحظات ابتدایی آنقدر درخواست‌ها زیاد شود که منابع بسیاری از سیستم استفاده شود. در نهایت نتفلیکس تصمیم گرفته است با در نظر گرفتن مزایا و معایب بیان شده، transcode را بعد از اضافه شدن هر ویدیو انجام دهد.مراحل ترنسکدینگZero Configuration Service Mesh with On-Demand Cluster Discovery (مش سرویس با کشف خوشه بر اساس تقاضا)تاریخچه مختصری از IPC در نتفلیکس: نتفلیکس از اولین شرکت‌هایی بود که در سال ۲۰۰۸ به فضای ابری AWS روی آورد و تا سال ۲۰۱۰ پخش آنلاین نتفلیکس به طور کامل روی AWS اجرا می‌شد. در آن زمان، ابزارهای محیط ابری تقریباً وجود نداشتند (CNCF تا سال ۲۰۱۵ شکل نگرفته بود). از آنجایی که هیچ راه‌حل موجودی در دسترس نبود، نتفلیکس نیاز داشت خودش آن‌ها را بسازد. برای ارتباط بین فرآیندی (IPC) بین سرویس‌ها، نتفلیکس به مجموعه ویژگی‌های غنی‌ای نیاز داشت که معمولاً یک متعادل‌کننده بار عادی ارائه می‌دهد. همچنین به راه‌حلی نیاز داشت که واقعیت کار در فضای ابری را پوشش دهد: محیطی بسیار پویا که گره‌ها در آن بالا و پایین می‌آیند و سرویس‌ها باید به سرعت به تغییرات واکنش نشان دهند و در صورت خرابی، مسیر خود را تغییر دهند. برای بهبود در دسترس بودن، سیستم‌هایی طراحی شد که اجزا بتوانند به طور جداگانه از کار بیفتند و از نقاط خرابی واحد جلوگیری کنند. این اصول طراحی نتفلیکس را به سمت متعادل‌کننده بار سمت کلاینت سوق داد و قطعی برق شب کریسمس ۲۰۱۲ این تصمیم را بیشتر تثبیت کرد. در طول این سال‌های اولیه در فضای ابری، نتفلیکس Eureka را برای کشف سرویس و Ribbon (که در داخل شرکت با نام NIWS شناخته می‌شود) را برای IPC ساخت. Eureka مشکل چگونگی کشف نمونه‌ها توسط سرویس‌ها برای ارتباط را حل کرد و Ribbon منطق سمت کلاینت را برای متعادل‌سازی بار و همچنین بسیاری از ویژگی‌های تاب‌آوری دیگر فراهم کرد. Eureka و Ribbon رابط کاربری ساده اما قدرتمندی ارائه دادند.برای اینکه یک سرویس با سرویس دیگری ارتباط برقرار کند، باید دو چیز را بداند: نام سرویس مقصد و اینکه آیا ترافیک باید امن باشد یا خیر. مفاهیم انتزاعی که Eureka برای این منظور ارائه می‌دهد، IP‌های مجازی (VIP) برای ارتباط ناامن و VIP‌های امن (SVIP) برای ارتباط امن هستند. کلاینت‌های IPC با هدف قرار دادن آن VIP یا SVIP نمونه‌سازی می‌شوند و کد کلاینت Eureka با دریافت آن‌ها از سرور Eureka، ترجمه آن VIP را به مجموعه‌ای از جفت‌های IP و پورت مدیریت می‌کند. کلاینت همچنین می‌تواند به صورت اختیاری ویژگی‌های IPC مانند تلاش مجدد یا قطع مدار را فعال کند، یا به مجموعه‌ای از پیش‌فرض‌های معقول پایبند بماند. در این معماری، ارتباط سرویس به سرویس دیگر از طریق نقطه شکست واحد متعادل‌کننده بار انجام نمی‌شود. نکته منفی این است که Eureka یک نقطه شکست واحد جدید به عنوان source of truth برای میزبان‌هایی است که برای VIP‌ها ثبت شده‌اند. با این حال، اگر Eureka از کار بیفتد، سرویس‌ها می‌توانند به ارتباط با یکدیگر ادامه دهند، اگرچه اطلاعات میزبان آن‌ها با گذشت زمان و با بالا و پایین آمدن نمونه‌های VIP، قدیمی می‌شود. توانایی اجرا در یک حالت degraged اما در دسترس در طول قطعی برق، هنوز هم پیشرفت قابل توجهی نسبت به توقف کامل جریان ترافیک است.چرا مش؟ معماری فوق در طول دهه گذشته به خوبی کار کرده است، اگرچه تغییر نیازهای تجاری و تکامل استانداردهای صنعت، پیچیدگی‌های بیشتری را به اکوسیستم IPC نتفلیکس از چندین جهت اضافه کرده است.اول اینکه، نتفلیکس تعداد کلاینت‌های مختلف IPC را افزایش داده است. ترافیک IPC داخلی نتفلیکس اکنون ترکیبی از REST ساده، GraphQL و gRPC است.دوم، نتفلیکس از یک محیط فقط جاوا به یک محیط Polyglot منتقل شده است: اکنون از node.js، پایتون و انواع OSS و نرم‌افزارهای آماده نیز پشتیبانی می‌کند.سوم، نتفلیکس به افزودن قابلیت‌های بیشتر به کلاینت‌های IPC خود ادامه داده است: ویژگی‌هایی مانند محدود کردن همزمانی تطبیقی، شکستن مدار، پوشش ریسک و تزریق خطا به ابزارهای استانداردی تبدیل شده‌اند که مهندسان برای قابل اعتمادتر کردن سیستم به آن‌ها متوسل می‌شوند.در مقایسه با یک دهه پیش، اکنون از ویژگی‌های بیشتر، به زبان‌های بیشتر و در کلاینت‌های بیشتر پشتیبانی می‌شود. حفظ برابری ویژگی‌ها بین همه این پیاده‌سازی‌ها و اطمینان از اینکه همه آن‌ها به یک شکل رفتار می‌کنند، چالش برانگیز است: آنچه نتفلیکس می‌خواهد یک پیاده‌سازی واحد و آزمایش شده از همه این قابلیت‌ها است، تا بتواند تغییرات را ایجاد کرده و اشکالات را در یک مکان برطرف کند. اینجاست که سرویس مش وارد عمل می‌شود: می‌توان ویژگی‌های IPC را در یک پیاده‌سازی واحد متمرکز کرد و کلاینت‌های هر زبان را تا حد امکان ساده نگه داشت: آن‌ها فقط باید بدانند که چگونه با پروکسی محلی صحبت کنند. Envoy به عنوان پروکسی بسیار مناسب است. به نتفلیکس امکان می‌دهد تا به صورت پویا تعادل بار سمت کلاینت را طوری تنظیم کند که انگار یک متعادل‌کننده بار مرکزی است، اما همچنان از متعادل‌کننده بار به عنوان یک نقطه شکست واحد در مسیر درخواست سرویس به سرویس جلوگیری می‌کند.سوال بعدی این بود: چگونه باید این انتقال را انجام دهیم؟ نتفلیکس در مورد تعدادی محدودیت برای مهاجرت تصمیم گرفت.اول: نتفلیکس می‌خواست رابط کاربری موجود را حفظ کند.دوم: نتفلیکس می‌خواست مهاجرت را خودکار کند و آن را تا حد امکان یکپارچه کند.این دو محدودیت به این معنی بود که نتفلیکس باید از انتزاع‌های Discovery در Envoy پشتیبانی می‌کرد، تا کلاینت‌های IPC بتوانند به استفاده از آن در داخل سیستم ادامه دهند. خوشبختانه، Envoy برای این کار، انتزاع‌های آماده‌ای داشت. VIP‌ها می‌توانستند به عنوان Envoy Clusters نمایش داده شوند و پروکسی‌ها می‌توانستند آن‌ها را با استفاده از CDS از صفحه کنترل نتفلیکس دریافت کنند. میزبان‌های موجود در آن خوشه‌ها به عنوان Envoy Endpoints نمایش داده می‌شوند و می‌توانند با استفاده از Endpoint Discovery Service دریافت شوند.خیلی زود به مانعی برای مهاجرت یکپارچه برخورد شد: Envoy الزام می‌کند که کلاسترها به عنوان بخشی از پیکربندی پروکسی مشخص شوند. اگر سرویس A نیاز به ارتباط با کلاسترهای B و C داشته باشد، باید کلاسترهای B و C را به عنوان بخشی از پیکربندی پروکسی A تعریف کنید. این می‌تواند در مقیاس بزرگ چالش برانگیز باشد: هر سرویس مشخصی ممکن است با ده‌ها کلاستر ارتباط برقرار کند و آن مجموعه کلاسترها برای هر برنامه متفاوت است. علاوه بر این، Netflix همیشه در حال تغییر است: نتفلیکس دائماً ابتکارات جدیدی اضافه می‌کند و معماری خود را تغییر می‌دهد. این یعنی کلاسترهایی که یک سرویس با آن‌ها ارتباط برقرار می‌کند با گذشت زمان تغییر خواهند کرد.با توجه به مقادیر اولیه Envoy که در دسترس بود، رویکردهای مختلفی برای پر کردن پیکربندی کلاستر ارزیابی شد:از صاحبان سرویس خواسته شود کلاسترهایی را که سرویسشان باید با آن‌ها صحبت کند، تعریف کنند. این گزینه ساده به نظر می‌رسد، اما در عمل، صاحبان سرویس همیشه نمی‌دانند یا نمی‌خواهند بدانند که با چه سرویس‌هایی صحبت می‌کنند. سرویس‌ها اغلب کتابخانه‌های ارائه شده توسط تیم‌های دیگر را که با چندین سرویس دیگر در پشت صحنه صحبت می‌کنند، وارد می‌کنند یا با سایر سرویس‌های عملیاتی مانند تله‌متری و ثبت وقایع ارتباط برقرار می‌کنند. این یعنی صاحبان سرویس باید بدانند که این سرویس‌ها و کتابخانه‌های کمکی چگونه در پشت صحنه پیاده‌سازی می‌شوند و هنگام تغییر، پیکربندی را تنظیم کنند.ایجاد خودکار پیکربندی Envoy بر اساس نمودار فراخوانی یک سرویس. این روش برای سرویس‌هایی که از پیش موجود هستند ساده است، اما هنگام ایجاد یک سرویس جدید یا اضافه کردن یک خوشه بالادستی جدید برای برقراری ارتباط، چالش برانگیز است.همه خوشه‌ها را به هر برنامه ارسال کنید: این گزینه به دلیل سادگی جذاب بود، اما با محاسبات ساده به سرعت به نتفلیکس نشان داد که ارسال میلیون‌ها Endpoint به هر پروکسی امکان‌پذیر نیست.هر یک از این گزینه‌ها به اندازه کافی معایب قابل توجهی داشتند که نتفلیکس گزینه دیگری را بررسی کرد:چه می‌شد اگر می‌توانستیم اطلاعات کلاستر را در زمان اجرا، به صورت درخواستی دریافت کنیم، به جای اینکه از قبل تعریف کنیم؟در آن زمان، تلاش برای ایجاد شبکه سرویس هنوز در حال راه‌اندازی بود و تنها چند مهندس روی آن کار می‌کردند. نتفلیکس با Kinvolk مذاکره کرد تا ببیند آیا می‌توانند با نتفلیکس و جامعه Envoy در پیاده‌سازی این ویژگی همکاری کنند. نتیجه این همکاری، کشف خوشه بر اساس درخواست (ODCDS) بود. با این ویژگی، پروکسی‌ها اکنون می‌توانند اطلاعات خوشه را در اولین تلاش برای اتصال به آن جستجو کنند، به جای اینکه همه خوشه‌ها را در کانفیگ از پیش تعریف کنند.با وجود تغییرات در صفحه کنترل و صفحه داده، flow به شرح زیر است:درخواست کلاینت به Envoy می‌رسد.خوشه هدف را بر اساس هدر Host یا authority استخراج کنید (هدر استفاده شده در اینجا قابل تنظیم است، اما این رویکرد نتفلیکس است).اگر آن خوشه از قبل شناخته شده است، به مرحله ۷ بروید.خوشه وجود ندارد، بنابراین درخواست در حال انجام را متوقف می‌کنیم.یک درخواست به اندپوینت سرویس کشف خوشه (CDS) در صفحه کنترل ارسال کنید.صفحه کنترل یک پاسخ CDS سفارشی بر اساس پیکربندی سرویس و اطلاعات ثبت Eureka تولید می‌کند.Envoy خوشه (CDS) را دریافت می‌کند که باعث می‌شود اندپوینت از طریق سرویس کشف (EDS) استخراج شوند.اندپوینت ها برای خوشه بر اساس اطلاعات وضعیت Eureka برای آن VIP یا SVIP بازگردانده می‌شوند.درخواست کلاینت متوقف می‌شود.Envoy درخواست را به صورت عادی مدیریت می‌کند: با استفاده از یک الگوریتم متعادل‌سازی بار، یک اندپوینت را انتخاب می‌کند و درخواست را صادر می‌کند.این جریان در عرض چند میلی‌ثانیه تکمیل می‌شود، اما فقط در اولین درخواست به کلاستر. پس از آن، Envoy طوری رفتار می‌کند که انگار کلاستر در کانفیگ تعریف شده است. نکته مهم این است که این سیستم به نتفلیکس اجازه می‌دهد تا بدون نیاز به پیکربندی، سرویس‌ها را به طور یکپارچه به سرویس مش منتقل کند و یکی از محدودیت‌های اصلی خود را رفع کند. نتفلیکس همچنان از Eureka به عنوان source of truth برای VIP‌ها و وضعیت نمونه‌ها استفاده می‌کند که به نتفلیکس امکان می‌دهد در حین مهاجرت، از یک محیط ناهمگن شامل برخی از برنامه‌ها روی مش و برخی دیگر پشتیبانی نکند. یک مزیت دیگر نیز وجود دارد: می‌توان با fetch کردن داده‌ها برای کلاسترهایی که واقعاً با آن‌ها در ارتباط هستیم، میزان استفاده از حافظه Envoy را پایین نگه داشت.البته یک نکته منفی در fetch کردن این داده‌ها بر اساس تقاضا وجود دارد. آن هم این است که این کار باعث افزایش تأخیر در اولین درخواست به یک خوشه می‌شود. نتفلیکس با مواردی مواجه شده است که سرویس‌ها در اولین ریکوئست به دسترسی با تأخیر بسیار کم نیاز دارند و اضافه کردن چند میلی‌ثانیه اضافی، سربار زیادی را اضافه می‌کند. برای این موارد استفاده، سرویس‌ها باید خوشه‌هایی را که با آن‌ها ارتباط برقرار می‌کنند از قبل تعریف کنند. در مجموع، نتفلیکس معتقد است که کاهش پیچیدگی در سیستم، این نکته منفی را برای مجموعه کوچکی از سرویس‌ها توجیه می‌کند.مدیریت حجم ترافیک بالا در نتفلیکسELB (Elastic Load Balancer) توزیع‌کننده ترافیک: ELB دارای دو طرح متعادل‌کننده بار است. اولین ردیف برای تعادل بار پایه مبتنی بر DNS. تعادل بار در ابتدا در مناطق، سپس نمونه‌ها. ردیف دوم سرویس ELB آرایه‌ای از نمونه‌های متعادل‌کننده بار است که توازن بار چرخشی را نسبت به نمونه‌های خود که پشت آن در همان منطقه هستند انجام می‌دهد.در نتفلیکس، ترافیک عظیمی جریان دارد. اینجاست که نقش ELB یا همان متعادل‌کننده بار الاستیک مشخص می‌شود. نتفلیکس از سرویس load balancer الاستیک آمازون (ELB) برای هدایت ترافیک به سرویس‌های front-end استفاده می‌کند. ELB به طور خودکار ترافیک ورودی برنامه را در چندین هدف، در یک یا چند منطقه در دسترس توزیع می‌کند. بر سلامت نقاط هدف ثبت شده خود نظارت می‌کند و ترافیک را فقط به نقاط هدف سالم هدایت می‌کند و در واقع در Netflix مسئول مسیریابی ترافیک است.توزیع کننده بارELB یک تعادل بار دو لایه را انجام می‌دهد که در آن بار ابتدا بر روی مناطق در دسترس و سپس نمونه‌ها (سرورها) متعادل می‌شود. ELB‌ها به گونه‌ای تنظیم شده‌اند که بار ابتدا در zone‌ها و سپس instance‌ها متعادل شود:Tier اول: تصور کنید نتفلیکس به بخش‌های متعددی تقسیم شده است. ELB ابتدا ترافیک ورودی را در میان این بخش‌ها یا همان Zones به صورت چرخشی و منصفانه توزیع می‌کند. به این ترتیب، هیچ بخشی بیش از حد شلوغ نمی‌شود و کاربران در هر گوشه‌ای از این قلمرو به سرعت به محتوا دسترسی پیدا می‌کنند. اولین لایه شامل load balancer با الگوریتم Round Robin پایه مبتنی بر DNS است. هنگامی که درخواست در اولین بار متعادل‌کننده فرود می‌آید، در یکی از مناطق (با استفاده از الگوریتم دور چرخشی) که ELB شما برای استفاده از آن پیکربندی شده است (z1 to z3)، متعادل می‌شود.Tier دوم: سطح یا لایه دوم آرایه‌ای از نمونه‌های متعادل‌کننده بار است و باز هم الگوریتم Round Robin را برای توزیع درخواست در بین نمونه‌هایی که پشت آن در همان منطقه یکسان هستند، انجام می‌دهد. هر بخش (Zone) خود به تعدادی سرور تقسیم می‌شود که مستقیماً به درخواست‌های کاربران پاسخ می‌دهند. ELB در این مرحله نیز وارد عمل می‌شود و درخواست‌های ورودی را به صورت چرخشی میان این سرورها توزیع می‌کند. به این ترتیب، بار بیش از اندازه روی هیچ سروری توزیع نمی‌شود و کاربران تجربه‌ای روان و بدون وقفه دارند.سرویس اختصاصی ZUULفیلترهای ZUUL (API gateway) برای مدیریت پروتکل‌های شبکه، سرورهای وب، مدیریت اتصال و کار پروکسی استفاده می‌شوند. این سرویس شامل سه فیلتر جداگانه، مانند فیلترهای ورودی برای احراز هویت، مسیریابی یا تنظیم درخواست‌ها؛ فیلترهای اندپوینت برای درخواست‌های مربوط به سرویس‌های backend؛ و فیلتر خروجی برای متریک یا اضافه کردن/حذف هدرهای سفارشی است. کاربرد اصلی آن هدایت ترافیک به خوشه‌های مختلف است. زول یک سرویس Gateway است که مسیریابی پویا، مانیتورینگ، انعطاف‌پذیری و امنیت را برای ترافیک سرویس‌های نتفلیکس فراهم می‌کند. این سرویس امکان مسیریابی آسان بر اساس پارامترهای کوئری، URL و مسیر را می‌دهد.برای درک بهتر نحوه کار زول، اجزای مختلف آن را بررسی می‌کنیم:نحوه عملکرد زولسرور Netty مسئولیت رسیدگی به پروتکل شبکه، وب سرور، مدیریت اتصال و کار پروکسی را بر عهده می‌گیرد. هنگامی که درخواست به سرور Netty برخورد می‌کند، درخواست را به فیلتر ورودی پروکسی می‌کند.فیلتر ورودی مسئول احراز هویت و مسیریابی درخواست است و سپس درخواست را به فیلتر اندپوینت ارسال می‌کند.فیلتر اندپوینت برای بازگرداندن یک پاسخ ایستا یا ارسال درخواست به سرویس Backend استفاده می‌شود.هنگامی که پاسخ را از سرویس Backend دریافت کرد، درخواست را به فیلتر خروجی ارسال می‌کند.یک فیلتر خروجی برای فشرده‌سازی محتوا، محاسبه معیارها یا افزودن/حذف هدرها استفاده می‌شود.پس از آن، پاسخ به سرور Netty ارسال می‌شود و سپس توسط کلاینت دریافت می‌شود.ویژگی‌های ZUUL:پشتیبانی از http2TLS متقابلretry logicداشتن همزمانی یا concurrencyمزایای ZUUL:مسیریابی پویا: ابتدا درخواست را تجزیه و تحلیل می‌کند و می‌تواند مسیر را بر اساس کلمات کلیدی، آدرس اینترنتی یا مسیر مشخص شده انتخاب کند. به این ترتیب، کاربران به سرعت به مقصد خود (فیلم مورد نظر) می‌رسند.نظارت و پایداری: زول همواره بر عملکرد سیستم نظارت می‌کند. او سلامت سرورها را بررسی می‌کند و در صورت لزوم، ترافیک را به مسیرهای جایگزین هدایت می‌کند تا هیچ‌گاه وقفه‌ای در تماشای فیلم‌ها رخ ندهد. به این ترتیب، پایداری و دسترسی مداوم برای کاربران تضمین می‌شود.امنیت و حفاظت: زول امنیت محتوا را بر عهده دارد. او با فیلتر کردن درخواست‌های غیرمجاز و مشکوک، از نفوذها و حملات سایبری جلوگیری می‌کند. به این ترتیب، اطلاعات کاربران و محتوای ارزشمند نتفلیکس در امنیت کامل قرار می‌گیرند.انعطاف و کارایی: زول قابلیت‌های ویژه‌ای نیز در اختیار توسعه‌دهندگان قرار می‌دهد. آن‌ها می‌توانند با استفاده از زول، ترافیک ورودی را تقسیم‌بندی کنند و عملکرد سرورهای جدید را آزمایش نمایند. اگر تیم‌ها نیاز به آزمایش تغییراتی داشته باشند که به چندین درخواست متوالی در ساخت جدیدشان نیاز دارند، تست‌های canary را اجرا می‌کنند که بدون ایجاد اختلال در سیستم همان کاربران را برای مدت کوتاهی به ساخت جدیدشان هدایت می‌کند. می‌توان سرویس‌های جدید را تست کرد. وقتی سرویسی را ارتقا می‌دهید و می‌خواهید نحوه رفتار آن با درخواست‌های API بلادرنگ بررسی کنید، در آن صورت، می‌توانید سرویس خاص را روی یک سرور مستقر کنید و می‌توانید بخشی از ترافیک را به سرویس جدید جهت بررسی به صورت real time هدایت کنید.سرویس Hystrixسپر دفاعی سیستم‌های توزیع‌شده: Hystrix یک circuit breaker است. در یک سیستم پیچیده توزیع شده، ممکن است یک سرور به پاسخ سرور دیگری متکی باشد. وابستگی‌های بین سرورها می‌تواند منجر به تأخیر شود و اگر یکی از سرورها در نقطه‌ای از کار بیفتد، ممکن است کل سیستم از کار بیفتد. کتابخانه Hystrix با افزودن منطقlatency tolerance و fault tolerance، تعاملات بین سرویس‌های توزیع شده را کنترل می‌کند. Hystrix این کار را با ایزوله کردن نقاط دسترسی بین سرویس‌ها، سیستم‌های remote و کتابخانه‌های third party انجام می‌دهد. مثلاً اگر میکروسرویسی که لیست فیلم‌های مناسب را به کاربر ارائه می‌کند، fail شود، ترافیک به میکروسرویسی که ۱۰ فیلم برتر را برمی‌گرداند تغییر مسیر می‌دهد و در نتیجه failure کنترل می‌شود.مزایای Hystrix:Real-time monitoringجلوگیری از cascading failure: دیگر لازم نیست اثر دومینویی بر سیستم حاکم باشد. هیستریکس به سرعت خرابی‌ها را شناسایی و کنترل می‌کند و از گسترش آن‌ها جلوگیری می‌کند.کنترل تأخیرها: تأخیر و کندی از بین خواهد رفت. هیستریکس تأخیر ناشی از وابستگی‌های خارجی را مهار می‌کند و تعاملات روان و responsive را تضمین می‌کند.بازیابی سریع: در صورت خرابی، هیستریکس یک بازیابی سریع را سازماندهی می‌کند و به سیستم ما اجازه می‌دهد با اختلال کم به حالت عادی بازگردد.ایجاد قابلیت downgrade سرویس: هنگامی که با چالش‌های غیرقابل عبور مواجه می‌شویم، هیستریکس با فعال کردن مکانیزم‌های پشتیبان‌گیری به شیوه‌ای مناسب، حتی در مواجهه با مشکلات، تجربه‌ی پیوسته ای را برای کاربر تضمین می‌کند.هوشیاری بالا: هیستریکس به عنوان نگهبان هوشیار عمل می‌کند و نظارت تقریباً بی‌درنگ، هشدارهای تشریحی و کنترل عملیاتی عمیق را ارائه می‌دهد، بنابراین می‌توان از تهدیدهای بالقوه پیشگیری کرد.کش کردن درخواست‌ها به صورت concurrency aware: هیستریکس از ذخیره‌سازی هوشمندانه درخواست‌ها استفاده می‌کند و تعاملات گذشته را به خاطر می‌سپارد تا عملکرد را بهینه کند.دسته‌بندی خودکار برای افزایش کارایی: هیستریکس درخواست‌های مشابه را با هم گروه می‌کند و از قدرت batch processing برای ساده‌سازی عملیات و افزایش کارایی استفاده می‌کند.پلتفرم TitusTitus یک پلتفرم مدیریت container است که اجرای container مقیاس‌پذیر و قابل اعتماد و ادغام cloud-native با Amazon AWS را فراهم می‌کند. Titus توسط نتفلیکس ساخته شده است و برای تقویت استریم، recommendation و سیستم‌های محتوا استفاده می‌شود. Titus هزاران نمونه AWS EC2 را مدیریت می‌کند و روزانه صدها هزار container را برای workload‌های دسته‌ای و سرویس راه‌اندازی می‌کند. Titus می‌تواند تصاویر بسته‌بندی شده (images packaged) را به عنوان container‌های Docker اجرا کند و در عین حال امنیت و قابلیت اطمینان (reliability) بیشتری را در مورد اجرای container فراهم کند. می‌توان Titus را به عنوان نسخه نتفلیکس Kubernetes در نظر گرفت.استفاده از Chaos MonkeyChaos Monkey اسکریپتی است که به طور مداوم در تمام محیط‌های Netflix اجرا می‌شود و با خاموش کردن تصادفی نمونه‌های سرور باعث بی‌نظمی و هرج و مرج (chaos) می‌شود. از این رو، در حین نوشتن کد، توسعه‌دهندگان نتفلیکس به طور مداوم در محیطی از سرویس‌های غیرقابل اعتماد و قطعی‌های غیرمنتظره فعالیت می‌کنند. در واقع Chaos Monkey نمونه‌ها را به طور تصادفی متوقف (terminate) می‌کند تا اطمینان حاصل کند که توسعه‌دهندگان، سرویس‌ها را به گونه‌ای پیاده‌سازی می‌کنند که در برابر خرابی‌ها انعطاف‌پذیر باشد.معماری مایکروسرویس‌های نتفلیکسنتفلیکس یکی از اولین شرکت‌هایی بود که معماری میکروسرویس‌ها را پذیرفت و از معماری monolithic به میکروسرویس‌ها در بستر cloud مهاجرت کرد. در حقیقت، این شرکت مفاهیم میکروسرویس‌ها را، قبل از این که حتی به طور آکادمیک معرفی شده باشند، اجرا کرد. بر این اساس می‌توانیم نتفلیکس را به عنوان یک پیشگام در زمینه مهاجرت به میکروسرویس‌ها مطرح کنیم.در حدود ۲۰ سال قبل، نتفلیکس مانند کلوپی بود که با دادن حق اشتراک، فیلم‌ها را در قالب DVD عرضه می‌کرد؛ اما در حال حاضر یکی از بزرگ‌ترین سیستم‌های پخش زنده در بستر اینترنت است. همان طور که مشخص است، برای چنین نیازمندی متفاوت و وسیعی که در طول زمان برای این شرکت ایجاد شد، معماری گذشته دیگر پاسخگو نبود و لازم بود تصمیمات متفاوتی در خصوص ساختار معماری آن گرفته شود. در ابتدا، معماری نتفلیکس یکپارچه بود و شامل یک برنامه جاوا بود که به طور مستقیم با یک پایگاه داده اوراکل متصل شده بود. این ساختار، که در دهه ۹۰ و اوایل ۲۰۰۰ رایج بود، به زودی محدودیت‌های خود را نشان داد. کد یکپارچه تشخیص و رفع مشکلات را به یک فرایند طولانی تبدیل کرد و طراحی single point of failure پایگاه داده منجر به اختلالات قابل توجهی در سرویس شد. عدم انعطاف‌پذیری در اجرای تغییرات، به دلیل ارتباط تنگاتنگ بین برنامه و پایگاه داده، مشکلات را بیشتر کرد.مهاجرت نتفلیکس به میکروسرویس‌ها بیشتر از دو سال به طول انجامید. چالش‌های زیادی در این بازه رخ داد، از جمله این که نتفلیکس می‌بایست هم زیرساخت‌های ابری خود را نگهداری می‌کرد تا از صحت عملکرد آن مطمئن شود، هم ساختار سنتی خود را حفظ می‌کرد، تا کاربران به مشکل نخورند؛ این مسئله هزینه زیادی را به این شرکت وارد کرد. به علاوه انتقال حجم زیادی از داده به سرورهای جدید، مشکلاتی از قبیل لود زیاد بار و کارآیی پایین را در بر داشت.برای رفع این مشکلات، نتفلیکس به سمت معماری میکروسرویس‌ها حرکت کرد و برنامه یکپارچه خود را به مجموعه‌ای از سرویس‌های کوچک و مستقل تقسیم کرد. هر میکروسرویس، مانند یک عضو در بدن انسان، عملکرد خاصی را در اکوسیستم گسترده‌تر سرویس نتفلیکس انجام می‌دهد. میکروسرویس‌ها در نتفلیکس به عنوان سرویس‌های کوچک و مستقل که از طریق مکانیزم‌های سبک مانند API منابع HTTP ارتباط برقرار می‌کنند، تعریف شده‌اند. این پارادایم طراحی باعث ترویج جداسازی دغدغه‌ها، ماژولاریتی، مقیاس‌پذیری و تقسیم‌بندی بار کاری می‌شود. نتفلیکس حدود ۷۰۰ میکروسرویس دارد.اجزای کلیدی معماری میکروسرویس نتفلیکس شامل:لایه پروکسی و API gateway: مدیریت درخواست‌های ورودی و مسیریابی آن‌ها به سرویس‌های مناسب.لایه‌های قدیمی و مدرن: تسهیل انتقال هموار از سیستم‌های قدیمی به سرویس‌های جدید.سرویس‌های میانی و پلتفرم: ارائه قابلیت‌های اساسی برای پشتیبانی از میکروسرویس‌های مختلف. به عنوان مثال، سرویس ذخیره‌سازی ویدیو از سرویسی که وظیفه رمزگذاری ویدیوها را بر عهده دارد یا سرویسی که مسئول تبدیل فرمت آن‌ها است، جدا می‌شود.قابلیت اطمینان (Reliability) در میکروسرویس‌ها: چطور می‌توان اطمینان داشت که چنین سیستمی همیشه قابل اعتماد و در دسترس است؟نتفلیکس برای افزایش قابلیت اطمینان (reliability) میکروسرویس‌ها:از ابزارهایی مانند Hystrix، Titus و Chaos Monkey استفاده می‌کند.میکروسرویس‌های حیاتی و مهم را جدا می‌کند (Critical Microservices).سرویس‌ها به صورت stateless طراحی می‌شود.سبک معماری نتفلیکس به صورت مجموعه‌ای از سرویس‌ها ساخته شده است. تمام API‌‌های مورد نیاز برای برنامه‌ها و وب‌اپ‌ها را تامین می‌کند. زمانی که درخواستی در endpoint دریافت می‌شود، این end point دیگر میکروسرویس‌ها را برای داده‌های مورد نیاز فرا می‌خواند و این میکروسرویس‌ها نیز ممکن است داده‌ها را از میکروسرویس‌های دیگری درخواست کنند. پس از آن، پاسخ کامل برای درخواست API به end point فرستاده می‌شود.اکوسیستم میکروسرویس‌های نتفلیکس بر اساس کارایی به دو دسته تقسیم شده است.سرویس‌های حیاتی: آن‌هایی هستند که کاربرها به صورت مکرر با آن‌ها ارتباط دارند. این سرویس‌ها از عمد به شکل مستقل از بقیه نگه داشته می‌شوند. این استقلال، تضمین می‌کند که سرویس‌های پایه متاثر از failure‌ها واقع نمی‌شود و کاربران می‌توانند به استفاده از آن‌ها ادامه دهند. میکروسرویس‌های حیاتی شامل قابلیت‌های اساسی مانند جستجوی ویدئو، پیمایش فیلم ‎‌‌ها و پخش ویدئو هستند. چنین روشی منجر به دسترسی‌پذیری (availability) بالا می‌شود و در بدترین سناریو کاربران می‌توانند کارهای ابتدایی را انجام دهند چرا که بخش‌های حیاتی در دسترس هستند.سرویس‌های stateless: این سرویس‌ها، مسئول serve کردن درخواست‌های API به کاربران هستند و طوری طراحی شده‌اند که با instance‌های دیگر، حتی در صورت بروز failure، بدون مشکل کار کنند. این سرویس‌ها برای بالا نگه داشتن availability نیاز هستند.نتفلیکس تعدادی از سرویس‌ها را به عنوان سرویس‌های حیاتی جدا می‌کند و وابستگی آن‌ها به سایر سرویس‌ها را به حداقل می‌رساند. طراحی سرویس‌ها به گونه‌ای است که اگر یکی از endpoint‌ها دچار خطا شد یا درخواست به موقع سرویس‌دهی نشد، بتوان به سرور دیگری سوئیچ کرد و کار را انجام داد. در واقع به جای تکیه بر یک سرور خاص و حفظ وضعیت (state) در آن سرور، می‌توان درخواست را به سرور (service instance) دیگری هدایت کرد. اگر سروری از کار بیفتد با سرور دیگری جایگزین خواهد شد. یعنی یک سرور خاص نیست که برای ما اهمیت دارد، بلکه کارکردی که دارد باعث می‌شود به آن اهمیت دهیم. این رویکرد امکان می‌دهد که در صورت بروز خطا در یک سرور، به راحتی و بدون اختلال در تجربه کاربری، درخواست‌ها را به سرور دیگری منتقل کنند.همانطور که گفته شد، نتفلیکس برای قابل اعتماد کردن معماری میکروسرویس خود، چندین رویکرد و ابزار پیشرفته را به کار گرفته است. این اقدامات شامل موارد زیر است:استفاده از Hystrix برای مدیریت شکست‌ها: همانطور که دیدیم، Hystrix یک کتابخانه circuit breaker ایجاد شده توسط نتفلیکس است که به میکروسرویس‌ها اجازه می‌دهد تا در مواجهه با خطاها، به صورت مقاوم عمل کنند. این ابزار به سرویس‌ها کمک می‌کند تا در زمان خرابی‌ها، ترافیک را به روش‌های پیش‌فرض یا فال‌بک هدایت کنند.مقیاس‌پذیری ابری و استفاده از AWS: با استفاده از زیرساخت ابری آمازون وب سرویس‌ها (AWS)، نتفلیکس از مزایای مقیاس‌پذیری، انعطاف‌پذیری و قابلیت اطمینان بالا بهره‌مند می‌شود. این زیرساخت ابری به نتفلیکس امکان می‌دهد تا منابع خود را بر اساس نیاز فوری افزایش یا کاهش دهد.مانیتورینگ و لاگ‌گیری پیشرفته: نتفلیکس از ابزارهای مانیتورینگ و لاگ‌گیری پیشرفته استفاده می‌کند تا بتواند عملکرد سیستم و میکروسرویس‌های خود را به طور مداوم زیر نظر داشته باشد. این امکان به تیم‌های مهندسی اجازه می‌دهد تا به سرعت مشکلات را شناسایی و رفع کنند.Chaos Engineering: نتفلیکس پیشرو در استفاده از Chaos Engineering است، یک رویکرد آزمایشی که به طور عمدی شرایط خرابی را در محیط تولید ایجاد می‌کند تا اطمینان حاصل شود که سیستم قادر به تحمل خرابی‌ها و بازیابی از آن‌ها است.با ترکیب این رویکردها و ابزارها، نتفلیکس توانسته است معماری میکروسرویس خود را به یکی از قابل اعتمادترین و مقیاس‌پذیرترین سیستم‌ها در صنعت پخش زنده تبدیل کند.کش کردن با EV Cacheدر اکثر برنامه‌ها، بخشی از داده‌ها هستند که مکررا استفاده می‌شود. برای پاسخ سریع‌تر، این داده‌ها را می‌توان در بسیاری از endpoint‌ها کش کرد و می‌توان آن‌ها را به جای سرور اصلی از حافظه کش دریافت کرد. این باعث کاهش بار سرور اصلی می‌شود، اما مشکل این است که اگر گره پایین بیاید، RAM هم پایین می‌آید و این می‌تواند به عملکرد برنامه ضربه بزند. برای حل این مشکل Netflix لایه کش سفارشی خود را به نام کش EV ساخته است. EVCache یک راه‌حل ذخیره‌سازی cache توزیع شده مبتنی بر Memcached و Spymemcached است که به خوبی با Netflix OSS و زیرساخت AWS EC2 یکپارچه شده است. EVCache در واقع یک پوشش (wrapper) در اطراف Memcached است. نتفلیکس خوشه‌های زیادی را در تعدادی از نمونه‌های AWS EC2 مستقر کرده‌ است. به طور سنتی ذخیره‌سازی cache روی RAM انجام می‌شود، اما ذخیره کردن حجم زیادی از داده‌ها در RAM هزینه زیادی دارد. از این رو نتفلیکس تصمیم گرفت تا برخی از داده‌های cache را به SSD منتقل کند. EVcache برای ذخیره‌سازی توزیع‌شده استفاده می‌شود. وقتی گره از کار می‌افتد، تمام حافظه پنهان همراه با آن از دست می‌رود و تا زمانی که تمام داده‌ها بازیابی نشوند، عملکرد کاهش می‌یابد. اما نتفلیکس با EVcache با چندین کپی از حافظه در گره‌ها، تقسیم‌بندی می‌شود. حافظه پنهان از نزدیکترین حافظه پنهان یا گره خوانده می‌شود. اگر گره در دسترس نباشد، از سایر گره‌های موجود دریافت می‌شود.انواع EV Cache:سرویس EVCache ساده: این نوع EVCache شامل یک خوشه Memcached با چندین گره است که در یک منطقه (Zone) در دسترس هستند. این نوع EVCache برای برنامه‌هایی که به پایداری بالا نیاز ندارند مناسب هستند.سرویس استقرار Multi-Zone: این نوع EVCache شامل چندین خوشه Memcached در چندین منطقه (Zone) است. داده‌ها در تمام خوشه‌ها به طور همزمان ذخیره می‌شوند و در صورت خرابی یک منطقه، داده‌ها در مناطق دیگر همچنان در دسترس خواهند بود. این نوع EVCache برای برنامه‌هایی که به پایداری بالا نیاز دارند مناسب است. طبیعتاً هزینه Multi-Zone EVCache Deployment بیشتر از EVCache ساده است.مراحل استفاده از EVCache:برنامه EVCache یک درخواست برای خواندن یا نوشتن داده ارسال می‌کند.سرویس EVCache درخواست را به خوشه Memcached مناسب هدایت می‌کند.اگر درخواست برای خواندن باشد، گره Memcached داده‌ها را به EVCache برمی‌گرداند.سرویس EVCache داده‌ها را به برنامه برمی‌گرداند.اگر درخواست برای نوشتن باشد، EVCache، داده‌ها را به تمام خوشه‌های Memcached در تمام مناطق ارسال می‌کند.گره‌های Memcached داده‌ها را ذخیره می‌کنند.هر cluster دارای تعداد زیادی گره‌ی Memcached است و آن‌ها نیز cache client‌هایی دارند. داده‌ها در سراسر cluster در یک منطقه (zone) به اشتراک گذاشته می‌شود و چندین نسخه کپی از cache در sharded node ذخیره می‌شود. در هر write برای client، تمام گره‌ها در همه cluster‌ها به‌روزرسانی می‌شوند، اما read از حافظه cache، فقط به نزدیک‌ترین cluster و گره‌های آن (نه همه cluster‌ها و گره‌ها) ارسال می‌شود. در صورتی که یک گره در دسترس نباشد، از گره دیگری که در دسترس است می‌خواند. این رویکرد کارایی (performance)، دسترس‌پذیری (availability) و قابلیت اطمینان (reliability) را افزایش می‌دهد. منظور از performance در اینجا سرعت است. با ذخیره‌سازی داده‌ها در حافظه کش، زمان پاسخگویی به درخواست‌ها به طور قابل توجهی کاهش می‌یابد. و منظور از reliablity هم مقاومت سیستم در برابر خرابی‌ها و ناپایداری‌هاست.پایگاه‌داده‌هانتفلیکس، برای ذخیره‌سازی داده‌های متنوع خود، از دو پایگاه داده‌ مجزا و قدرتمند بهره می‌گیرد: MySQL و Cassandra. هر یک از این پایگاه‌ها، ویژگی‌های منحصر به فردی دارند و برای مقاصد خاصی به کار گرفته می‌شوند.سرویس MySQL: صورتحساب و اطلاعات کاربر از پایگاه داده mysql استفاده می‌کند. دلیل استفاده از پایگاه داده mysql ایمن نگه داشتن داده‌ها است.برای حفاظت از اطلاعات حیاتی مانند جزئیات صورت‌حساب‌ها، پروفایل کاربران و تراکنش‌های مالی، نتفلیکس به پایگاه داده‌ای با قابلیت انطباق ACID نیاز دارد. در این میان، MySQL با داشتن ساختاری مستحکم و امکان راه‌اندازی چندین سرور اصلی همزمان (Master-Master Setup)، گزینه‌ای ایده‌آل به شمار می‌رود. پایگاه داده MySQL نتفلیکس روی instance‌های Amazon EC2 با موتور InnoDB ذخیره‌سازی مستقر شده است.یکی از ویژگی‌های بارز این کانفیگ، بهره‌گیری از «پروتکل تکثیر همزمان» است. بدین معنی که هر گونه نوشته‌ای که روی سرور اصلی اولیه (master) انجام می‌شود، به‌طور همزمان بر روی سرور اصلی دیگر نیز تکثیر می‌گردد. تأیید نهایی تنها زمانی صادر می‌شود که صحت نوشتن اطلاعات در هر دو سرور اصلی تأیید شده باشد. این امر، سطح بالایی از دسترسی‌پذیری داده‌ها را تضمین می‌کند.نتفلیکس برای هر گره، یک Read Replica نیز راه‌اندازی کرده است. این کار، دسترس‌پذیری و مقیاس‌پذیری بالایی را به ارمغان می‌آورد. به این ترتیب، تمامی کوئری های خواندنی به سمت کپی‌های خواندنی هدایت می‌شوند و تنها کوئری های نوشتنی به سمت سرورهای اصلی هدایت می‌شوند. در صورت بروز خطا در سرور اصلی اولیه MySQL، سرور اصلی ثانویه به سرعت نقش اصلی را بر عهده می‌گیرد و ورودی DNS متعلق به پایگاه داده به این سرور جدید تغییر مسیر داده می‌شود. بدین ترتیب، کوئری های نوشتنی نیز به سمت این سرور اصلی جدید هدایت خواهند شد.شماتیک کپی های دیتابیسسرویس Cassandra: Cassandra برای فایل‌های مدیا و مشاهده رکورد تاریخ استفاده می‌شود. برخی از داده‌ها به صورت غیر فشرده ذخیره می‌شوند، در حالی که بقیه به صورت فشرده ذخیره می‌شوند.سرویس Cassandra یک پایگاه داده‌ NoSQL متن‌باز (open-source) است که توانایی مدیریت حجم عظیمی از داده‌ها را دارد و به خوبی از پسِ عملیات سنگین خواندن و نوشتن برمی‌آید. با افزایش روزافزون کاربران نتفلیکس، حجم داده‌های مربوط به سابقه تماشای هر عضو نیز به طرز چشمگیری افزایش یافت. این حجم عظیم داده، مدیریت آن‌ها را به چالشی جدی تبدیل کرده است. نتفلیکس از Cassandra برای مقیاس پذیری (scalability)، عدم وجود نقاط شکست واحد (single points of failure) و استقرارهای بین منطقه‌ای (cross-regional deployment) استفاده می‌کند. نتفلیکس انواع داده‌ها را در نمونه‌های Cassandra DB خود ذخیره می‌کند. به عنوان مثال، تاریخچه مشاهده هر کاربر در Cassandra ذخیره می‌شود. در ابتدا تاریخچه مشاهده در یک سطر (row) ذخیره می‌شد، اما با افزایش کاربران نتفلیکس، حجم داده‌ها نیز افزایش یافت و منجر به هزینه عملیاتی بیشتر و کارایی کمتر اپلیکیشن شد.نتفلیکس با در نظر گرفتن دو هدف اصلی، اقدام به مقیاس‌گذاری ذخیره‌سازی داده‌های سابقه تماشا نموده است:کاهش اشغال فضای ذخیره‌سازی (Storage Footprint کوچک‌تر).ثبات performance خواندن/نوشتن با افزایش داده‌های تماشای هر عضو (نسبت نوشتن به خواندن داده‌های سابقه تماشا در Cassandra حدود ۹:۱ است).تعامل دیتابیس Cassandraویژگی‌های Cassandra در نتفلیکس:مدل داده‌ای کاملاً Denormalizedبیش از ۵۰ خوشه Cassandraبیش از ۵۰۰ گرهبیش از ۳۰ ترابایت بک آپ گیری روزانهبزرگ‌ترین خوشه: ۷۲ گرهیک خوشه: بیش از ۲۵۰ هزار نوشتن در ثانیهوقتی برای حل این مشکل، نتفلیکس اقدام به فشرده‌سازی ردیف‌های قدیمی نمود، داده‌ها به دو بخش تقسیم شدند:تاریخچه تماشای زنده (Live Viewing History - LiveVH): این بخش شامل تعداد محدودی از داده‌های اخیر سابقه تماشا با آپدیت های مکرر است. این داده‌ها که به وفور برای وظایف ETL مورد استفاده قرار می‌گیرند، به صورت فشرده‌نشده ذخیره می‌شوند.سابقه تماشای فشرده‌شده (Compressed Viewing History - CompressedVH): حجم عظیمی از سابقه‌های تماشای قدیمی در این بخش، داده‌ها در یک ستون واحد برای هر کلید ردیف (Row Key) و به صورت فشرده ذخیره می‌شوند تا فضای ذخیره‌سازی اشغال‌شده به حداقل برسد.پردازش داده‌ها در نتفلیکسنتفلیکس از Kafka و Apache Chukwa برای جمع‌آوری و پردازش داده‌ها استفاده می‌کند. این داده‌ها شامل گزارش خطا، فعالیت‌های رابط کاربری، رویدادهای عملکرد، فعالیت‌های تماشای ویدئو و رویدادهای عیب‌یابی و تشخیص هستند. آن‌ها روزانه چیزی حدود ۵۰۰ میلیارد رویداد داده، معادل ۱.۳ پتابایت و در ساعات اوج ۸ میلیون رویداد به ازای ۲۴ گیگابایت در ثانیه را پردازش می‌کنند.این رویدادها شامل طیف گسترده‌ای از اطلاعات هستند، از جمله:گزارش‌های خطافعالیت‌های رابط کاربریرویدادهای عملکردفعالیت‌های تماشای ویدیورویدادهای (event) عیب‌یابی و تشخیصبه کارگیری Apache ChukwaApache Chukwa یک سیستم جمع‌آوری داده open-source برای نظارت بر سیستم‌های توزیع شده بزرگ است. Apache Chukwa بر روی سیستم فایل توزیع شده Hadoop (همان HDFS) و چارچوب Mapreduce ساخته شده است و مقیاس‌پذیری و استحکام Hadoop را به ارث برده است. Apache Chukwa همچنین دارای مجموعه‌ای منعطف و قدرتمند از ابزارها برای نمایش (displaying)، نظارت (monitoring) و تجزیه ‌و‌تحلیل (analyzing) داده‌های جمع‌آوری شده است. این ابزار، لاگ‌ها و رخدادها را از قسمت‌های مختلف سیستم جمع‌آوری و آنالیز می‌کند. Apache Chukwa رویدادها را از بخش‌های مختلف سیستم جمع‌آوری می‌کند و آن‌ها را در فرمت Hadoop file sequence (S3) می‌نویسد و سپس تیم Big Data آن فایل‌های S3 را در Hive در فرمت داده Parquet پردازش می‌کند. این فرآیند، پردازش دسته‌ای نام دارد که عموماً به صورت ساعتی یا روزانه انجام می‌شود و کل مجموعه داده‌ها را مورد بررسی قرار می‌دهد.نقش Apache KafkaApache Kafka یک پلتفرم استریم رویداد توزیع ‌شده open-source است که توسط هزاران شرکت برای pipeline‌های داده با کارایی بالا، تجزیه‌وتحلیل جریان داده‌ها، یکپارچه‌سازی داده‌ها و اپلیکیشن‌های حیاتی استفاده می‌شود. در نتفلیکس Apache Kafka مسئول انتقال داده‌ها از kafka جلویی (fronting kafka) به موارد مختلفی از جمله S3، Elastic Search، و kafka ثانویه (Consumer kafka) است. مسیریابی این پیام‌ها با استفاده از فریمورک Apache Samza انجام می‌شود. ترافیک ارسالی توسط Chukwa می‌تواند استریم‌های کامل یا فیلتر شده باشد، بنابراین گاهی اوقات ممکن است لازم باشد فیلترهای بیشتری روی استریم‌های Kafka اعمال شود. به همین دلیل router از یک Kafka به Kafka دیگر در نظر گرفته می‌شود.حضور Apache SamzaApache Samza یک فریمورک open-source محاسباتی غیرهمزمان برای پردازش استریم است. به عبارت دیگر Apache Samza یک موتور پردازش داده مقیاس‌پذیر است که پردازش و آنالیز داده‌ها را به صورت real-time ممکن می‌سازد. Apache Samza در ارتباط با Apache Kafka توسعه یافته است.Elastic Search در نتفلیکسElasticsearch یک موتور جستجو و آنالیز توزیع شده است که بر روی Apache Lucene ساخته شده است. در واقع Elasticsearch یک موتور جستجوی full-text توزیع شده با قابلیت multitenant است. نتفلیکس از Elasticsearch برای مصورسازی داده‌ها، پشتیبانی مشتری و برای تشخیص خطا در سیستم استفاده می‌کند. با Elasticsearch به راحتی می‌توان وضعیت سیستم را monitor کرد، لاگ‌های خطا و خرابی‌ها را عیب‌یابی کرد. به عنوان مثال، اگر کاربر قادر به پخش ویدئو نباشد، مسئول خدمات مشتری این مشکل را با استفاده از elasticsearch حل می‌کند. تیم پخش ویدئو، کاربر را جستجو می‌کند تا بداند چرا ویدیو در دستگاه کاربر پخش نمی‌شود. آن‌ها از تمام اطلاعات و رویدادهایی که برای آن کاربر خاص اتفاق می‌افتد آگاه می‌شوند و متوجه می‌شوند که چه چیزی باعث خطا در استریم ویدیو شده است. همچنین برای پیگیری استفاده از منابع و شناسایی مشکلات ثبت نام (signup) یا ورود (login) از elasticsearch استفاده می‌شود. از Elastic Search برای جستجوی لیست فیلم‌ها یا سریال‌ها بر اساس عنوان یا هر برچسب مرتبط با آن استفاده می‌شود. یکی دیگر از کاربردهای Elastic Search ردیابی رویدادهای کاربر در صورت بروز خطا است.جریان کار جست و جوی محتوا:کلاینت عنوان ویدیو را جستجو می‌کند.سرویس کشف محتوا (CDS) از جستجوی الاستیک درخواست می‌کند تا بررسی کند که آیا عنوان در پایگاه داده وجود دارد یا خیر.اگر عنوان ویدیو در جستجوی الاستیک پیدا شود، CDS جزئیات را از پایگاه داده دریافت می‌کند.جزئیات ویدیو به کلاینت بازگردانده می‌شود.CDS از سرویس شباهت محتوا (CSS) درخواست می‌کند که لیستی از عناوین ویدیوی مشابه را به CDS برمی‌گرداند.CDS جزئیات ویدیو را از پایگاه داده برای آن عناوین ویدیوی مشابه دریافت می‌کند.CDS جزئیات ویدیوی مشابه را به کلاینت برمی‌گرداند.اسپارک (Spark) و سیستم توصیه ویدئوهنگامی که صفحه اول Netflix باز می‌شود، دیده می شود که هر ویدئو تصویر مربوط به خودش را دارد. به این تصاویر، تصاویر تیتر می‌گویند. Netflix حداکثر کلیک را برای ویدیوها از کاربران می‌خواهد و این کلیک‌ها به تصاویر تیتر بستگی دارد. Netflix باید تصویر تیتر قانع‌کننده مناسبی را برای یک ویدیوی خاص انتخاب کند. برای انجام این کار، Netflix چندین اثر هنری را برای یک فیلم خاص ایجاد می‌کند و این تصاویر را به صورت تصادفی برای کاربران نمایش می‌دهد. برای یک فیلم، تصاویر می‌توانند برای کاربران مختلف متفاوت باشند. نتفلیکس بر اساس اولویت‌ها و سابقه تماشای شما پیش‌بینی می‌کند که چه نوع فیلم‌هایی را بیشتر دوست دارید یا چه بازیگرانی را در یک فیلم بیشتر دوست دارید. با توجه به سلیقه کاربران، تصاویر برای آن‌ها نمایش داده می‌شود.اگر کاربری بخواهد محتوا یا ویدیویی را در Netflix پیدا کند، سیستم توصیه Netflix به کاربران کمک می‌کند تا فیلم‌ها یا ویدیوهای مورد علاقه خود را بیابند. برای ساخت این سیستم توصیه، Netflix باید علاقه کاربر را پیش‌بینی کند و انواع مختلفی از داده‌ها را از کاربران جمع‌آوری می‌کند، از جمله:تعامل کاربر با سرویس (مشاهده سابقه و نحوه امتیازدهی کاربر به عناوین دیگر)سایر اعضا با سلیقه و ترجیحات مشابهاطلاعات فراداده از ویدیوهای قبلاً تماشا شده برای یک کاربر مانند عناوین، ژانر، دسته‌ها، بازیگران، سال انتشار و غیرهدستگاه کاربر، در چه زمانی کاربر فعال‌تر است و برای چه مدت کاربر فعال استنتفلیکس از دو الگوریتم مختلف برای ساخت یک recommendation system استفاده می‌کند:فیلتر مشارکتی: ایده این فیلترینگ این است که اگر دو کاربر سابقه رتبه‌بندی مشابهی داشته باشند، در آینده نیز رفتار مشابهی خواهند داشت.فیلتر مبتنی بر محتوا: ایده این است که آن ویدیوهایی را فیلتر کنید که مشابه ویدیویی است که کاربر قبلاً دوست داشته است. فیلترینگ مبتنی بر محتوا به شدت به اطلاعات محصولات مانند عنوان فیلم، سال انتشار، بازیگران، ژانر بستگی دارد. بنابراین برای پیاده‌سازی این فیلتر، دانستن اطلاعاتی که هر مورد را توصیف می‌کند مهم است.موتور Apache SparkApache Spark یک موتور چند زبانه برای اجرای مهندسی داده، علم داده و یادگیری ماشین در ماشین‌ها یا خوشه‌های single‑node است. نتفلیکس از Apache Spark و یادگیری ماشین برای پیشنهاد فیلم استفاده می‌کند.دو عنصر کلیدی در سیستم توصیه نقش آفرینی می‌کنند:یادگیری ماشین: نتفلیکس از الگوریتم‌های هوشمند یادگیری ماشین استفاده می‌کند تا اطلاعات شما را تحلیل کند. این الگوریتم‌ها با بررسی سوابق تماشای فیلم‌هایتان، امتیازدهی‌های شما و حتی عادت‌های تماشایی (زمان تماشا، مدت زمان تماشا و ...) ترجیحات و الگوهای رفتاری شما را درک می‌کنند.اسپارک: حجم عظیم داده‌های نتفلیکس، تحلیل آن‌ها را با روش‌های سنتی غیرممکن کرده است. اسپارک با موازی‌سازی محاسبات، تحلیل این حجم انبوه از اطلاعات را با سرعت و دقت بالایی انجام می‌دهد.معماری زیرساخت ردیابی توزیع شده در Netflix:۱. مشکل: مهندسان نتفلیکس برای بررسی ایرادات استریم داده‌ها مجبور به بررسی حجم عظیمی از داده‌ها و لاگ‌ها بودند. این فرآیند زمان‌بر، طاقت‌فرسا و مستعد خطا بود.۲. راه‌حل: استفاده از ردیابی توزیع ‌شده برای جمع‌آوری و تجزیه و تحلیل داده‌های مربوط به تراکنش‌ها در سراسر سیستم. انتخاب ابزار Open-Zipkin به عنوان یک ابزار منبع باز محبوب برای ردیابی توزیع ‌شده.۳. نتفلیکس برای رفع چالش بررسی خطاهای سیستم استریم، که مستلزم تحلیل دستی و زمان‌بر حجم عظیمی از لاگ‌ها بود، به سراغ پیاده‌سازی معماری ردیابی توزیع‌ شده رفت. این کار با انتخاب ابزار Open-Zipkin آغاز شد تا بتوان مسیر هر درخواست را در سیستم دنبال کرد، مشکلات را سریع‌تر شناسایی نمود و عملکرد را با یافتن گلوگاه‌ها بهبود داد. کتابخانه‌های tracer در سطح کد به منظور جمع‌آوری اطلاعات تراکنش‌ها پیاده‌سازی شدند و داده‌های جمع‌آوری‌شده به سیستم پردازش Real-Time ارسال شدند.با توجه به چالش‌هایی مانند حجم زیاد داده و نیاز به پردازش Real-Time، نتفلیکس ابزار Mantis را توسعه داد که داده‌ها را با بافر کردن و پردازش همزمان تحلیل می‌کرد. همچنین با ارائه زبان MQL، امکان کاوش دقیق‌تری در داده‌ها فراهم شد. این سیستم با فشرده‌سازی و بهینه‌سازی مصرف منابع، تحلیل سریع‌تر و موثرتری را ممکن کرد و توانست داده‌ها را در زمان اجرا تحلیل کرده و کارایی سیستم را بالا ببرد.در حوزه ذخیره‌سازی، افزایش مداوم داده‌ها چالش‌هایی برای تیم ایجاد کرد. در ابتدا از Elasticsearch استفاده شد، اما به‌مرور به دلیل محدودیت مقیاس‌پذیری، به Cassandra مهاجرت کردند. همچنین برای کاهش هزینه و افزایش کارایی، از تکنیک‌هایی مثل فشرده‌سازی با zstd، استفاده از حافظه‌های ابری EBS و ساختار Tiered Storage بهره گرفتند. این اقدامات منجر به بهینه‌سازی قابل توجه هزینه‌ها و افزایش انعطاف‌پذیری سیستم ذخیره‌سازی شدند.برای جمع بندی، اقدامات انجام گرفته برای ارتقای برخی از Quality Attribute ها را مرور می کنیم:کارایی (Performance)شبکه CDN: کاهش فاصله فیزیکی و تأخیر.پخش با بیت نرخ تطبیقی: تضمین پخش روان حتی با اتصالات کندتر (با از دست دادن کیفیت ویدئو).پیش نمایش و بافر: تضمین پخش بدون وقفه حتی با نوسانات لحظه‌ای.کدینگ و فشرده سازی (VP9, HEVC): در عین حفظ کیفیت تصویر عالی، به نسبت‌های فشرده‌سازی بالایی دست می‌یابند. میزان داده برای ارسال ویدئو را کاهش می‌دهد.بهینه‌سازی شبکه (Open Connect): نتفلیکس با ارائه‌دهندگان خدمات اینترنتی (ISP) همکاری می‌کند تا اتصالات اختصاصی را برای اولویت دادن به ترافیک نتفلیکس برقرار کند. این کار از تراکم در مسیرهای عمومی اینترنت می‌کاهد و سرعت تحویل را بهبود می‌بخشد.تحلیل پیش‌بینی‌کننده: نتفلیکس از الگوریتم‌های یادگیری ماشین برای پیش‌بینی تقاضای آینده و مقیاس‌گذاری زیرساخت خود قبل از ساعات اوج استفاده می‌کند و به حداقل رساندن گلوگاه‌های احتمالی و مشکلات بافرینگ کمک می‌کند.Availability (دسترس‌پذیری)زیرساخت و افزونگی (Redundancy):مراکز داده با توزیع جهانی: نتفلیکس شبکه وسیعی از مراکز داده را در سراسر جهان راه‌اندازی کرده است که به صورت استراتژیک قرار گرفته‌اند و تأثیر قطعی یا اختلالات منطقه‌ای را به حداقل می‌رسانند.استراتژی چند ابری: استفاده از چندین ارائه دهنده ابر مانند AWS، Google Cloud Platform و Microsoft Azure، افزونگی را افزایش می‌دهد و وابستگی به هر فروشنده را کاهش می‌دهد. این امر حتی در صورت وجود مشکل با یک ارائه دهنده، تداوم سرویس را تضمین می‌کند.تکرار محتوا: محتوا در سراسر مراکز داده مختلف تکرار می‌شود تا حتی در صورت بروز مشکل در یک مکان، در دسترس بودن را تضمین کند. این تضمین می‌کند که کاربران می‌توانند از سرورهای نزدیک به خود به نمایش‌ها و فیلم‌های مورد علاقه خود دسترسی داشته باشند و تأخیر و اختلالات احتمالی را به حداقل برسانند.مقاومت و همیاری شبکه (Open Connect): همکاری با ارائه دهندگان خدمات اینترنتی (ISP) از طریق Open Connect، اتصالات اختصاصی با پهنای باند بالا ایجاد می‌کند که اولویت را به ترافیک نتفلیکس می‌دهند. این امر از مسیرهای شلوغ اینترنت عمومی عبور می‌کند و مسیر مستقیم‌تر و قابل اعتمادتری برای انتقال داده ارائه می‌دهد.نظارت لحظه‌ای: نتفلیکس به طور مداوم زیرساخت و عملکرد پلتفرم خود را برای هرگونه ناهنجاری یا مشکل احتمالی نظارت می‌کند. این به آن‌ها اجازه می‌دهد تا قبل از تشدید شدن مشکلات و تأثیرگذاری بر کاربران، آن‌ها را شناسایی و حل کنند.مکانیسم‌های بازیابی خودکار: بسیاری از سیستم‌ها به مکانیسم‌های بازیابی خودکار مجهز هستند که می‌توانند بدون نیاز به دخالت دستی از مشکلات جزئی بهبود یابند و زمان خرابی را به حداقل برسانند.امنیت (Security)رمزنگاری: داده‌های کاربران، از جمله رمزعبور، اطلاعات پرداختی و تاریخچه تماشا، در حالت سکون و حین انتقال با استفاده از الگوریتم‌های رمزنگاری قدرتمند رمزگذاری می‌شوند. این کار حتی در صورت رهگیری انتقال داده‌ها، دسترسی یا رمزگشایی آن‌ها را برای طرف‌های غیرمجاز دشوار می‌کند.کنترل دسترسی: کنترل‌های دقیق دسترسی محدود می‌کنند که چه کسی می‌تواند به داده‌های کاربری درون نتفلیکس دسترسی داشته باشد و رویه‌های احراز هویت قوی برای جلوگیری از دسترسی غیرمجاز وجود دارد.شفافیت و انطباق: نتفلیکس به مقررات مربوط به حریم خصوصی داده مانند GDPR و CCPA پایبند است و به کاربران اطلاعات شفافی در مورد جمع‌آوری داده‌ها و شیوه‌های استفاده از آن‌ها ارائه می‌دهد.چالش‌های کلیدی و راه‌حل‌های ارائه شده در این معماری:مدیریت وابستگی‌ها: یکی از چالش‌های اصلی، مدیریت وابستگی‌ها بین سرویس‌ها برای جلوگیری از خرابی‌های متوالی بود. نتفلیکس برای مدیریت تایم‌اوت‌ها، تلاش‌های مجدد (retry) و اجرای مکانیزم‌های جایگزین، از Hystrix استفاده کرد.پایداری و قضیه CAP: با تمرکز بر تعادل میان سازگاری و دسترسی، نتفلیکس سازگاری نهایی را انتخاب کرد و از فناوری‌هایی مانند Cassandra برای مدیریت داده‌های توزیع شده استفاده کرد.قابلیت اطمینان زیرساخت: یک حادثه در شب کریسمس ۲۰۱۲، زمانی که یک خرابی در سیستم کنترل AWS منجر به اختلالات گسترده شد، نیاز به یک زیرساخت مطمئن را برجسته کرد. این حادثه نتفلیکس را به توسعه یک استراتژی چند منطقه‌ای برای افزایش استقامت سوق داد.سرویس‌های stateless در مقابل سرویس‌های دارای حالت: نتفلیکس بین سرویس‌های بدون حالت، که مقدار زیادی از داده‌ها را ذخیره نمی‌کنند و به سرعت از دست دادن گره بهبود می‌یابند، و سرویس‌های دارای حالت مانند پایگاه‌های داده و حافظه‌های نهان، که در آن‌ها از دست دادن گره اهمیت بیشتری دارد، تمایز قائل شد.استراتژی‌های کشینگ: نتفلیکس استراتژی کشینگ خود را از کش‌های تک‌گره‌ای به رویکردی مطمئن‌تر با استفاده از EVCache، یک فناوری مبتنی بر MemcacheD، تکامل داد و قابلیت اطمینان را تضمین کرد.تحلیل معماری اسپاتیفایاسپاتیفای یکی از محبوب‌ترین سرویس‌های استریم موسیقی در دنیاست، که این محبوبیت بی‌دلیل نیست. پشت پرده، این پلتفرم از یک فناوری پیشرفته استفاده می‌کند تا خدماتش را به میلیون‌ها کاربر در سراسر جهان ارائه دهد. از معماری مبتنی بر میکروسرویس‌ها گرفته تا بهره‌گیری از containerization و ابزارهای پیشرفته مانیتورینگ.۱. تاریخچه تحول معماری اسپاتیفایداستان موفقیت اسپاتیفای از سال ۲۰۰۶ آغاز شد، زمانی که «دنیل اک» و «مارتین لورنتزون» با هم آشنا شدند و رویای ساخت یک سرویس قانونی و مقرون‌به‌صرفه برای مقابله با دزدی موسیقی را شکل دادند. اسپاتیفای در سال ۲۰۰۸ کارش را در سوئد آغاز کرد و بعد به کشورهای اروپایی دیگر گسترش یافت.یکی از عوامل مهمی که باعث شد اسپاتیفای در ابتدای کار به سرعت محبوب شود، مدل تجاری نوآورانه‌ی آن بود: ارائه‌ی سرویس freemium که به کاربران امکان می‌داد به‌صورت رایگان از بخشی از موسیقی‌ها استفاده کنند و در صورت تمایل با پرداخت هزینه، به نسخه‌ی premium بدون تبلیغ و با امکانات بیشتر دسترسی داشته باشند. تمرکز بر تجربه‌ی کاربری نیز نقش مهمی در موفقیت اسپاتیفای ایفا کرد؛ از طراحی ساده و کاربرپسند رابط کاربری گرفته تا پلی‌لیست‌های شخصی‌سازی‌شده و پیشنهادات هوشمندانه. همچنین، اسپاتیفای سرمایه‌گذاری گسترده‌ای روی همکاری با شرکت‌های موسیقی و هنرمندان انجام داد تا بتواند آرشیوی غنی و در حال رشد را در اختیار کاربران قرار دهد. قابلیت‌هایی مثل اشتراک‌گذاری و ساخت پلی‌لیست‌های مشترک با دوستان و دنبال‌کننده‌ها، به گسترش طبیعی سرویس کمک زیادی کرد.با رشد اسپاتیفای، این شرکت وارد بازارهای جدید از جمله آمریکا (در سال ۲۰۱۱) شد و به توسعه‌ی پلتفرمش ادامه داد؛ قابلیت‌هایی مانند پادکست‌ها و محتوای انحصاری را اضافه کرد تا کاربران بیشتری را جذب و حفظ کند.۲. نیازمندی‌های سیستمبرای طراحی یک اپلیکیشن استریم موسیقی مانند اسپاتیفای، ابتدا باید نیازمندی‌ها را شناخت.۲.۱. نیازمندی‌های عملکردی (Functional Requirements)جستجو: کاربران بتوانند آهنگ‌ها، هنرمندان، آلبوم‌ها و پلی‌لیست‌ها را جستجو کنند.استریم موسیقی: کاربران بتوانند آهنگ‌ها را به صورت زنده پخش کنند.پلی‌لیست‌ها: کاربران بتوانند پلی‌لیست بسازند، به اشتراک بگذارند یا آن‌ها را ویرایش کنند.پیشنهاد موسیقی: بر اساس تاریخچه‌ی شنیداری و سلیقه‌ی کاربران، آهنگ‌هایی به آن‌ها پیشنهاد داده شود.مدل تبلیغاتی: کاربران نسخه‌ی رایگان، پس از چند آهنگ، تبلیغات صوتی خواهند شنید.۲.۲. نیازمندی‌های غیرعملکردی (Non-Functional Requirements)Latency (تأخیر): تأخیر پایین برای پخش فوری موسیقی بعد از انتخاب کاربر، دریافت سریع نتایج جستجو، و تعامل روان با رابط کاربری حیاتی است. پخش زنده‌ی آهنگ‌ها باید با تأخیر بسیار کم انجام شود.Scalability (مقیاس‌پذیری): مقیاس‌پذیری تضمین می‌کند که با افزایش تعداد کاربران، سیستم بتواند بار اضافی را بدون افت عملکرد مدیریت کند. سیستم باید بتواند صدها میلیون کاربر جهانی و میلیون‌ها استریم همزمان را پشتیبانی کند.Availability (دسترس‌پذیری): کاربران باید بدون وقفه به امکاناتی مثل استریم موسیقی، جستجو و سایر قابلیت‌ها دسترسی داشته باشند. سیستم همیشه باید در دسترس باشد و قطعی نداشته باشد.Robustness (پایداری و مقاومت): شامل توانایی مقابله با ورودی‌های نامعتبر، مشکلات شبکه، خرابی سرور و رفتارهای غیرمنتظره از سمت کلاینت است.پوشش جهانی: پشتیبانی از کاربران در مناطق مختلف جغرافیایی با کمک CDN برای تحویل سریع‌تر فایل‌های صوتی.CAP Theorem: با توجه به ماهیت سرویس استریم موسیقی مانند Spotify که دسترسی آنی به آهنگ‌ها و metadata برای تجربه کاربری اهمیت دارد، باید روی Availability (دسترس‌پذیری) و Partition Tolerance (تحمل پارتیشن) تمرکز کرد. Partition Tolerance اطمینان حاصل می‌کند که در صورت بروز اختلالات شبکه‌ای، سیستم همچنان فعال باقی بماند و کاربران بتوانند به آهنگ‌ها دسترسی داشته باشند. Availability تضمین می‌کند که حتی در صورت خرابی سرور، کاربران بتوانند آهنگ‌ها را جستجو و پخش کنند.۲.۳. نیازمندی‌های ظرفیت (Capacity Requirements)فرضیات ترافیکی:کاربران فعال کل: ۵۰۰ میلیونکاربران فعال روزانه: ۱۰۰ میلیونمتوسط تعداد استریم روزانه هر کاربر: ۱۰حجم متوسط هر آهنگ: ۵ مگابایتطول متوسط آهنگ: ۴ دقیقهکاتالوگ آهنگ‌ها: ۱۰۰ میلیون آهنگتخمین پهنای باند شبکه:استریم روزانه: ۱۰۰ میلیون کاربر × ۱۰ استریم/کاربر = ۱ میلیارد استریمانتقال داده روزانه: ۱ میلیارد استریم × ۵ مگابایت/استریم = ۵ پتابایتانتقال داده در هر ثانیه: ۵ پتابایت / ۸۶۴۰۰ ثانیه ≈ ۵۸ گیگابایت در ثانیهتخمین فضای ذخیره‌سازی:موسیقی‌ها: ۱۰۰ میلیون آهنگ × ۵ مگابایت/آهنگ = ۵۰۰ ترابایتمتادیتای آهنگ‌ها: ۱۰۰ میلیون آهنگ × ۲ کیلوبایت/آهنگ = ۲۰۰ گیگابایتمتادیتای کاربران: ۵۰۰ میلیون کاربر × ۱۰ کیلوبایت/کاربر = ۵ ترابایت۳. معماری کلاناسپاتیفای از معماری microservices استفاده می‌کند تا سیستمش قابلیت مقیاس‌پذیری و نگهداری بالا داشته باشد. این معماری پلتفرم را به سرویس‌های کوچک و مستقلی تقسیم می‌کند که هرکدام مسئول انجام عملکرد خاصی هستند، مانند مدیریت کاربران، ساخت پلی‌لیست، استریم محتوا یا موتورهای پیشنهاددهنده.معماری کلان اسپاتیفای (High-Level Design)مزایای معماری Microservices:Scalability: هر سرویس می‌تواند به‌صورت مستقل و بر اساس میزان تقاضا مقیاس‌پذیر شود.Fault Isolation: در صورت خرابی یک سرویس، سایر سرویس‌ها تحت تأثیر قرار نمی‌گیرند.Independent Deployment: توسعه‌دهندگان می‌توانند هر سرویس را به‌صورت جداگانه به‌روزرسانی کنند، بدون اینکه بر کل سیستم تأثیر بگذارد.اجزای اصلی در معماری سطح بالای اسپاتیفای عبارتند از:SpotifyWebServer: به‌عنوان لایه‌ی BFF (Backend for Frontend) عمل می‌کند که وظایفی مانند احراز هویت، rate limiting، و اعتبارسنجی‌ها را انجام می‌دهد.SongSearchService: سرویس جستجوی آهنگ که نتایج مرتبط با کوئری کاربر را برمی‌گرداند.Elasticsearch: برای افزایش سرعت جستجو بر اساس نام آهنگ، خواننده، متن ترانه یا سایر metadataها استفاده می‌شود. این سرویس ایندکسی از محتوای قابل جستجو ایجاد می‌کند تا retrieval سریع ممکن شود.SongMetadataService: سرویسی که APIهایی برای دریافت داده از MetadataDB ارائه می‌دهد.MetadataDB: سیستم مرجع برای metadata آهنگ‌ها.SongStreamingService: برای استریم فایل صوتی آهنگ به کاربر استفاده می‌شود.ObjectStore: سیستم مرجع برای نگهداری فایل‌های صوتی.CDN: شبکه تحویل محتوا که آهنگ‌ها را cache می‌کند تا latency کاهش یابد.۴. فناوری‌های کلیدی و Tech Stack۴.۱. فناوری‌های بک‌اندJava: زبان برنامه‌نویسی اصلی اسپاتیفای است و برای ساخت RESTful APIها و مدیریت وابستگی‌ها از Spring Framework استفاده می‌شود.Scala: برخی از سرویس‌های اصلی با Scala نوشته شده‌اند.Node.js: برخی سرویس‌های بک‌اند نیز با Node.js توسعه داده شده‌اند.Apache Kafka: برای پردازش داده‌ها و رویدادها به صورت real-time استفاده می‌شود.Apache Cassandra: دیتابیس NoSQL که برای ذخیره‌ی اطلاعاتی مانند پلی‌لیست‌ها و آرشیو موسیقی کاربران به کار می‌رود.Redis: برای cache کردن داده‌هایی مثل اطلاعات مربوط به آهنگ‌ها، آلبوم‌ها و هنرمندان.Docker: برای containerization و اجرای میکروسرویس‌ها در قالب کانتینرهای سبک.۴.۲. فناوری‌های فرانت‌اندReact: برای ساخت رابط کاربری وب‌اپ.Redux: برای مدیریت state در اپلیکیشن.Sass: برای تولید CSS با قابلیت‌های بیشتر.Webpack: برای bundle کردن فایل‌های جاوااسکریپت و دیگر منابع.۴.۳. زیرساخت (Infrastructure)Amazon Web Services (AWS): برای ارائه منابع محاسباتی و ذخیره‌سازی.Kubernetes: برای orchestration کانتینرها و مدیریت میکروسرویس‌ها.Terraform: برای پیاده‌سازی infrastructure به‌صورت کد.Prometheus: برای مانیتورینگ سلامت سیستم‌ها.Grafana: برای ساخت داشبوردهای تحلیلی و بصری‌سازی داده‌ها.۵. مدل سیستمی اسپاتیفایبرای اینکه بتوانند درباره‌ی نرم‌افزار خود صحبت کنند و به تفاهم برسند، اسپاتیفای یک زبان مشترک و مجموعه‌ای از تعریف‌ها به اسم «مدل سیستمی اسپاتیفای» ایجاد کرده است. این مدل، مجموعه‌ای از موجودیت‌ها و انتزاعات پایه‌ای را معرفی می‌کند که به تجزیه و تحلیل اطلاعاتی درباره‌ی سلامت نرم‌افزار، مالکیت و وابستگی‌های آن کمک می‌کند. این درک مشترک از نرم‌افزار و منابع، کلید موفقیت در مقیاس کاری اسپاتیفای است.۵.۱. موجودیت‌های اصلی مدل سیستمی:API ها: مرزهای بین کامپوننت‌ها را تعریف می‌کنند، یعنی مشخص می‌کنند هر بخش چطور با بقیه ارتباط دارد.Component ها: بخش‌های مستقل نرم‌افزاری هستند، مثل یک سرویس بک‌اند، یک وب‌سایت، یک پایپ‌لاین دیتا یا حتی یک کتابخانه.Resource ها: زیرساخت‌هایی هستند که یک کامپوننت برای اجرا به آن‌ها نیاز دارد، مثل دیتابیس، ماشین مجازی یا فضای ذخیره‌سازی.ارتباط موجودیت های مدل سیستمی۵.۲. انتزاع‌های جدید برای مدیریت پیچیدگی:System ها: مجموعه‌ای از موجودیت‌هایی که با هم کار می‌کنند تا یک عملکرد مشخص ارائه دهند.Domain ها: سیستم‌ها و موجودیت‌هایی که به یک حوزه‌ی کسب‌وکار مربوط می‌شوند.با تبدیل این مدل به متادیتا، اسپاتیفای توانسته است یک کاتالوگ نرم‌افزاری ایجاد کند که مالکیت، وابستگی، چرخه‌عمر و سایر اطلاعات را دنبال و ثبت می‌کند.۶. استفاده از مدل C4 برای دیاگرام‌های اسپاتیفایمدل C4 یک روش سبک، ساده و موثر برای بصری‌سازی معماری نرم‌افزار است. این مدل مجموعه‌ای از انتزاعات مشخص، نشانه‌گذاری استاندارد و بهترین روش‌ها برای کشیدن دیاگرام را ارائه می‌دهد. این مدل تعادل خوبی بین روش‌های پراکنده‌ و استانداردهای خشک ایجاد می‌کند.Context Diagramاسپاتیفای از نشانه‌گذاری‌ها و اصول C4 استفاده کرده، اما بخش های انتزاعی آن را با مدل سیستمی خود جایگزین کرده است. نتیجه، مجموعه‌ای جدید از دیاگرام‌های پایه برای مستندسازی معماری و طراحی سیستم است:System Landscape Diagram: نشان می‌دهد یک مجموعه سیستم مرتبط چطور با هم در ارتباطند و چه وابستگی‌هایی به بیرون دارند. مثلاً همه‌ی سیستم‌هایی که توسط یک تیم اداره می‌شوند.System Context Diagram: نشان می‌دهد یک سیستم چطور در بافت کلی کسب‌وکار، کاربران و سایر سیستم‌ها قرار گرفته است.System Components Diagram: نشان می‌دهد اجزای داخلی یک سیستم چیست. (در مدل C4 به آن Container Diagram هم می‌گویند).container diagram۶.۱. نمونه‌ای از جزئیات معماری با مدل C4 (Backstage)کانتینر: سیستم Backstage از سه جزء اصلی تشکیل شده است:یک برنامه وب Backstage که مسئول نمایش مهم‌ترین اطلاعات به کاربر است.یک سرویس Backstage Backend که مسئول راه‌اندازی سایر افزونه‌های Backstage مانند Software Catalog است.یک پایگاه داده که مسئول ذخیره هرگونه داده‌ای است که باید به کاربر ارائه شود. این پایگاه داده معمولاً داده‌های خاص افزونه را ذخیره می‌کند، به این معنی که بسته به نحوه تصمیم‌گیری شما برای نوشتن برنامه Backstage، می‌توانید نمونه‌های پایگاه داده زیادی داشته باشید.کامپوننت: برنامه وب Backstage از افزونه‌ها تشکیل شده است. برخی از نمونه‌های افزونه‌ها می‌توانند یک افزونه CI/CD (مانند Circle CI، Travis CI) یا کاتالوگ نرم‌افزار باشند (ویژگی‌های اصلی نیز افزونه هستند). این افزونه‌ها معمولاً فراخوانی‌های API را به سرویس‌های دیگر ارسال می‌کنند تا اطلاعات را به کاربر ارائه دهند. اگر افزونه نیاز به دسترسی به API دارد، Backstage سه گزینه ارائه می‌دهد:دسترسی مستقیم به API.پیکربندی Backstage برای پروکسی کردن به یک API موجود.ایجاد یک افزونه backend اگر API در کنار افزونه frontend پیاده‌سازی شود.اتوماسیون دیاگرام‌های معماری در Backstage:داشتن یک کاتالوگ کامل از نرم‌افزار، متادیتاها و کامپوننت‌ها، امکان تولید خودکار دیاگرام‌های معماری و مرور تعاملی آن‌ها را فراهم کرده است. این دیاگرام‌ها همیشه با واقعیت به‌روز هستند، زیرا از روی متادیتای زنده تولید می‌شوند. Backstage با سیستم افزونه‌پذیری خود، امکان اضافه کردن تب "Architecture" به صفحه‌ی هر سیستم را فراهم کرده که دیاگرام Spotify Component آن سیستم را نشان می‌دهد.۷. شبکه تحویل محتوا (CDN) برای استریماسپاتیفای از Content Delivery Networks برای تحویل موسیقی و محتوای صوتی با تأخیر پایین استفاده می‌کند. CDN فایل‌های صوتی را روی سرورهای مرزی (edge servers) که به‌طور جهانی توزیع شده‌اند، cache می‌کند تا از نزدیک‌ترین مکان به کاربر، محتوا را تحویل دهد.نقش CDN در اسپاتیفای:کاهش Latency: محتوا از سرورهای جغرافیایی نزدیک‌تر ارائه می‌شود و باعث کاهش زمان بارگذاری و بافر می‌گردد.توزیع بار: با انتقال ترافیک به edge servers، فشار روی زیرساخت اصلی اسپاتیفای کاهش می‌یابد.بهینه‌سازی هزینه: CDN هزینه بالایی دارد، بنابراین راه‌اندازی CDN اختصاصی ممکن است مقرون‌به‌صرفه‌تر باشد. برخی آهنگ‌ها فقط در نواحی خاصی محبوب‌اند؛ بنابراین، نگهداری آن‌ها فقط در CDNهای منطقه‌ای مناسب‌تر است. فقط آهنگ‌های با تقاضای بالا در CDN ذخیره شوند و بقیه در سرورهای با ظرفیت بالا و هزینه کمتر.۸. زیرساخت داده و Apache Kafkaاسپاتیفای حجم بسیار زیادی از داده‌هایی را که کاربران در زمان واقعی (real-time) تولید می‌کنند، پردازش می‌کند. برای مدیریت این داده‌ها، از Apache Kafka استفاده می‌شود؛ یک پلتفرم توزیع‌شده برای event-streaming که حجم زیادی از داده را بین سرویس‌ها ingest، process و انتقال می‌دهد.خطوط پردازش داده:Apache Kafka: مدیریت eventهای real-time مثل پخش آهنگ، رد کردن آهنگ (skip) و لایک کردن.Apache Samza و Storm: پردازش داده‌های real-time برای به‌روزرسانی آنی سیستم‌های پیشنهاددهنده و ویژگی‌های شخصی‌سازی‌شده.۹. سیستم‌های ذخیره‌سازیاسپاتیفای از چندین راه‌حل ذخیره‌سازی برای کاربردهای مختلف، از داده‌های کاربران گرفته تا محتوای صوتی، استفاده می‌کند. در ابتدا از PostgreSQL استفاده می‌کرد اما به دلیل مشکلات مقیاس‌پذیری به ترکیبی از دیتابیس‌ها مهاجرت کرد.Cassandra: یک پایگاه‌داده NoSQL برای ذخیره داده‌های گسترده و توزیع‌شده مانند پروفایل کاربران، داده‌های پلی‌لیست و فعالیت‌های کاربر. Cassandra در دسترس‌پذیری بالا و تحمل خرابی بسیار مناسب است.Amazon S3: برای ذخیره فایل‌های صوتی حجیم، کاور آلبوم و دیگر محتوای استاتیک. مقیاس‌پذیری و هزینه مناسب S3 برای کتابخانه گسترده موسیقی اسپاتیفای حیاتی است. آهنگ‌ها را می‌توان Tiering کرد، به این شکل که آهنگ‌های کمتر محبوب به کلاس ذخیره‌سازی S3 Standard-Infrequent Access منتقل شوند تا هزینه‌ها بهینه شوند.MySQL: برای تراکنش‌های آنلاین با ساختار رابطه‌ای.Redis: برای کشینگ توزیع‌شده، و همچنین برای کش اطلاعات مربوط به آهنگ‌ها، آلبوم‌ها و هنرمندان.HBase: ممکن است در سناریوهایی با throughput بالا مانند آنالیزها و متریک‌های real-time استفاده شود.HDFS (Hadoop Distributed File System): برای ذخیره آفلاین داده‌های حجیم.AWS, Google Cloud, Azure: به عنوان ذخیره‌سازی ابری.Hive: برای تحلیل داده‌های کلان در سطح سازمانی.۱۰. سیستم Personalizationسیستم پیشنهاددهنده اسپاتیفای یکی از قابلیت‌های کلیدی آن است که پلی‌لیست‌هایی مثل Discover Weekly و Daily Mix را براساس ترجیحات کاربر شخصی‌سازی می‌کند.مدل‌های Machine Learning: برای ارائه پیشنهادهای دقیق، رفتار کاربر، metadata موسیقی و سابقه گوش‌دادن تحلیل می‌شوند.Collaborative Filtering: استفاده از الگوریتم‌های collaborative filtering برای پیشنهاد محتوا براساس سلیقه کاربران مشابه.Natural Language Processing (NLP): برای پردازش و دسته‌بندی محتوای پادکست‌ها و metadata، و بهبود پیشنهادهای مربوط به محتوای گفتاری.۱۱. APIها برای ارتباط بین سرویس‌هاارتباط بین microservices در اسپاتیفای از طریق RESTful APIs یا gRPC انجام می‌شود. این APIها پایه ارتباط بین سرویس‌هایی مانند سرویس پلی‌لیست، سرویس کاربران و سرویس محتوا هستند.API Gateway: اسپاتیفای از API Gateway برای مدیریت ارتباط بین frontend و backend استفاده می‌کند. این قابلیت امکان مسیریابی بهینه درخواست‌ها، load balancing و ویژگی‌های امنیتی مانند rate limiting را فراهم می‌کند.۱۲. لایه Cacheاسپاتیفای به‌طور گسترده‌ای از caching برای پاسخ‌دهی سریع‌تر و کاهش بار روی دیتابیس‌ها استفاده می‌کند.Redis یا Memcached: برای ذخیره‌سازی داده‌هایی که زیاد استفاده می‌شوند مانند پلی‌لیست‌های کاربر، آهنگ‌های اخیراً پخش‌شده و جزئیات پروفایل.Edge Caching: علاوه بر caching توسط CDN برای فایل‌های صوتی، ممکن است caching لایه‌ای برای metadata مانند عنوان آهنگ و نام خواننده استفاده شود.۱۳. پایش (Monitoring) و ثبت لاگبا توجه به پیچیدگی سیستم، اسپاتیفای از ابزارهای monitoring و logging برای بررسی عملکرد سیستم، شناسایی مشکلات و اطمینان از اجرای روان استفاده می‌کند.Grafana و Prometheus: برای مانیتورینگ لحظه‌ای متریک‌های سیستم؛ Prometheus برای جمع‌آوری متریک و Grafana برای visualization و هشداردهی استفاده می‌شود.ELK Stack: برای لاگ‌گیری متمرکز و رفع اشکال، ممکن است از ELK (Elasticsearch، Logstash، Kibana) استفاده شود تا مهندسان بتوانند لاگ‌های سرویس‌های مختلف را تحلیل کنند.۱۴. امنیت و کنترل دسترسیاسپاتیفای اقدامات امنیتی گسترده‌ای برای محافظت از داده‌های کاربران و پلتفرم خود پیاده کرده است.OAuth2 و JWT: برای احراز هویت (Authentication) و Authorization کاربران. این مکانیسم‌ها دسترسی امن به منابعی مانند پلی‌لیست‌ها و کتابخانه موسیقی را فراهم می‌کنند.رمزنگاری (Encryption): داده‌ها، به‌ویژه اطلاعات شخصی و اعتبارنامه‌ها، هم در حالت انتقال (با TLS) و هم در حالت ذخیره‌شده رمزنگاری می‌شوند.۱۵. DevOps و استقرار پیوسته (Continuous Deployment)اسپاتیفای از رویکردهای DevOps برای استقرار سریع و روان ویژگی‌های جدید و به‌روزرسانی‌ها استفاده می‌کند. از CI/CD pipelines برای توسعه سریع، تست و استقرار بهره می‌برد.Docker و Kubernetes: برای بسته‌بندی microservices از Docker استفاده می‌کند و با Kubernetes آن‌ها را orchestration می‌کند تا مدیریت مقیاس‌پذیر و بهینه صورت گیرد.۱۶. طراحی عمیق۱۶.۱. پایگاه داده metadata (Metadata Datastore)رویکرد اول: استفاده از پایگاه داده Relational: ساختار schema از پیش تعریف‌شده‌ای وجود دارد که به‌ندرت به‌روزرسانی می‌شود. می‌توان داده‌ها را نرمال‌سازی کرد و اطلاعات خواننده، تهیه‌کننده و سایر موارد را در جدول‌های جداگانه ذخیره کرد تا redundancy داده‌ها کاهش یابد. از آن‌جایی که فقط ۱ گیگابایت داده نیاز است، همه‌ی داده‌ها می‌توانند در یک سرور پایگاه‌داده قرار گیرند.رویکرد دوم: استفاده از پایگاه داده NoSQL: نیاز به تکرار داده‌ها وجود دارد، مثلاً اطلاعات مشترک مربوط به خواننده‌ها یا سایر جزئیات برای چندین آهنگ باید مجدداً ذخیره شوند.Songid: Stringname: StringaudioURL: String۱۶.۲. Object Store و نحوه کارکرد استریم آهنگAmazon S3: می‌توان از Amazon S3 برای ذخیره آهنگ‌ها استفاده کرد.رویکرد اول: HTTP Range Requests: برای استریم صوتی یا ویدیویی، می‌توان فایل را به‌صورت کامل در Blob Storage ذخیره کرد و با استفاده از HTTP Range Request بخش‌هایی از آن را درخواست کرد. در صورتی‌که سرعت اینترنت کاربر پایین باشد، این کار می‌تواند منجر به buffering شود، مخصوصاً وقتی که داده‌های با bitrate بالا درخواست شود.رویکرد دوم: Adaptive Bitrate با HTTP Range Requests: نسخه‌های مختلفی از فایل صوتی با bitrateهای متفاوت (مثلاً 320kbps، 128kbps و...) در Object Store ذخیره می‌شوند. اپلیکیشن کلاینت ابتدا نسخه‌ای با bitrate پیش‌فرض (مثلاً 320kbps) را دریافت می‌کند تا فقط بخش اولیه فایل دانلود و پخش شود، و زمان بارگذاری اولیه کاهش یابد. هم‌زمان اپلیکیشن پهنای باند اینترنت کاربر را پایش می‌کند و در صورت ناکافی بودن، به نسخه‌ای با bitrate پایین‌تر سوئیچ می‌کند. این روش نیاز به کنترل بیشتر از سمت کلاینت و هماهنگی دقیق دارد.رویکرد سوم: HLS یا DASH برای Adaptive Bitrate Streaming: در پروتکل‌های استاندارد مانند HLS (HTTP Live Streaming) و DASH (Dynamic Adaptive Streaming over HTTP)، محتوا به قطعات کوتاه (chunks) با bitrateهای مختلف تقسیم می‌شود. پلیر رسانه یک manifest file را می‌خواند و بر اساس وضعیت شبکه، مناسب‌ترین قطعه را انتخاب می‌کند.نکته: می‌توان رویکرد هیبریدی داشت: فایل manifest و قطعات (chunks) آهنگ‌های محبوب در CDN ذخیره شوند و آهنگ‌های کمتر محبوب در S3. هنگامی‌که کلاینت درخواستی برای پخش آهنگ ارسال می‌کند، backend تصمیم می‌گیرد که URL فایل manifest را از CDN برگرداند یا از S3 (بر اساس فاکتورهایی مثل محبوبیت).۱۶.۳. Failover در ElasticsearchElasticsearch سیستم مرجع (System of Record) برای metadata آهنگ‌ها نیست. اگر این سرویس دچار خرابی شود، می‌توان cache آن را مجدداً با استفاده از داده‌های موجود در MetadataDB بازسازی کرد. همچنین، هر بروزرسانی در MetadataDB، به‌صورت event به Elasticsearch cluster ارسال شده و ایندکس آن به‌روز می‌شود.۱۶.۴. بهینه‌سازی‌هاشناسایی و حذف گلوگاه‌ها (Bottlenecks): مثلا اگر یک خواننده مشهور آهنگ جدیدی منتشر کند، اکثر درخواست‌ها برای آن آهنگ خاص خواهند بود. در این حالت، سرورهای وب که این درخواست‌ها را پردازش می‌کنند فشار زیادی را به S3 وارد می‌کنند و این گلوگاه ایجاد می‌کند. راه‌حل: ذخیره آهنگ‌های محبوب در CDN (مثل Amazon CloudFront) باعث کاهش تأخیر و بهبود تجربه کاربری می‌شود.عملکرد (Performance):Load Balancer: استفاده از شاخص مناسب برای توزیع ترافیک باعث بهبود عملکرد می‌شود. پیشنهاد می‌شود توزیع بر اساس پهنای باند شبکه انجام شود، نه CPU.کش کاربر: کاربر می‌تواند آهنگ‌های پرپخش خود را در کش ذخیره کند و بار سرور را کاهش دهد.کش سرور: سرور نیز می‌تواند تعداد محدودی از آهنگ‌های پرپخش را در کش حافظه نگه‌ دارد تا از بار روی دیتابیس و CDN کم شود.رمزگذاری و فشرده‌سازی صوتی: می‌توان سیستم‌هایی برای فشرده‌سازی فایل صوتی ایجاد کرد تا فضا بهینه‌تر استفاده شود.گسترش پایگاه‌داده:مدل Leader-Follower: از آنجایی که تعداد عملیات خواندن بسیار بیشتر از نوشتن است (تعداد زیاد کاربران که آهنگ پخش می‌کنند، اما تعداد کم هنرمندان که آهنگ آپلود می‌کنند)، می‌توان از مدل Leader → Follower استفاده کرد:یک پایگاه‌داده اصلی (Leader) برای نوشتن و خواندن.چندین پایگاه‌داده ثانویه (Follower/Slave) فقط برای خواندن.این کار باعث می‌شود metadata آهنگ‌ها و کاربران به‌صورت سریع و بهینه خوانده شوند.در نهایت می توان گفت معماری سیستم Spotify یک معماری پیچیده و مبتنی بر microservices است که برای پاسخ‌گویی به نیازهای کاربران گسترده و مدیریت داده‌های عظیم طراحی شده است. با استفاده از فناوری‌هایی مانند CDN، Apache Kafka، سیستم‌های پیشنهاددهنده مبتنی بر machine learning، و ابزارهای ذخیره‌سازی cloud، Spotify موفق به ارائه تجربه‌ای پایدار، مقیاس‌پذیر و شخصی‌سازی‌شده برای کاربران خود شده است. بهره‌گیری از caching، پردازش real-time و زیرساخت امن، Spotify را قادر ساخته تا تجربه استریم صوتی بی‌وقفه‌ای را در سطح جهانی ارائه دهد.تحلیل معماری اوبرمعماری سطح بالا در اوبر (و سایر اپ های مشابه)۱. تاریخچه تحول معماریاوبر، با هدف اتصال سریع و آسان مسافران به حمل‌ونقل، به یکی از بزرگترین پلتفرم‌های اشتراک سفر در جهان تبدیل شده است. در پشت این فرآیند به ظاهر ساده (رزرو تاکسی در ۱ تا ۲ دقیقه)، معماری عظیمی وجود دارد که هر مرحله از وارد کردن موقعیت مکانی تا نهایی شدن رزرو را پشتیبانی می‌کند. اوبر به عنوان یک سیستم حمل و نقل آنی، فراتر از هدف اولیه خود رشد کرده و اکنون بخش‌های مختلفی از جمله تحویل غذا (Uber Eats) و حمل بار (Uber Freight) را نیز پشتیبانی می‌کند. این سیستم از لحظه‌ای که کاربر ثبت‌نام می‌کند تا پایان سفر، حجم عظیمی از داده تولید می‌کند که شامل اطلاعات مسافر، موقعیت مکانی، پرداخت، دسته‌بندی‌ها، راننده‌ها و هزینه سفر است. اوبر این داده‌ها را به صورت یکپارچه جمع‌آوری، ذخیره و تحلیل می‌کند.اوبر در سال ۲۰۰۹ با معماری مونولیتیک (Monolithic) راه‌اندازی شد. این سیستم شامل یک Backend و یک Frontend واحد، و یک پایگاه داده مرکزی (با استفاده از Python و SQLAlchemy) بود. این معماری در ابتدا و با تعداد کم سفرها و شهرهای فعال، کافی بود. اما با گسترش سریع اوبر به شهرهای مختلف و افزایش پیچیدگی نیازهای تجاری، محدودیت‌های معماری مونولیتیک مشخص شد.از سال ۲۰۱۴، اوبر به معماری سرویس‌گرا (Service-Oriented Architecture - SOA) و در واقع همان میکروسرویس مهاجرت کرد. در این معماری، هر سرویس کوچک و مستقل است، یک وظیفه‌ی خاص تجاری را انجام می‌دهد و می‌تواند از استک فناوری مناسب خود استفاده کند. ارتباط بین سرویس‌ها از طریق API انجام می‌شود. مزیت اصلی این معماری، امکان استقرار مستقل هر سرویس است که سیستم را مقیاس‌پذیر و انعطاف‌پذیر می‌سازد. این معماری اکنون نه‌تنها سرویس حمل‌ونقل، بلکه بخش‌های دیگر مانند تحویل غذا و حمل بار را نیز پشتیبانی می‌کند.با این حال، با رشد شدید سرویس‌ها، سیستم میکروسرویس‌ها نیز پیچیده‌تر شد. ارتباطات بین سرویس‌ها دشوارتر گردید و توسعه‌دهندگان با چالش‌هایی مانند مدیریت وابستگی‌ها، هماهنگی بالا و افت بهره‌وری مواجه شدند. اوبر برای حل این مشکلات، الگوی DOMA (Domain-Oriented System Architecture) را اتخاذ کرد. در DOMA، سیستم به مجموعه‌هایی به‌نام دامنه (Domain) تقسیم می‌شود که هر دامنه شامل سرویس‌های مرتبط با یک حوزه خاص تجاری است. دامنه‌ها در مجموعه‌های بزرگ‌تری به‌نام لایه‌ها (Layers) گروه‌بندی می‌شوند که وابستگی‌ها را کنترل می‌کنند. این طراحی، به شکل یک ساختار لایه‌ای از میکروسرویس‌هاست. DOMA باعث شد ساختار میکروسرویس‌ها از پیچیدگی خارج شده و به ماژول‌هایی کوچک‌تر، منعطف‌تر، و قابل استفاده مجدد تقسیم شوند. مزایای DOMA شامل تجربه بهتر توسعه‌دهنده، کاهش پیچیدگی سیستم، مهاجرت آسان‌تر در آینده و امکان نوآوری سریع است.۲. نیازمندی‌های سیستمبرای طراحی یک اپلیکیشن رزرو تاکسی مانند اوبر، ابتدا باید نیازمندی‌ها را شناخت.۲.۱. نیازمندی‌های عملکردی (Functional Requirements)نمایش تاکسی‌های اطراف کاربر: کاربران باید بتوانند لیست تمام خودروهای موجود همراه با کمترین قیمت و زمان تقریبی رسیدن (ETA) را ببینند.امکان رزرو تاکسی: کاربران باید بتوانند مسیر خود را انتخاب و خودرو رزرو کنند.رهگیری موقعیت مکانی: کاربران باید بتوانند مکان راننده را روی نقشه مشاهده کنند. همچنین موقعیت لحظه‌ای سفر باید به‌روزرسانی شده و ارتباط میان راننده و مسافر ساده شود.لغو سفر: کاربران باید در هر لحظه قادر به لغو سفر خود باشند.ایجاد حساب کاربری و ورود کاربر: ثبت‌نام و احراز هویت امن باید برای کاربران ساده و سریع باشد.تطبیق بلادرنگ راننده و مسافر: کاربران باید بتوانند در لحظه به رانندگان اطراف متصل شوند، بر اساس موقعیت، نوع خودرو و در دسترس بودن راننده.پرداخت امن: تراکنش‌های مالی باید از طریق درگاه‌های پرداخت امن و روش‌های رمزنگاری قوی انجام شوند.شخصی‌سازی مبتنی بر هوش مصنوعی: اوبر با استفاده از الگوریتم‌های هوش مصنوعی، تجربه کاربران را شخصی‌سازی می‌کند (مانند پیشنهاد مبدا/مقصدهای پرتکرار با توجه به داده‌های گذشته و شرایط لحظه‌ای).۲.۲. نیازمندی‌های غیرعملکردی (Non-Functional Requirements)پوشش جهانی: سیستم باید بتواند در مناطق مختلف جغرافیایی خدمات ارائه دهد.تأخیر پایین (Low Latency): سیستم باید در شرایط اوج ترافیک، تأخیر را به حداقل رسانده و پخش فوری موسیقی بعد از انتخاب کاربر، دریافت سریع نتایج جستجو، و تعامل روان با رابط کاربری حیاتی است.دسترسی‌پذیری بالا (High Availability): کاربران باید بدون وقفه به امکاناتی مثل استریم موسیقی، جستجو و سایر قابلیت‌ها دسترسی داشته باشند. راه‌کارهای Failover برای تضمین ارائه خدمات بدون قطعی پیاده‌سازی شود.پایداری بالا و سازگاری داده‌ها (High Reliability & Consistency): سیستم باید توانایی مقابله با ورودی‌های نامعتبر، مشکلات شبکه، خرابی سرور و رفتارهای غیرمنتظره از سمت کلاینت را داشته باشد. اصل CAP (Consistency, Availability, Partition Tolerance) می‌گوید یک سیستم توزیع‌شده نمی‌تواند هم‌زمان هم بسیار در دسترس و هم کاملاً سازگار باشد — اما در واقع، همه اجزای سیستم نیاز نیست که هم‌زمان این دو ویژگی را داشته باشند — برخی اجزا باید سازگار باشند (مثل اطلاعات پرداخت)، و برخی دیگر باید در دسترس باشند (مثل موقعیت راننده).مقیاس‌پذیری (Scalability): سیستم باید بتواند صدها میلیون کاربر جهانی و میلیون‌ها استریم همزمان را پشتیبانی کند. زیرساخت باید توانایی پذیرش افزایش ترافیک را بدون کاهش کیفیت عملکرد داشته باشد.امنیت (Security): پیاده‌سازی پروتکل‌های احراز هویت، رمزنگاری و محافظت از اطلاعات کاربران الزامی است.تطابق با مقررات (Compliance): سیستم باید مطابق با مقررات حفاظت از داده (مثل GDPR) عمل کرده و حفظ حریم خصوصی کاربران را تضمین کند.۲.۳. اهداف بازنویسی برنامه اوبرافزایش دسترسی‌پذیری تجربه اصلی کاربر (core rider experience).فراهم کردن امکان آزمایش‌های گسترده روی مسیرهای مشخص.۲.۴. برآورد ظرفیت (Capacity Estimation)با فرض ۵ میلیون کاربر فعال و ۲۰۰,۰۰۰ راننده و متوسط روزانه ۱ میلیون سفر:درخواست‌ها در ثانیه: اگر هر کاربر به طور متوسط ۵ عمل در اپلیکیشن انجام دهد، مجموعاً روزانه ۵ میلیون درخواست پردازش می‌شود که معادل تقریباً ۵۸ درخواست در ثانیه است.نیاز به فضای ذخیره‌سازی: اگر هر پیام حدود ۵۰۰ بایت حجم داشته باشد، روزانه به حدود ۲.۳۲ گیگابایت فضا نیاز داریم.۳. معماری کلان (High-Level Design)معماری اوبر از میکروسرویس‌های متعددی تشکیل شده است که هر کدام وظیفه خاصی را بر عهده دارند. این سرویس‌ها از طریق لود بالانسر (Load Balancer - LB) و Web Application Firewall (WAF) به یکدیگر و به کلاینت‌ها (اپ‌های کاربر و راننده) متصل می‌شوند. تصویر کلی معماری اوبر نشان‌دهنده تعامل بین سرویس‌های اصلی مانند Customer Services، Driver Services، Payment Services، Notification Services و DataBases است. سیستم‌های تحلیل و مقابله با گلوگاه‌ها (Analytics و Bottleneck Conditions) نیز از اجزای مهم این معماری هستند.معماری سطح بالای اپ اوبر۴. اجزای کلیدی سیستم و نحوه تعامل آن‌ها۴.۱. Map Service و Segmentها:اوبر برای تعیین موقعیت مکانی و یافتن راننده‌های اطراف، از مفهومی به نام Segment استفاده می‌کند. یک Segment یک ناحیه مستطیلی روی نقشه است. کل یک شهر را می‌توان به چندین Segment تقسیم کرد و موقعیت تاکسی‌ها و کاربران در این Segmentها مشخص می‌شود.از آنجا که تاکسی‌ها دائماً در حرکت هستند، اطلاعات موقعیت مکانی آن‌ها به صورت لحظه‌ای دریافت و توسط Map Service مدیریت می‌شود. Map Service وظیفه نگاشت و مدیریت Segmentها برای کاربران و راننده‌ها را بر عهده دارد و همچنین ETA و مسیر رسیدن را محاسبه می‌کند.در مناطق پرتراکم، Map Service Segmentها را به بخش‌های کوچک‌تر تقسیم می‌کند و در مقابل، Segmentهای کم‌تراکم را با هم ادغام می‌کند تا مدیریت بهینه‌تر باشد.اوبر برای تقسیم نقشه‌ها به سلول‌های کوچک، از کتابخانه Google S2 استفاده می‌کند. این سلول‌ها (مثلاً به اندازه ۳ کیلومتر) شناسه منحصربه‌فرد دارند و به راحتی در سیستم توزیع شده مدیریت می‌شوند.اوبر در گذشته از Mapbox استفاده می‌کرد اما بعدها به Google Maps API مهاجرت کرد.نمایش segment۴.۲. تعامل کاربران و رانندگان (User/Driver App, Services, WebSocket):اپلیکیشن کاربر (User App) و User Service: کاربران از طریق User App با سیستم در ارتباط هستند. این اپ به User Service متصل می‌شود که مخزن اطلاعات مربوط به کاربران است و از طریق APIها امکان دریافت و به‌روزرسانی اطلاعات را فراهم می‌کند. این سرویس روی یک پایگاه داده MySQL-based User DB قرار دارد و اطلاعات را در Redis نیز cache می‌کند.اپلیکیشن راننده (Driver App) و Driver Service: راننده‌ها از طریق Driver App به سیستم وصل می‌شوند. Driver App به Driver Service متصل است که معادل User Service برای رانندگان است. این سرویس نیز روی پایگاه داده MySQL-based Driver DB قرار دارد و اطلاعات را در Redis cache می‌کند.WebSocket Servers و Location Service: Driver App برای ارسال موقعیت لحظه‌ای راننده، از طریق مجموعه‌ای از WebSocket Servers با Location Service در ارتباط است. این سرویس، موقعیت راننده را دریافت کرده و هر چند ثانیه یک‌بار موقعیت را به Map Service می‌فرستد تا Segment راننده را مشخص کرده و نگاشت راننده‌ها به Segmentها را در Redis به‌روزرسانی کند. Location Service همچنین اطلاعات موقعیت را در Cassandra ذخیره می‌کند و مسیر حرکت راننده را برای صورتحساب یا بررسی های آتی نگهداری می‌کند.WebSocket Manager و WebSocket Handler: WebSocket Handlerها یک اتصال دائمی با راننده‌ها برقرار می‌کنند تا پینگ‌های موقعیت مکانی را دریافت کنند یا اعلان‌های مربوط به سفرها را ارسال نمایند. این Handlerها به یک WebSocket Manager متصل‌اند که با استفاده از Redis پایش می‌کند کدام راننده به کدام Handler متصل است. Redis علاوه بر نگهداری اطلاعات اتصال راننده‌ها، یک نگاشت معکوس هم نگه می‌دارد تا مشخص شود هر راننده به کدام host متصل است.۴.۳. Trip Service:Trip Service مخزن تمام اطلاعات مرتبط با سفرهاست. این سرویس روی یک پایگاه داده MySQL Trips DB و یک Cassandra قرار دارد.MySQL اطلاعات مربوط به سفرهایی که در شُرف شروع یا در حال انجام هستند را نگه می‌دارد.زمانی که سفر به پایان می‌رسد، اطلاعات به Cassandra منتقل می‌شود. دلیل استفاده از دو نوع دیتابیس این است که اگر فقط از MySQL استفاده شود، حجم داده‌ها بسیار زیاد می‌شود. اطلاعات سفر فعال که نیاز به به‌روزرسانی دارد در MySQL نگهداری می‌شود، اما پس از اتمام سفر، توسط یک Trip Archiver (یک Job زمان‌بندی‌شده) به Cassandra منتقل می‌شود. Trip Service همچنین APIهای مربوط به سفر را ارائه می‌دهد.۴.۴. Cab Request Service و Cab Finder Service:زمانی که کاربر می‌خواهد یک تاکسی رزرو کند، این فرآیند توسط Cab Request Service آغاز می‌شود. این سرویس برای رزرو تاکسی و دریافت اطلاعات مربوط به تاکسی رزروشده، با Cab Finder Service در ارتباط است. Cab Request Service درخواست سفر را با موقعیت مبدا و مقصد از اپلیکیشن مشتری دریافت می‌کند.Cab Finder مختصات موقعیت مبدا کاربر را از Map Service دریافت می‌کند تا Segment آن نقطه و Segmentهای اطراف را بررسی کرده و راننده‌هایی که به مشتری نزدیک‌تر هستند را پیدا کند.Cab Finder همچنین مفهوم "mode" را پیاده‌سازی می‌کند (مثلاً کاربر Premium یا کاربر معمولی). اطلاعات موردنیاز برای تشخیص راننده مناسب، از طریق ماژولی به نام Driver Priority Engine تأمین می‌شود که راننده‌ها را بر اساس نیاز آن mode رتبه‌بندی می‌کند.پس از انتخاب مناسب‌ترین راننده، Cab Finder به WebSocket Manager پیام می‌دهد تا راننده از طریق WebSocket Handler مربوطه از سفر مطلع شود. همزمان، کاربر نیز از طریق Cab Request Service مطلع می‌شود.پس از اختصاص راننده، Cab Finder با Trip Service ارتباط می‌گیرد تا سفری جدید ثبت شود.۴.۵. سیستم تطبیق راننده و مسافر (Dispatch System - DISCO):اوبر برای تطبیق تقاضا (مسافران) و عرضه (رانندگان) از سیستمی به نام DISCO استفاده می‌کند که مصرف سوخت را کاهش، زمان انتظار را کمینه و ETA کلی را به حداقل می‌رساند.سرویس عرضه (Supply Service): هر خودرو موقعیت مکانی خود را هر ۴ ثانیه به سرور ارسال می‌کند. اطلاعات از طریق Load Balancer و Web Application Firewall به سرور منتقل می‌شود. Kafka REST API به عنوان مرکز داده عمل می‌کند و داده‌ها را به حافظه، دیتابیس و DISCO منتقل می‌کند.سرویس تقاضا (Demand Service): درخواست کاربر از طریق WebSocket ارسال می‌شود. مکان کاربر با GPS شناسایی شده و نیازهای او (مثلاً نوع خودرو) ثبت می‌شود.الگوریتم تطبیق: شناسه سلول (Cell ID) به عنوان کلید Shard استفاده می‌شود. Consistent Hashing برای تقسیم مسئولیت بین سرورها انجام می‌شود. نزدیک‌ترین راننده‌ها با در نظر گرفتن سیستم جاده‌ای (نه صرفاً موقعیت جغرافیایی) از طریق ETA محاسبه و رتبه‌بندی می‌شوند. سیستم به سادگی با افزودن سرورهای جدید در شهرهای تازه توسعه می‌یابد.۴.۶. ساخت نقشه و محاسبه ETA:همانطور که گفته شد اوبر در گذشته از Mapbox استفاده می‌کرد اما بعدها به Google Maps API مهاجرت کرد.Trace Coverage: تطابق مسیرهای GPS گذشته با جاده‌ها برای شناسایی مسیرهای ناقص یا اشتباه.Preferred Access Points: تعیین دقیق‌ترین نقاط سوار شدن در مکان‌های خاص (مثل فرودگاه) با استفاده از الگوریتم‌های یادگیری ماشین.محاسبه ETA: برای اوبر حیاتی است زیرا روی درآمد و تجربه کاربر تأثیر مستقیم دارد. از داده GPS رانندگان برای پیش‌بینی ترافیک استفاده می‌کند. شبکه جاده‌ای به صورت گراف (تقاطع‌ها نودها و مسیرها یال‌ها) مدل‌سازی می‌شود. از الگوریتم Dijkstra یا OSRM برای محاسبه سریع‌ترین مسیر استفاده می‌شود.۴.۷. خدمات (Services):Customer Service: اطلاعات و احراز هویت کاربران.Driver Service: اطلاعات و احراز هویت رانندگان.Payment Service: مدیریت پرداخت‌ها.Notification Service: ارسال اعلان‌ها.۴.۸. سیستم Analytics و Machine Learning (Kafka, Spark, Hadoop, Michelangelo):Kafka: به صورت مداوم در حال دریافت Eventهایی مانند موقعیت مکانی، رزرو شدن یا نشدن تاکسی، به‌روزرسانی‌های سفر و... است. Cab Finder نیز یک event در Kafka قرار می‌دهد تا ثبت کند که آیا راننده‌ای برای سفر پیدا شده یا نه، و از این اطلاعات برای تحلیل‌ها استفاده می‌شود.Payment Service (در Analytics): یک Payment Service بر روی Kafka قرار دارد که به Event تکمیل سفر گوش می‌دهد. به محض تکمیل سفر، بر اساس مسافت، زمان و غیره، مبلغ پرداختی محاسبه شده و در یک Payment MySQL DB ذخیره می‌شود. در صورتی که روش پرداخت نیاز به درگاه داشته باشد، این سرویس به یک Payment Gateway متصل می‌شود.Spark Streaming Cluster و Hadoop Cluster: اسپارک Streaming Cluster Eventهای پایه (مثل "راننده پیدا نشد" ) را بررسی می‌کند و همه Eventها را در یک Hadoop Cluster ذخیره می‌کند تا تحلیل‌های پیشرفته‌تری انجام شود.از این داده‌ها برای پروفایلینگ کاربر و راننده، رتبه‌بندی راننده‌ها و اجرای Fraud Engine (موتور کشف تقلب) استفاده می‌شود. همچنین برای به‌دست آوردن اطلاعات ترافیکی و بهبود Map Service نیز کاربرد دارند.اوبر ابزار اختصاصی خود با نام LIDAR (Ledger of Interactive Data Analysis) را توسعه داده است که ترکیبی از Jupyter Notebook با Apache Spark و پلتفرم داده داخلی اوبر است.پلتفرم یادگیری ماشین Michelangelo: در سال ۲۰۱۵، اوبر پلتفرم یادگیری ماشین خود با نام Michelangelo را معرفی کرد. این پلتفرم جامع برای ML و AI، تمام مراحل چرخه ML را پوشش می‌دهد: مدیریت داده، آموزش مدل، ارزیابی، پیش‌بینی، استقرار مدل و مانیتور پیش‌بینی‌ها. در سال ۲۰۲۵، Michelangelo وظایف پیشرفته‌تری مانند مدل‌سازی‌های Generative AI را نیز پشتیبانی می‌کند، از جمله پیش‌بینی تقاضا، قیمت‌گذاری پویا و تحلیل رفتاری کاربران و رانندگان.لاگ‌برداری در Backend و پردازش آفلاین داده: سیستم‌های Backend اوبر، تعاملات کاربر را ثبت و تحلیل می‌کنند. این داده‌ها سپس در فرآیندهای آفلاین پردازش شده و تبدیل به مدل‌هایی قابل استفاده برای تصمیم‌سازی و تحلیل رفتار کاربران می‌شوند.تحلیل داده: از تحلیل اثر تخفیف‌ها تا پیش‌بینی بازگشت سفرهای فرودگاهی، تحلیل داده در اوبر امکان پیش‌بینی تقاضا، تشخیص روندها و شخصی‌سازی خدمات را فراهم کرده است.۴.۹. مقابله با خرابی مراکز داده:در صورت خرابی مرکز داده اصلی، اوبر از گوشی راننده به عنوان منبع داده پشتیبان استفاده می‌کند. سیستم از طریق ارسال یک State Digest رمزنگاری‌شده به اپ راننده، اطلاعات سفر را حفظ می‌کند. مرکز پشتیبان از اپ راننده Digest را دریافت کرده و با آن به‌روز می‌شود.۵. قابلیت اطمینان (Reliability)از دیدگاه مهندسی، اوبر تلاش می‌کند که تجربه اصلی سفر در اوبر با دسترسی‌پذیری ۹۹.۹۹% همراه باشد. این یعنی فقط یک ساعت خاموشی در کل سال، یا یک دقیقه در هفته. برای رسیدن به این هدف، معماری جدید یک چارچوب "core" و "optional" برای کد تعریف کرد.کدهای Core: شامل تمام بخش‌های حیاتی مانند ثبت‌نام، آغاز سفر، پایان سفر یا لغو آن هستند و باید همیشه اجرا شوند. این کدها تحت بازبینی شدید قرار می‌گیرند.کدهای Optional: می‌توانند بدون لطمه به عملکرد اصلی، غیرفعال شوند و بازبینی سبک‌تری دارند. این تفکیک باعث می‌شود ویژگی‌های جدید تست شوند و در صورت مشکل، به سرعت غیرفعال شوند بدون اینکه تجربه سفر مختل شود.۶. Riblets؛ معماری جدید اپ مسافر اوبرمعماری موبایلی اولیه اوبر بر پایه MVC (Model-View-Controller) بود. با رشد اپ و بزرگ‌تر شدن تیم، MVC پاسخ‌گو نبود. مشکلات اصلی شامل Controllerهای حجیم (که مسئول همه‌چیز بودند) و فرآیند آپدیت شکننده به دلیل استفاده از if-elseهای تو در تو برای آزمایش قابلیت‌های جدید بود. الگوی VIPER به عنوان یک مسیر میانی، سطح انتزاع بیشتری ارائه می‌داد. اما VIPER نیز مشکلاتی داشت: ساختار iOS-محور آن برای Android کارایی کمتری داشت و تفکیک کامل بین منطق تجاری و نمایشی در آن سخت بود. اوبر برای حل این مشکلات، الگوی اختصاصی خود به نام Riblets را ابداع کرد.الگوی Ribletsویژگی‌های Riblets:منطق به قطعات کوچک و تست‌پذیر تقسیم می‌شود.هر Riblet تنها یک وظیفه دارد (اصل Single Responsibility).ساختار اپ یک درخت از Ribletهاست.تفاوت اصلی Riblets با VIPER در این است که در Riblets، رُوتینگ بر پایه منطق تجاری است، نه منطق نمایشی.معماری جدید اوبر سازگار با هر دو پلتفرم iOS و Android طراحی شد تا توسعه‌دهندگان بتوانند بر بستر مشترک همکاری کنند.اجزای Riblet و مسئولیت‌ها:Builder: ساختن Riblet و تعریف وابستگی‌ها.Component: فراهم کردن سرویس‌ها و data streamهای مورد نیاز Interactor.Router: متصل و جدا کردن Ribletهای فرزند؛ فعال/غیرفعال‌سازی Interactor.Interactor: اجرای منطق تجاری مانند درخواست سفر یا واکشی داده. مالک وضعیت (state) و منطق تجاری مربوط به محدوده‌ی خودش است. درخواست‌هایی به سرویس‌ها می‌فرستد تا داده دریافت کند.Presenter: ترجمه داده بین Interactor و View.View (Controller): نمایش UI، تعامل با کاربر، دریافت ورودی و نمایش داده.جریان داده در Ribletهاجریان داده درون یک Riblet:داده‌ها فقط در یک جهت حرکت می‌کنند: Service → Model Stream → Interactor. مدل‌ها Immutable (تغییرناپذیر) هستند. یعنی Interactor باید برای اعمال تغییرات، فقط از طریق لایه سرویس اقدام کند.از Backend به View: داده وضعیت سفر از سرویس دریافت می‌شود، روی مدل استریم قرار می‌گیرد، Interactor آن را دریافت کرده و به Presenter ارسال می‌کند، سپس Presenter آن را برای View قالب‌بندی می‌کند.از View به Backend: کاربر روی دکمه‌ای کلیک می‌کند. View این رویداد را به Presenter می‌دهد، Presenter متد مربوطه را روی Interactor فراخوانی می‌کند، و در نهایت Interactor یک درخواست به سرویس ارسال می‌کند.ارتباط بین Reibletهاارتباط بین Riblet‌ها:هنگامی که یک Interactor تصمیم تجاری می‌گیرد، ممکن است نیاز داشته باشد داده‌ای را به Riblet دیگر ارسال کند یا رویدادی را اطلاع دهد. برای این کار، Interactor تصمیم‌گیرنده یک interface را فراخوانی می‌کند که توسط Interactor Riblet مقصد پیاده‌سازی شده است.به سمت بالا (parent): از listener استفاده می‌شود (تقریباً همیشه توسط والد پیاده‌سازی می‌شود).به سمت پایین (child): از delegate استفاده می‌شود (توسط فرزند پیاده‌سازی می‌شود و معمولاً برای ارتباط مستقیم و هم‌زمان است). راه‌حل بهتر برای ارتباط به سمت پایین، استفاده از observable stream است. والد می‌تواند یک stream را به فرزند بدهد تا اطلاعات را دریافت کند. این روش توصیه‌شده برای ارسال داده از والد به فرزند است.دستاوردها با Riblets:افزایش دسترسی‌پذیری تجربه اصلی: Ribletها وظایف تفکیک‌شده و مشخصی دارند، بنابراین تست آن‌ها آسان‌تر است. هر Riblet به صورت مستقل تست می‌شود که اطمینان بیشتری در به‌روزرسانی و پایداری برنامه فراهم می‌کند. جداسازی Ribletهای حیاتی از کد اختیاری، امکان بازبینی سخت‌گیرانه‌تری را برای بخش‌های حیاتی فراهم کرد. همچنین، قابلیت rollback سراسری به وضعیت پایدار برای جریان اصلی فراهم شد. همه کدهای optional تحت feature flag هستند و در صورت مشکل، به راحتی می‌توان آن‌ها را غیرفعال کرد و تنها به core flow برگشت.بستر مناسب برای توسعه آینده: Ribletها امکان جداسازی روشن منطق تجاری و نمایشی را فراهم کردند. معماری جدید platform-agnostic است که به توسعه‌دهندگان iOS و Android کمک می‌کند از اشتباهات یکدیگر درس بگیرند و راحت‌تر همکاری کنند. تست و پیاده‌سازی قابلیت‌های جدید ساده‌تر شده است، زیرا می‌توان آن‌ها را به صورت plugin در قالب Ribletهای اختیاری اضافه کرد. این ساختار باعث می‌شود توسعه برنامه در سال‌های آینده نیز ساده بماند.۷. مدیریت و ذخیره‌سازی داده‌هااوبر از مجموعه متنوعی از پایگاه‌های داده برای مدیریت حجم عظیم داده‌های خود استفاده می‌کند. در ابتدا از PostgreSQL استفاده می‌کرد اما به دلیل مشکلات مقیاس‌پذیری به ترکیبی از دیتابیس‌ها مهاجرت کرد.MySQL: برای تراکنش‌های آنلاین با ساختار رابطه‌ای. همچنین برای User DB، Driver DB و Trips DB (برای سفرهای فعال) استفاده می‌شود.Cassandra: برای اپلیکیشن‌های RealTime (NoSQL توزیع‌شده). برای ذخیره اطلاعات موقعیت راننده و همچنین برای آرشیو سفرهای کامل‌شده.Redis: برای کشینگ توزیع‌شده و همچنین برای کش اطلاعات User Service، Driver Service، و پایش اتصال راننده‌ها به WebSocket Handlerها.HDFS (Hadoop Distributed File System): برای ذخیره آفلاین داده‌های حجیم.AWS, Google Cloud, Azure: به عنوان ذخیره‌سازی ابری.Hive: برای تحلیل داده‌های کلان در سطح سازمانی.آماده‌سازی زیرساخت (Infrastructure Provisioning): اوبر از Terraform برای مدیریت Infrastructure as Code (IaC) استفاده می‌کند که فرآیند استقرار را تسریع و خطای انسانی را کاهش می‌دهد.ساخت تصاویر کانتینری (Container Images): اوبر از ابزار اختصاصی uBuild (معرفی‌شده در سال ۲۰۱۵) برای ساخت تصاویر کانتینری امن، سازگار و بهینه‌شده استفاده می‌کند.بهینه‌سازی عملکرد پایگاه داده با CacheFront:Docstore، پایگاه داده توزیع‌شده اوبر، توان پردازش ده‌ها میلیون درخواست در ثانیه را دارد. برای بهبود تأخیر (Latency) و کاهش هزینه، CacheFront طراحی شد که مکانیزم کش را در لایه کوئری پایگاه داده Docstore ادغام می‌کند.CacheFront از تکنیک‌هایی مانند Timeout تطبیقی، Negative Caching، Cache Warming و ابزار Redis به عنوان کش توزیع‌شده استفاده می‌کند.به لطف CacheFront، نرخ Cache Hit در اوبر به ۹۹.۹٪ رسیده و بیش از ۴۰ میلیون درخواست در ثانیه بدون فشار بر موتور ذخیره‌سازی پردازش می‌شود.دیتابیس اوبر۸. امنیت داده‌هاحفظ امنیت داده کاربران، یکی از اولویت‌های اصلی اوبر است. رویکرد امنیتی اوبر بر پایه‌ی رمزنگاری دقیق (Fine-Grained Encryption) بنا شده و شامل کنترل دسترسی دقیق، سیاست‌های نگهداری داده و رمزنگاری در حالت سکون (At Rest) است. اوبر همچنین از سیستم‌های شناسایی تهدید مبتنی بر هوش مصنوعی برای کشف و خنثی‌سازی تهدیدات احتمالی به‌صورت بلادرنگ استفاده می‌کند.کنترل دسترسی دقیق (Fine-Grained Access Control): اوبر از رویکرد ستون‌محور برای کنترل دسترسی استفاده می‌کند و دسترسی را تا سطح هر ستون تعیین می‌کند. از ویژگی‌های Apache Parquet برای اعمال محدودیت‌های دسترسی بر اساس برچسب‌های تعریف‌شده استفاده می‌کند.رمزنگاری در حالت سکون (Encryption at Rest): برای جلوگیری از دسترسی غیرمجاز، اوبر از رمزنگاری سطح ستون با استفاده از الگوریتم‌هایی مثل AES-GCM و AES-CTR بهره می‌برد.سیاست‌های نگهداری داده (Data Retention Policies): اوبر از سیاست‌های نگهداری پویا و انعطاف‌پذیر استفاده می‌کند که امکان حذف انتخابی داده‌ها بر اساس دسته‌بندی‌ها یا برچسب‌ها را فراهم می‌کند.توصیه‌های امنیتی برای کاربران: اوبر پیشنهاد می‌کند کاربران رمز عبور خود را به صورت دوره‌ای تغییر دهند، اطلاعات تماس خود را به‌روز نگه دارند، از به‌اشتراک‌گذاری اطلاعات ورود پرهیز کنند و از رمزهای متفاوت برای حساب‌ها استفاده نمایند.۹. بهره‌برداری از داده کاربران برای تصمیم‌سازی هوشمندداده کاربران موتور محرکه صنعت حمل‌ونقل اشتراکی است. این داده‌ها برای بهینه‌سازی نرخ تبدیل، شخصی‌سازی تجربه کاربر، تحلیل رفتار کاربران و طراحی راهکارهای ارتباطی هدفمند مورد استفاده قرار می‌گیرند.پردازش آفلاین دیتا در اوبراستانداردسازی لاگ‌ها (Logs): فرآیند ثبت لاگ‌ها در اپلیکیشن موبایل، طبق استانداردهای سخت‌گیرانه‌ای انجام می‌شود تا ثبات بین پلتفرم‌ها، رعایت حریم خصوصی و بهینه‌سازی مصرف شبکه تضمین شود.۱۰. معماری کانال گفت‌وگو در اوبر (Chat Channel Architecture)کانال چت اوبر، نمونه‌ای از تعهد به کارایی عملیاتی و تجربه کاربری ممتاز است. در سال ۲۰۲۵، اوبر از چت‌بات‌های مبتنی بر هوش مصنوعی برای پاسخ‌گویی به سوالات متداول و کاهش زمان پاسخ‌گویی استفاده می‌کند.کانال چت اوبرمراحل تحول:پایه‌گذاری: راه‌اندازی چت با WebSocket برای پیام‌رسانی بلادرنگ.تطبیق‌پذیری: بهره‌گیری از Apache Kafka برای مقیاس‌پذیری.بهینه‌سازی: استفاده از GraphQL Subscriptions و طراحی بدون وضعیت (Stateless) برای افزایش پایداری.آینده‌نگری: معماری‌های هیبریدی و پایگاه‌داده‌های Real-Time مانند Apache Cassandra برای پاسخ‌دهی سریع و شخصی‌سازی.۱۱. ساخت اجرایی (Runnable Artifact) و فعال‌سازی قابلیت‌هابرای توصیف کامل یک پیکربندی API در سیستم اوبر، فایل‌های YAML و Thrift تمام اجزا را شامل می‌شوند. Self-served Gateway مسئول آن است که این پیکربندی‌ها را کنار هم قرار دهد تا یک محیط اجرایی برای Gateway ایجاد کند.۱۱.۱. دو نوع Gateway:نوعی که پیکربندی‌ها را به صورت داینامیک دریافت کرده و APIها را بر اساس آن‌ها سرویس می‌دهد (مشابه ابزارهایی مانند Kong، Tyk یا reverse proxy هایی مثل Envoy و Nginx).نوعی که با استفاده از code generation، یک artifact قابل اجرا (build) ایجاد می‌کند.در اوبر، رویکرد دوم یعنی تولید کد (Code Generation) انتخاب شده است تا یک artifact اجرایی تولید شود.۱۱.۲. مراحل Code Generation:تولید اشیای schema: تمام فایل‌های schema توسط پردازنده‌هایی اجرا می‌شوند تا کد native در زبان Go برای thriftrw و protoc تولید شود. این کار برای serialization/deserialization و ایجاد رابط‌های کلاینت مورد نیاز است.تولید serialization اختصاصی: قراردادهای API با اپ‌های موبایل نیاز به serialization اختصاصی برای نوع‌های خاصی مانند i64، enum و پروتکل‌های مختلف دارند.گراف وابستگی‌ها (DAG): کدهای endpoint، کلاینت‌های backend و middlewareها به‌صورت static تولید می‌شوند. کلاینت‌ها مستقل‌اند و می‌توان بلافاصله تولیدشان کرد. Middleware ممکن است به صفر یا چند client وابسته باشد. Endpoint ها ممکن است به صفر یا چند middleware و حداکثر یک client وابسته باشند. این گراف جهت‌دار بدون حلقه (DAG) در زمان build حل می‌شود.اتصال بین پروتکل‌ها: چون کلاینت‌ها مستقل از endpointها تولید می‌شوند، یک endpoint می‌تواند HTTP باشد ولی backend آن gRPC. این نگاشت در مرحله‌ی build انجام می‌شود.تولید API: در این مرحله، گراف به ترتیب طی می‌شود تا تمام endpointها تولید شوند. برای هر endpoint قالب بارگذاری می‌شود، نگاشت بین درخواست endpoint و درخواست client (و بالعکس) تولید می‌شود، وابستگی‌ها تزریق می‌شوند، و شیء IDL با تغییرات درخواست-پاسخ، hydrate می‌شود.کل فرآیند Code Generation در یک کتابخانه‌ی متن‌باز اوبر به نام Zanzibar کپسوله شده است.۱۱.۳. چالش‌ها و درس‌های آموخته شده در توسعه Gateway:زبان برنامه‌نویسی: نسل قبلی Gateway با Node.js ساخته شده بود که برای لایه‌های I/O سنگین مناسب بود. اما در اوبر، به دلیل هماهنگی با تیم‌های داخلی، زبان Go انتخاب شد. اگرچه عملکرد بسیار خوبی داشت، ولی نبود Generics باعث شد حجم کد تولیدشده بالا برود، تا جایی که به محدودیت linker در Go برخورد کردند و مجبور شدند symbol table و اطلاعات debug را غیرفعال کنند. برخی قوانین نام‌گذاری در Go با Thrift ناسازگار بود که خطاهای عجیبی ایجاد می‌کرد.فرمت serialization: مدیر پروتکل در Gateway از چندین پروتکل پشتیبانی می‌کند. این موضوع باعث ایجاد ناسازگاری‌هایی میان JSON و Thrift در نگاشت Union، Set، List و Map شد. برای حل این مشکل، استانداردهای داخلی خاصی توسعه داده شد.پیکربندی پویا (Config Store): پیش‌تر، همه پیکربندی‌ها در Git نگهداری می‌شد، حتی پیکربندی‌های پویا مثل rate limit. این روش نیاز به Code Generation و Deploy داشت. اکنون بخش‌های پویا در یک Config Store ذخیره می‌شوند تا به‌روزرسانی سریع‌تر باشد.UI Gateway و درک Payload: توسعه API تکی در UI آسان است، اما در حالت batch یا زمانی که Thriftها تو در تو باشند، دشوار می‌شود. جداسازی build system از UI نیز نمایش خطاها را سخت می‌کند، پس حفظ قرارداد بین این دو حیاتی است. در برخی کاربردها نیاز به deserialize کردن payload وجود دارد که پیچیدگی سیستم build و بار اجرایی را افزایش می‌دهد. اگر پروتکل frontend و backend یکسان باشند، بهتر است فقط به header و verbها دسترسی داشته باشیم.۱۲. بهبود تجربه و ارتباط راننده و مسافرنمایش مقصد سفر به راننده پیش از قبول کردن سفر.اجرای طرح‌های تشویقی جدید برای پاداش به رانندگانی که تلاش بیشتری می‌کنند.تعامل فعال با رانندگان برای کاهش لغو سفرهای پذیرفته‌شده و ایجاد مشوق‌هایی برای حفظ کیفیت خدمات.تلاش برای پاسخ‌گویی سریع به وقایع غیرمنتظره، به‌منظور تضمین کیفیت بالا در تمام لحظات سفر.۱۳. تست‌های داخلی پیشنهادشده توسط تیم اوبراوبر برای اطمینان از عملکرد صحیح سیستم، تست‌های زیر را انجام می‌دهد:تست Functional (رزرو، لغو، پرداخت).تست بار و عملکرد (ترافیک بالا، Kafka، موقعیت GPS).تست یکپارچگی سرویس‌ها (Supply, Demand, Dispatch و Kafka).تست تحمل خطا و بازیابی (خرابی مرکز داده، بازیابی Digest).تست مکان‌یابی و الگوریتم‌های Dispatch (با S2 و OSRM).تست امنیتی (رمزنگاری، احراز هویت، API).تست تحلیل داده (Kafka، Hadoop، ElasticSearch).۱۴. مدل سطح بالای دیتاطراحی مدل دیتامعماری سیستم اوبر نمونه‌ای از مهندسی نوآورانه است که یکی از بزرگترین سیستم‌های حمل‌ونقل اشتراکی جهان را پشتیبانی می‌کند. این سیستم از یک معماری مونولیتیک اولیه به میکروسرویس‌ها و سپس به معماری دامنه‌محور (DOMA) تحول یافته است تا مقیاس‌پذیری، پایداری و انعطاف‌پذیری لازم را برای سرویس‌دهی به میلیون‌ها کاربر فراهم کند. اوبر با بهره‌گیری از تکنولوژی هایی مانند Node.js, React.js, GraphQL, Mapbox, Hadoop, Apache Spark, CacheFront, Docstore, Cassandra, Redis و پلتفرم هوش مصنوعی Michelangelo، توانسته تجربه‌ای یکپارچه، پایدار، مقیاس‌پذیر و کاربرپسند در همه‌ی پلتفرم‌ها ایجاد کند. معماری دامنه‌محور (DOMA) و یکپارچگی تحلیلی با داده‌های کلان، نه‌تنها کیفیت خدمات اوبر را تضمین کرده، بلکه به الگویی برای سایر شرکت‌های فناورانه تبدیل شده است.شمای کلی معماریاین مطلب، بخشی از تمرین های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع:https://netflixtechblog.com/introducing-impressions-at-netflix-e2b67c88c9fbhttps://dev.to/gbengelebs/netflix-system-design-backend-architecture-10i3https://medium.com/@narengowda/netflix-system-design-dbec30fede8dhttps://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749https://blog.bytebytego.com/p/a-brief-history-of-scaling-netflixhttps://dev.to/gbengelebs/netflix-system-design-how-netflix-onboards-new-content-2dlbhttps://netflixtechblog.com/title-launch-observability-at-netflix-scale-8efe69ebd653https://www.devlane.com/blog/spotify-a-deep-dive-into-their-tech-stackhttps://engineering.atspotify.com/2022/07/software-visualization-challenge-acceptedhttps://www.designgurus.io/answers/detail/discuss-spotify-system-architecturehttps://backstage.spotify.com/learn/backstage-for-all/architecture-and-technologyhttps://ujjwalbhardwaj.me/post/system-design-design-spotify-music-streaming-platform/https://medium.com/@ishwarya1011.hidkimath/system-design-music-streaming-services-64df330b5624https://www.codekarle.com/system-design/Uber-system-design.htmlhttps://www.uber.com/en-GB/blog/architecture-api-gateway/https://www.uber.com/en-FR/blog/new-rider-app-architecture/https://intellisoft.io/the-foundation-of-uber-the-tech-stack-and-software-architecture/https://www.clickittech.com/software-development/system-design-uber/https://www.geeksforgeeks.org/system-design/system-design-of-uber-app-uber-system-architecture/ Fatemeh Rafiee Fatemeh Rafiee Sat, 12 Jul 2025 17:15:29 +0330 https://virgool.io/@fatemehrafiee/%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-hjik7htsxanv در این جا به صورت خلاصه بررسی می کنیم که سند معماری نرم افزار (SAD) چه اهمیتی داره و چه موضوعاتی رو باید پوشش بده.در مهندسی نرم افزار غالبا وقتی صحبت از متدولوژی های چابک میشه، بحث نوشتن داکیومنت ها به آخرین اولویت تنزل پیدا می کنه. در حالی که متدولوژی های Agile این موضوع رو بیان نمیکنن که اسناد لازم نیستن، بلکه میگن باید روی اسناد مهم و کاربردی وقت گذاشته بشه، اون هم نه به این صورت که در ابتدای راه توسعه زمان زیادی رو صرف نوشتن اسناد کنیم و از کار اصلی، یعنی توسعه جا بمونیم. (مثل RUP که فاز بندی های نسبتا مجزایی داشت)سند معماری نرم افزار هم برخلاف بعضی از اسناد مربوط به طراحی و تحلیل یکی از اسناد مهم و کابردیه که عدم حضورش به پیشرفت کار به شکل جدی ضربه وارد میکنه چرا که به تعداد زیادی از ذینفعان و طیف گستردهای مربوط میشه. ولی اگر اصولی نوشته نشه، بود و نبودش عملا فرق زیادی نداره. یه نکته مهم در اسناد معماری، اینه که سند باید در کل فرایند توسعه، به روز باشه چون در غیر این صورت قابل استفاده نیست. از طرفی هم باید abstract و سطح بالا باشه و جزئیات در اون وارد نشه چرا که جزء اسناد بالا دستی محسوب میشه.نبود این سند (یا اصولی نبودنش) باعث میشه دانش ضمنی ای که در افراد تیم وجود داره، به مرور زمان از بین بره. به این مفهوم که به این ترتیب، معماری یک سامانه ممکنه به یک گروه خاصی وابستگی پیدا کنه و وقتی افراد جدید وارد سازمان میشن به اون گروه برای فهم سیستم نیاز دارن و اگر اون ها هم سازمان رو ترک کرده باشن، عملا باید reverse engineering انجام بگیره تا دلیل تصمیمات معماری مشخص بشه و یا دوباره از ابتدا طراحی انجام بشه. یا حتی ممکنه خود افراد اصلی که این تصمیم رو گرفتن هم بعد از مدتی نسبت به علت تصمیمات معماری که در گذشته اتخاذ کردن دچار فراموشی بشن.همچنین سند معماری به عنوان یک رابط بین stake holder های فنی و غیرفنی عمل میکنه و هر یک از این ذینفعان از یک بخش معماری بهره میبرن و در صورتی که این سند آپدیت باشه، افراد میتونن در صورت نیاز بهش رجوع کنن و تعاملات تیم ها با همدیگه آسون تر میشه، چون این سند در واقع مبنای توسعه قرار می گیره.لازم به ذکره که SAD عمدتا باید توسط افراد ارشد تیم، مثل معمار یا tech lead تنظیم بشه و صرفا در بخش های جزئی تر میشه از توسعه دهنده ها هم کمک گرفت.برای اینکه بتونیم راهکارهای معماری و تصمیماتی که اتخاذ میشه رو بررسی و توجیه کنیم (فضای راه حل)، ابتدا نیازه که نیازمندی ها (فضای مسئله) رو درست درک کرده باشیم چرا که معماری باید مناسب یک سیستم باشه. این نیازمندی ها هم میتونن functional باشن و هم non functional.نکته در خصوص ابزار پیاده سازی: از word و PDF و ابزارهای عام منظوره بهتره استفاده نشه و به جاش از confluence که یکی از سامانه های ویکی هست استفاده بشه.مدل های مختلفی برای نوشتن سند معماری نرم افزار وجود داره که یکی از ابتدایی ترین اون ها مدل 4 + 1 هست. که پنج نمای مختلف رو شامل میشه. یکی از این 5 نما، نمای use case هست که در بخش فضای مسئله وجود داره. فضای حل مسئله همچنین دو بخش دیگه هم داره: مقدمه و Quality Attribute ها. در بخش مقدمه که عموما کوتاه هست، اسکوپ کار و تعاریف و واژه ها و استانداردها و constraint ها آورده میشه.در بخش use case view هم معمولا functional requirement ها توصیف میشن، البته این کار برای تمام use case ها انجام نمیشه، چرا که در این صورت، سند معماری بسیار حجیم خواهد شد. بهتر هست که صرفا برای موارد کاربری کلان این کار انجام بشه. توجه داریم که وقتی use case کشیده میشه، باید به notation ها هم پایبند باشیم ولی برای شروع میشه اون ها رو به طور موقت نادیده گرفت. بعد از تعیین actor ها و روابط بین اون ها، به هر یوزکیس یک شناسه و عنوان هم اختصاص داده میشه و در نهایت، هر یوزکیس به یک actor نسبت داده میشه (assign میشه) و برای هر یک هم توصیفی در حد چند جمله داریم.برای این که سند SAD بیش از حد طولانی نشه، به توصیف تک تک موارد کاربری نمی پردازیم و به جای اون، یکی از کاربردها رو توضیح می-دیم یا یوزکیس ها رو گروه بندی می کنیم و هر گروه رو بررسی می کنیم.در ادامه ی فضای حل مسئله، باید ویژگی های کیفی سیستم هم بیان بشن. در حقیقت آوردن اسم QA کافی نیست، و باید معیار سنجش و همچنین بازه مطلوبش برای سیستم ما هم ذکر بشه. مثلا میانگین response time سامانه باید زیر 2 ثانیه باشه (جزو performance)فضای راه حل از 12 فصل تشکیل شده. البته تکمیل کردن این فصل ها به صورت چرخشی و تکاملی انجام میشه و نه به یکباره.1. نمای منطقی: شامل بلوک های اصلی سازنده سیستم و نحوه ارتباط بین اجزا و همچنین لایه ها.2. نمای استقرار: نمای فیزیکی سیستم، و شامل سرورها و کانتینرها و VMهاست. یکی از بخش های اصلیش هم جدول استقرار هست که البته اگر سامانه ای هنوز در نیمه های راه باشه، ممکنه جدول استقرارش نیمه تکمیل باشه.3. نمای process: شامل executable های محیط عملیاتی و mapping اون ها با سرورهاست. البته در یک جدول دیگر، ارتباط بین process ها هم بیان میشه. (پردازه مبدا و مقصد و پروتکل ها و …)توجه داریم که منظور از process در اینجا، processهای سیستم هست و نه فرایندهای بیزینسی سازمان.4. نمای پیاده سازی: شامل ماژول های اصلی که توسعه داده میشن، و ساختار پروژه ها و زیرپروژه ها و تصمیمات مربوط به توسعه و پیاده سازی.5. نمای تست: شامل تصمیمات کلان در زمینه تست (به ویژه اون هایی که روی معماری تاثیرگذارن) و همچنین تکنولوژی و رویکردهایی که برای تست به کار گرفته می¬شه.6. نمای log: شامل سطوح لاگ، ساختار و فرمت ثبت لاگ، سیستم های مدیریت لاگ، و KPIهایی که بدست میاد.7. نمای monitoring: شامل منابع (حافظه و CPU) و ابزارها (مثل پروموتئوس) و سناریوهای پایش هست.8. نمای داده: شامل تصمیمات مهم در زمینه دیتابیس ها و الگوریتم های به کارگرفته شده در لایه داده و دلیل استفاده از اون ها (مثل Cache, CQRS) و همچنین مدیریت متادیتا و بازیابی دیتا. تصمیمات مربوط به data integration و data migration هم در این بخش قرار می گیره.9. بخش Use case realization: برای حداکثر سه use case کلان و پرکاربرد، نشون میده مولفه ها چطور با هم تعامل دارن و روند اجرای کارها به چه ترتیبی ست. البته با نماهای process و منطقی هم ارتباط داره.10. تکنولوژی ها و ابزارها: به طور خلاصه هر تکنولوژی رو به همراه ورژن و جایگاه استفاده اش لیست می کنه.11. تصمیمات معماری: این فصل باید برای زمانی که کسی نیاز داشته باشه در زمان کوتاهی متوجه روند تغییرات در سیستم بشه، مناسب باشه و شامل تصمیم ها و دلایل انتخابشون و جایگزین های موجود باشه. این کار هم برای افرادی که جدید به تیم اضافه میشن مفیده و هم برای زمانی که خود شخص تصمیم گیر، فراموش کرده در گذشته چرا یک گزینه خاص رو انتخاب کرده. (به خصوص وقتی که یک تصمیم بدیهی نبوده باشه)12. بخش Technical debts: در این قسمت به صورت خلاصه، هر یک از ریسک ها و بدهی های فنی رو (به صورت جدا) لیست می کنیم و تاثیرش رو در صورت رخ دادن بررسی می کنیم و همچنین اولویت رسیدگی به اون رو هم مشخص می کنیم. این تصمیمات عمدتا بخاطر وقت، دانش، یا تجربه کم گرفته می شن.13. نمای Reporting: این قسمت شامل هر نوع ابزار و تکنیک و الگویی میشه که برای گزارش های تحلیلی لازم هست و همچنین mapping این گزارش ها با افراد و نقش ها.نکته:- گاهی اوقات بعضی نماها شبیه هم میشن و تفکیکشون سخت می شه (به خصوص در معماری میکروسرویس)- بین نمودارهای UML و نماها در معماری هیچ نگاشتی وجود ندارد و بسته به نیاز و کمک به فهم سیستم، تصمیم گرفته میشه که در کدوم نما، کدوم نمودار قرار بگیره. (نمودار خاصی برای هر فصل وجود نداره)- مشخص کردن معماری To-Be علاوه بر معماری As-Is این فرصت رو میده که gap ها رو شناسایی کنیم و سیستم رو راحت تر بهبود بدیم.- لایه منطقی و پیاده سازی در برخی پروژه ها به خاطر نزدیکی زیاد به هم، ممکنه ادغام بشن.یکی از شیوه های مستندسازی معماری، مدل C4 است که از 4 بخش system context, containers, components, code تشکیل شده، که به صورت سلسله مراتبی قرار می گیرن. این مدل عموما با ساخت دیاگرام، یک overview از کل پروژه نشون میده. برای کشیدن این نمودار معمولا، سه سطح اول کفایت می کنه و بهتره وارد سطح code نشیم چون اکثر اوقات فقط باعث overhead می شه. برای شروع هم کافی هست که با باکس های ساده آغاز کنیم که شامل اسم موجودیت و نوعش هست. استفاده از notation ها و رنگ ها صرفا باید به عنوان یک مکمل، به درک بهتر نمودارها کمک کنه و اگر با حذف اون ها، درک افراد دچار مشکل می شه، باید در انتخاب اسامی و توضیحات تجدید نظر کنیم.هر کدوم از بخش های مدل C4 یک سطح از انتزاع رو توصیف می کنن. ویوی Context یک بررسی اجمالی سطح بالا از سیستم و تعاملاتش با موجودیت های خارجی ارائه میده. نمای Container کمی زوم می کنه تا بتونه بلوک های سازنده اصلی مثل اپلیکیشن ها و دیتابیس ها رو نمایش بده. نمای Component وارد هر یک از کانتینرها میشه و اون ها رو به بخش های جزئی و کوچکتر تقسیم می کنه و روابط و مسئولیت های هریک رو بررسی می کنه. در نمای Code هم پیاده سازی جزئیات، کلاس ها و متدها یافت میشه. Fatemeh Rafiee Fatemeh Rafiee Tue, 13 May 2025 07:37:39 +0330 https://virgool.io/@fatemehrafiee/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-15-%D9%85%D9%81%D9%87%D9%88%D9%85-%D8%AF%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-xpekh2gespug Infrastructure as Code (IaC)یکی از مفاهیم مهم در معماری نرم افزار، بحث زیرساخت هست. IaC این امکان رو به مهندسان میده که به صورت غیردستی، زیرساخت رو مدیریت و تنظیم کنند. زیرساخت هم شامل سرورها، شبکه، دیتابیس و … میشه. به بیان ساده، با نوشتن script یا فایل های مربوط به configureation، این امکان فراهم میشه که زیرساخت config بشه و همچنین قابلیت استفاده مجدد هم فراهم میشه (Reusability). این اسکریپت معمولا به صورت فایل های yaml یا json نوشته میشه.همچنین دو نوع IaC وجود داره: Imperative و Declarativeدر نوع Imperative، تمرکز روی مشخص کردن نحوه رسیدن به یک state خاص هست ولی در کدهای Declarative، صرفا وضعیت نهایی مورد انتظار در زیرساخت نوشته میشه و از ابزارها خواسته میشه که به اون state برسند. طبیعی هست که در نوع دوم، وضعیت قبلی زیرساخت برای ابزارها مشخص هست و ازش اطلاع دارن. نوع Declarative احتمالا چالش های کمتری نسبت به Imperative داره ولی کاستومایز کردن در اون هم سخت تره. به همین دلیل استفاده از ترکیب این دو پیشنهاد میشه.همچنین IaC مزیت های زیادی داره از جمله اتومات کردن فرایند، داشتن version control، انعطاف پذیری، بالابردن سرعت و کاهش خطاهای انسانی و میتونه در پایپ لاین های CI/CD هم قرار بگیره.ابزارهای رایج برای IaC موارد زیر هستند:Terraform(Declarative), Cloud Formation, Ansible(Imperative), OpenToFu(Declarative), Puppet2. API Gateway & Service Meshاغلب در بحث ماکروسرویس ها، تعداد زیادی سرویس در سمت بک اند وجود دارد، API Gateway همان نقطه ابتدایی دسترسی به این سیستم هاست و مانند یک رابط بین کلاینت و سرویس عمل میکنه و زمانی که یک درخواست ارسال میشه، مسئول اینه که اون درخواست رو به سرویس مرتبطش ارجاع بده و اطمینان حاصل میکنه هر چیزی که وارد میشه، از policy و کانفیگ مورد نظر ما تبعیت میکنه. علاوه بر routing، گیت وی کارهای مربوط به احراز هویت، rate limiting و کش کردن رو هم برعهده دارد.ابزار های Gateway های رایج: NGINX، AWS API Gatewayتوجه داریم API Gateway در صورتی که به صورت مناسب طراحی نشه میتونه به یک single point of failure تبدیل بشه.مفهوم service mesh به API Gateway نزدیکه ولی service mesh لایه زیرساختیه که مسئولیت ارتباط داخلی سرویس ها با یکدیگر رو (با ایجاد یک پلتفرم centralized) بر عهده دارد و به بهینه سازی ارتباط بین اپلیکیشن ها کمک میکند به این صورت که برای هر سرویس، یک پروکسی به نام sidecar وجود داره (مثل Envoy) که اطمینان حاصل میکنه جریان ترافیک به صورت عادی برقراره. نکته مثبت service mesh اینه که لازم نیست هر بار یک ستاپ جدید ایجاد کنیم، همه این ها به صورت اتومات فراهم میشه، کافیه که وقتی capability های جدید اضافه میشه، سرویس ها بهش subscribe کنند. سرویس مش همچنین کارهایی مانند traffic routing, retry, circuit breaking رو انجام میده.از ابزارهای Service Mesh هم میتونیم به Istio, Linkerd اشاره کنیم.در نهایت API Gateway و Service mesh وجه اشتراک زیادی دارند، از جمله مدیریت ارتباط بین ماکروسرویس ها، افزایش امنیت (از طریق authentication و encrytion) و مدیریت ترافیک.3. CQRS:تکنیک CQRS یک پترن معماری ست که در اون، سرویس های مربوط به خوندن دیتا از سرویس های مربوط به ایجاد تغییر در دیتا، جداسازی میشه. بنابراین دو مدل برای دیتا وجود داره: مدل command و مدل Query. در مدل کامند، دستورات مربوط به آپدیت، ساخت و حذف وجود داره و در مدل کوئری، دستور خوندن از دیتابیس رو داریم.به این ترتیب performance و scalability سیستم بهتر خواهد شد. البته این تکنیک بیشتر در مواقعی کاربرد داره که workload عملیات خوندن و عملیات تغییر در دیتا با هم تفاوت زیادی داشته باشه.این روش به این خاطر مفیده که دیتابیس بهینه برای read و modification دیتا با هم تفاوت دارد. برای عملیات خوندن، دیتابیسی بهینه ست که نرمال نشده باشه و در نتیجه نیاز به join های زیادی نداشته باشیم. ولی برای ایجاد تغییرات، دیتابیس بهینه باید نرمال باشه.دو حالت در خصوص پیاده سازی CQRS وجود داره. این امکان وجود داره read model و write model رو داخل یک data store داشته باشیم. یا اینکه یک data store جداگانه برای نوشتن و یک data store برای خوندن داشته باشیم. در این حالت میتونیم از دیتابیس های متفاوتی برای هر یک استفاده کنیم. به عنوان مثال، میتوان از دیتابیس های NoSQL برای خواندن و از دیتابیس های Relational برای نوشتن استفاده کرد.4. Event-Driven Architecture:این دیزاین پترن، به نوعی در مقابل Request driven architecture قرار می گیرد. و نحوه کار آن به این صورت است که سرویس ها در آن به شکل مستقیم با یکدیگر ارتباط ندارند و مبنای تعامل آن ها با یکدیگر، از طریق event هاییه که رخ میده. تعدادی از کامپوننت های سیستم، آن هایی هستن که این Event ها رو تولید و منتشر می کنن. سایر کامپوننت ها نیز آن هایی هستن که مسئول پاسخ دادن به این Event ها می باشند. البته یک المان دیگر، به نام Event bus یا Message broker هم به عنوان واسط وجود داره که ایونت های مرتبط رو به دریافت کننده های مربوطه route میکنه. ابزارهایی مثل Kafka یا RabbitMQ نمونه هایی از ابزار این بخش هستند. به بیان دیگر، broker ها مثل یک هاب عمل میکنن و event consumerها برای دریافت انواع خاصی از پیام ها subscribe شون میکنن.مزیت این پترن اینه که کامپوننت ها نسبت به همدیگه، loosely coupled هستند و به این ترتیب Extensibility بالایی در سیستم خواهیم داشت. همچنین نوع ارتباطشون هم async هست.معماری publish/subscribe، Message Queue و Event Sourcing از انواع معماری Event-Driven محسوب میشن. به عنوان مثال وقتی در یک سیستم ثبت سفارش، کاربری خرید انجام میده، این اتفاق یک سیگنال به همه اجزا، اعم از محاسبه فاکتور، ارسال ایمیل یا پیامک، انبارداری و حمل و نقل ارسال می کنه و هر یک از این مصرف کننده ها با توجه به functionality خودش، به این پیام واکنش نشون میده.5. Serverless Architecture:این نوع معماری به سناریویی گفته میشه که مدیریت سرورها در زمان اجرای کد تحت کنترل ما نیست، بلکه کل عملیات مربوط به زیرساخت، مانند نگهداری و Scale کردن، توسط خود cloud provider انجام میشه. به بیان دیگه، سرور داریم ولی تحت نظارت مستقیم ما نیست. در عوض کاری که انجام میدیم، توسعه FaaS (همان Function as a service) است. این پلتفرم ها همچنین به صورت Pay as you go کار میکنن و بر اساس مدت زمانی که کد روی سرور اجرا شده هزینه داره.معماری serverless نیز به صورت event-based هست، یعنی درخواست های HTTP، آپلود کردن فایل، تغییر در db و موارد این چنینی باعث فراخوانی توابع میشن. این معماری از این جهت نسبت به ماشین های مجازی یا کانتینرها برتری داره که زمان خیلی کمتری رو برای آماده سازی نیاز داره (چند ثانیه در مقایسه با چند دقیقه) و همچنین scaling اش به شکل خودکار انجام میشه در حالی که در کانتینرها به پلتفرم هایی مثل کوبرنتیز نیاز داریم.پلتفرم های رایج Serverless مانند: AWS, Azure, Google.توجه داریم که در این معماری، مفاهیمی مثل cold start (یعنی طول کشیدن زمان بیشتری برای اجرا شدن یک تابع برای اولین بار یا بعد از مدت زمان زیادی غیرفعال بودن) و همچنین محدودیت concurrency نقش پررنگی دارند.6. API-first Approach:این روش به این مفهوم است که اولین چیزی که قبل از شروع کد مورد توجه و طراحی قرار می گیره، API ها هستن. در واقع با اولویت دادن به API، اون رو به عنوان بلوک های سازنده نرم افزار در نظر میگیرن. با ابزار مخصوص مانند Swagger و با حضور تیم های مختلف از جمله بک اند و فرانت اند و حتی QA، ساختار API طراحی و داکیومنت میشه و به این ترتیب مورد تایید همگی قرار میگیره. زمانی که ورودی ها و خروجی ها و status code های مربوط به یک endpoint از قبل مشخص شده باشن، هر یک از تیم ها میتونه به صورت موازی از اون استفاده کنه. این موضوع باعث افزایش سرعت توسعه و کاهش conflict ها در زمان integration میشه. همچنین تاثیر مثبتی رو تجربه توسعه دهنده (Developer experience) داره چرا که API ها از داکیومنت و ساختار خوبی برخوردارن.به طور مشخص تر، وقتی از ابتدا صرفا کد نوشته میشه و بعدا سراغ API میریم، سمت فرانت اند به بخش اندکی از دیتا دسترسی دارن و این موضوع تسک هایی که میتونن تکمیل کنن رو کمتر میکنه، در حالی که اگر از ابتدا یک API مشخص داشته باشیم، همه بخش های نرم افزار به دیتای واحد و جامعی دسترسی دارن.7. Domain Driven Design:طراحی Domain driven یک دیدگاه طراحی سیستمه که حوزه اصلی بیزینس رو به عنوان مرکز در نظر می گیره. به همین دلیل در این نوع دیزاین، باید بیزینس به خوبی مدل شه چرا که کد هم قراره به گونه ای نوشته شه که با مدل ذهنی افراد بیزینس اصلی منطبق باشه. یعنی در نهایت یک مدل مشترک بین افراد تکنیکال و بیزینسی ایجاد میشه که برای هر دو قابل درکه. این نوع طراحی چند مفهوم پایه ای داره:Domain: حوزه ای از فعالیت که نرم افزار ما روی آن تمرکز داره.ubiquitous language: توافق روی یک سری از واژه های مشخص.Entities: موجودیت هاValue object: یک آبجکتی که صرفا با مقداری که بهش داده میشه تعریف میشه و هویت مستقل نداره. (مثل شماره ها و آدرس ها)Aggregate: یک دسته از آبجکت های مرتبط با هم که با آن ها مثل یک واحد مجزا رفتار خواهد شدBounded context: تقسیم بندی هر دامنه از نرم افزار به بخش هایی که هر یک زبان، مدل، قوانین و داده های خاص خودش رو داره. (مثل بخش حساب کاربری، یا مدیریت محصول)از مزایای DDD میشه به همراستا بودن با بیزینس اشاره کرد و اینکه در اغلب مواقع، سیستم ها ماژولار و decoupled هستن و طبیعتا ارتباط بین توسعه دهندگان و domain expert ها رو هم بهتر میکنه. البته برای کاربردهایی در scale کوچک توصیه نمیشه چون در این صورت over head اش زیاد خواهد بود.8. Hexagonal architecture:معماری هگزاگونال که به معماری ports و adaptors هم شناخته میشه، هدفش جداسازی هسته اصلی بیزینس از لایه های خارجی مثل دیتابیس و API ها و UI هست و به نوعی منطق بیزینس رو نسبت به مسائل تکنیکال ایزوله میکنه. به این ترتیب core اصلی بیزینس اطلاعی درمورد فریمورک ها و دیتابیس ها و اجزاء فنی سیستم نداره و port ها تعیین میکنن که این هسته اصلی چگونه با دنیای بیرونی ارتباط برقرار کنه. Adapter ها نیز اجزایی هستند که پورت ها رو پیاده سازی می کنند مثل http controller یا kafkaهمچنین این پورت ها میتونن خارجی یا داخلی باشن (outbound, inbound) بسته به اینکه آیا توسط actor های خارجی برای صدا زدن اپلیکیشن اصلی استفاده میشن یا توسط اپ به کار گرفته میشن که با سرویس های خارجی ارتباط برقرار کنن.این نوع معماری testability را تا حد قابل توجهی آسون تر میکنه و همچنین سیستم رو loosely coupled میکنه چرا که میشه دیتابیس ها، API ها و سایر اجزاء رو بدون تغییر دادن هسته اصلی، جایگزین کرد.9. Event Sourcingالگوی Event Sourcing یک پترن معماریه که در اون ما استیت فعلی یا نهایی سیستم رو ذخیره سازی نمی‌کنیم به صورت مستقیم، بلکه یک زنجیره یه متوالی از اتفاقات که رخ دادن رو سیو می‌کنیم و هر زمانی که بخواهیم استیت فعلی سیستم رو متوجه بشیم باید اون ایونت‌ها رو کنار هم قرار بدیم (به نوعی از هر ترنزکشن لاگ گرفته می‌شه.)طبیعتاً این کار باعث میشه که دیباگ کردن و track کردن خطاها آسون‌تر بشه ولی نیاز به فضای ذخیره سازی بیشتری وجود داره به خاطر اینکه هیچ چیزی حذف یا overwrite نمیشه و هر یک از اتفاقات باید به زنجیره اتفاقات قبلی append بشن. درحالی که اگر از این پترن استفاده نشه، همون رکورد قبلی، هر دفعه آپدیت میشه.این الگو برای tracability و تحلیل رفتار بسیار مفیده چرا که در صورت کشف باگ، امکان بازسازی همون سناریو رو فراهم میکنه ولی از پیچیدگی بیشتری ممکنه برخوردار باشه و از طرفی هم حجم بالای داده ها چالش ایجاد کنه. البته برای حل مشکل حجم، میشه از تکنیک هایی مثل snapshot استفاده کرد، یعنی در پایان چرخه های مشخص از سیستم، وضعیت سیستم در آن لحظه ثبت بشه و از اون به بعد، مثل قبل عمل بشه. مثلا در یک فروشگاه لازم نیست برای محاسبه سود، هر دفعه تمام تراکنش ها از زمان تاسیس فروشگاه با هم تجمیع بشن؛ بلکه کافیه state مربوط به هفته پیش رو داشته باشیم و transaction های هفته جاری رو بر اون اعمال کنیم.10. Low-code/No-code platforms:این پلتفرم‌ها محیط توسعه‌ای هستند که به کاربرا این امکان رو میده که با کمترین مقدار کد زدن و با استفاده از رابط های گرافیکی و کارهایی مثل درگ اند دراپ یک اپلیکیشن توسعه بدن. در بعضی مواقع بخش low code مربوط می‌شه به وقتی که کسی می‌خواد customization پیشرفته‌ای داشته باشه ولی در خیلی از مواقع هم میشه بدون کد زدن و صرفا با انجام configuration، به خروجی مد نظر رسید. همچنین امکان اتصال به دیتابیس ها و وب سرویس ها و حتی deployment هم در برخی از این پلتفرم ها وجود دارد.از نکات مثبت این نوع پلتفرم‌ها development سریع هست، همچنین کاهش هزینه‌ها رو هم نتیجه میده و اینکه افرادی که لزوماً توسعه دهنده نیستن هم می‌تونن با این ابزارها کار کنن، مثل تیم مارکتینگ یا منابع انسانی. از طرفی هم به پروتوتایپ زدن کمک می‌کنه. ولی از سمت دیگه مشکلی مثل vendor lock-in داره و ما کنترل کمتری روی ابزاری که در دستمون هست داریم، بنابراین ممکنه scalability خوبی هم نداشته باشیم.به عنوان مثال، Webflow یکی از این ابزارهاست که برای ساخت وبسایت به کار میره یا از Glide برای ساخت اپلیکیشن موبایل می توان استفاده کرد.11. Business Process Management Systems (BPMS):مفهوم BPMS یک پلتفرم نرم‌افزاری که این امکان رو میده تا فرایندهای بیزینسی طراحی اجرا و مانیتور بشن. تنها فایده اون مربوط به اتومیشن نیست، باعث افزایش بهره وری و بهبود فرایندها میشه.در کل خود یک فرایند بیزینسی مجموعه‌ای از گام‌ها و تسک‌ها هستش که با ترتیب خاصی انجام میشن تا یک هدف بیزینسی محقق بشه، مثل فرایند اعطای وام یا دریافت خسارت از بیمه.کارهایی که یک BPMS می‌تونه انجام بده شامل این موارد هست: مدل کردن اجرا سازی خودکار فرایندها، مانیتورینگ، بهینه سازی و تشخیص bottleneck و تخصیص تسک به افراد. این سیستم همچنین قابلیت integrate شدن با سایر ابزارها مثل ERP و CRM رو داره.مشکل vendor lock in و همچنین overhead و پیچیدگی در اینجا هم دیده می‌شه.از جمله نمونه‌های این ابزار:Appian و Bizagi و Bonita12. Message Queue (such as Kafka and RabbitMQ):مکانیزم Message queue یک روش برقراری ارتباط که اجازه میده تبادل پیام به صورت asyncronous بین قسمت‌های مختلف یک سیستم (کامپوننت ها یا میکروسرویس ها) انجام بشه که باعث میشه از لحاظ زمانی decouple بشن.یعنی فرستنده و دریافت کننده لزومی نداره که در یک زمان با هم تعامل داشته باشند و دریافت کننده حتی لازم نیست که اطلاع داشته باشه چه کسی پیام رو ارسال کرده. به جای این کار، اجزای سیستم پیام ها رو به یک صف می فرستن و مصرف کننده ها پیام ها رو دریافت می کنن.غیر از ایزوله سازی و ایجاد استقلال بین تولید کننده پیام و دریافت کننده یکی دیگر از فواید این مکانیزم، scalability و پردازش آسانکرونه. مواردی که مسیج کیو در اون‌ها بیشتر کاربرد داره شامل فرایند‌های ارسال و دریافت ایمیل یا SMS در تعداد بالا یا پردازش ویدیو بعد از آپلوده.نحوه کار هم به این صورت که ایجاد کننده پیام یک پیام رو به صف ارسال می‌کنه و سپس message broker اون رو ذخیره می‌کنه و دریافت کننده پیام بعداً پیام رو از داخل صف برمی‌داره.چند نوع الگوی پیام رسانی مختلف هم وجود داره: Point to point, work queues, publish subscribeهمچنین معمولا در مواقعی که صرفا می خوایم از صف استفاده کنیم RabbitMQ جوابگو هست ولی اگر به history نیاز داشته باشیم یا بخوایم داده ها به چند مصرف کننده ارسال بشن، Kafka گزینه مطلوب تریه و اغلب برای رویدادهای سنگین تر به کار میره.13. Container orchestration (such as Kubernetes):مفهوم Container orchestration به مدیریت خودکار کانتینرها گفته می‌شه مثل اجرا کردن و اسکیل کردن اون‌ها به خصوص زمانی که تعداد زیادی کانتینر در سرورها وجود داره.به طور مثال اگر فرض کنیم که ۱۰ تا میکرو سرویس داشته باشیم که هر کدومشون در چند کانتینر در حال اجرا شدن هستند فرایندهای اجرا و پایان هر کدوم و همچنین آپدیت کردن اون‌ها بدون down time اگر به صورت دستی بخواد صورت بگیره خیلی چالش برانگیزه.فانکشن‌های اصلی که kubernetes انجام میده شامل:برنامه‌ریزی زمان اینکه کدوم کانتینر روی کدوم سرور اجرا بشه، کانتینرهایی که کرش کردن restart بشن یا جایگزین بشن، تعداد کانتینرها بر اساس درخواست کم یا زیاد بشه، نرم‌افزارها با کمترین زمان down time آپدیت بشن، همچنین کانتینرها قابلیت برقراری ارتباط با همدیگه رو داشته باشن.چند مفهوم در کوبرنتیز:به کوچک‌ترین واحد در کوبرنتیز پاد گفته میشه و معمولاً به هر پاد یک کانتینر اختصاص داده می‌شه.نود (node) به یک سرور گفته میشه که در اون پادها ران میشن. به گروهی از نودها هم کلاستر گفته می‌شه.14. Multi-Tenancy Architecture:پترن Multi-tenancy یک الگوی معماری نرم‌افزاره که در اون یک نمونه از اپلیکیشن و زیرساختش مصرف کننده‌های زیادی رو تامین می‌کنه هر کدوم از اون مصرف کننده‌ها فکر می‌کنه که داره از اپ خصوصی خودش استفاده می‌کنه و می‌تونه دیتای مخصوص خودش رو داشته باشه ولی در واقعیت همه این مصرف کننده‌ها دارن از یک بکند یکسان استفاده می‌کنن.این نوع معماری چند تایپ مختلف داره:1. اپ و دیتابیس مشترک به نحوی که همه مصرف کننده‌ها از یک اپ و دیتابیس استفاده می‌کنن2. نوعی که در اون اپ مشترک ولی دیتابیس جدا هستدر نوع single tenancy هم اپ و هم دیتابیس جدا هستن.در چنین اپلیکیشن‌هایی هر دو مصرف کننده به صورت مستقل از برنامه استفاده می‌کنند ولی کد و بکند مشترکه. دیتای کاربران مانند permissionها و تسک‌ها امن و ایزوله ست.از مزایای این نوع معماری کاهش هزینه‌هاست به این دلیل که منابع زیرساختی کمتری استفاده می‌شه و به خاطر اینکه فقط یک کد بیس وجود داره نگهداری ازش راحت‌تره. فرآیند on boarding هم سریع‌تره به خاطر اینکه nodeهای جدید می‌تونن بدون نیاز به ایجاد تغییر در زیرساخت اضافه بشن.اکثر اپ‌هایی که امروز باهاشون سروکار داریم از این نوع معماری پیروی می‌کنند مثل جیمیل و zoom15. Enterprise Integration Patterns:الگوهای Enterprise integration یک دسته از دیزاین پترن‌ها هستند که روش‌های مرسومی رو توصیف می‌کنن که چند سیستم نرم‌افزاری رو از طریق پیام‌ها با هم integrate میکنه و به زبان ساده تر، مجموع الگوهایی که برای حل مشکلات ارتباط بین سیستم های مختلف در سازمان ها به کار میره.دلیل اهمیت این الگوها این هست که سیستم‌ها باید بتونن با هم دیتا تبادل کنن و با همدیگه کار کنن، در حالی که distributed هستند و توسط تیم‌های مختلفی توسعه داده شدن. EIP باعث ایجاد یه زبان مشترک بین دولوپر و معمار و تحلیلگر میشه.ما نمی‌تونیم یه فانکشن رو به صورت عادی در سیستم صدا بزنیم؛ به طور مثال integrate کردن سیستم‌های ecommerce و ERP و CRM نیاز به هماهنگی بیشتری داره.همچنین چند مفهوم کلی در EIP داریم: زیرساخت انتقال پیام که شامل این موارده: پیامی که رد و بدل می‌شه و مثلاً می‌تونه در فرمت json باشه، یکی کانالی هستش که در اون پیام تبادل می‌شه که می‌تونه Kafka یا RabbitMQ باشه، و یک مسیج روتر. ساختار پیام ها که میتونه به صورت Command، یا ثبت یک رخداد باشه. البته گاهی اوقات نیازه که فرمت پیام دچار تغییر بشه (بخاطر ایجاد سازگاری بین دو سیستم)مراجع:https://www.spiceworks.com/tech/devops/articles/what-is-serverless/https://redis.io/glossary/domain-driven-design-ddd/https://www.crowdstrike.com/en-us/cybersecurity-101/cloud-security/serverless-architecture/https://www.spiceworks.com/tech/tech-general/articles/event-driven-architecture/https://www.postman.com/api-first/https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-drivenhttps://www.kurrent.io/blog/snapshots-in-event-sourcinghttps://www.solo.io/topics/service-mesh/service-mesh-vs-api-gatewayhttps://www.contentful.com/blog/what-is-api-first/https://www.datadoghq.com/knowledge-center/serverless-architecture/www.youtube.com/watch?v=efRu7odnEQohttps://www.youtube.com/watch?v=zpAA1t5AeLwhttps://www.youtube.com/watch?v=hUVBT7wA6Kwhttps://www.youtube.com/watch?v=i2eVTk2Fb40 Fatemeh Rafiee Fatemeh Rafiee Fri, 09 May 2025 10:32:09 +0330