مرور سه نمونه معماری موفق و معروف ( آمازون ، گوگل ، نتفلیکس)

بررسی برخی از معماری ها

در این قسمت ابتدا برخی از معماری های متدول را توضیح میدهیم و بعد وارد بررسی معماری های شرکت های مختلف می شویم

معماری یونیکرنل (Unikernel)

معماری یونیکرنل (Unikernel) یک معماری سیستم عامل است که بر اساس مفهوم کرنل مجازی (virtual kernel) ساخته شده است. کرنل مجازی یک نوع کرنل است که به جای اینکه یک برنامه کامل باشد، فقط یک مجموعه کوچک از توابع ضروری را برای اجرای یک برنامه کاربردی فراهم می کند.

معماری یونیکرنل مزایای زیادی نسبت به معماری های سنتی سیستم عامل دارد، از جمله:

سادگی و کارایی: معماری یونیکرنل بسیار ساده تر از معماری های سنتی است، زیرا فقط یک مجموعه کوچک از توابع را اجرا می کند. این امر منجر به بهبود کارایی و امنیت می شود.

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

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

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

ایمنی:معماری یونیکرنل از نظر امنیتی بسیار ایمن تر از معماری های سنتی است، زیرا فقط یک برنامه کاربردی را اجرا می کند. این امر خطر حملات امنیتی را کاهش می دهد.

در یک سیستم عامل سنتی، تمام برنامه های کاربردی در یک فضای واحد اجرا می شوند. این امر به مهاجمان اجازه می دهد تا از یک برنامه کاربردی آسیب پذیر برای حمله به سایر برنامه های کاربردی استفاده کنند.

در یک سیستم عامل یونیکرنل، هر برنامه کاربردی در یک فضای جداگانه اجرا می شود. این امر به مهاجمان اجازه نمی دهد تا از یک برنامه کاربردی آسیب پذیر برای حمله به سایر برنامه های کاربردی استفاده کنند.

انعطاف پذیری:معماری یونیکرنل بسیار انعطاف پذیر است، زیرا می تواند برای اجرای طیف گسترده ای از برنامه های کاربردی استفاده شود.

سیستم عامل های سنتی معمولاً برای اجرای برنامه های کاربردی خاص طراحی شده اند. به عنوان مثال، یک سیستم عامل لینوکس برای اجرای برنامه های کاربردی مبتنی بر هسته لینوکس طراحی شده است.

معماری یونیکرنل می تواند برای اجرای طیف گسترده ای از برنامه های کاربردی استفاده شود، از جمله برنامه های کاربردی مبتنی بر لینوکس، برنامه های کاربردی مبتنی بر ویندوز، برنامه های کاربردی وب، و برنامه های کاربردی موبایل.

برخی از معایب این معماری عبارتند از:

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

علاوه بر این، توسعه دهندگان باید بتوانند برنامه کاربردی را به گونه ای طراحی کنند که با محدودیت های سیستم عامل یونیکرنل سازگار باشد. این امر می تواند چالش برانگیز باشد، زیرا برنامه کاربردی باید از منابع سیستم عامل به طور کارآمد استفاده کند و از آسیب پذیری های امنیتی جلوگیری کند.

محدودیت های عملکردی: سیستم عامل های یونیکرنل ممکن است از نظر عملکردی محدود باشند، زیرا فقط برای اجرای یک برنامه کاربردی خاص طراحی شده اند. این امر به این دلیل است که سیستم عامل یونیکرنل باید توابعی را فراهم کند که برای اجرای برنامه کاربردی خاص ضروری هستند.

به عنوان مثال، یک سیستم عامل یونیکرنل که برای اجرای یک برنامه کاربردی وب طراحی شده است، باید توابعی را برای مدیریت شبکه، مدیریت پایگاه داده، و پردازش درخواست های HTTP فراهم کند. این توابع می توانند بر عملکرد سیستم عامل تأثیر بگذارند.

محدودیت های پشتیبانی: پشتیبانی از سیستم عامل های یونیکرنل ممکن است دشوار باشد، زیرا تعداد توسعه دهندگان و متخصصانی که در این زمینه مهارت دارند محدود است. این امر می تواند مشکل ساز باشد، زیرا ممکن است لازم باشد سیستم عامل یونیکرنل در صورت بروز اشکالات یا باگ ها به روز شود.

علاوه بر این، توسعه دهندگان ممکن است برای دریافت پشتیبانی از سیستم عامل یونیکرنل مجبور به پرداخت هزینه باشند. این امر می تواند برای سازمان هایی که بودجه محدودی دارند مشکل ساز باشد.

در مجموع، معماری یونیکرنل یک معماری سیستم عامل امیدوار کننده است که مزایای زیادی نسبت به معماری های سنتی دارد. با این حال، این معماری معایبی نیز دارد که باید در نظر گرفته شوند.

معماری یونیکرنل در موارد استفاده مختلفی مورد استفاده قرار می گیرد، از جمله:

· اجرای برنامه های کاربردی حساس از نظر امنیتی، مانند برنامه های کاربردی دولتی یا مالی.

معماری یونیکرنل به دلیل امنیت بالا، برای اجرای برنامه های کاربردی حساس از نظر امنیتی بسیار مناسب است. در یک سیستم عامل یونیکرنل، هر برنامه کاربردی در یک فضای جداگانه اجرا می شود. این امر به مهاجمان اجازه نمی دهد تا از یک برنامه کاربردی آسیب پذیر برای حمله به سایر برنامه های کاربردی استفاده کنند.

به عنوان مثال، سازمان های دولتی یا مالی ممکن است از سیستم عامل های یونیکرنل برای اجرای برنامه های کاربردی حساس خود مانند سامانه های مالی یا سامانه های دفاعی استفاده کنند.

· اجرای برنامه های کاربردی در محیط های محدود، مانند دستگاه های IoT یا محیط های cloud.

معماری یونیکرنل به دلیل اندازه کوچک و سادگی، برای اجرای برنامه های کاربردی در محیط های محدود بسیار مناسب است. در یک سیستم عامل یونیکرنل، فقط توابعی که برای اجرای برنامه کاربردی ضروری هستند، اجرا می شوند. این امر باعث می شود که سیستم عامل یونیکرنل کارآمدتر و مصرف کننده منابع کمتری باشد.

به عنوان مثال، سازمان های دولتی یا نظامی ممکن است از سیستم عامل های یونیکرنل برای اجرای برنامه های کاربردی در دستگاه های IoT مانند پهپادها یا حسگرها استفاده کنند.

· اجرای برنامه های کاربردی با کارایی بالا، مانند برنامه های کاربردی پردازش داده یا بازی های ویدیویی.

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

به عنوان مثال، سازمان های فناوری اطلاعات ممکن است از سیستم عامل های یونیکرنل برای اجرای برنامه های کاربردی پردازش داده یا بازی های ویدیویی استفاده کنند.

معماری مونولوتیک(monolithic architecture)

معماری یکپارچه یک معماری نرم افزاری است که از یک واحد منطقی و یک فایل اجرایی واحد تشکیل شده است. تمام بخش‌های برنامه کاملاً به هم متصل و به هم وابسته هستند. این معماری معمولا برای کاربردهای کوچک و ساده مناسب است.

تاریخچه و تکامل معماری‌های یکپارچه را می‌توان دردوران محاسبات بزرگ در اواسط قرن بیستم، زمانی که محدودیت‌های فنی گزینه‌های طراحی سیستم‌های نرم‌افزاری را محدود می‌کرد، ردیابی کرد. معماری های یکپارچه برای کاربردهای کوچک و ساده مناسب بودند، اما با پیشرفت تکنولوژی و نیازهای تجاری، به گلوگاهی برای رشد تبدیل شدند.

روش های مختلفی برای طراحی معماری داخلی یک برنامه کاربردی یکپارچه وجود دارد، مانند استفاده از رویکرد لایه ای، مدولار یا مبتنی بر مؤلفه. هر یک از این روش ها از نظر کارایی، سادگی، انعطاف پذیری و قابلیت نگهداری مزایا و معایب خاص خود را دارند. برخی از ویژگی های مشترک یک معماری یکپارچه عبارتند از:

تک اجرای یا Single executable: کل برنامه به صورت یک فایل اجرایی بسته بندی و مستقر می شود. همه اجزا و ماژول ها با هم ترکیب شده اند.

اتصال محکم: اجزا و ماژول های داخل برنامه بسیار به هم مرتبط هستند و به یکدیگر وابسته هستند. تغییرات ایجاد شده در یک مؤلفه ممکن است نیاز به تغییرات در سایر بخش‌های برنامه داشته باشد.

حافظه اشتراکی: همه اجزای برنامه دارای فضای حافظه یکسانی هستند. آنها می توانند مستقیماً به ساختارهای داده مشترک دسترسی داشته باشند و آنها را اصلاح کنند.

استقرار یکپارچه: کل برنامه به صورت یک واحد مستقر می شود. به روز رسانی یا تغییرات در برنامه نیاز به استقرار مجدد کل یکپارچه دارد.

جریان کنترل متمرکز: جریان کنترل در برنامه معمولاً توسط یک ماژول مرکزی یا یک تابع اصلی مدیریت می شود. جریان اجرا به صورت متوالی از یک جزء به جزء دیگر حرکت می کند.

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

· تجزیه سرویس: نحوه شناسایی و استخراج خدمات مستقلی که یک قابلیت تجاری را از برنامه یکپارچه محصور می کند.

· توسعه موازی: نحوه اجرای موازی برنامه یکپارچه هنگام توسعه میکروسرویس ها و نحوه مدیریت وابستگی ها و ارتباطات بین آنها.

· بازسازی پایگاه داده: نحوه تقسیم پایگاه داده یکپارچه به پایگاه های داده جداگانه برای هر میکروسرویس، و نحوه رسیدگی به مسائل مربوط به سازگاری و یکپارچگی داده ها.

· مدیریت تراکنش: نحوه مدیریت تراکنش‌هایی که در چندین ریزسرویس انجام می‌شوند، و نحوه برخورد با اقدامات نهایی و سازگاری.

برخی از نکات و بهترین روش ها برای طراحی و توسعه یک برنامه کاربردی یکپارچه عبارتند از:

· از معماری لایه ای استفاده کنید: برنامه را به لایه های مختلفی مانند ارائه، کسب و کار، دسترسی به داده ها و پایگاه داده جدا کنید و برای هر لایه رابط ها و مسئولیت های واضحی تعریف کنید.

· از طراحی ماژولار استفاده کنید: برنامه را به ماژول های کوچکتر تقسیم کنید که نشان دهنده یک ویژگی یا یک عملکرد است، و از کپسوله سازی و انتزاع برای پنهان کردن جزئیات پیاده سازی و افشای تنها رابط های ضروری استفاده کنید.

· از رویکرد مبتنی بر مؤلفه استفاده کنید: برنامه را به اجزای قابل استفاده مجدد تقسیم کنید که از طریق یک رابط کاملاً تعریف شده سرویسی را ارائه می دهند و از تزریق وابستگی و وارونگی کنترل برای مدیریت وابستگی ها و تعاملات بین مؤلفه ها استفاده کنید.

· از الگوهای طراحی استفاده کنید: برای حل مشکلات رایج طراحی و بهبود کیفیت و قابلیت نگهداری کد، از الگوهای طراحی مناسب مانند کارخانه، تک تن، استراتژی، ناظر و واسطه استفاده کنید.

· از ابزارهای کیفیت کد استفاده کنید: از ابزارهایی مانند تحلیلگر کد، فرمت‌کننده کد، پوشش کد، و بازبینی کد استفاده کنید تا مطمئن شوید کد از بهترین شیوه‌ها، استانداردها و قراردادها پیروی می‌کند و هر گونه خطا، باگ یا آسیب‌پذیری را شناسایی و رفع می‌کند. .

برخی از مزایا و معایب معماری یکپارچه عبارتند از:

مزایا:

سادگی: معماری یکپارچه ساده تر از معماری های دیگر است و نیازی به پیچیدگی های ارتباط بین سرویس ها، مدیریت شبکه، مقیاس پذیری و نظارت ندارد.

کارایی: یک معماری یکپارچه می تواند سریعتر اجرا شود زیرا نیازی به فراخوانی سرویس های خارجی ندارد و از منابع سخت افزاری کمتری استفاده می کند.

امنیت: یک معماری یکپارچه می تواند امن تر باشد زیرا دسترسی به داده ها و منطق محدود به یک واحد است و نیازی به احراز هویت و مجوز بین سرویس ها نیست.

معایب:

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

مقیاس پذیری: مقیاس یک معماری یکپارچه می تواند دشوار باشد زیرا برای افزایش ظرفیت برنامه، باید کل واحد را روی سرورهای بیشتری توزیع کنیم و این می تواند هزینه ها و پیچیدگی ها را افزایش دهد.

ناکارآمدی: یک معماری یکپارچه می تواند ناکارآمد باشد زیرا برای ایجاد تغییرات در برنامه، باید کل یکپارچه را دوباره کامپایل کرده و مجدداً مستقر کنیم و این می تواند سرعت و انعطاف پذیری توسعه را کاهش دهد.

معماری ابر (cloud architecture)

معماری ابر به مجموعه اجزا، فناوری‌ها و روش‌هایی اطلاق می‌شود که برای ایجاد محیطی به منظور محاسبات ابری به کار گرفته می‌شوند.

اجزای اصلی معماری ابر عبارتند از:

1. زیرساخت جلویی (Frontend) شامل:

رابط کاربری، برنامه‌های کاربردی سمت کلاینت و دستگاه یا شبکه‌ای که کاربران از طریق آن با ابر تعامل می‌کنند.

2. زیرساخت انتهایی (Backend) شامل:

برنامه‌های کاربردی سرور

سرویس‌های اصلی ارائه‌دهنده خدمات ابری

محیط مجازی‌سازی (Runtime) برای اجرای سرویس‌ها

ذخیره‌ساز ابری برای داده‌ها

زیرساخت سخت‌افزاری و نرم‌افزاری

نرم‌افزارهای مدیریت و امنیت

3. مدل تحویل خدمات ابری (Cloud Service Model) شامل SaaS، PaaS و IaaS

4. شبکه و ارتباطات

بنابراین اجزای معماری ابر، مجموعه لایه‌ها و سرویس‌هایی هستند که برای ایجاد زیرساختی به منظور محاسبات و ذخیره‌سازی ابری ضروری می‌باشند. معماری ابر نقشه راهی برای ترکیب بهینه منابع و قابلیت‌ها به منظور پاسخگویی به نیازهای کسب و کار در محیط ابری است.

معماری ابری (Cloud Architecture) به این صورت عمل می‌کند:

معماری ابری شامل اجزا و لایه‌های مختلفی است که با هم یک پلتفرم محاسبات ابری را فراهم می‌کنند تا کاربران بتوانند به صورت درخواستی به منابع و سرویس‌ها دسترسی داشته باشند.

سمت Back-End شامل تمامی منابع و سرویس‌های ابری از جمله سرورها، ذخیره‌سازی، شبکه و برنامه‌های کاربردی است که توسط ارائه‌دهنده خدمات ابری فراهم می‌شود.

Front-End شامل رابط کاربری و برنامه‌هایی است که کاربران از طریق آن‌ها با ابر تعامل می‌کنند.

یک شبکه، Back-End و Front-End را به هم متصل می‌کند تا داده‌ها بین آن‌ها رد و بدل شود.

هنگامی که کاربران از طریق Front-End، درخواستی ارسال می‌کنند، این درخواست‌ها از طریق Middleware به Back-Endفرستاده می‌شود و سرویس‌ مورد نظر، وظیفه یا درخواست را انجام می‌دهد.

انواع مدل‌های سرویس‌دهی ابری عبارتند از: IaaS، PaaS، SaaS

که هرکدام بسته به نوع نیازهای سازمانی مناسب هستند.

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

در معماری ابری، ابزارها و تکنولوژی‌های خاص نقش حیاتی در بهبود کارایی، انعطاف‌پذیری و مدیریت منابع ایفا می‌کنند:

· کانتینرها: کانتینرها، مانند Docker، امکان بسته‌بندی برنامه‌ها و وابستگی‌های آن‌ها در یک محفظه قابل حمل را فراهم می‌آورند، که اجرای آن‌ها در محیط‌های مختلف را آسان‌تر می‌سازد.

· سرویس‌های بدون سرور (Serverless): فناوری‌های بدون سرور به توسعه‌دهندگان اجازه می‌دهند تا برنامه‌هایی بسازند و اجرا کنند بدون نیاز به مدیریت سرورها، که به خودی خود مدیریت منابع و مقیاس‌بندی را بهینه می‌کند.

· ابزارهای مدیریت و نظارت: ابزارهایی مانند Kubernetes برای مدیریت کلانشهرهای کانتینری، Prometheus برای نظارت و Grafana برای داشبورد و تجزیه و تحلیل داده‌ها، به شناسایی و رفع خطاها و بهبود عملکرد کمک می‌کنند.

این تکنولوژی‌ها با هم کار می‌کنند تا محیطی انعطاف‌پذیر، قابل مدیریت و کارا در معماری ابری ایجاد کنند، که به سازمان‌ها اجازه می‌دهد به سرعت به نیازهای تغییریافته پاسخ دهند.

در معماری‌های ابری، امنیت یکی از حیاتی‌ترین جنبه‌ها است که شامل مجموعه‌ای از رویکردها و بهترین شیوه‌ها برای حفاظت از داده‌ها، برنامه‌ها و زیرساخت‌ها در برابر تهدیدهای امنیتی می‌شود. این رویکردها شامل رمزنگاری داده‌ها برای اطمینان از امنیت اطلاعات در حین انتقال و ذخیره‌سازی و مدیریت هویت و دسترسی است تا تضمین شود که فقط کاربران مجاز قادر به دسترسی به منابع هستند. استفاده از سیاست‌های امنیتی محکم، نظارت مداوم بر ترافیک شبکه و تجزیه و تحلیل رفتاری برای شناسایی الگوهای مشکوک نیز بخشی از این رویکردها است.

تأثیرات زیست‌محیطی معماری‌های ابری : این تأثیرات می‌توانند شامل مصرف انرژی، انتشار گازهای گلخانه‌ای، و استفاده از منابع طبیعی باشند. رویکردهای سبز در طراحی زیرساخت ابری، مانند بهینه‌سازی مصرف انرژی در مراکز داده، استفاده از انرژی‌های تجدیدپذیر، و بهبود کارایی سیستم‌های خنک‌کننده، به کاهش این تأثیرات کمک می‌کنند. هدف از این رویکردها کاهش اثرات منفی بر محیط زیست ضمن حفظ کارایی و قابلیت اطمینان سرویس‌های ابری است.

انواع اصلی معماری ابری عبارتند از:

1. معماری ابر عمومی (Public Cloud Architecture)

در این معماری، منابع و زیرساخت محاسبات ابری توسط یک ارائه‌دهنده خدمات ابری عمومی تأمین و مدیریت می‌شود. معماری ابر عمومی به راحتی امکان مقیاس‌پذیری را فراهم می‌کند اما منابع به اشتراک گذاشته می‌شوند.

2. معماری ابر خصوصی (Private Cloud Architecture)

ابر خصوصی به ابری اطلاق می‌شود که توسط سازمانی به طور اختصاصی میزبانی و مدیریت می‌شود. این نوع معماری امکان کنترل بیشتر بر منابع و امنیت بالاتری را فراهم می‌کند اما هزینه‌برتر است.

3. معماری ابر ترکیبی (Hybrid Cloud Architecture)

در معماری ترکیبی از مزایای هر دو مدل ابر عمومی و خصوصی بهره گرفته می‌شود. این مدل انعطاف‌پذیری بالایی دارد.

4. معماری چند ابری (Multi Cloud Architecture)

در این معماری از چندین ارائه‌دهنده مختلف خدمات ابری عمومی استفاده می‌شود. مزیت اصلی آن انعطاف‌پذیری بالا و جلوگیری از وابستگی به یک ارائه‌دهنده خاص است.

مهمترین مزایای معماری ابری (Cloud Architecture) به شرح زیر می‌باشند:

1. کاهش هزینه‌های سرمایه‌ای اولیه

2. افزایش سرعت به بازار و راه‌اندازی سریع‌تر خدمات

3. انعطاف‌پذیری و مقیاس‌پذیری بالا

4. تسریع تحول دیجیتال و مدرن‌سازی

5. امکان بهره‌مندی از جدیدترین فناوری‌ها

6. افزایش دسترس‌پذیری و قابلیت اطمینان

7. بهبود امنیت اطلاعات

در مجموع، معماری ابری باعث کاهش هزینه‌ها، تسریع ارائه محصولات و سرویس‌ها، و بهبود تجربه کاربری می‌شود و پاسخگویی سازمان‌ها به تغییرات را افزایش می‌دهد.

چالش‌ها و محدودیت‌های معماری ابری شامل موارد زیر می‌شود:

1. امنیت و حفظ حریم خصوصی: اطمینان از امنیت داده‌ها و برنامه‌ها در محیط ابری چالش‌برانگیز است.

2. مدیریت هزینه: کنترل هزینه‌ها در محیط‌های ابری، به خصوص با مدل پرداخت بر اساس مصرف، دشوار است.

3. پیچیدگی مدیریت: مدیریت و نظارت بر منابع ابری می‌تواند پیچیده باشد، به ویژه در محیط‌های چند ابری.

4. قابلیت اطمینان و عملکرد: تضمین عملکرد و در دسترس بودن مداوم خدمات در سطح جهانی می‌تواند چالش‌برانگیز باشد.

5. وابستگی به ارائه‌دهنده خدمات: وجود وابستگی شدید به ارائه‌دهنده‌های خدمات ابری می‌تواند ریسک‌هایی ایجاد کند.

6. انتقال و مهاجرت داده‌ها: انتقال داده‌ها و برنامه‌ها به ابر و بین ابرهای مختلف می‌تواند پیچیده و هزینه‌بر باشد.

7. مسائل قانونی و مقرراتی: رعایت قوانین و مقررات مربوط به داده‌ها در مناطق جغرافیایی مختلف می‌تواند محدودکننده باشد.

معماری میکرو سرویس

معماری میکروسرویس، یک رویکرد مدرن در توسعه نرم‌افزار است که در آن برنامه‌های کاربردی به مجموعه‌ای از خدمات مستقل و کوچک تقسیم می‌شوند. این سرویس‌ها می‌توانند به طور مستقل توسعه و استقرار یابند و از طریقAPIهای کاملاً تعریف‌شده با یکدیگر ارتباط برقرار کنند، که این امر بویژه در سازمان‌های بزرگ و پیچیده با چندین تیم توسعه مستقل مفید است. معماری میکروسرویس، که سبک خاصی از معماری نرم افزار و مشتق شده از معماری سرویس‌گرا (SOA) است، هدفش ارتقاء خودمختاری بالای سرویس‌ها از نظر منطق کارکردی-داده‌ای و نیز پلتفرم پیاده‌سازی و اجرا است. این سبک معماری علاوه بر استفاده از مفاهیم معماری سرویس‌گرا، از مفاهیم معماری رخدادمحور و سیستم‌های توزیع‌شده نیز بهره می‌برد.

مشخصه‌های اصلی معماری میکروسرویس شامل خودگردانی و تخصصی بودن هر سرویس است. هر سرویس بر حل یک مشکل خاص تمرکز دارد و می‌تواند بدون تأثیر بر عملکرد سایر سرویس‌ها مستقلانه توسعه یابد. این امر به چابکی، مقیاس‌پذیری منعطف و استقرار آسان سیستم کمک می‌کند.

معماری میکروسرویس در چند سال اخیر به شدت در حال گسترش و فراگیری در میان توسعه‌دهندگان و معماران است. اگرچه اولین اشاره مستقیم به واژه "میکروسرویس‌ها" به سال 2011 و در یک کارگاه معماری نرم‌افزار برمی‌گردد، اما این موضوع در طی سال‌های 2014 و 2015 داغ شد و هم اکنون میکروسرویس‌ها به عنوان یکی از موضوعات جذاب در دنیای نرم‌افزار و معماری محسوب می‌شوند. هر ماه مقالات، کتاب‌ها و ارائه‌های جدیدی از آن منتشر می‌شود و در کنفرانس‌ها یا سمینارهای تجاری-علمی نیز علاقه‌مندان زیادی را به خود جذب می‌کند. بر اساس گزارش‌های گوگل از میزان رشد جستجوی عبارات مرتبط با میکروسرویس، نقش محوری آن در معماری و توسعه سیستم‌ها مشخص است. تاریخچه معماری میکروسرویس‌ها به اوایل دهه 2000 بازمی‌گردد، زمانی که تعدادی از شرکت‌های پیشرو در صنعت نرم‌افزار شروع به اکتشاف و پیاده‌سازی این مدل کردند. این رویکرد به عنوان یک راه‌حل به چالش‌های موجود در معماری‌هایmonolithic (یکپارچه) ظهور یافت، که در آن‌ها تغییرات و مقیاس‌پذیری به سختی صورت می‌گرفت. با افزایش نیاز به انعطاف‌پذیری، توسعه سریع‌تر و استقلال بیشتر بین تیم‌های توسعه، معماری میکروسرویس‌ها به تدریج به عنوان یک رویکرد مطلوب در نظر گرفته شد.

از نظر داخلی، معماری میکروسرویس‌ها به شکلی طراحی می‌شود که هر سرویس به صورت مستقل عمل کند و برای حل یک مشکل خاص یا ارائه یک قابلیت مشخص طراحی شده باشد. هر سرویس می‌تواند به طور جداگانه توسعه یابد، آزمایش شود و مقیاس‌پذیری داشته باشد، و از طریق API‌های تعریف‌شده با سایر سرویس‌ها ارتباط برقرار کند. این اجزاء مانند کانتینرها یا ماشین های مجازی، مستقل به طور معمول در محیط‌هایی که از نظر شبکه‌ای از هم جدا هستند اجرا می‌شوند.

مشخصه‌های اصلی معماری میکروسرویس شامل خودگردانی و تخصصی بودن هر سرویس است. هر سرویس بر حل یک مشکل خاص تمرکز دارد و می‌تواند بدون تأثیر بر عملکرد سایر سرویس‌ها مستقلانه توسعه یابد. این امر به چابکی، مقیاس‌پذیری منعطف و استقرار آسان سیستم کمک می‌کند.

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

مزایای استفاده از معماری میکروسرویس عبارت‌اند از:

- چابکی در توسعه و استقرار، به دلیل اینکه تیم‌ها می‌توانند مستقل و سریع‌تر کار کنند.

- مقیاس‌پذیری منعطف که به هر سرویس اجازه می‌دهد به صورت مستقل مقیاس‌پذیر شود.

- استقرار آسان و کاهش هزینه‌های مرتبط با اشتباهات توسعه.

با این حال، معماری میکروسرویس هم محدودیت‌هایی دارد. برخی از محدودیت‌های آن شامل کندی عملکرد به دلیل ارتباطات شبکه‌ای بین سرویس‌ها، افزایش احتمال آسیب‌های امنیتی و پیچیدگی‌های بیشتر در توسعه سرویس‌هایی که با یکدیگر در بستر شبکه ارتباط برقرار می‌کنند است.

در مقایسه، معماری Monolithic، که رویکرد سنتی‌تری در توسعه نرم‌افزار است، کل برنامه را به عنوان یک واحد واحد اجرا می‌کند و تمامی اجزای سیستم را بر اساس یک زبان برنامه‌نویسی و یک فریم‌ورک مشخص می‌نویسد. چک کوچکی. این معماری محدودیت‌های خاص خود را دارد، از جمله نیاز به Build و Deployمجدد کل برنامه برای هر تغییر کوچکی که انجام می‌شود. این امر می‌تواند باعث افزایش زمان و هزینه‌های توسعه شود و در مواردی که تغییرات سریع و مکرر مورد نیاز است، مشکل‌ساز باشد. علاوه بر این، در معماری Monolithic، اگر یک بخش از سیستم دچار خطا شود، این امر می‌تواند تأثیر منفی بر کل سیستم داشته باشد، چرا که تمامی اجزا به هم مرتبط و وابسته هستند. این موضوع، به ویژه در سیستم‌های بزرگ و پیچیده، مدیریت خطا و نگهداری را دشوار می‌کند.

به طور مقابل، معماری میکروسرویس‌ها به طور طبیعی مشکلات مربوط به مقیاس‌پذیری و انعطاف‌پذیری را که در معماری‌های Monolithicمشاهده می‌شود، حل می‌کند. به دلیل اینکه هر سرویس به صورت مستقل عمل می‌کند و تنها از طریق APIها با دیگر سرویس‌ها ارتباط برقرار می‌کند، توسعه، آزمایش و استقرار سرویس‌ها به صورت مجزا و سریع‌تر انجام می‌گیرد. این امر به تیم‌های توسعه اجازه می‌دهد تا به صورت مستقل و چابک‌تر عمل کنند، و در نتیجه به سازمان‌ها کمک می‌کند تا به سرعت به تغییرات بازار و نیازهای کاربران پاسخ دهند.

قانون دو پیتزا

قانون Two-Pizza Teams ایجاد تیم های کوچک و مستقل تشکیل شده است که می توانند با دو پیتزا تغذیه سیر شوند. ایده کاهش پیچیدگی، سربار و هزینه های ارتباطی تیم های بزرگ و وابسته به یکدیگر و افزایش چابکی، کارایی و نوآوری توسعه نرم افزار است.

تاریخچه Two-Pizza Teams از بنیانگذار و مدیر عامل آمازون جف بزوس می‌آید که این قانون را در روزهای اولیه این شرکت وضع کرد. او می‌خواست از مشکلات بوروکراسی، تفکر گروهی و تصمیم‌گیری کند که اغلب سازمان‌های بزرگ را گرفتار می‌کند اجتناب کند و فرهنگ مالکیت، مسئولیت‌پذیری و وسواس مشتری را در میان کارمندان خود تقویت کند. او همچنین می خواست از مفهوم قانون کانوی استفاده کند که بیان می کند ساختار یک سیستم نرم افزاری ساختار سازمانی را که آن را تولید می کند منعکس می کند. هدف او با ایجاد تیم های کوچک و مستقل، ایجاد سیستم های نرم افزاری ماژولار و مقیاس پذیر بود.

یکی از نمونه‌هایی که چگونه Two-Pizza Teamsدر آمازون کار می‌کنند، توسعه AWS، پلتفرم رایانش ابری است که بسیاری از خدمات اینترنت را تامین می‌کند. AWS به عنوان یک پروژه داخلی برای استانداردسازی و ساده‌سازی راه ارتباط تیم‌های مختلف در آمازون و دسترسی به منابع مشترک شرکت آغاز شد. آمازون با ایجاد سرویس‌های کوچک و مستقلی که APIهای تعریف شده را در معرض دید قرار می‌داد، توانست وابستگی‌ها و تنگناهای بین تیم‌ها را کاهش دهد و امکان تحویل سریع‌تر و مکرر ویژگی‌ها و به‌روزرسانی‌ها را فراهم کند. بعداً آمازون متوجه شد که این خدمات می تواند به مشتریان خارجی نیز ارائه شود و به این ترتیب AWS متولد شد.

تیم‌های دو پیتزا نه تنها توسط آمازون، بلکه توسط شرکت‌های دیگری که می‌خواهند رویکردی چابک‌تر و مشتری‌محورتر برای توسعه نرم‌افزار اتخاذ کنند، استفاده می‌شوند.

برخی از مزایای تیم های دو پیتزا عبارتند از:

· آنها تحویل سریع‌تر و مکرر ویژگی‌ها و به‌روزرسانی‌ها را امکان‌پذیر می‌کنند، زیرا هر تیم می‌تواند به طور مستقل توسعه، آزمایش و استقرار کند.

· آنها مقیاس پذیری و عملکرد سیستم نرم افزار را افزایش می دهند، زیرا هر سرویس را می توان با توجه به تقاضا و در دسترس بودن منابع، کوچک یا بزرگ کرد.

· آنها تحمل خطا و انعطاف‌پذیری سیستم نرم‌افزاری را بهبود می‌بخشند، زیرا هر سرویس را می‌توان جدا کرد و از خرابی‌ها بدون تأثیر بر کل سیستم بازیابی کرد.

· آنها از تنوع و تکامل پشته فناوری پشتیبانی می کنند، زیرا هر تیم می تواند از زبان ها، چارچوب ها و ابزارهای مختلف استفاده کند.

برخی از چالش های تیم های دو پیتزا عبارتند از:

· آن‌ها پیچیدگی و سربار طراحی سیستم را افزایش می‌دهند، زیرا نیاز به برنامه‌ریزی دقیق و هماهنگی تجزیه، ارتباطات، یکپارچه‌سازی و استقرار سرویس دارند.

· آن‌ها خطر تأخیر و شکست شبکه را معرفی می‌کنند، زیرا ارتباطات بین سرویس به قابلیت اطمینان و در دسترس بودن شبکه بستگی دارد.

· آن‌ها نیاز به تست و استراتژی‌های نظارتی پیچیده‌تری دارند، زیرا شامل چندین سرویس توزیع شده و پویا هستند که با یکدیگر تعامل دارند.

· آن‌ها خواستار قابلیت‌های عملیاتی و حاکمیتی بیشتری هستند، زیرا شامل مدیریت امنیت، پیکربندی، نسخه‌سازی و مستندسازی سرویس‌ها می‌شود.

مقایسه معماری ها :

در ادامه به مقایسه انواع معماری ها میپردازیم :

مدیریت پیچیدگی: در معماری مونولیتیک، پیچیدگی برنامه با رشد آن افزایش می‌یابد و مدیریت آن سخت‌تر می‌شود. در معماری میکروسرویس، پیچیدگی برنامه به چندین سرویس کوچک و مستقل تقسیم می‌شود و مدیریت آن آسان‌تر می‌شود. در معماری یونیکرنل، پیچیدگی برنامه به اندازه‌ی متوسط است، زیرا هر برنامه به صورت یک کرنل مستقل اجرا می‌شود و نیازی به سیستم عامل ندارد. در معماری ابری، پیچیدگی برنامه به حداقل می‌رسد، زیرا برنامه‌ها به صورت سرویس‌های آماده‌ی ابری ارائه می‌شوند و نیازی به مدیریت زیرساخت ندارند.

توانایی تغییر: در معماری مونولیتیک، تغییر در یک بخش از برنامه ممکن است تأثیر منفی بر سایر بخش‌ها داشته باشد و نیاز به کامپایل و استقرار مجدد کل برنامه داشته باشد. در معماری میکروسرویس، تغییر در یک سرویس مستقل از سایر سرویس‌ها است و نیاز به کامپایل و استقرار مجدد فقط آن سرویس دارد. در معماری یونیکرنل، تغییر در یک برنامه مستقل از سایر برنامه‌ها است و نیاز به کامپایل و استقرار مجدد فقط آن برنامه دارد. در معماری ابری، تغییر در یک سرویس ابری مستقل از سایر سرویس‌های ابری است و نیاز به کامپایل و استقرار مجدد فقط آن سرویس دارد.

توانایی تست: در معماری مونولیتیک، تست کل برنامه به صورت یکپارچه انجام می‌شود و نیاز به تست هماهنگی بین اجزاء دارد. در معماری میکروسرویس، تست هر سرویس به صورت جداگانه انجام می‌شود و نیاز به تست هماهنگی بین سرویس‌ها دارد. در معماری یونیکرنل، تست هر برنامه به صورت جداگانه انجام می‌شود و نیاز به تست هماهنگی بین برنامه‌ها دارد. در معماری ابری، تست هر سرویس ابری به صورت جداگانه انجام می‌شود و نیاز به تست هماهنگی بین سرویس‌های ابری دارد .

توانایی بازیابی: در معماری مونولیتیک، بازیابی از خطاها و اشکالات سخت‌تر است، زیرا هر خطا ممکن است کل برنامه را متوقف کند و نیاز به راه‌اندازی مجدد کل برنامه داشته باشد. در معماری میکروسرویس، بازیابی از خطاها و اشکالات آسان‌تر است، زیرا هر خطا فقط یک سرویس را متوقف می‌کند و نیاز به راه‌اندازی مجدد فقط آن سرویس دارد. در معماری یونیکرنل، بازیابی از خطاها و اشکالات متوسط است، زیرا هر خطا فقط یک برنامه را متوقف می‌کند و نیاز به راه‌اندازی مجدد فقط آن برنامه دارد. در معماری ابری، بازیابی از خطاها و اشکالات آسان‌تر است، زیرا هر خطا فقط یک سرویس ابری را متوقف می‌کند و نیاز به راه‌اندازی مجدد فقط آن سرویس دارد.

نتفلیکس

نتفلیکس در سال 1997 توسط رید هستینگز و مارک رندولف تأسیس شد. آنها ابتدا یک شرکت اجاره فیلم آنلاین به نام Pure Softwareداشتند که به مشتریان اجازه می‌داد فیلم‌ها را به صورت آنلاین اجاره کنند و DVDها را از طریق پست دریافت نمایند.

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

در سال 1999، آنها نام شرکت را از Pure Software به نتفلیکس تغییر دادند. در ابتدا، محتوای نتفلیکس محدود به فیلم‌های دسته دوم بود اما به مرور زمان شروع به اضافه کردن محتوای اختصاصی و محبوب‌تر کردند.

نتفلیکس در سال 2007 خدمات استریم ویدیو را راه‌اندازی کرد که به کاربران اجازه می‌داد محتوا را بدون نیاز به دانلود مستقیماً مشاهده کنند. همچنین، شروع به تولید محتوای اختصاصی خود مثل سریال ها و فیلم‌ها کردند.

تا سال 2010، نتفلیکس به 20 میلیون مشترک در سراسر جهان دست یافت. در طی سال‌های بعدی نیز به رشد خود ادامه داد و در حال حاضر با بیش از 220 میلیون مشترک، بزرگترین سرویس استریم ویدیو در جهان محسوب می‌شود.

نتفلیکس همچنان به سرمایه‌گذاری روی محتوای اختصاصی و بهبود تجربه کاربری ادامه می‌دهد و یکی از موفق‌ترین شرکت‌های فناوری در سراسر جهان به شمار می‌رود.

معماری نتفلیکس

در دنیای خدمات پخش زنده، نتفلیکس همچون یک انحصار، میلیون‌ها بیننده را در سراسر جهان با کتابخانه‌ای عظیم از محتوا که به طور بی‌درنگ به صفحه‌هایی با اندازه‌های مختلف تحویل داده می‌شود، مجذوب خود کرده است. پشت این تجربه به ظاهر بی‌زحمت، یک طراحی سیستم دقیق و زیبا نهفته است. در این مقاله، ما طراحی سیستم نتفلیکس را مورد بررسی قرار خواهیم داد.

الزامات طراحی سیستم نتفلیکس

الزامات کارکردی (Functional Requirements)

· کاربران باید بتوانند حساب‌های کاربری ایجاد کنند، وارد شوند و خارج شوند.

· مدیریت اشتراک برای کاربران.

· اجازه به کاربران برای پخش ویدئو و قابلیت‌های مکث، پخش، بازگردانی و پیش‌رفت سریع.

· قابلیت دانلود محتوا برای تماشای آفلاین.

· توصیه محتوای شخصی‌سازی شده بر اساس ترجیحات کاربر و تاریخچه تماشا.

الزامات غیرکارکردی(Non-Functional Requirements)

· کمترین تأخیر و بالاترین پاسخ‌دهی هنگام پخش محتوا.

· قابلیت مقیاس‌پذیری برای پشتیبانی از تعداد زیادی کاربر همزمان.

· در دسترس بودن بالا با حداقل زمان توقف.

· احراز هویت و اجازه دسترسی امن برای کاربران.

· رابط کاربری شهودی برای ناوبری آسان.

طراحی سطح بالای سیستم نتفلیکس

این شرکت دسته‌بندی‌های بزرگی از فیلم‌ها و محتوای تلویزیونی را مدیریت می‌کند و کاربران برای دسترسی به این محتواها، اجاره ماهانه پرداخت می‌کنند. نتفلیکس بیش از 180 میلیون مشترک در بیش از 200 کشور دارد.

نتفلیکس بر روی دو ابر (Cloud) کار می‌کند: AWS و Open Connect. این دو ابر به عنوان ستون فقرات نتفلیکس عمل می‌کنند و هر دو در ارائه بهترین ویدئو به مشترکین بسیار مؤثر هستند.

نتفلیکس به طور عمده از 3 جزء تشکیل شده است:

1. مشتری:

دستگاه (رابط کاربری) که برای جستجو و پخش ویدیوهای نتفلیکس استفاده می‌شود. تلویزیون، ایکس‌باکس، لپ‌تاپ یا تلفن همراه و غیره.

2. OC (Open Connect) یا CDN نتفلیکس:

CDN شبکه‌ای از سرورهای توزیع‌شده در مکان‌های جغرافیایی مختلف است، و Open Connect CDN جهانی سفارشی خود نتفلیکس است.

هر چیزی که شامل پخش ویدئو می‌شود را مدیریت می‌کند.

این شبکه در مکان‌های مختلف توزیع شده است و هنگامی که دکمه پخش را فشار می‌دهید، ویدئو از این جزء به دستگاه شما پخش می‌شود.

بنابراین، اگر سعی کنید ویدئو را در آمریکای شمالی پخش کنید، ویدئو از نزدیک‌ترین Open Connect (یا سرور) به جای سرور اصلی ارائه می‌شود (پاسخ سریع‌تر از نزدیک‌ترین سرور).

پشتیبانی (دیتابیس):

این بخش همه چیزهایی را که شامل پخش ویدئو نمی‌شود (پیش از فشار دادن دکمه پخش) مانند پذیرش محتوای جدید، پردازش ویدئوها، توزیع آن‌ها به سرورهای واقع در نقاط مختلف جهان و مدیریت ترافیک شبکه را مدیریت می‌کند.

بیشتر فرآیندها توسط سرویس‌های وب آمازون (AWS) مدیریت می‌شوند.

معماری میکروسرویس‌های نتفلیکس

قبل از معماری میکروسرویس، مثل اکثر سیستم‌ها از معماری‌های مونولیتیک یا Monolithic استفاده می‌کردند که در آنها تمام کامپوننت‌های مورد نیاز یک برنامه درون یک پروسه یا سرویس واحد قرار دارد. به معماری مونولوتیک قبلا به صورت مفصل پرداخته شده که از تکرار مکررات اجتناب میکنیم.

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

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

نتفلیکس چطور معماری میکروسرویس را قابل اعتماد کرد؟

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

1. استفاده از Hystrix برای مدیریت شکست‌ها

Hystrix یک کتابخانه مدارشکن ایجاد شده توسط نتفلیکس است که به میکروسرویس‌ها اجازه می‌دهد تا در مواجهه با خطاها، به صورت مقاوم عمل کنند. این ابزار به سرویس‌ها کمک می‌کند تا در زمان خرابی‌ها، ترافیک را به روش‌های پیش‌فرض یا فال‌بک هدایت کنند، کاهش زمان توقف و افزایش قابلیت اطمینان سیستم.

2. جداسازی میکروسرویس‌های حیاتی

نتفلیکس برخی از سرویس‌های حیاتی را جدا می‌کند و آن‌ها را کمتر وابسته یا کاملاً مستقل از دیگر سرویس‌ها می‌سازد. این کار به کاهش تاثیر زنجیره‌ای خرابی‌ها کمک می‌کند و اطمینان حاصل می‌شود که حتی در صورت خرابی بخشی از سیستم، بخش‌های حیاتی همچنان قابل دسترسی باشند.

3. اتخاذ رویکرد سرورهای بی‌حالت

نتفلیکس سرورها را به گونه‌ای طراحی کرده است که هر یک از آن‌ها می‌توانند بدون نیاز به حفظ حالت خاصی، درخواست‌ها را پاسخ دهند. این رویکرد امکان می‌دهد که در صورت بروز خطا در یک سرور، به راحتی و بدون اختلال در تجربه کاربری، درخواست‌ها را به سرور دیگری منتقل کنند.

4. مقیاس‌پذیری ابری و استفاده از AWS

با استفاده از زیرساخت ابری آمازون وب سرویس‌ها (AWS)، نتفلیکس از مزایای مقیاس‌پذیری، انعطاف‌پذیری و قابلیت اطمینان بالا بهره‌مند می‌شود. این زیرساخت ابری به نتفلیکس امکان می‌دهد تا منابع خود را بر اساس نیاز فوری افزایش یا کاهش دهد.

5. مانیتورینگ و لاگ‌گیری پیشرفته

نتفلیکس از ابزارهای مانیتورینگ و لاگ‌گیری پیشرفته استفاده می‌کند تا بتواند عملکرد سیستم و میکروسرویس‌های خود را به طور مداوم زیر نظر داشته باشد. این امکان به تیم‌های مهندسی اجازه می‌دهد تا به سرعت مشکلات را شناسایی و رفع کنند.

6. Chaos Engineering

نتفلیکس پیشرو در استفاده از Chaos Engineering است، یک رویکرد آزمایشی که به طور عمدی شرایط خرابی را در محیط تولید ایجاد می‌کند تا اطمینان حاصل شود که سیستم قادر به تحمل خرابی‌ها و بازیابی از آن‌ها است.

با ترکیب این رویکردها و ابزارها، نتفلیکس توانسته است معماری میکروسرویس خود را به یکی از قابل اعتمادترین و مقیاس‌پذیرترین سیستم‌ها در صنعت پخش زنده تبدیل کند.

نحوه نمایش ویدیو بر روی انواع دستگاه ها:

نتفلیکس بیش از 2200 دستگاه را پشتیبانی می‌کند و هر یک از آن‌ها نیازمند رزولوشن‌ها و فرمت‌های مختلفی است. برای قابل مشاهده کردن ویدئوها بر روی دستگاه‌های مختلف، نتفلیکس عملیات ترنسکودینگ یا انکودینگ را انجام می‌دهد، که شامل یافتن خطاها و تبدیل ویدئوی اصلی به فرمت‌ها و رزولوشن‌های مختلف است.

فرآیند ترنسکودینگ (transcoding):

1. تجزیه و تحلیل ویدئوی اصلی: ابتدا، ویدئوی اصلی تجزیه و تحلیل می‌شود تا خطاهای احتمالی شناسایی و اصلاح شوند.

2. انتخاب فرمت‌ها و رزولوشن‌ها: بر اساس دستگاه‌های پشتیبانی شده، نتفلیکس فرمت‌ها و رزولوشن‌های مختلفی را برای ویدئو تعیین می‌کند. این انتخاب شامل فرمت‌های استاندارد برای تلویزیون‌ها، رایانه‌های شخصی، تبلت‌ها و تلفن‌های همراه است.

3. انکودینگ ویدئو: سپس، ویدئوی اصلی به فرمت‌ها و رزولوشن‌های مختلف انکود می‌شود. این فرآیند شامل فشرده‌سازی ویدئو برای اطمینان از کاهش حجم داده‌ها بدون از دست دادن کیفیت قابل توجه است.

4. ذخیره‌سازی و توزیع: پس از انکودینگ، ورژن‌های مختلف ویدئو در سرورهای نتفلیکس ذخیره می‌شوند. این سرورها بخشی از شبکه تحویل محتوای (CDN) نتفلیکس هستند، که توزیع موثر ویدئوها به کاربران در سراسر جهان را تضمین می‌کند.

5. پخش بهینه: هنگامی که کاربر درخواست پخش ویدئویی را می‌دهد، نتفلیکس به طور خودکار بهترین ورژن ویدئو را بر اساس پهنای باند و دستگاه کاربر انتخاب می‌کند. این اطمینان حاصل می‌کند که کاربران تجربه پخش بهینه‌ای داشته باشند، حتی در شرایط پهنای باند محدود.

با این رویکرد، نتفلیکس تضمین می‌کند که کاربران در هر دستگاهی، با هر سرعت اینترنتی، تجربه تماشای ویدئویی بی‌نظیری داشته باشند، و همزمان، بهره‌وری شبکه و زیرساخت‌های خود را بهینه سازد.

بهینه سازی فایل ها در نتفلیکس

نتفلیکس همچنین بهینه‌سازی فایل‌ها را برای سرعت‌های مختلف شبکه انجام می‌دهد. کیفیت یک ویدئو زمانی خوب است که شما ویدئو را با سرعت بالای شبکه تماشا می‌کنید. نتفلیکس چندین نسخه مشابه (تقریباً 1100-1200) برای همان فیلم با رزولوشن‌های مختلف ایجاد می‌کند.

این نسخه‌ها نیاز به مقدار زیادی ترنسکودینگ و پیش‌پردازش دارند. نتفلیکس ویدئوی اصلی را به چندین قطعه کوچکتر تقسیم می‌کند و با استفاده از کارگرهای موازی در AWS، این قطعات را به فرمت‌های مختلف (مانند mp4، 3gp و غیره) در رزولوشن‌های متفاوت (مانند 4k،1080P و بیشتر) تبدیل می‌کند. پس از ترنسکودینگ، زمانی که چندین نسخه از فایل‌ها برای همان فیلم وجود دارد، این فایل‌ها به تمام سرورهای Open Connectکه در مکان‌های مختلفی در سراسر جهان قرار دارند، منتقل می‌شوند.

در زیر فرآیند گام به گام نحوه اطمینان نتفلیکس از کیفیت پخش بهینه آورده شده است:

· زمانی که کاربر اپلیکیشن نتفلیکس را بر روی دستگاه خود بارگذاری می‌کند، ابتدا نمونه‌های AWS وارد عمل می‌شوند و برخی وظایف مانند ورود به سیستم، توصیه‌ها، جستجو، تاریخچه کاربر، صفحه اصلی، صورت‌حساب، پشتیبانی مشتری و غیره را انجام می‌دهند.

· پس از آن، زمانی که کاربر دکمه پخش را بر روی یک ویدئو فشار می‌دهد، نتفلیکس سرعت شبکه یا ثبات اتصال را تجزیه و تحلیل می‌کند و سپس بهترین سرور Open Connect نزدیک به کاربر را پیدا می‌کند.

· بسته به دستگاه و اندازه صفحه نمایش، فرمت ویدئوی مناسب به دستگاه کاربر پخش می‌شود. هنگام تماشای ویدئو، ممکن است متوجه شده باشید که ویدئو به صورت پیکسلی ظاهر می‌شود و پس از مدتی دوباره به HD بازمی‌گردد.

· این اتفاق به این دلیل می‌افتد که برنامه به طور مداوم بهترین سرور Open Connect را برای پخش چک می‌کند و در صورت نیاز بین فرمت‌ها (برای بهترین تجربه تماشا) جابجا می‌شود.

داده‌های کاربر مانند جستجوها، تماشاها، مکان، دستگاه، نظرات و پسندها در AWS ذخیره می‌شوند، نتفلیکس از این داده‌ها برای ساخت توصیه‌های فیلم برای کاربران با استفاده از مدل یادگیری ماشینی یا هادوپ استفاده می‌کند.

مدیریت حجم ترافیک بالا در نتفلیکس

مدیریت حجم ترافیک بالا در Netflixبه وسیله ابزارهای مختلفی انجام می‌شود. این ابزارها شامل موارد زیر هستند:

1. Elastic Load Balancer (ELB): ELBوظیفه مسیریابی ترافیک به سرویس‌های جلویی را بر عهده دارد. ELBاز یک طرح دو مرحله‌ای برای توزین بار استفاده می‌کند. در مرحله اول، بار بین مناطق و سپس در مرحله دوم بین نمونه‌های سرویس توزیع می‌شود.

2. ZUUL: ZUUL یک سرویس دروازه است که مسیریابی دینامیک، نظارت، انعطاف‌پذیری و امنیت را فراهم می‌کند. این سرویس امکان مسیریابی آسان بر اساس پارامترهای کوئری، URLو مسیر را به سرویس‌های مورد نیاز فراهم می‌کند.

3. Hystrix: Hystrix برای کنترل تعاملات بین سرویس‌های توزیع شده استفاده می‌شود. این ابزار با افزودن منطق تحمل تأخیر و خطا، از تأخیر و خرابی سرویس‌ها جلوگیری می‌کند.

4. EV Cache: برای بهبود عملکرد و سرعت دسترسی به داده‌ها، از لایه کش سفارشی با نام EV Cache استفاده می‌شود. این لایه کش بر اساس Memcachedعمل می‌کند و به جای سرور اصلی، از کش برای دسترسی به داده‌ها استفاده می‌شود.

استفاده از این ابزارها در Netflixبهبود عملکرد سیستم، در دسترس بودن و قابلیت اطمینان را افزایش می‌دهد و به مدیریت بار ترافیک بالا کمک می‌کند.

پردازش داده‌ها در نتفلیکس با استفاده از Kafka و Apache Chukwa

نتفلیکس از Kafka و Apache Chukwa برای جمع‌آوری و پردازش داده‌ها استفاده می‌کند. این داده‌ها شامل گزارش خطا، فعالیت‌های رابط کاربری، رویدادهای عملکرد، فعالیت‌های تماشای ویدئو و رویدادهای عیب‌یابی و تشخیص هستند.

Apache Chukwa یک سیستم جمع‌آوری داده‌های متن باز است که بر پایه HDFS و فریمورک MapReduce ساخته شده است. این سیستم قابلیت مقیاس‌پذیری و استحکام Hadoop را داراست و ابزارهای قدرتمندی برای نمایش، نظارت و تجزیه و تحلیل نتایج فراهم می‌کند.

Chukwa رویدادها را از قسمت‌های مختلف سیستم جمع‌آوری می‌کند و می‌توان از آن برای نظارت و تجزیه و تحلیل استفاده کرد. این رویدادها در فرمت فایل توالی Hadoop (S3)نوشته می‌شوند و سپس تیم Big Data آن‌ها را در Hive در فرمت داده Parquet پردازش می‌کند.

برای بارگذاری رویدادهای آنلاین به EMR/S3، Chukwa از Kafka استفاده می‌کند. Kafka نقش انتقال داده‌ها از Kafka جلویی به چاه‌های مختلف را داراست. مسیریابی پیام‌ها با استفاده از فریمورک Apache Samza انجام می‌شود.

ترافیک ارسالی توسط Chukwa ممکن است جریان‌های کامل یا فیلترشده باشد، بنابراین ممکن است نیاز به اعمال فیلتر بیشتری بر روی جریان‌های Kafka باشد. به همین دلیل، استفاده از روتر می‌تواند به منظور انتقال از یک موضوع Kafka به موضوع Kafka دیگر مورد استفاده قرار گیرد.

Elastic Search

در سال‌های اخیر، استفاده از Elasticsearch در نتفلیکس رشد قابل توجهی داشته است. نتفلیکس حدود 150 خوشه Elasticsearch و 3500 میزبان با نمونه‌ها را به کار می‌برد. Elasticsearch در نتفلیکس برای مصورسازی داده‌ها، پشتیبانی مشتری و تشخیص خطاهای سیستم مورد استفاده قرار می‌گیرد.

Apache Spark برای توصیه فیلم

نتفلیکس از Apache Sparkو یادگیری ماشین برای توصیه فیلم استفاده می‌کند. وقتی شما صفحه اصلی را باز می‌کنید، مجموعه‌ای از ردیف‌های مختلف فیلم را مشاهده می‌کنید. نتفلیکس این ردیف‌ها را بر اساس داده‌های تاریخی و ترجیحات کاربران شخصی‌سازی می‌کند و تصمیم می‌گیرد کدام فیلم‌ها به کاربران نمایش داده شوند. همچنین، نتفلیکس برای کاربران خاص، مرتب‌سازی و رتبه‌بندی فیلم‌ها را بر اساس ارتباطات موجود در پلتفرم خود انجام می‌دهد. در اینجا نیز Apache Spark برای توصیه محتوا و شخصی‌سازی استفاده می‌شود.

سیستم توصیه ویدئو

سیستم توصیه نتفلیکس به کاربران کمک می‌کند تا محتوا یا ویدئوی مورد علاقه خود را کشف کنند. برای ساخت این سیستم، نتفلیکس باید علاقه کاربر را پیش‌بینی کند و اطلاعات مختلفی از کاربران جمع‌آوری کند، از جمله تاریخچه تماشا و امتیازدهی کاربر به عناوین دیگر، سلیقه‌ها و ترجیحات مشابه سایر اعضا، اطلاعات متادیتا از ویدئوهای قبلی که توسط کاربر تماشا شده اند، و دستگاه و زمان فعالیت کاربر. نتفلیکس از دو الگوریتم فیلترینگ همکارانه و فیلترینگ مبتنی بر محتوا برای ساخت سیستم توصیه استفاده می‌کند.

طراحی پایگاه داده سیستم نتفلیکس

نتفلیکس از دو پایگاه داده متفاوت یعنی MySQL (RDBMS) و Cassandra (NoSQL)برای اهداف مختلف استفاده می‌کند.

EC2 Deployed MySQL

نتفلیکس اطلاعات صورت‌حساب، اطلاعات کاربر و اطلاعات تراکنش را در پایگاه داده MySQL ذخیره می‌کند. برای رعایت استانداردهای ACID، نتفلیکس از تنظیمات master-master برای MySQL استفاده می‌کند و آن را بر روی نمونه‌های بزرگ EC2 آمازون با استفاده از InnoDB مستقر می‌کند.

تنظیمات از "پروتکل همگام‌سازی تکرار" پیروی می‌کند. در این روش، اگر نویسنده نود اصلی مستر باشد، عملیات همچنین به نود مستر دیگر تکرار می‌شود و تأییدیه فقط در صورت تأیید نوشتار هر دو نود اصلی و دور ارسال می‌شود. این باعث می‌شود دسترسی به داده‌ها تضمین شود. همچنین نتفلیکس برای هر نود (محلی و منطقه‌ای) یک کپی خواندنی تنظیم کرده است که دسترسی بالا و قابلیت مقیاس‌پذیری را تضمین می‌کند.

تمام پرس‌وجوهای خواندنی به کپی‌های خواندنی هدایت می‌شوند و تنها پرس‌وجوهای نوشتاری به نودهای مستر هدایت می‌شوند.

در صورت خرابی نود مستر اصلی MySQL، نود مستر ثانویه نقش اصلی را به عهده می‌گیرد و ورودی route53 (پیکربندی DNS) برای پایگاه داده به این نود جدید اصلی تغییر می‌کند. این کار همچنین پرس‌وجوهای نوشتاری را به این نود مستر جدید اصلی هدایت می‌کند.

Cassandra

Cassandra یک پایگاه داده NoSQL است که می‌تواند مقادیر زیادی داده را مدیریت کند و همچنین می‌تواند نوشتن و خواندن سنگین را مدیریت کند. با افزایش تعداد کاربران در نتفلیکس، داده‌های تاریخچه تماشای هر عضو نیز افزایش یافت. این باعث افزایش تعداد کل داده‌های تاریخچه تماشا شد و مدیریت این حجم عظیم از داده‌ها برای نتفلیکس به چالش تبدیل شد.

نتفلیکس برای ذخیره‌سازی داده‌های تاریخچه تماشا، دو هدف اصلی را در نظر گرفته است:

· کاهش اثر پایین‌تر ذخیره‌سازی.

· عملکرد یکنواخت خواندن/نوشتن با افزایش تماشای هر عضو (نسبت نوشتن به خواندن داده‌های تاریخچه تماشا در Cassandra حدود 9 به 1 است).

نتفلیکس بیش از 50 خوشه Cassandra، بیش از 500 نود، بیش از 30 ترابایت پشتیبان‌گیری روزانه و بزرگ‌ترین خوشه با 72 نود دارد. هر خوشه بیش از 250K نوشتار در ثانیه را پشتیبانی می‌کند. ابتدا، تاریخچه تماشا در Cassandra در یک ردیف ذخیره می‌شد. با افزایش تعداد کاربران در نتفلیکس، اندازه ردیف‌ها و حجم داده‌ها افزایش یافت. این باعث افزایش حجم ذخیره‌سازی، هزینه عملیاتی بیشتر و کاهش عملکرد برنامه شد. راه‌حل این مشکل فشرده‌سازی ردیف‌های قدیمی بود.

نتفلیکس داده‌ها را به دو بخش تقسیم کرد:

· تاریخچه تماشای زنده (LiveVH): شامل تعداد کمی از داده‌های تاریخی تماشای اخیر کاربران با به‌روزرسانی‌های مکرر است. این داده‌ها به صورت فشرده‌نشده برای کارهای ETL استفاده می‌شوند.

· تاریخچه تماشای فشرده (CompressedVH): شامل بخشی از سوابق تماشای قدیمی‌تر با به‌روزرسانی‌های نادر است. داده‌ها در یک ستون در هر کلید ردیف ذخیره می‌شوند و به صورت فشرده برای کاهش اثر پایین‌تر ذخیره‌سازی ذخیره می‌شوند.

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

نتفلیکس با شروع از یک معماری ساده مونولیتیک، به مرور زمان و با افزایش تعداد کاربران، نیاز به معماری پیچیده‌تر و مقیاس‌پذیرتری پیدا کرد. به همین دلیل، این شرکت به سمت استفاده از معماری میکروسرویس‌ها و معماری بدون سرور حرکت کرد تا بتواند نیازهای در حال رشد خود را برآورده سازد.

ویژگی اصلی این معماری جدید، تفکیک سرویس‌های مختلف به میکروسرویس‌های کوچکتر، مستقل و به شدت گسترده پذیر است. همچنین استفاده از زیرساخت ابری و سرویس‌های آمازون، موجب افزایش انعطاف‌پذیری، در دسترس بودن و مقیاس‌پذیری شده است.

علاوه بر معماری، نتفلیکس در زمینه پردازش داده‌ها و سیستم‌های توصیه‌گر هم سرمایه‌گذاری قابل توجهی انجام داده است که باعث شده یکی از بهترین سرویس‌های پخش ویدیوی تقاضا‌محور در جهان باشد.

در مجموع می‌توان گفت که نتفلیکس با تکیه بر معماری‌های نوین، سیستم‌های توصیه‌گر و یادگیری ماشین، خدمات خود را به طور مداوم بهینه کرده و رضایت مشتریان خود را حفظ نموده است.

آمازون

در این قسمت ابتدا داستان و تاریخچه شرکت امازون را تعریف میکنیم و در هر بازه ی زمانی معماری های مختلف آن را در ان زمان و قسمت هاهی جدیدی که به آن اضافه می شود را بررسی میکنیم .

در دل گاراژی در سیاتل، واشنگتن، جرقه‌ای زده شد که به تولد یکی از غول‌های دنیای فناوری انجامید. جف بیزوس، در سال ۱۹۹۴، با فروش کتاب در وب نوپای آن زمان، بذر شرکتی را کاشت که امروزه به نام آمازون می‌شناسیم. اگرچه این کمپانی برای عموم مردم با پلتفرم خرده‌فروشی‌اش شناخته شده است، اما بخش اعظم سود عملیاتی آن (تا سال ۲۰۲۴) از زیرمجموعه رایانش ابری‌اش، Amazon Web Services (AWS)، حاصل می‌شود. آمازون همچنین با پلتفرمBedrock در حال تبدیل شدن به رهبر هوش مصنوعی تولید متن(GenAI) است. این شرکت غول‌پیکر در عرصه رسانه نیز با مدل اشتراک سرگرمی و ورزشی Prime Video که محتوای اختصاصی هم ارائه می‌دهد، درگیر «جنگ‌های استریمینگ» است و برای جذب مخاطب رقابت می‌کند.

اما داستان آمازون فراتر از این خلاصه ابتدایی است. این شرکت آمریکایی چندملیتی، بر تجارت الکترونیک، رایانش ابری و پخش دیجیتال تمرکز دارد. آمازون را «یکی از تاثیرگذارترین نیروهای اقتصادی و فرهنگی جهان» لقب داده‌اند و از باارزش‌ترین برندهای دنیا به شمار می‌رود.

بنیانگذار آمازون، جف بیزوس، در سال ۱۹۹۴ از گاراژ خانه‌اش در بل‌вью، واشنگتن، دست به کار شد. شرکتی که او بنا نهاد، ابتدا به عنوان یک بازار آنلاین کتاب فعالیت می‌کرد، اما به مرور دامنه محصولاتش را گسترش داد و به «فروشگاه همه‌چیز» ملقب شد. امروزه، آمازون زیرمجموعه‌های متعددی دارد، از جمله AWS، زوکس (خودروهای خودران)، Kuiper Systems (اینترنت ماهواره‌ای)، Amazon Lab126 (تحقیق و توسعه سخت‌افزار کامپیوتری)، رینگ، توئیچ، IMDb، MGM Holdings وWhole Foods Market.

اما نفوذ آمازون به همین ختم نمی‌شود. این شرکت در صنایع مختلفی از جمله لجستیک، تولید محتوا، هوش مصنوعی و حتی هوافضا نیز فعالیت دارد. آن‌ها با خرید Whole Foods Market وارد عرصه خواربارفروشی شدند و با راه‌اندازی Prime Video به میدان سرگرمی‌های خانگی قدم گذاشتند. همچنین سرمایه‌گذاری‌های کلانی در حوزه‌هایی مانند تحویل با پهپاد و دستیارهای صوتی هوشمند انجام داده‌اند.

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

با وجود این چالش‌ها، آمازون به راه خود ادامه می‌دهد و همچنان در حال نوآوری و توسعه است. آینده این غول فناوری چه خواهد بود؟ آیا همچنان به رشد تصاعدی خود ادامه می‌دهد یا با موانعی جدی روبرو خواهد شد؟ تنها زمان پاسخ این سوالات را خواهد داد.

تاسیس شرکت آمازون

امازون، که ابتدا به عنوان یک فروشنده کتاب آنلاین شروع به کار کرد، تبدیل به یک عامل مهم تغییر در بخش‌ها و صنایع مختلف شده است. شرکت توسط جف بزوس، ویس پرزیدنت سابق شرکت دی. ای. شاو & کو، در سال 1994 در واشنگتن تأسیس شد. او شرکت را ابتدا با نام کادابرا ثبت کرد، اما پس از چند ماه به امازون تغییر نام داد، زیرا یک وکیل نام آن را اشتباه شنیده بود. انتخاب این نام به دلیل ویژگی‌هایی مانند بزرگترین رودخانه جهان بوده و بزوس قصد داشت فروشگاهی بسازد که بزرگترین کتابفروشی جهان باشد.

امازون با سرویس‌های فروشنده‌های ثالث، سرویس‌های اشتراک و تبلیغات ریشه دوانده است. همواره هدف خود را گسترش فروش با "بهبود تمام جنبه‌های تجربه مشتری، از جمله کاهش قیمت‌ها، بهبود در دسترسی، ارائه زمان‌های تحویل سریعتر، افزایش انتخاب، گسترش اطلاعات محصول، بهبود سهولت استفاده و کسب اعتماد مشتری" اعلام کرده است.

امازون به عنوان یک "مختل نما" کلاسیک در تاریخ، برای ایجاد تغییرات گسترده، نیازمند اختراع (و گاهی خرید) فناوری‌ها و روش‌های جدید بوده است. نوآوری‌های امازون، از جمله دستگاه خواندن الکترونیکی کیندل و خط تولید محصولات خانه هوشمند اکو، نه تنها تجربه مشتری را بهبود بخشیده، بلکه نحوه انجام معاملات توسط افراد و شرکت‌ها را نیز تغییر داده است.

در ابتدای کار، امازون از گاراژ خانه بزوس در خیابان نورث‌ایست 28 در بلویو، واشنگتن اداره می‌شد. امازون با گذشت زمان، با توسعه در بخش‌های مختلف و ایجاد تغییرات چشمگیر در نحوه خرید و فروش آنلاین، به یکی از بزرگترین شرکت‌های جهان تبدیل شده است.

سال 1995 پلتفرم فروش کتاب :

سال 1995، آغازی مهم در تاریخ امازون بود. جف بزوس، سومین ثروتمند جهان (تا سال 2024)، امازون را تنها به عنوان یک فروشنده کتاب نمی‌دید. او از ابتدا امازون را یک شرکت فناوری می‌دانست، این نگرشی بود که توسط بسیاری از منتقدان مورد تمسخر قرار گرفت

با توجه به تحقیقات خود، بزوس کتاب‌ها را به عنوان نقطه ورودی آسان به تجارت الکترونیک می‌دید. او یک وب‌سایت خرده‌فروشی جامع را پیش‌بینی می‌کرد که در نهایت به دنیای فروشگاه‌های بزرگ، فروشگاه‌های ورزشی، جواهرات، فروشگاه‌های موسیقی و ویدئو، فروشگاه‌های مستقل و هر چیز دیگری گسترش می‌یابد. شعار او "سریع بزرگ شو" بود، که این شعار را بر روی تی‌شرت‌های کارمندان چاپ کرده و به سرعت ثابت کرد که یک استراتژی برنده است. مانند بسیاری از شرکت‌های نوپای اوایل، اوایل امازون با زیان‌های فصلی مواجه بود. هرچند فروش و نقدینگی آن پرقدرت بودند، اما بسیاری از دلارهای آغازین به کارهایی چون توسعه سریع، بهینه‌سازی زمان تحویل، مدیریت و رصد موجودی و بهبود پلتفرم آنلاین چرخانده می‌شدند. امازون تا سال 2003، چهار سال پس از عرضه عمومی اولیه در سال 1997، سود خود را ثبت نکرد.

استراتژی اولیه امازون به عنوان یک فروشنده بدون موجودی بود، اما به زودی دریافت که برای دستیابی به کنترل بیشتر در تحویلات نیاز به انبارها دارد. پس از عرضه عمومی در سال 1997، شرکت آغاز به ساخت یک مجموعه رشدی از انبارها کرد، از انبارهای بزرگ تا انبارهای کوچک در تقریباً هر گوشه‌ای از کشور.

علاوه بر این، بزوس پس از خواندن یک گزارش درباره آینده اینترنت که رشد تجارت وب را در 2300 درصد پیش‌بینی کرده بود، لیستی از 20 محصول که می‌توانستند آنلاین بازاریابی شوند، ایجاد کرد. او این لیست را به پنج محصول واعظتان محدود کرد که شامل: دیسک‌های کوچک، سخت‌افزار کامپیوتر، نرم‌افزار کامپیوتر، ویدئوها و کتاب‌ها بودند. بزوس در نهایت تصمیم گرفت که کسب و کار جدید خود را به فروش کتاب‌ها آنلاین اختصاص دهد، به دلیل تقاضای جهانی بزرگ برای ادبیات، قیمت واحد کتاب‌ها و تعداد زیادی از عناوین موجود در چاپ. در 16 ژوئیه 1995، آمازون به عنوان یک فروشنده کتاب آنلاین آغاز به کار کرد و دنیایی از کتاب‌ها را به هر کسی با دسترسی به وب جهانی فروخت. اولین کتابی که در آمازون فروخته شد، کتاب "مفاهیم جاری و تشابه‌های خلاقانه" نوشته Douglas Hofstadter بود. در دو ماه اول فعالیت، آمازون به تمامی 50 ایالت آمریکا و بیش از 45 کشور فروخته بود و فروش آمازون به 20,000 دلار هفتگی رسید.

سال ۱۹۹۵ یک نقطه عطف مهم در تاریخ تجارت الکترونیک بود. در آن سال، جف بزوس، کارآفرین باهوش و آینده‌نگر، با راه اندازی آمازون به عنوان یک پلتفرم آنلاین فروش کتاب، جرقه‌ای زد که بعدها به غول فناوری امروز تبدیل شد. اما داستان آمازون فراتر از یک فروشگاه کتاب اینترنتی ساده است. در این متن، تلاش می‌کنیم با تلفیق دو منبع به همراه اطلاعات اضافی، تصویری جامع از آن دوران اولیه و اهمیت سال ۱۹۹۵ برای این شرکت ترسیم کنیم.

بزوس که در آن زمان ثروتش به اندازه امروز افسانه‌ای نبود، اما دیدگاهی بلندمدت داشت. او آمازون را صرفاً یک کتابفروش نمی‌دید، بلکه آن را یک شرکت فناوری می‌پنداشت. این طرز فکر در ابتدا توسط بسیاری تمسخر می‌شد، اما زمان به درستی بزوس گواهی داد. او معتقد بود که کتاب‌ها یک نقطه ورود آسان به تجارت الکترونیک هستند و از همان ابتدا چشم‌اندازی وسیع‌تر، با در بر گرفتن فروشگاه‌های بزرگ، ورزشی، جواهر فروشی و حتی خواربارفروشی‌ها، در ذهن داشت. شعار او «سریع بزرگ شو» بود که روی تی‌شرت کارمندان نقش می‌خورد و به سرعت به استراتژی برنده تبدیل شد.

روزهای اولیه آمازون مانند بسیاری از استارت‌آپ‌ها با ضررهای فصلی همراه بود. با وجود فروش و جریان نقدینگی خوب، بخش زیادی از این درآمدها برای توسعه‌ی سریع به کسب‌و‌کار بازگردانده می‌شد. تمرکز اصلی بر پیشرفت‌های فناوری برای بهبود زمان تحویل، مدیریت و ردیابی موجودی و بهینه‌سازی پلتفرم آنلاین بود. جالب است بدانید که آمازون تا سال ۲۰۰۳، یعنی شش سال پس از عرضه اولیه سهام در سال ۱۹۹۷، اولین سود خود را ثبت نکرد.

یکی از استراتژی‌های اولیه بزوس، راه‌اندازی آمازون بدون انبار بود. اما او زود متوجه شد که برای کنترل بیشتر بر تحویل‌ها به انبارها نیاز دارد. پس از عرضه اولیه سهام در سال ۱۹۹۷، این شرکت شبکه‌ای رو به رشد از انبارهای بزرگ و کوچک در سراسر کشور ایجاد کرد.

اما چرا ۱۹۹۵ برای آمازون اهمیت ویژه‌ای داشت؟ در این سال، پس از مطالعه گزارشی درباره آینده اینترنت و پیش‌بینی رشد ۲۳۰۰ درصدی تجارت الکترونیک، بزوس فهرستی از ۲۰ محصول که می‌توانستند به صورت آنلاین به فروش برسند، تهیه کرد. او در نهایت با در نظر گرفتن تقاضای جهانی بالا، قیمت پایین کتاب و تعداد زیاد عناوین موجود، تصمیم گرفت روی فروش آنلاین کتاب تمرکز کند. در ۱۶ جولای ۱۹۹۵، آمازون رسماً به عنوان یک کتابفروش آنلاین افتتاح شد و بزرگترین مجموعه کتاب‌های جهان را برای هر کسی که به وب دسترسی داشت، عرضه کرد. اولین کتاب فروخته شده، «مفاهیم سیال و قیاس‌های خلاقانه» اثر داگلاس هافستادر بود. طی دو ماه اول فعالیت، آمازون به تمام ۵۰ ایالت آمریکا و بیش از ۴۵ کشور کتاب فروخت.

سال ۱۹۹۵ تنها نقطه آغاز ماجرای آمازون نبود، بلکه تولد غول فناوری بود که امروز می‌شناسیم. این شرکت با تمرکز بر نوآوری، توجه به مشتری و گسترش مداوم فعالیت‌های خود، توانست از یک پلتفرم ساده‌ی فروش کتاب به ابرقدرتی در عرصه تکنولوژی و تجارت الکترونیک تبدیل شود. مسیر موفقیت آمازون همچنان ادامه دارد و این شرکت همچنان در حال تغییر شکل بخشیدن به نحوه تعامل ما با دنیای دیجیتال است.

معماری مونولیتیک آمازون در سال ۱۹۹۵
در سال ۱۹۹۵، زمانی که آمازون به عنوان یک پلتفرم آنلاین فروش کتاب راه اندازی شد، از معماری مونولیتیک استفاده می‌کرد. در این معماری، تمام کد و داده‌های برنامه در یک واحد واحد قرار دارند. این امر باعث می‌شود که توسعه و نگهداری برنامه ساده‌تر باشد، زیرا همه چیز در یک مکان قرار دارد. این معماری برای شرکت‌های نوپا و کسب‌وکارهای کوچکتر با تمرکز محدود محصولات، مانند آمازون در ابتدای کار، مزایایی داشت. معماری مونولیتیک به آمازون این امکان را می‌داد تا به سرعت رشد کند و در عین حال بر توسعه و نگهداری سیستم خود تمرکز کند، چرا که تمام کدها و سرویس‌ها در یک پایگاه کد یکپارچه قرار داشتن

مزایا و معایب معماری مونولیتیک برای آمازون

• سرعت: زمان لازم برای توسعه و راه‌اندازی برنامه کوتاه‌تر بود.
• هزینه: هزینه‌های توسعه و نگهداری برنامه کاهش یافت.
• سادگی توسعه و نگهداری: تمامی اجزاء نرم‌افزاری در یک مکان قرار داشتند که باعث سهولت در توسعه و نگهداری می‌شد.
• همگرایی: از آنجا که همه بخش‌ها بخشی از یک سیستم یکپارچه بودند، هماهنگی و یکپارچگی بالاتری در عملکردها وجود داشت.
• تست آسان‌تر: تست کردن یک سیستم مونولیتیک نسبت به سیستم‌های پراکنده یا مبتنی بر میکروسرویس‌ها ساده‌تر بود.
• قابلیت نگهداری: در صورت تغییر در یک قسمت از برنامه، ممکن بود سایر قسمت‌ها نیز تحت تأثیر قرار بگیرند.
• ایمنی: برنامه آسیب‌پذیری بیشتری در برابر حملات امنیتی داشت.
• کمبود انعطاف‌پذیری: با افزایش اندازه و پیچیدگی برنامه، ایجاد تغییرات یا افزودن قابلیت‌های جدید دشوارتر می‌شد.
• مقیاس‌پذیری محدود: مقیاس‌بندی یک سیستم مونولیتیک بزرگ به مراتب دشوارتر است، چرا که تغییر در هر بخش نیازمند تغییرات در کل سیستم است.
• وابستگی به زبان برنامه‌نویسی و تکنولوژی: سیستم‌های مونولیتیک اغلب به یک زبان برنامه‌نویسی و مجموعه‌ای از تکنولوژی‌ها وابسته هستند، که انعطاف‌پذیری را در استفاده از تکنولوژی‌های جدید کاهش می‌دهد.

چرا آمازون معماری مونولیتیک خود را تغییر داد؟

با رشد آمازون و گسترش محصولات و خدمات آن، معماری مونولیتیک دیگر پاسخگو نبود. این معماری نمی‌توانست حجم ترافیک و تنوع محصولات جدید را مدیریت کند. علاوه بر این، معماری مونولیتیک قابل نگهداری نبود و امنیت آن نیز ضعیف بود.

سال 2000 آغاز عصر خدمات شخص ثالث

در سال ۲۰۰۰، آمازون با هدف تبدیل شدن به بزرگترین فروشگاه آنلاین جهان، درهای خود را به روی فروشندگان شخص ثالث باز کرد و به خرده‌فروشان مستقل این امکان را داد تا طیف گسترده‌ای از کالاهای جدید، دست دوم، بازسازی شده و یا منحصر به فرد خود را در این پلتفرم ارائه دهند. آمازون در ازای دریافت هزینه‌های تراکنش، میزبان این پلتفرم و انجام بسیاری از کارهای لجستیکی را بر عهده می‌گرفت.

راه‌اندازی خدمات شخص ثالث آمازون در سال ۲۰۰۰ منجر به ظهور سرویس Fulfillment by Amazon (FBA) شد. این سرویس به فروشندگان شخص ثالث اجازه می‌داد موجودی خود را به آمازون ارسال کنند و در ازای هزینه‌ای اضافی، آمازون محصولات را انبار، ارسال و بازگرداندن آنها را به عهده می‌گرفت. گزینه دیگر Fulfilled by Merchant (FBM) یا Merchant Fulfilled Network (MFN) است که فروشنده موظف است تمام امور لجستیکی (انبار، حمل و نقل و پردازش بازگرداندن) را خود انجام دهد.

توسعه خدمات آمازون برای فروشندگان

آمازون با ارائه محصولات و خدمات جدید، همکاری خود را با فروشندگان تقویت می‌کند. برخی از این خدمات عبارتند از: ادغام انبارداری و توزیع انبار، خدمات تحویل، مدیریت حمل و نقل و موجودی، و خدمات مدیریت ارتباط با مشتری (CRM) در مشارکت‌های خود. این شرکت همچنین یک بازوی مالی، Amazon Lending، را ارائه می‌دهد که به فروشندگان واجد شرایط امکان وام گرفتن تا ۵ میلیون دلار را می‌دهد.

بخش خدمات فروشنده شخص ثالث همچنان در حال رشد است و در سال ۲۰۲۳، تقریباً ۶۰ درصد از فروش را به خود اختصاص داده است.

عبور از بحران و تبدیل شدن به یک غول فناوری

علیرغم انتظارات آمازون مبنی بر عدم سودآوری تا چهار تا پنج سال، سرمایه‌گذاران از رشد نسبتاً کند این شرکت شکایت کردند و معتقد بودند که آمازون به اندازه کافی سریع سودآوری نمی‌کند تا سرمایه‌گذاری آنها را توجیه کند یا حتی در بلندمدت زنده بماند. در سال ۲۰۰۱، حباب دات کام ترکید و بسیاری از شرکت‌های الکترونیکی را نابود کرد، اما آمازون زنده ماند و پس از سقوط فناوری به پیش رفت تا تبدیل به یک بازیگر بزرگ در فروش آنلاین شود. این شرکت سرانجام در سه‌ماهه چهارم سال ۲۰۰۱ اولین سود خود را به دست آورد: ۰.۰۱ دلار (یعنی ۱ سنت) به ازای هر سهم، با درآمدی بیش از ۱ میلیارد دلار. این حاشیه سود، هرچند بسیار ناچیز بود، به منتقدان ثابت کرد که مدل تجاری غیرمعمول بزوس می‌تواند موفق باشد.

سال 2000 تا 2002 و همچنان معماری مونولیتیک

از سال ۲۰۰۰ تا ۲۰۰۲، آمازون مثل قبل از معماری مونولیتیک استفاده می‌کرد. در مورد این معماری و مزایای ان صحبت کردیم در طول پروژه . اما یواش یواش زمان ان بود که دیگر امازون از این معماری عبور کند و به سمت معماری های جدید تر برود . امازون در سال ۲۰۰۰ با راه‌اندازی خدمات شخص ثالث خود، شروع به رشد سریع کرد. این رشد سریع، نیاز به مقیاس‌پذیری بیشتری را برای معماری مونولیتیک آمازون ایجاد کرد و مقدمات اولیه برای رفتن به سمت معماری میکروسرویس داشت ایجاد می شد.

سال 2002 وب سرویس آمازون

سال 2002، شاهد شروعی بزرگ در تاریخ آمازون بودیم: معرفی Amazon Web Services . آمازون وب سرویس ابتدا به عنوان راه حلی برای نیازهای خود آمازون طراحی شد، اما بزودی به پلتفرمی برای سایر کسب‌وکارها تبدیل شد تا بتوانند برنامه‌های خود را در فضای ابری بسازند، مستقر کنند و گسترش دهند.در سال 2002، آمازون با هدف تبدیل شدن به یک فناوری پیشرو، خدمات رایانش ابری خود را با نام Amazon Web Services (AWS) راه اندازی کرد. AWS در ابتدا برای پشتیبانی از نیازهای تجارت الکترونیک خود آمازون طراحی شده بود، اما به سرعت در دسترس سایر کسب‌وکارها قرار گرفت تا به آنها کمک کند تا برنامه‌های خود را در فضای ابری ایجاد، مستقر و مقیاس‌بندی کنند.

آمازون وب سرویس یک پلتفرم رایانش ابری است که توسط آمازون ارائه می‌شود. به زبان ساده، AWS به کسب‌وکارها و توسعه‌دهندگان امکان می‌دهد تا بدون نیاز به خرید و نگهداری سخت‌افزارهای گران‌قیمت، منابع محاسباتی مانند سرورها، ذخیره‌سازی داده‌ها و پایگاه‌های داده را از طریق اینترنت استفاده کنند.

برخی از خدمات پر استفاده که امازون ارائه می دهد عبارتند از :

• رایانش: AWS منابع محاسباتی مقیاس‌پذیر را در فضای ابری ارائه می‌دهد.
• ذخیره‌سازی: AWS راه‌حل‌های ذخیره‌سازی متنوعی را در فضای ابری ارائه می‌دهد.
• پایگاه داده: AWS پایگاه‌های داده متنوعی را در فضای ابری ارائه می‌دهد.
• شبکه: AWS خدمات شبکه‌ای متنوعی را در فضای ابری ارائه می‌دهد.
• تجزیه و تحلیل: AWS خدمات تجزیه و تحلیل داده‌های متنوعی را در فضای ابری ارائه می‌دهد.
• یادگیری ماشین: AWS خدمات یادگیری ماشین متنوعی را در فضای ابری ارائه می‌دهد.
• امنیت: AWS خدمات امنیتی متنوعی را در فضای ابری ارائه می‌دهد.

آمازون وب سرویس اکنون بزرگترین پلتفرم رایانش ابری در جهان است AWS با ارائه بیش از 200 خدمت مختلف، از جمله در زمینه‌های محاسبات، ذخیره‌سازی، پایگاه داده، شبکه، تحلیل داده‌ها، یادگیری ماشین، امنیت و بیشتر، به پلتفرم پیشرو در زمینه رایانش ابری تبدیل شده است.

امازون وب سرویس در اوایل فعالیت خود شاهد نوآوری و رشد سریع بود. در سال 2007، AWS سرویس Amazon S3 (Simple Storage Service) را راه‌اندازی کرد که راه‌حلی قابل اطمینان و مقیاس‌پذیر برای ذخیره‌سازی داده‌های کسب‌وکارها ارائه می‌کرد. این موضوع با راه‌اندازی Amazon EC2 (Elastic Compute Cloud) در سال 2008 دنبال شد که منابع محاسباتی قابل مقیاس‌پذیری در فضای ابری فراهم کرد.

آمازون وب سرویس از زمان تأسیس خود توسط جف بزوس، با هدف ایجاد یک پلتفرم که کسب‌وکارها بتوانند فضای محاسباتی را اجاره کنند، رشد کرده است. این شرکت با عرضه خدماتی مانند EC2 و S3، که چگونگی ساخت برنامه‌های موبایلی توسط توسعه‌دهندگان را تغییر داد، به یک رهبر در زمینه رایانش ابری تبدیل شد.

تا سال 2023، AWS حدود یک‌سوم بازار ابری را در اختیار دارد، پیشتاز از Microsoft’s Azure (23%) و Alphabet’s Google Cloud (11%). همچنین، AWS یک کسب‌وکار بسیار سودآور برای آمازون است، به طور تاریخی حدود 15 تا 18 درصد از کل فروش را تشکیل می‌دهد، اما تقریباً 50 درصد از درآمد عملیاتی شرکت را تولید می‌کند. امروزه توسط میلیون‌ها کسب‌وکار در سراسر جهان استفاده می‌شود و به عنوان پیشرو در پلتفرم رایانش ابری شناخته می‌شود. این شرکت همچنان به نوآوری و معرفی خدمات و ویژگی‌های جدید ادامه می‌دهد تا به نیازهای متغیر مشتریان خود پاسخ دهد.

برخی از بزرگ ترین مشتریان این شرکت عبارتند از :

Netflix، Airbnb ، Spotify ، Lyft ، Yelp ، The New York Times ، The Washington Post، The BBC

برخی از مهم ترین خدمات ارائه شده توسط aws

• یک) Amazon Route 53:

سرویس DNS برای مدیریت نام دامنه و ارائه خدمات DNS. این سرویس به شما امکان می دهد تا نام دامنه های خود را مدیریت کنید و خدمات DNS را برای وب سایت ها، برنامه های کاربردی ، خدمات وب ، شبکه های خصوصی و سایر منابع آنلاین خود ارائه دهید.

مدیریت نام دامنه: می توانید نام دامنه های خود را ثبت کنید، رکوردهای DNS را ایجاد و مدیریت کنید، و تنظیمات DNS خود را به طور کامل کنترل کنید.

دسترسی بالا : Route 53 از زیرساخت جهانی AWS برای ارائه خدمات DNS با قابلیت اطمینان بالا استفاده می کند.

سرعت: Route 53 از تکنیک های مختلفی برای سرعت بخشیدن به زمان پاسخگویی DNS استفاده می کند.

امنیت: Route 53 از اقدامات امنیتی مختلفی برای محافظت از نام دامنه ها و داده های DNS شما استفاده می کند.

قابلیت مقیاس پذیری: Route 53 می تواند به راحتی برای پشتیبانی از ترافیک DNS در هر اندازه ای مقیاس بندی شود.

قیمت گذاری مقرون به صرفه: Route 53 بر اساس تعداد رکوردهای DNS و ترافیک پرس و جو که شما استفاده می کنید، قیمت گذاری می شود.

• دو ) Amazon CloudFront: شبکه تحویل محتوا (CDN) برای توزیع سریعتر و با تاخیر کمتر محتوا. CDN ها شبکه ای از سرورها هستند که در سراسر جهان توزیع شده اند و برای ارائه محتوای وب به کاربران با سرعت و تاخیر کمتر استفاده می شوند. CloudFront محتوای وب شما را از سرورهای نزدیک به کاربران شما ارائه می دهد، که منجر به سرعت بارگذاری سریعتر و تجربه کاربری بهتر می شود. همچنین می تواند به راحتی برای پشتیبانی از ترافیک وب در هر اندازه ای مقیاس بندی شود. CloudFront از اقدامات امنیتی مختلفی برای محافظت از محتوای وب شما استفاده می کند. یکی دیگر از مزایای استفاده از CloudFront این است که از زیرساخت جهانی AWS برای ارائه خدمات CDN با قابلیت اطمینان بالا استفاده می کند به همین خاطر قابلیت اطمینان بالایی دارد و به خاطر اینکه بر اساس ترافیک داده ای که شما استفاده می کنید، قیمت گذاری می شود بسیار مقرون به صرفه است.
• سه ) Elastic Load Balancing (ELB): توزیع خودکار و هدایت ترافیک برای برنامه های توزیع شده. ELB ترافیک ورودی را به طور خودکار بین چندین هدف، مانند Amazon EC2 instances یا containers، توزیع می کند. این کار به منظور افزایش قابلیت اطمینان، مقیاس پذیری و عملکرد برنامه های شما انجام می شود. ELB ترافیک ورودی را به طور خودکار بین اهداف سالم توزیع می کند و نیازی به تنظیمات دستی یا اضافی نیست و همچنین به راحتی برای پشتیبانی از ترافیک در هر اندازه ای مقیاس بندی شود و از این موضوع هم مشکلی ندارد . و مانند بقیه محصولات امنیت و اطمینان بالایی دارد و کاملا مقرون به صرفه است . از elb می شود در قسمت های مختلفی استفاده کرد مثلا می توان برای توزیع ترافیک ورودی به برنامه های وب خود بین چندین سرور برنامه استفاده کنید، می توانید برای توزیع ترافیک ورودی به API های خود بین چندین سرور API استفاده کنید، می توانید برای توزیع ترافیک ورودی به شبکه های خصوصی خود بین چندین سرور داخلی استفاده کنید و ...
• چهار ) AWS Shield: محافظت در برابر حملات DDoS .

این سرویس برای محافظت از برنامه ها و منابع شما در برابر حملات Distributed Denial-of-Service (DDoS) طراحی شده است. AWS Shield می تواند از شما در برابر حملات DDoS لایه 3 و 4، مانند SYN floods، UDP floods و ICMP floods محافظت کند. این محافظت کاملا خودکار است و این سرویس به طور خودکار حملات DDoS را شناسایی و مسدود می کند. و مانند بقیه سرویس های امازون وب سرویس کاملا مقیاس پذیر و به صرفه است . البته این سرویس به دو صورت استاندارد و پیشرفته ارائه می شود. نسخه ی استاندارد به صورت رایگان برای همه مشتریان AWS ارائه می شود و محافظت در برابر حملات DDoS لایه 3 و 4 را ارائه می دهد. اما نسخه ی پیشرفته برای مشتریانی که به محافظت DDoS پیشرفته تری نیاز دارند، مانند محافظت در برابر حملات لایه 7، محافظت از برنامه های وب و پشتیبانی 24/7، در دسترس است و باید برای آن هزینه جداگانه ای پرداخت کنید .

• پنج ) Amazon ElastiCache: ذخیره سازی داده در حافظه برای افزایش سرعت و مقیاس پذیری برنامه ها.

یک سرویس ذخیره سازی داده در حافظه است که توسط Amazon Web Services (AWS) ارائه می شود. این سرویس برای افزایش سرعت و مقیاس پذیری برنامه های شما با ذخیره داده های frequently accessed در حافظه (RAM) طراحی شده است. ElastiCache می تواند تاخیر را به طور قابل توجهی کاهش دهد و عملکرد برنامه شما را به طور قابل توجهی افزایش دهد. همچنین می تواند به راحتی برای ذخیره سازی حجم عظیمی از داده ها مقیاس بندی شود. همچنین بر اساس مقدار داده ای که ذخیره می کنید، قیمت گذاری می شود پس کاملا مقرون به صرفه است و هزینه ی اضافی پرداخت نمیکنید . ElastiCache از دو موتور ذخیره سازی داده در حافظه اصلی پشتیبانی می کند: اولی Redis است که یک پایگاه داده NoSQL منبع باز است که به دلیل سرعت و عملکرد بالا شناخته شده است و دومی Memcached است که یک سیستم ذخیره سازی داده-ارزش ساده است که به دلیل سرعت و مقیاس پذیری بالا شناخته شده است. از این سرویس استفاده های مختلفی می شود مانند : می تواند برای ذخیره سازی داده های پویا، مانند اشیاء جلسه، سبدهای خرید و داده های بازی، استفاده شود ، می تواند برای ذخیره سازی نتایج پرس و جو پایگاه داده، به منظور کاهش زمان پاسخگویی پرس و جو، استفاده شود ، می تواند برای ذخیره سازی داده های کش، به منظور افزایش سرعت دسترسی به داده ها، استفاده شود. به صورت کلی می توان گفت ElastiCache یک ابزار قدرتمند و انعطاف پذیر است که می تواند برای افزایش سرعت و مقیاس پذیری برنامه های شما استفاده شود.

و تعداد زیادی سرویس دیگر که نمی توانیم همه ی ان هارا در این جا توضیح دهیم مانند Amazon Relational Database Service (Amazon RDS): سرویس مدیریت پایگاه داده رابطه ای ، Amazon Simple Storage Service (Amazon S3): سرویس ذخیره سازی برای ذخیره و مدیریت داده ها به صورت آنلاین و سرویس های دیگر ....

شروع معماری ابری در آمازون سال 2002

آمازون از معماری ابری اولین بار سال 2002 استفاده کرد البته اون موقع صرفا برای مصارف خود شرکت استفاده میکرد و تا سال 2006 به همین صورت ادامه داشت . معماری ابر رو در قسمت معماری ها به صورت کامل توضیح دادیم و اگر بخوایم به صورت خلاصه بگیم معماری ابر به چارچوبی کلی اشاره دارد که اجزای مختلف یک سیستم رایانش ابری را به هم مرتبط می‌کند. این معماری شامل زیرساخت‌ها: شامل لایه‌های فیزیکی مانند سرورها، شبکه‌ها، ذخیره‌سازی و مراکز داده می‌شود ، پلتفرم‌ها: شامل نرم‌افزارها و ابزارهایی است که برای توسعه و استقرار برنامه‌های کاربردی در ابر استفاده می‌شوند و برنامه‌های کاربردی: شامل برنامه‌هایی هستند که در فضای ابری اجرا می‌شوند ، است که در کنار هم یک محیط ابر را تشکیل می‌دهند. این سه بخش قسمت های اصلی معماری ابر هستند . امازون از سال 2006 با راه‌اندازی Amazon Web Services (AWS) به عنوان یک پلتفرم رایانش ابری، به طور فزاینده‌ای از این فناوری استفاده می‌کند و ان را در خدمت کاربران و مشتریان خود قرار می دهد.

چارچوب‌های معماری ابر:

• مدل SaaS (Software as a Service): در این مدل، نرم‌افزار به عنوان یک سرویس از طریق اینترنت ارائه می‌شود. کاربران می‌توانند بدون نیاز به نصب یا نگهداری نرم‌افزار، از آن استفاده کنند.
• مدل PaaS (Platform as a Service): در این مدل، یک پلتفرم برای توسعه و استقرار برنامه‌های کاربردی ارائه می‌شود. کاربران می‌توانند بدون نیاز به مدیریت زیرساخت، برنامه‌های خود را در این پلتفرم اجرا کنند.
• مدل IaaS (Infrastructure as a Service): در این مدل، زیرساخت‌های فناوری اطلاعات به عنوان یک سرویس ارائه می‌شود. کاربران می‌توانند از منابع محاسباتی، ذخیره‌سازی و شبکه به صورت مجازی و در فضای ابری استفاده کنند.

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

• تجارت الکترونیک: آمازون از AWS برای پشتیبانی از وب‌سایت تجارت الکترونیک خود، Amazon.com، و همچنین سایر پلتفرم‌های تجارت الکترونیک مانند Amazon Marketplace استفاده می‌کند.
• خدمات وب: آمازون از AWS برای ارائه خدمات وب مانند Amazon Prime Video، Amazon Music و Amazon Kindle استفاده می‌کند.
• رایانش ابری: آمازون از AWS برای ارائه خدمات رایانش ابری به سایر کسب‌وکارها استفاده می‌کند.
• هوش مصنوعی: آمازون از AWS برای توسعه و استقرار خدمات هوش مصنوعی مانند Amazon Rekognition و Amazon Lex استفاده می‌کند.
• یادگیری ماشین: آمازون از AWS برای توسعه و استقرار خدمات یادگیری ماشین مانند Amazon SageMaker و Amazon Polly استفاده می‌کند.

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

• مقیاس‌پذیری: معماری ابری به آمازون این امکان را می‌دهد تا به سرعت و به آسانی زیرساخت‌های خود را مقیاس‌بندی کند تا با تقاضای رو به رشد خود پاسخ دهند.
• قابلیت اطمینان: معماری ابری به آمازون این امکان را می‌دهد تا از داده‌ها و برنامه‌های خود در برابر خطاها و خرابی‌ها محافظت کند.
• امنیت: معماری ابری به آمازون این امکان را می‌دهد تا از داده‌ها و برنامه‌های خود در برابر تهدیدات امنیتی محافظت کند.
• کاهش هزینه: معماری ابری می‌تواند به آمازون در کاهش هزینه‌های فناوری اطلاعات کمک کند.
• افزایش سرعت و چابکی: آمازون می‌تواند به سرعت برنامه‌ها و خدمات جدید را توسعه و استقرار دهد.
• مجموعه وسیع خدمات: ارائه خدمات متنوع در حوزه های مختلف.
• استقرار سریع: امکان توسعه و به روز رسانی سریع برنامه ها و خدمات.
• مدیریت آسان: کنسول مدیریت کاربرپسند برای کمک به کاربران در مدیریت و نظارت بر منابع.

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

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

سال 2005 و بزرگ ترین اتفاق معماری آمازون

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

گسترش آمازون به حوزه کامپیوتر ابری با AWS (Amazon Web Services) و جمع‌سپاری با Amazon Mechanical Turk، حرکات استراتژیک مهمی بودند. AWS که در سال ۲۰۰۶ راه‌اندازی شد، به سرعت به یک بازیگر غالب در زمینه کامپیوتر ابری تبدیل شد. طیف وسیعی از خدمات ارائه شده توسط AWS شامل قدرت محاسباتی، گزینه‌های ذخیره‌سازی و سایر قابلیت‌ها است که برای کسب‌وکارها و افراد ضروری است. ورود زودهنگام و نوآوری‌های مداوم AWS به آن کمک کرد تا بخش قابل توجهی از زیرساخت اینترنت را تحت کنترل داشته باشد.

آمازون در سال ۲۰۰۵ سرویس Amazon Prime را راه‌اندازی کرد. این یک سرویس عضویت بود که حمل‌ونقل رایگان دو روزه در ایالات متحده آمریکا (به جز مناطق دورافتاده) را برای تمام خریدهای واجد شرایط با هزینه سالانه ثابت ۷۹ دلار ارائه می‌داد. این سرویس تجربه مشتری را با ارائه حمل‌ونقل سریع و رایگان به طور قابل توجهی بهبود بخشید. معرفی Amazon Prime یک حرکت استراتژیک برای افزایش وفاداری مشتریان و تشویق به خریدهای مکرر بود.

همچنین Amazon Mechanical Turk که در سال ۲۰۰۵ معرفی شد، یک بازار جمع‌سپاری است. این سرویس، کسب‌وکارها را با افرادی که قادر به انجام وظایفی هستند که کامپیوترها هنوز نمی‌توانند به طور مؤثر انجام دهند (مانند اعتبارسنجی داده‌ها و تحقیق) متصل می‌کند.

آمازون حدود سال ۲۰۰۶ سرویس Fulfillment by Amazon (FBA) را راه‌اندازی کرد. این سرویس به کسب‌وکارهای کوچک و فروشندگان ثالث امکان می‌داد تا از شبکه لجستیک و توزیع آمازون استفاده کنند. فروشندگان می‌توانستند محصولات خود را در مراکز تکمیل سفارش آمازون نگهداری کنند و زمانی که محصولی فروخته می‌شد، آمازون بسته‌بندی، حمل‌ونقل، خدمات مشتری و برگشت کالا را انجام می‌داد. این برای کسب‌وکارهای کوچک یک تغییر بازی بود، زیرا به آن‌ها دسترسی به پایگاه مشتریان گسترده و توانایی‌های لجستیکی درجه یک آمازون را می‌داد. همچنین تجربه مشتریان در Amazon.com را بهبود می‌بخشید، زیرا محصولات فروخته شده توسط فروشندگان ثالث که از FBA استفاده می‌کردند، واجد شرایط برای پیشنهادات حمل‌ونقل آمازون، از جمله مزایای Prime بودند.

در سال های بعد Amazon Kindle که در سال ۲۰۰۷ عرضه شد، روش مطالعه کتاب‌ها را متحول کرد. موفقیت آن منجر به افزایش فروش کتاب‌های الکترونیکی شد و تا سال ۲۰۱۰، فروش کتاب‌های الکترونیکی در آمازون از کتاب‌های فیزیکی پیشی گرفت. این تغییر نه تنها رفتار مصرف‌کنندگان را تغییر داد، بلکه بر صنعت نشر نیز تأثیر گذاشت.

از سال ۲۰۱۱ تا ۲۰۱۵، آمازون با ارائه خدمات پخش جریانی مانند Amazon Music و Amazon Video، حضور خود را در بخش سرگرمی گسترش داد. این سرویس‌های پخش، حضور آمازون را در بخش سرگرمی گسترده‌تر کردند. تا سال ۲۰۱۵، ارزش بازاری آمازون از والمارت پیشی گرفت که نشان‌دهنده گذار آمازون از یک خرده‌فروش آنلاین به یک غول فناوری متنوع بود.

مهاجرت به میکروسرویس
چرا آمازون از معماری مونولیتیک به سمت معماری میکروسرویس رفت؟ آمازون، به عنوان یکی از پیشگامان تجارت الکترونیک، در طول سال‌ها با رشد فزاینده‌ای روبرو بوده است. این رشد، چالش‌های متعددی را برای زیرساخت‌های فناوری اطلاعات این شرکت به وجود آورده است. یکی از این چالش‌ها، مقیاس‌پذیری سیستم‌های مونولیتیک بود.

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

• مقیاس‌پذیری دشوار: سیستم‌های مونولیتیک به سختی می‌توانند با افزایش ترافیک و تعداد کاربران همگام شوند و زمانی که روز به روز به ترافیک و کاربران وبسایت امازون افزوده میشد این اتفاق مانند عذاب بود.
• چابکی کم: تغییر و ارتقای این سیستم‌ها به دلیل وابستگی‌های متعدد، دشوار و زمان‌بر است و گاها لازم می شود از اول دوباره سیستم را طراحی کنند.
• پایداری ضعیف: بروز مشکل در یک بخش از سیستم می‌تواند کل سیستم را تحت تاثیر قرار دهد.
• سرعت توسعه پایین: وابستگی‌های متعدد در سیستم‌های مونولیتیک، سرعت توسعه و انتشار ویژگی‌های جدید را کاهش می‌دهد. و خودتان می توانید حدس بزنید برای امازون که دائم در حال نو آوری و توسعه بود این قضیه چه قدر دست و پا گیر بود.

آمازون هم مانند سایر شرکت‌های بزرگ از معماری مونولیتیک به معماری میکروسرویس رفتند به دلیل مزایایی که این تغییر در معماری به آنها ارائه داد. در معماری مونولیتیک، تمامی عملکردها در یک قطعه کد تجمیع شده و همگی به هم وابسته هستند. این باعث می‌شد که تغییر یا افزودن یک ویژگی به یک سامانه مونولیتیک مشکل و هزینه‌بر شود و تغییر یک ویژگی حتی ساده، فرآیند زمان‌بر و گرانی شود. هرچه تعداد تغییرات بیشتر شود، برنامه نویسی پیچیده‌تر می‌شود تا جایی که ارتقاء و افزایش مقیاس تقریباً غیرممکن می شد. با گذشت زمان ، شرکت‌ها نمی‌توانستند بدون شروع دوباره از ابتدا تغییراتی در کد خود اعمال کنند.

در این نقطه بود که توسعه‌دهندگان تصمیم گرفتند که عملکرد یک سامانه مونولیتیک را به میکروسرویس‌های کوچکتر و مستقل تقسیم کنند. میکروسرویس‌ها از طریق رابط‌های برنامه‌نویسی (API) به طور مستقل به یک معماری بر پایه میکروسرویس متصل می‌شوند. این معماری امکان توسعه، ارتقاء و مقیاس‌پذیری مستقل هر میکروسرویس را به شرکت‌ها ارائه می‌دهد. این امکان وجود دارد بدون نیاز به قطعی در خدمت‌رسانی، تاثیر منفی بر بخش‌های دیگر از برنامه یا نیاز به بازنگری دیگر میکروسرویس‌ها. این فرآیند ساده‌تر است و وقتی یک بخش از برنامه نیاز به تنظیم یا ارتقاء دارد این کار بدون تاثیر بر سایر بخش‌ها انجام می شود

علاوه بر این که این تغییر آن ها را از شر مشکلات منولیتیک راحت میکرد همچنین مزایای معماری میکروسرویس را هم به آن ها اضافه میکرد که دیگر شرایط خیلی بهتر از قبل می شد.

ویژگی های مهمی که میکروسرویس به آمازون می داد:

• مقیاس‌پذیری آسان: هر میکروسرویس به طور مستقل قابل مقیاس‌بندی است، که انعطاف‌پذیری و کارایی بیشتری را فراهم می‌کند.
• چابکی بالا: استقلال و وابستگی‌های محدود میکروسرویس‌ها، چابکی و سرعت عمل را در توسعه و استقرار تغییرات افزایش می‌دهد.
• پایداری بیشتر: جداسازی میکروسرویس‌ها، خطاها را محدودتر می‌کند و پایداری و قابلیت اطمینان سیستم را افزایش می‌دهد.
• سرعت توسعه بالا: تیم‌های توسعه می‌توانند به طور مستقل و همزمان روی بخش‌های مختلف سیستم کار کنند.

مهاجرت آمازون به میکروسرویس یک فرآیند پیچیده و زمان‌بر بود. این شرکت با استفاده از ابزارها و روش‌های مختلف، به تدریج سیستم‌های خود را به سمت این معماری جدید منتقل کرد. امروزه، آمازون به طور گسترده از میکروسرویس‌ها در سراسر سیستم‌های خود استفاده می‌کند. این امر به این شرکت کمک کرده است تا به یک رهبر در صنعت تجارت الکترونیک تبدیل شود و به طور مداوم خدمات نوآورانه و با کیفیتی را به مشتریان خود ارائه دهد. مهاجرت آمازون به میکروسرویس، یک نمونه موفق از چگونگی استفاده از این معماری برای غلبه بر چالش‌های مقیاس‌ پذیری است .

مراحل تبدیل و انتقال از مونولیتیک به میکروسرویس توسط آمازون :
خوب از انجایی که در این موارد اطلاعاتی در اینترنت نیست اکثر اطلاعات این بخش ها پیشبینی و تحلیل های شخصی خودمان است . بازسازی یک مونولیت یک کار پیچیده است. برنامه ریزی دقیق، اجرا و ارزیابی مداوم برای موفقیت ضروری است. با این حال، مزایای معماری میکروسرویس مانند مقیاس پذیری، انعطاف پذیری و قابلیت نگهداری، اغلب مزایای تلاش برای انتقال را توجیه می کند

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

• اشیاء داده و فعالیت هایی که سیستم روی آنها انجام می دهد را شناسایی کردند.
• این فعالیت ها معمولا به صورت توابع و متدهای نرم افزاری کدگذاری شده اند.
• اجزا را بر اساس نوع داده ها و فعالیت های مرتبط با آنها گروه بندی کردند.

مرحله ی بعدی ساده سازی و بازسازی اجزا بود

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

مرحله ی سوم شناسایی وابستگی های اجزا است

• با استفاده از تحلیل ایستا یا پویا، وابستگی های بین اجزا را شناسایی کردند.
• این کار به آن ها کمک کرد تا متوجه شوند که کدام اجزا را می توان با هم گروه بندی کرد.

مرحله ی چهارم شناسایی گروه های اجزا

• گروه هایی از اجزا را که از نظر منطقی به هم مرتبط بودند و می توانستند به میکروسرویس تبدیل شوند، شناسایی کردند.

مرحله پنجم ایجاد API برای رابط کاربری از راه دور :

• یک API یکپارچه طراحی کردند که رابط کاربری و برنامه های کاربردی بتوانند از آن برای دستکاری داده ها استفاده کنند.
• این API باید بدون شکستن سازگاری با نسخه های قبلی، قابل ارتقا و نسخه دار باشد.

مرحله ی ششم انتقال گروه های اجزا به ماکروسرویس ها:

• به عنوان یک مرحله میانی، گروه های اجزا را به پروژه های جداگانه و استقرارهای جداگانه منتقل کردند.
• هر ماکروسرویس باید به طور مستقل از خط لوله CI/CD سیستم قابل استقرار باشد.

مرحله هفتم انتقال ماکروسرویس ها به میکروسرویس ها

• اجزا، اشیاء داده و توابع را به تدریج از سیستم مونولیتیک خارج کرده و به میکروسرویس ها منتقل کردند.
• به خاطر داشته باشید که هر میکروسرویس مخزن داده خاص خود را نگهداری می کند و فقط مجموعه کوچکی از فعالیت ها را روی اشیاء داده درون آن مخزن انجام می دهد.

مرحله آخر استقرار و تست

• پس از آماده شدن یک ماکروسرویس یا میکروسرویس برای استقرار، تست یکپارچه و استقرار را انجام دهید.
• اطمینان حاصل کنید که سیستم مونولیتیک از سرویس جدید برای نیازهای داده ای خود به جای مخزن داده قدیمی استفاده می کند.
• تمام عملکردهایی که به داده های منتقل شده دسترسی دارند را در تمام رابط های کاربری آزمایش کنید تا مطمئن شوید که هیچ عملکردی هنوز سعی در استفاده از مخزن داده قدیمی ندارد.
• پس از اینکه آزمایش نشان داد که کد مونولیتیک باقی مانده از سرویس جدید برای اطلاعات خود استفاده می کند و به نظر نمی رسد هیچ ارتباط باقی مانده ای با مخزن داده قدیمی وجود داشته باشد، سرویس جدید را می توان در سیستم های تولید مستقر کرد.

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

در ابتدا، این ساختار تک محصولی به خوبی کار می‌کرد. اما با پیوستن توسعه‌دهندگان بیشتر به تیم، پایگاه کد به سرعت گسترش یافت. به‌روزرسانی‌ها و پروژه‌های متعدد، تاثیر منفی بر توسعه نرم‌افزار و عملکرد وبسایت داشتند. با کاهش آشکار بهره‌وری، نیاز به رویکردی جدید احساس می‌شد.

در سال ۲۰۰۱، تأخیر در توسعه، چالش‌های کدگذاری و وابستگی‌های بین سرویس‌ها، توانایی آمازون را برای پاسخگویی به نیازهای مشتریان رو به افزایش محدود می‌کرد. شرکت و وبسایت آن در حال انفجار بودند، اما روشی برای همگام شدن با این رشد وجود نداشت.

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

آمازون چگونه این کار را انجام داد؟

• تجزیه کد: توسعه‌دهندگان کد منبع را تجزیه و تحلیل کردند و بخش‌هایی را که یک هدف عملکردی واحد را ارائه می‌دادند، استخراج کردند. همانطور که انتظار می‌رفت، این یک فرآیند زمان‌بر بود، زیرا تمام کدها در هم تنیده شده بودند و عملکردهای مختلف وبسایت به هم مرتبط بودند. با این حال، توسعه‌دهندگان تلاش کردند بخش‌هایی را که می‌توانستند به میکروسرویس تبدیل شوند، شناسایی و جدا کنند.
• ایجاد رابط وب سرویس: پس از جداسازی بخش‌های کد، توسعه‌دهندگان آن‌ها را در یک رابط وب سرویس قرار دادند. به عنوان مثال، آن‌ها یک سرویس برای دکمه خرید در صفحه محصول، یک سرویس برای تابع محاسبه مالیات و غیره ایجاد کردند. هر عملکرد بخش خاص خود را داشت.
• مالکیت تیمی: آمازون مالکیت هر سرویس مستقل را به یک تیم از توسعه‌دهندگان اختصاص داد تا گلوگاه‌های توسعه را با جزئیات بیشتری شناسایی کنند. با تمرکز تعداد کمی از توسعه‌دهندگان روی یک سرویس، حل چالش‌ها با کارایی بیشتری انجام می‌شد. همچنین، هر سرویس روی عملکرد کل سیستم تأثیر مستقیم نمی‌گذاشت، بنابراین کار روی آن آسان‌تر بود.

معماری سرویس‌گرا (SOA) آمازون تا حد زیادی سرآغاز چیزی است که اکنون به عنوان میکروسرویس‌ها می‌شناسیم. این منجر به توسعه تعدادی راه‌حل برای پشتیبانی از معماری‌های میکروسرویس توسط آمازون شد، مانند آمازون AWS و آپولو، که در حال حاضر به شرکت‌های سراسر جهان فروخته می‌شود. بدون انتقال به میکروسرویس‌ها، آمازون نمی‌توانست به باارزش‌ترین شرکت جهان تبدیل شود که در تاریخ ۱ آگوست ۲۰۲۲ دارای ارزش بازار ۱.۶ تریلیون دلار است.

قسمت های مختلف آمازون :

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

آمازون وبسرویس رو کلی راجبش حرف زدیم پس کمتر تو این قسمت راجبش صحبت میکنیم صرفا در مورد معماری چند مستجره صحبت میکنیم :

معماری چند مستاجره در آمازون وب سرویس

معماری چند مستاجره (Multi-tenant architecture) که به اصطلاح چند مستاجری هم نامیده می‌شود، امروزه به دلیل رشد رایانش ابری و مدل‌های کسب‌وکار نرم‌افزار به عنوان سرویس (SaaS)، اهمیت بیشتری پیدا کرده است. SaaS به ما امکان می‌دهد نرم‌افزارها را از طریق اینترنت به عنوان یک سرویس ارائه دهیم، در حالی که چند مستاجری به شرکت‌ها این امکان را می‌دهد تا با به اشتراک گذاشتن منابع بین کاربران مختلف، برنامه‌ها را سریع‌تر و کارآمدتر توسعه و مقیاس‌بندی کنند.

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

معماری چند مستاجره چیست؟

معماری چند مستاجره رویکردی طراحی است که به چند گروه کاربر - که به عنوان مستاجر شناخته می‌شوند - امکان دسترسی به یک نمونه از یک برنامه یا سیستم را می‌دهد. این بسیار شبیه یک آپارتمان است که مستاجران مختلف آپارتمان های خود را دارند. همه آپارتمان ها خصوصی و امن هستند اما زیرساخت مشترکی دارند.

این نوع معماری به شرکت‌ها این امکان را می‌دهد تا با استفاده از همان منابع سخت‌افزاری برای چندین نمونه از یک برنامه برای چندین مستاجر، در هزینه‌های زیرساخت صرفه‌جویی کنند. این امر به ویژه برای شرکت‌های SaaS مفید است زیرا به آن‌ها اجازه می‌دهد برنامه‌های خود را مقیاس‌بندی کنند و مقرون‌به‌صرفه باقی بمانند.

معماری چند مستاجره چگونه کار می‌کند؟

معماری چند مستاجره محیط‌های مجزا و جداگانه‌ای را در یک زیرساخت فیزیکی واحد، مانند ماشین مجازی، سرور یا پلتفرم ابری ایجاد می‌کند. این با پارتیشن‌بندی ذخیره‌سازی و پردازش داده انجام می‌شود و به هر مستاجر فضای اختصاصی خود در سیستم اختصاص داده می‌شود. یک مستاجر با برنامه تعامل می‌کند و می‌تواند به داده‌های خود دسترسی داشته باشد.

مستاجران به موارد زیر اشاره دارند:

• کاربران و گروه‌های کاربری داخل شرکت شما (بخش‌ها، تیم‌ها، کارمندان فردی)
• کاربران و گروه‌های کاربری خارج از شرکت شما (فروشندگان، شرکای تجاری)
• مشتریانی (مشترکین یا مشتریانی) که محصول شما را خریداری می‌کنند

از آنجایی که هر محیط چند مستاجره از یکدیگر جدا شده است، می‌توان آن‌ها را برای برآوردن نیازهای هر مستاجر به صورت جداگانه سفارشی کرد بدون اینکه بر سایر محیط‌ها تأثیر بگذارد. مستاجران می‌توانند ویژگی‌هایی مانند طراحی رابط کاربری و تنظیمات امنیت داده‌ها را برای محیط خود شخصی‌سازی کنند. علاوه بر این، مجموعه قوانین مختلفی را می توان بر اساس کنترل دسترسی، تخصیص منابع و در دسترس بودن ویژگی ها برای هر دامنه اعمال کرد.

امنیت در معماری چند مستاجره AWS:

AWS اقدامات امنیتی متعددی را برای محافظت از داده های مشتریان خود انجام می دهد. این اقدامات شامل موارد زیر است:

• جداسازی داده ها: داده های هر مستاجر از داده های سایر مستاجران جدا شده است.
• مجوزها: AWS از یک سیستم مجوز قوی برای کنترل دسترسی به داده ها و منابع استفاده می کند.
• رمزگذاری: AWS از رمزگذاری برای محافظت از داده های مشتریان در حال انتقال و در حال استراحت استفاده می کند.

خدمات AWS که از معماری چند مستاجره استفاده می کنند:

• Amazon Elastic Compute Cloud (EC2): EC2 یک سرویس محاسبات ابری است که به شما امکان می دهد ماشین های مجازی (VM) را در ابر AWS راه اندازی و مدیریت کنید.
• Amazon Simple Storage Service (S3): S3 یک سرویس ذخیره سازی ابری است که به شما امکان می دهد هر مقدار داده ای را در ابر AWS ذخیره کنید.
• Amazon Relational Database Service (RDS): RDS یک سرویس پایگاه داده ابری است که به شما امکان می دهد پایگاه داده های رابطه ای را در ابر AWS راه اندازی و مدیریت کنید.

آمازون پرایم

در این قسمت از دو معماری میکروسرویس و معماری چندلایه استفاده میشود . راجب میکروسرویس که کامل صحبت کردیم . حالا بریم سراغ معماری چند لایه صحبت کنیم .

معماری چند لایه ای چیست؟

معماری چند لایه ای (Multi-layered architecture) روشی برای سازماندهی نرم افزار به لایه های مستقل است که هر کدام مسئولیت های مشخص و متمایزی دارند. این لایه ها معمولا بسته هستند، یعنی فقط با لایه های مجاور خود تعامل دارند. در حالی که معماری هایی با یک یا دو لایه نیز وجود دارند، معماری چند لایه معمولاً دارای سه یا بیشتر لایه است که به آن معماری n لایه ای نیز گفته می شود.

یک معماری چند لایه معمولاً دارای ساختار و لایه های زیر است:

• لایه نمایش (Presentation Layer): با رابط کاربری کاربر سروکار دارد و اطلاعات را به شکلی نمایش می دهد که برای کاربر قابل درک باشد.
• لایه کاربرد (Application Layer): منطق اصلی برنامه را در خود جای داده و درخواست های کاربر را پردازش می کند.
• لایه تجارت (Business Layer): قوانین و منطق کسب و کار را پیاده سازی می کند و با سیستم های داخلی دیگر تعامل دارد.
• لایه داده (Data Layer): از پایگاه داده و ذخیره سازی اطلاعات برنامه مراقبت می کند.

مزایای استفاده از معماری چند لایه در آمازون پرایم:

استفاده از معماری چند لایه در آمازون پرایم برای شرکت آمازون چندین مزیت داشته است:

• استقلال: تغییرات در یک لایه بر روی سایر لایه ها تأثیر نمی گذارد، بنابراین هر لایه را می توان بدون عوارض جانبی احتمالی در برنامه اصلاح کرد.
• قابلیت مقیاس پذیری: هر لایه را می توان روی یک سرور متفاوت اجرا کرد، که امکان مقیاس بندی آسان با افزایش تقاضا را فراهم می کند.
• سازماندهی: هر لایه وظیفه ای distinct و جداگانه را انجام می دهد، که منجر به جداسازی مناسب دغدغه ها (Separation of concerns) شده و کد را قابل فهم تر می کند.
• نگهداری: توسعه و نگهداری هر لایه ساده تر است، زیرا هر لایه مسئولیت محدودی دارد.
• قابلیت استفاده مجدد: اجزای هر لایه را می توان در برنامه های دیگر نیز استفاده کرد.

در آمازون پرایم، هر لایه وظیفه خاصی را انجام می دهد:

• لایه نمایش: رابط کاربری برنامه را مدیریت می کند و به کاربران اجازه می دهد به فیلم ها، برنامه های تلویزیونی، موسیقی و غیره دسترسی داشته باشند.
• لایه کاربرد: درخواست های کاربر را دریافت و پردازش می کند و دستورات مناسب را به لایه تجارت ارسال می کند.
• لایه تجارت: قوانین و منطق کسب و کار را اجرا می کند، مانند بررسی صحت اشتراک کاربر و دسترسی به محتوا.
• لایه داده: داده های کاربر، فیلم ها، برنامه های تلویزیونی، موسیقی و سایر اطلاعات را در پایگاه داده ذخیره می کند.

استفاده از معماری چند لایه به آمازون پرایم این امکان را می دهد تا برنامه ای مقیاس پذیر، قابل نگهداری و سازمان یافته برای کاربران خود ایجاد کند.

در نظر داشته باشید که معماری چند لایه برای برنامه های کوچک ممکن است پیچیدگی غیرضروری به همراه داشته باشد و بر عملکرد تاثیر بگذارد. اما برای برنامه های بزرگ و پیچیده مانند آمازون پرایم، این مزایا باعث شده است که استفاده از این معماری انتخاب مناسبی باشد.

آمازون ویدیو

معماری محتوا محور (Content Driven Architecture) چیست؟

معماری محتوا محور رویکردی برای توسعه و مدیریت وب سایت ها است که بر محتوا به عنوان عنصر اصلی تمرکز دارد. این رویکرد با در نظر گرفتن نیازهای تولیدکنندگان محتوا (Content creators) طراحی شده است و هدف آن ایجاد سیستمی است که هم انعطاف پذیر باشد و هم برای کاربران آسان استفاده باشد.

مزایای استفاده از معماری محتوا محور در آمازون ویدیو:

• انعطاف پذیری: معماری محتوا محور به ediorها اجازه می دهد تا به راحتی ساختار و چیدمان صفحات را تغییر دهند بدون نیاز به کدگذاری دستی. این امر به ویژه برای وب سایت هایی با محتوای پویا که مرتباً در حال تغییر هستند مفید است.
• قابلیت استفاده: رابط کاربری ویرایشگر بصری است و به ediorها اجازه می دهد تا محتوا را به صورت مستقیم ویرایش کنند و ببینند که چگونه در صفحه نمایش داده می شود. این امر باعث صرفه جویی در وقت و کاهش خطاها می شود.
• کشف پذیری: معماری محتوا محور ابزارهایی را برای ediorها فراهم می کند تا الگوها و اجزای محتوا را کشف کنند و از آنها استفاده مجدد کنند. این امر باعث صرفه جویی در وقت و ایجاد ثبات در ظاهر و احساس وب سایت می شود.
• مقیاس پذیری: معماری محتوا محور به گونه ای طراحی شده است که با رشد وب سایت مقیاس پذیر باشد. این امر با استفاده از اجزای محتوا قابل استفاده مجدد و مدل داده های انعطاف پذیر حاصل می شود.

نحوه استفاده آمازون ویدیو از معماری محتوا محور:

آمازون ویدیو از یک CMS بدون سر (Headless CMS) به همراه ویرایشگر بصری Stackbit استفاده می کند تا معماری محتوا محور را پیاده سازی کند. این سیستم به ediorها اجازه می دهد تا:

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

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

آمازون موزیک
در امازون موزیک هم علاوه بر میکروسرویس از معماری مبتنی بر رویداد استفاده می شود.

معماری رویداد محور (Event-Driven Architecture) چیست؟

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

آمازون موزیک از معماری رویداد محور به چند روش مختلف استفاده می کند:

پیشنهادات موسیقی: هنگامی که کاربری به موسیقی خاصی گوش می دهد، رویدادی ایجاد می شود که به سرویس پیشنهادات موسیقی ارسال می شود. این سرویس از این رویداد برای پیشنهاد موسیقی های مشابه به کاربر استفاده می کند.

لیست های پخش شخصی سازی شده: هنگامی که کاربری آهنگی را به لیست پخش اضافه می کند، رویدادی ایجاد می شود که به سرویس لیست پخش ارسال می شود. این سرویس از این رویداد برای به روز رسانی لیست پخش های شخصی سازی شده کاربر استفاده می کند.

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

مزایای استفاده از معماری رویداد محور در آمازون موزیک:

• مقیاس پذیری: معماری رویداد محور به راحتی مقیاس پذیر است، زیرا تولیدکنندگان و مصرف کنندگان رویداد به صورت مجزا عمل می کنند. این امر به آمازون موزیک اجازه می دهد تا با افزایش تعداد کاربران، به راحتی ظرفیت خود را افزایش دهد.
• قابلیت ارتقا: معماری رویداد محور به این معنی است که اجزای مختلف سیستم می توانند به طور مستقل ارتقا داده شوند. این امر باعث کاهش زمان و هزینه ارتقا می شود.
• انعطاف پذیری: معماری رویداد محور این امکان را به آمازون موزیک می دهد تا به راحتی ویژگی های جدیدی را به سیستم اضافه کند، زیرا مصرف کنندگان جدید رویداد می توانند به راحتی به سیستم اضافه شوند.
• زمان واقعی: رویدادها تقریباً به صورت بلادرنگ منتشر و دریافت می شوند، که به آمازون موزیک این امکان را می دهد تا تجربیات کاربری در زمان واقعی را ارائه دهد، مانند پیشنهادات موسیقی فوری پس از گوش دادن به یک آهنگ.

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

پیشنهاد ما برای آمازون
معماری Unikernel-based microservices می‌تواند برخی از معایب معماری میکروسرویس سنتی را برای شرکت‌هایی مانند آمازون برطرف کند. معماری میکروسرویس یونکرنل بیس (Microservices Unikernel-based) یک رویکرد جدید برای طراحی و توسعه سیستم‌های نرم افزاری است که از مزایای هر دو معماری میکروسرویس و یونکرنل استفاده می‌کند. این معماری می‌تواند برای بهبود عملکرد، مقیاس‌پذیری و امنیت سیستم‌های بزرگ و پیچیده مانند آمازون مفید باشد.

توضیح در مورد Unikernel-based Microservices :

1. یونیکرنل چیست؟یونیکرنل یک تصویر اجرایی سبک وزن است که شامل کد برنامه و کمینه‌ترین اجزای لازم سیستم عامل برای اجرای آن برنامه است. به جای اینکه یک سیستم عامل کامل را روی هر ماشین مجازی اجرا کنید، یونیکرنل تنها اجزای ضروری را برای اجرای یک میکروسرویس خاص بارگذاری می‌کند.
2. معماری Unikernel-based Microservices در این معماری، هر میکروسرویس به صورت یک یونیکرنل جداگانه اجرا می‌شود. این امر موجب می‌شود که هر سرویس به طور مستقل و با حداقل وابستگی‌های سیستمی کار کند.

مزایای Unikernel-based Microservices نسبت به میکروسرویس‌های سنتی

• کارایی و عملکرد: کاهش اورهد سیستم عامل به معنای بهبود کارایی و سرعت است. یونیکرنل‌ها بسیار سریع‌تر از ماشین‌های مجازی سنتی بوت می‌شوند و منابع کمتری مصرف می‌کنند.
• امنیت: با کاهش سطح تماس سیستم‌عامل (کاهش تعداد درایورها و سرویس‌های غیرضروری)، نقاط آسیب‌پذیر کمتری وجود دارد، که این امر امنیت را افزایش می‌دهد.
• بهره‌وری منابع: یونیکرنل‌ها با استفاده کارآمدتر از منابع سخت‌افزاری، امکان استقرار بیشتر میکروسرویس‌ها را در یک سرور فراهم می‌کنند.
• تفکیک و ایزولاسیون: هر یونیکرنل یک محیط مجزا فراهم می‌کند، که این امر به ایزولاسیون و تفکیک بهتر سرویس‌ها کمک می‌کند.
• کاهش پیچیدگی: با کم شدن وابستگی‌های سیستمی و کاهش اورهد سیستم عامل، پیچیدگی کلی سیستم کاهش می‌یابد.
• کارایی بهتر در محیط‌های توزیع شده: یونیکرنل‌ها برای محیط‌های ابری و توزیع شده، که نیازمند استقرار سریع و کارآمد هستند، ایده‌آل هستند.

از آنجایی که آمازون یک سیستم بزرگ و پیچیده است و این معماری برای سیستم‌های بزرگ و پیچیده‌ای مانند آمازون که نیاز به عملکرد بالا، مقیاس‌پذیری و امنیت دارند بسیار مناسب است و همچنین این معماری برای سیستم‌های مبتنی بر ابر که نیاز به مقیاس‌پذیری و انعطاف‌پذیری دارند، مناسب است پس این معماری می تواند کاملا برای آمازون مناسب باشد.

معماری میکروسرویس یونکرنل بیس یک رویکرد جدید و نویدبخش برای طراحی و توسعه سیستم‌های نرم افزاری است که می‌تواند مزایای زیادی برای سیستم‌های بزرگ و پیچیده مانند آمازون ارائه دهد. این معماری یک فناوری جدید و در حال ظهور است و هنوز در مراحل اولیه توسعه خود قرار دارد. با این حال، این معماری پتانسیل زیادی در اینده خواهد داشت .

گوگل

تاریخچه گوگل: از آغاز تا کنون

آغازین گام‌ها:

۱۹۹۶: لری پیج و سرگئی برین، دو دانشجوی دکترای دانشگاه استنفورد، پروژه‌ای تحقیقاتی به نام BackRub را آغاز می‌کنند. هدف این پروژه، تحلیل ساختار لینک‌های وب جهان‌گستر برای درک اهمیت آن‌ها بود.

۱۹۹۷-۱۹۹۸:الگوریتم PageRank توسط پیج و برین توسعه می‌یابد. این الگوریتم، اهمیت یک صفحه وب را بر اساس کیفیت و تعداد لینک‌های ورودی به آن ارزیابی می‌کند.
اولین نسخه موتور جستجوی گوگل در وب‌سایت دانشگاه استنفورد راه‌اندازی می‌شود.
گوگل به عنوان یک شرکت خصوصی با سرمایه‌گذاری دوستان و خانواده ثبت می‌شود.

رشد و چالش‌های اولیه:

۱۹۹۹:گوگل به اولین دفتر خود در پالو آلتو، کالیفرنیا نقل مکان می‌کند.
با وجود مخالفت‌های اولیه، گوگل مدل تبلیغات متنی را برای حفظ رابط کاربری ساده و سرعت بارگذاری بالا اتخاذ می‌کند.
گوگل به دلیل طراحی ساده و نتایج جستجوی برتر، کاربران وفاداری جذب می‌کند.
اولین پیشنهاد خرید گوگل توسط Excite.com ارائه می‌شود که توسط پیج و برین رد می‌شود.

نوآوری و گسترش:

دهه ۲۰۰۰:گوگل فروش تبلیغات مبتنی بر کلمات کلیدی را آغاز می‌کند و مدل جدیدی در صنعت تبلیغات آنلاین را پایه‌گذاری می‌کند.
گوگل در سال ۲۰۰۴ با شعار "شرور نباشید" به بورس اوراق بهادار راه می‌یابد.
گوگل با خرید Pyra Labs، مالک Blogger، دامنه فعالیت خود را در زمینه تولید محتوا و جمع‌آوری اطلاعات گسترش می‌دهد.
گوگل برای رقابت با شرکت‌هایی مانند مایکروسافت و یاهو، محصولات متنوعی مانند Gmail، Google Chrome و Google Earth را ارائه می‌دهد.
گوگل با چالش‌هایی مانند تقلب در کلیک و بحث‌هایی پیرامون حریم خصوصی و ردیابی داده‌ها روبرو می‌شود.

تحولات و چالش‌های جدید:

دهه ۲۰۱۰ و بعد از آن:گوگل Google+ را به عنوان چهارمین تلاش خود در زمینه شبکه‌های اجتماعی راه‌اندازی می‌کند که با استقبالی متوسط روبرو می‌شود.
گوگل با بازسازی ساختاری خود به عنوان Alphabet Inc. و تبدیل شدن Google به زیرمجموعه اصلی آن، امکان تنوع‌بخشی به فعالیت‌های خود را فراتر از جستجو فراهم می‌کند.
اعتراضات کارکنان گوگل به مسائلی مانند آزار جنسی، نگرانی‌های اخلاقی در مورد برخی پروژه‌ها و رویه‌های انحصاری ادعایی، این شرکت را تحت شعاع قرار می‌دهد.
گوگل با ورود به حوزه‌هایی مانند بازی‌های ابری با Google Stadia، با نظارت‌های نظارتی و چالش‌های حقوقی روبرو می‌شود.

وضعیت فعلی و آینده:

۲۰۲۴:گوگل همچنان به عنوان یک بازیگر اصلی در صنعت فناوری به فعالیت خود ادامه می‌دهد و با چالش‌ها و فرصت‌های جدیدی روبرو است.
این شرکت در حال عبور از چارچوب‌های نظارتی، رقابت و نگرانی‌های اجتماعی است و در عین حال به سمت پیشرفت‌های تکنولوژیکی مانند هوش مصنوعی و رایانش ابری گام برمی‌دارد.
مسیر آینده گوگل به توانایی آن در سازگاری و نوآوری در عین توجه به ملاحظات اخلاقی و اجتماعی بستگی دارد.

تاریخچه معماری گوگل

معماری گوگل در طول زمان برای پاسخگویی به نیازهای کاربران رو به رشد و پیچیدگی های خدماتش تکامل یافته است. در اینجا مروری بر تاریخچه معماری گوگل در سطح بالا آورده شده است:

1. سال های اولیه: زمانی که گوگل برای اولین بار در سال 1998 تاسیس شد، بر اساس معماری نسبتا ساده ای کار می کرد. بنیانگذاران، لری پیج و سرگی برین، یک الگوریتم جستجوی نوآورانه ایجاد کردند و در ابتدا از سخت‌افزار ارزان قیمت برای پشتیبانی از موتور جستجوی خود استفاده کردند.

2. سیستم فایل گوگل (GFS): در اوایل دهه 2000، گوگل سیستم فایل توزیع شده خود را به نام GFS ایجاد کرد. GFS به Google اجازه داد تا مقادیر زیادی از داده‌های ساختاریافته و بدون ساختار را در چندین ماشین ذخیره و بازیابی کند و تحمل خطا و مقیاس‌پذیری را فراهم کند.

3. استفاده از Bigtable و MapReduce: گوگل با تکیه بر GFS، Bigtable، یک سیستم ذخیره سازی توزیع شده، و MapReduce، یک مدل برنامه نویسی برای پردازش مجموعه داده های بزرگ را توسعه داد. این فناوری‌ها به Google امکان داد تا حجم عظیمی از داده‌ها را در مجموعه‌ای از ماشین‌ها مدیریت کند و از خدمات اصلی و نیازهای پردازش داده پشتیبانی کند.

4. زیرساخت به عنوان یک سرویس (IaaS): در سال 2008، گوگل زیرساخت خود را به عنوان یک پلت فرم خدمات به نام Google App Engine راه اندازی کرد. به توسعه دهندگان یک محیط مقیاس پذیر و مدیریت شده برای ساخت و استقرار برنامه های کاربردی وب ارائه می دهد و بسیاری از پیچیدگی های زیرساختی را از بین می برد.

5. سرویس ابر Google Cloud Platform : گوگل با معرفی Google Cloud Platform در سال 2011، زیرساخت های خود را گسترش داد. GCP طیف وسیعی از خدمات رایانش ابری، از جمله ماشین های مجازی، ذخیره سازی، پایگاه های داده و یادگیری ماشینی را برای کمک به کسب و کارها و توسعه دهندگان برنامه های خود را می سازند، مستقر می کنند و مقیاس می دهند.

6. Borg و Kubernetes: در داخل، گوگل چندین سیستم مدیریت خوشه، از جمله Borg و جانشین منبع باز آن، Kubernetes را توسعه داده است. این سیستم ها امکان تخصیص کارآمد منابع، کانتینرسازی و هماهنگ سازی برنامه های کاربردی توزیع شده در مقیاس بزرگ را فراهم می کنند.

7. مراکز داده جهانی: گوگل شبکه گسترده ای از مراکز داده جهانی ایجاد کرده است تا از دسترسی مطمئن و کم تاخیر به خدمات خود در سراسر جهان اطمینان حاصل کند. این مراکز داده از فناوری‌های زیرساختی پیشرفته مانند سرورهای طراحی‌شده سفارشی، شبکه‌های پرسرعت و شیوه‌های کارآمد انرژی استفاده می‌کنند.

معماری گوگل با مقابله با چالش‌های جدید و ترکیب فناوری‌های نوظهور به تکامل و نوآوری خود ادامه می‌دهد. مقیاس پذیری، قابلیت اطمینان و عملکرد را در اولویت قرار می دهد تا حجم عظیمی از داده های پردازش شده توسط خدمات خود را مدیریت کند و انتظارات کاربران خود را برآورده کند.

گوگل از معماری میکروسرویس در طیف گسترده‌ای از محصولات و خدمات خود استفاده می‌کند، از جمله:

• جستجوی گوگل: سیستم جستجوی گوگل از مجموعه‌ای از میکروسرویس‌ها تشکیل شده است که هر کدام وظایف خاصی را انجام می‌دهند، مانند رتبه‌بندی نتایج جستجو، ذخیره‌سازی داده‌ها و ارائه نتایج.
• سرویس Gmail: Gmail از مجموعه‌ای از میکروسرویس‌ها تشکیل شده است که هر کدام وظایف خاصی را انجام می‌دهند، مانند ذخیره‌سازی ایمیل‌ها، ارسال ایمیل‌ها و فیلتر کردن اسپم.
• سرویس Google Maps: Google Maps از مجموعه‌ای از میکروسرویس‌ها تشکیل شده است که هر کدام وظایف خاصی را انجام می‌دهند، مانند ذخیره‌سازی داده‌های نقشه، ارائه تصاویر خیابان و مسیریابی.

ابزارهای گوگل برای توسعه میکروسرویس:

گوگل مجموعه‌ای از ابزارها را برای توسعه میکروسرویس ارائه می‌دهد، از جمله:

• ابزار Kubernetes: یک پلتفرم متن‌باز برای مدیریت و خودکارسازی استقرار و مقیاس‌بندی برنامه‌های مبتنی بر کانتینر.
• ابزار Cloud Run: یک پلتفرم بدون سرور برای اجرای برنامه‌های stateless.
• ابزار Istio: یک شبکه مش برای مدیریت ترافیک بین میکروسرویس‌ها.:

معماری میکروسرویس مزایای متعددی را برای توسعه و استقرار نرم‌افزار ارائه می‌دهد. گوگل از معماری میکروسرویس در طیف گسترده‌ای از محصولات و خدمات خود استفاده می‌کند و مجموعه‌ای از ابزارها را برای توسعه میکروسرویس ارائه می‌دهد.

جادوی سیستم های توزیع شده در گوگل

تصور کنید اطلاعات کل دنیا جلوی شماست، چطور اون رو جستجو میکنید؟ گوگل این کار رو با یه سیستم جادویی به اسم "سیستم توزیع شده" انجام میده. بیا باهم ببینیم این سیستم چطور کار میکنه!

سیستم توزیع شده چیه؟

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

مزایای این سیستم چیه؟

• سرعت بیشتر: چون چند تا کامپیوتر با هم کار میکنن، سرعت جستجو خیلی بیشتر میشه.
• مقیاس پذیری: هر وقت بخوان، میتونن کامپیوترهای بیشتری به سیستم اضافه کنن و قدرت جستجو رو بالا ببرن.
• مقاومت بیشتر: اگه یه کامپیوتر خراب بشه، بقیه میتونن کارش رو انجام بدن و جستجو متوقف نمیشه.

سیستم جستجوی گوگل چطور از این سیستم استفاده میکنه؟

تصور کنید یه سوال میپرسید، سیستم توزیع شده گوگل کارهای زیر رو انجام میده:

1. تقسیم کار: سوال شما به تیکه های کوچیکتر تقسیم میشه و به کامپیوترهای مختلف فرستاده میشه.
2. جستجوی موازی: هر کامپیوتر یه سری صفحات وب رو بررسی میکنه و نتایج اولیه رو پیدا میکنه.
3. جمع آوری نتایج: نتایج اولیه از همه کامپیوترها جمع آوری میشه.
4. رتبه بندی نتایج: الگوریتم های پیچیده ای نتایج رو بر اساس کیفیت و ارتباط با سوال شما رتبه بندی میکنن.
5. نمایش نتایج: بهترین نتایج به شما نشون داده میشن.

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

• ترجمه گوگل: ترجمه متن ها با استفاده از سیستم های توزیع شده سریع و دقیق تر میشه.

تقسیم کار: متن مورد نظر به بخش‌های کوچک‌تر تقسیم می‌شود و به سرورهای مختلف فرستاده می‌شود.

ترجمه موازی: هر سرور با استفاده از مدل‌های زبانی و هوش مصنوعی، بخش مربوطه را ترجمه می‌کند.

جمع‌آوری نتایج: ترجمه‌های انجام شده از همه سرورها جمع‌آوری و به هم پیوسته می‌شوند.

بهینه‌سازی: ترجمه با استفاده از الگوریتم‌های مختلف و فرهنگ لغت‌های تخصصی، بهینه‌سازی و ویرایش می‌شود.

ارائه نتیجه: ترجمه نهایی به شما نمایش داده می‌شود.

مزایای استفاده از سیستم‌های توزیع شده در ترجمه گوگل:

سرعت بیشتر: ترجمه متن‌ها به طور همزمان در سرورهای مختلف انجام می‌شود و سرعت ترجمه را به طور قابل توجهی افزایش می‌دهد.

دقت بیشتر: با استفاده از مدل‌های زبانی پیشرفته و هوش مصنوعی، ترجمه‌ها دقیق‌تر و روان‌تر می‌شوند.

قابلیت مقیاس‌پذیری: سیستم می‌تواند به راحتی با افزایش حجم تقاضا برای ترجمه، مقیاس‌بندی شود.

• یوتیوب: پخش ویدیو برای میلیون ها نفر بدون مشکل با کمک این سیستم ها انجام میشه.

ذخیره‌سازی ویدئو: ویدئوها به بخش‌های کوچک‌تر تقسیم می‌شوند و در سرورهای مختلف ذخیره می‌شوند.

پخش ویدئو: هنگامی که شما یک ویدئو را تماشا می‌کنید، بخش‌های مختلف ویدئو از سرورهای مختلف به دستگاه شما ارسال می‌شوند.

تنظیم کیفیت: سیستم به طور خودکار کیفیت ویدئو را با توجه به سرعت اینترنت شما تنظیم می‌کند.

پخش زنده: سیستم‌های توزیع شده امکان پخش زنده ویدئو را برای میلیون‌ها نفر به طور همزمان فراهم می‌کنند.

مزایای استفاده از سیستم‌های توزیع شده در یوتیوب:

پخش روان: ویدئوها بدون مشکل و با کیفیت بالا پخش می‌شوند.

قابلیت مقیاس‌پذیری: سیستم می‌تواند به راحتی با افزایش تعداد کاربران و حجم ترافیک، مقیاس‌بندی شود.

هزینه کمتر: استفاده از سرورهای متعدد به جای یک سرور قدرتمند، هزینه‌ها را کاهش می‌دهد.

• جی میل: ایمیل های شما با خیال راحت روی سرورهای توزیع شده گوگل ذخیره میشن.

ذخیره‌سازی ایمیل: ایمیل‌ها در سرورهای مختلف ذخیره می‌شوند تا از دست رفتن اطلاعات جلوگیری شود.

ارسال و دریافت ایمیل: ایمیل‌ها به طور همزمان به سرورهای مختلف ارسال و دریافت می‌شوند.

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

ضد هرزنامه: سیستم‌های توزیع شده به فیلتر کردن هرزنامه‌ها و ایمیل‌های ناخواسته کمک می‌کنند.

مزایای استفاده از سیستم‌های توزیع شده در جی میل:

دسترسی سریع: شما می‌توانید به سرعت و به آسانی به ایمیل‌های خود دسترسی داشته باشید.

قابلیت اطمینان بالا: احتمال از دست رفتن ایمیل‌ها بسیار کم است.

امنیت بالا: ایمیل‌ها با استفاده از روش‌های مختلف رمزنگاری محافظت می‌شوند.

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

کاربرد یادگیری ماشین در محصولات گوگل

یادگیری ماشین به عنوان شاخه‌ای از هوش مصنوعی، نقشی حیاتی در ارتقای عملکرد و ارائه خدمات متناسب با نیاز کاربران در محصولات مختلف گوگل ایفا می‌کند. در ادامه به برخی از کاربردهای برجسته یادگیری ماشین در 5 محصول محبوب گوگل می‌پردازیم:

1. جستجوی گوگل:

• الگوریتم رتبه‌بندی: با تحلیل محتوای صفحات وب، سیگنال‌های مرتبط با کیفیت و اعتبار محتوا را شناسایی و نتایج جستجو را بر اساس آن‌ها رتبه‌بندی می‌کند.
• پیشنهاد جستجو: با پیش‌بینی عبارت‌های جستجوی احتمالی، به کاربران در یافتن سریع‌تر اطلاعات مورد نظرشان کمک می‌کند.
• پاسخ‌های گوگل: به طور خودکار به سوالات متداول کاربران در صفحات نتایج جستجو پاسخ می‌دهد.
• شخصی‌سازی: نتایج جستجو را بر اساس علایق و رفتار گذشته کاربر، به صورت شخصی‌سازی شده ارائه می‌دهد.

2. جیمیل:

• فیلتر هرزنامه: با تشخیص و فیلتر کردن ایمیل‌های ناخواسته، صندوق ورودی کاربر را مرتب و پاکیزه نگه می‌دارد.
• طبقه‌بندی خودکار: ایمیل‌ها را به طور خودکار در دسته‌های مختلف مانند "کار"، "شبکه‌های اجتماعی" و "تبلیغات" طبقه‌بندی می‌کند.
• پاسخ‌های هوشمند: با پیشنهاد پاسخ‌های مناسب به ایمیل‌ها، به کاربران در صرفه‌جویی در زمان و افزایش سرعت پاسخگویی کمک می‌کند.
• جستجوی پیشرفته: با استفاده از هوش مصنوعی، به کاربران در یافتن سریع‌تر ایمیل‌های مورد نظرشان در میان حجم انبوه ایمیل‌ها کمک می‌کند.

3. گوگل مپ:

• مسیر یابی: با در نظر گرفتن ترافیک، شرایط آب و هوایی و سایر عوامل، بهترین مسیر را برای رسیدن به مقصد به کاربر پیشنهاد می‌دهد.
• زمان‌بندی سفر: با تخمین زمان تقریبی سفر، به کاربران در برنامه‌ریزی دقیق‌تر سفرشان کمک می‌کند.
• به روز رسانی زنده: اطلاعات مربوط به ترافیک، تصادفات و انسداد جاده‌ها را به طور زنده به کاربران ارائه می‌دهد.
• پیشنهاد مکان: با توجه به علایق و سابقه جستجوی کاربر، مکان‌های جدید و جذاب را به او پیشنهاد می‌دهد.

4. یوتیوب:

• پیشنهاد ویدیو: با تحلیل رفتار و علایق کاربر، ویدیوهای مرتبط و جذاب را به او پیشنهاد می‌دهد.
• زیرنویس خودکار: به طور خودکار زیرنویس ویدیوها را به زبان‌های مختلف generate می‌کند.
• تشخیص محتوای نامناسب: با استفاده از هوش مصنوعی، محتوای نامناسب و خشونت‌آمیز را در ویدیوها شناسایی و حذف می‌کند.
• تجزیه و تحلیل ویدیو: اطلاعات مربوط به عملکرد ویدیوها، مانند تعداد بازدیدها و نظرات را به صاحبان کانال‌ها ارائه می‌دهد.

5. گوگل کلود:

• تشخیص و پیش‌بینی خطا: با تحلیل داده‌ها، خطاهای احتمالی را پیش‌بینی و از بروز آن‌ها جلوگیری می‌کند.
• بهینه‌سازی منابع: با تخصیص بهینه منابع، عملکرد و کارایی سیستم‌ها را ارتقا می‌دهد.
• تجزیه و تحلیل داده‌ها: با ارائه ابزارهای مختلف، به کاربران در تحلیل داده‌ها و استخراج اطلاعات مفید از آن‌ها کمک می‌کند.
• شخصی‌سازی: خدمات و محصولات گوگل کلود را بر اساس نیازها و خواسته‌های کاربران، به صورت شخصی‌سازی شده ارائه می‌دهد.

معماری چندلایه در گوگل

معماری چندلایه یکی از رایج‌ترین معماری‌های نرم‌افزاری است که در بسیاری از محصولات و خدمات گوگل از جمله موارد زیر استفاده می‌شود:

1. جستجوی گوگل:

• لایه رابط کاربری: رابط کاربری جستجوی گوگل که کاربران با آن تعامل دارند.
• لایه منطق برنامه: شامل الگوریتم‌های رتبه‌بندی، پردازش زبان طبیعی و سایر منطق‌های مربوط به جستجو.
• لایه دسترسی به داده‌ها: شامل پایگاه داده‌های عظیم صفحات وب و سایر اطلاعات مرتبط.

2. جیمیل:

• لایه رابط کاربری: رابط کاربری جیمیل که کاربران برای ارسال و دریافت ایمیل از آن استفاده می‌کنند.
• لایه منطق برنامه: شامل موتور پردازش ایمیل، فیلتر هرزنامه و سایر منطق‌های مربوط به ایمیل.
• لایه ذخیره‌سازی: شامل سرورهایی که ایمیل‌ها را ذخیره می‌کنند.

3. یوتیوب:

• لایه رابط کاربری: رابط کاربری یوتیوب که کاربران برای تماشای و آپلود ویدیو از آن استفاده می‌کنند.
• لایه پردازش ویدئو: شامل پردازش ویدئو، رمزگذاری و سایر وظایف مربوط به ویدئو.
• لایه ذخیره‌سازی: شامل سرورهایی که ویدیوها را ذخیره می‌کنند.

4. گوگل مپ:

• لایه رابط کاربری: رابط کاربری گوگل مپ که کاربران برای مسیریابی و جستجوی مکان‌ها از آن استفاده می‌کنند.
• لایه منطق برنامه: شامل موتور مسیریابی، رندر نقشه و سایر منطق‌های مربوط به نقشه.
• لایه داده‌ها: شامل پایگاه داده‌های اطلاعات مربوط به مکان‌ها، جاده‌ها و سایر اطلاعات مرتبط.

مزایای استفاده از معماری چندلایه:

• مقیاس‌پذیری: این معماری به گونه‌ای طراحی شده است که به راحتی می‌توان آن را مقیاس‌بندی کرد تا بتواند نیازهای رو به رشد کاربران را برآورده کند.
• قابلیت نگهداری: این معماری به گونه‌ای طراحی شده است که به راحتی می‌توان آن را نگهداری و به روز رسانی کرد.
• قابلیت استفاده مجدد: اجزای این معماری می‌توانند در سیستم‌های دیگر نیز استفاده شوند.
• قابلیت تست: اجزای این معماری به طور جداگانه قابل تست هستند.

معایب استفاده از معماری چندلایه:

• پیچیدگی: این معماری می‌تواند پیچیده باشد و نیاز به تخصص و دانش فنی بالا برای طراحی و پیاده‌سازی دارد.
• کارایی: این معماری می‌تواند به دلیل وجود لایه‌های متعدد، کارایی کمتری نسبت به معماری‌های ساده‌تر داشته باشد.

معماری بدون سرور در گوگل

معماری بدون سرور برخلاف اسمش، به طور کامل سرورها را حذف نمی‌کند، بلکه وظایف مربوط به مدیریت سرور را از دوش ‍توسعه‌دهندگان برمی‌دارد. در این روش، شما فقط کدتان را نوشته و آن را ‍توسعه می‌دهید، و ارائه‌دهنده ابر وظایف مربوط به ‍تدارک، ‍مقیاس‌بندی و نگهداری سرور را به عهده می‌گیرد. این کار مزایای ‍متعددی به همراه دارد:

• ‍توسعه سریع‌تر: تمرکز ‍توسعه‌دهنده فقط روی کد خواهد بود، نه زیرساخت.
• کاهش هزینه‌ها: ‍توسعه‌دهنده فقط به ازای منابعی که استفاده می‌کند هزینه ‍می‌پردازد، و ‍هزینه‌های مربوط به سرورهای ‍غیرفعال حذف ‍می‌شود.
• ‍مقیاس‌‍پذیری ‍افزایش‌یافته: ‍مقیاس‌بندی ‍خودکار ‍می‌تواند به ‍طور ‍مناسب با ‍تغییرات ترافیک ‍انطباق ‍پیدا کند.
• قابلیت ‍اطمینان ‍افزایش‌یافته: خدمات ‍مدیریت‌شده ‍ارائه ‍شده توسط ‍ارائه‌دهندگان ابر، ‍قابلیت ‍دسترسی ‍بالا و ‍تحمل ‍خطا را ‍ارائه ‍می‌دهند.

کاربردهای معماری بدون سرور در محصولات گوگل:

• منطق ‍پشتیبان ‍برای برنامه‌های ‍موبایل: ‍توابع ‍منحصر به فرد ‍وظایفی ‍مانند ‍احراز هویت ‍کاربر، ‍پردازش ‍داده‌ها و ‍ارسال ‍اعلان‌ها را ‍انجام ‍می‌دهند.
• پردازش لحظه‌ای: ‍توابع بدون سرور ‍می‌توانند به ‍رویدادهایی ‍مانند ‍پرس‌وجوهای ‍جستجو، ‍کلیک ‍بر روی ‍تبلیغات یا ‍اقدامات ‍کاربر ‍در ‍زمان ‍واقعی ‍واکنش ‍نشان ‍دهند.
• خطوط لوله داده: ‍پردازش و ‍تجزیه و تحلیل ‍مجموعه داده‌های ‍بزرگ با استفاده از ‍توابع ‍بدون سرور ‍قابل ‍مقیاس‌بندی.
• ریزخدمات: ‍ساخت ‍خدمات ‍مدولار ‍بدون ‍نیاز به ‍مدیریت ‍سرورهای ‍منحصر به فرد ‍برای ‍هر ‍یک.
• ابزارهای ‍داخلی و ‍اتوماسیون: ‍ساده‌سازی ‍فرآیندهای ‍داخلی با استفاده از ‍توابع ‍بدون سرور ‍که ‍با ‍رویدادها یا ‍برنامه‌ریزی ‍فعال ‍می‌شوند.

مزایای ‍استفاده از ‍معماری بدون سرور برای گوگل:

• نوآوری ‍ سریع‌تر: ‍توسعه‌دهندگان ‍می‌توانند ‍بر ‍منطق ‍اصلی ‍تمرکز ‍کنند، ‍که ‍منجر به ‍تسریع ‍در ‍توسعه ‍محصول ‍می‌شود.
• بهینه‌سازی ‍ هزینه: ‍ مدل ‍ پرداخت ‍به ‍ازای ‍استفاده ‍منجر به ‍کاهش ‍هزینه‌های ‍زیرساخت ‍می‌شود.
• ‍مقیاس‌‍پذیری ‍افزایش‌یافته: ‍می‌توان ‍به ‍طور ‍کارآمد با ‍پیک‌های ‍ترافیک ‍بسیار ‍بالا ‍مقابله ‍کرد.
• افزایش ‍بهره‌وری ‍توسعه‌دهندگان: ‍معماری بدون سرور ‍توسعه و ‍توسعه ‍را ‍ساده‌تر ‍می‌کند.

چالش‌ها و ‍ ملاحظات:

• وابستگی به ‍ ارائه‌دهنده: ‍ توسعه‌دهنده به ‍ خدمات ‍ ارائه ‍ شده توسط ‍ یک ‍ارائه‌دهنده ‍ ابر ‍خاص ‍وابسته ‍می‌شود.
• اشکال‌‍ یابی و ‍ نظارت: ‍ اشکال‌‍ یابی ‍ مشکلات ‍ در ‍ توابع ‍ پراکنده ‍ می‌تواند ‍ پیچیده ‍ باشد.

تأخیر ‍ شروع ‍ سرد: ‍ توابع ‍ ممکن است ‍ پس از ‍ غیرفعال ‍ بودن ‍ برای ‍ مدتی، ‍ در ‍هنگام ‍ فعال ‍ شدن ‍ دوباره ‍با ‍تأخیر ‍ شروع ‍ سرد ‍ مواجه ‍شوند.

معماری بدون سرور ‍ مزایای ‍ قابل ‍ توجهی ‍ برای ‍ برنامه‌های ‍ مقیاس ‍ بزرگ ‍ مانند ‍ محصولات ‍ گوگل ‍ ارائه ‍ می‌دهد. ‍ این ‍ معماری ‍‍ توسعه ‍ سریع‌تر، ‍ کاهش ‍ هزینه‌ها، ‍و ‍ مقیاس‌‍ پذیری ‍ افزایش‌یافته ‍ را ‍ فراهم ‍ می‌کند، ‍ در ‍ حالی ‍ که ‍ نیاز به ‍ توجه دقیق به چالش‌های احتمالی ‍ دارد.

پیشنهاد های ما :

برای مشکلات معماری میکروسرویس در قسمت آمازون پیشنهاد مدنظر خودمون رو دادیم که در اینجا یکسان است و همان را می شود دوباره پیشنهاد داد.

پیشنهاداتی برای رفع مشکلات معماری بدون سرور گوگل:

کاهش وابستگی به ارائه دهنده:

• پشتیبانی از چندین ارائه دهنده: گوگل می تواند از چندین ارائه دهنده ابر مانند AWS، Azure و Oracle Cloud پشتیبانی کند. این به توسعه دهندگان اجازه می دهد تا از مزایای چندین ارائه دهنده ابر به طور همزمان استفاده کنند و از وابستگی به یک ارائه دهنده خاص جلوگیری کنند.
• ایجاد ابزارهای مهاجرت: گوگل می تواند ابزارهایی را برای مهاجرت آسان برنامه ها از یک ارائه دهنده ابر به ارائه دهنده دیگر ایجاد کند. این به توسعه دهندگان آزادی و انعطاف پذیری بیشتری می دهد تا در صورت نیاز به ارائه دهنده دیگری سوئیچ کنند.
• ایجاد استانداردهای باز: گوگل می تواند در ایجاد استانداردهای باز برای معماری بدون سرور مشارکت کند. این به ترویج قابلیت همکاری بین ارائه دهندگان مختلف ابر و کاهش وابستگی به یک ارائه دهنده خاص کمک می کند.

بهبود اشکال یابی و نظارت:

• ارائه ابزارهای اشکال یابی: گوگل می تواند ابزارهای اشکال یابی قدرتمندی را برای کمک به توسعه دهندگان در شناسایی و رفع مشکلات در برنامه های بدون سرور خود ارائه دهد. این ابزارها باید بصری و آسان برای استفاده باشند و باید بتوانند مشکلات را در توابع مختلف پراکنده شناسایی کنند.
• ارائه داشبوردهای نظارتی: گوگل می تواند داشبوردهای نظارتی جامعی را ارائه دهد که به توسعه دهندگان دید کاملی از برنامه های بدون سرور خود را ارائه می دهد. این داشبوردها باید اطلاعات مربوط به عملکرد، استفاده از منابع و سلامت برنامه را نشان دهند.
• ایجاد جامعه پشتیبانی: گوگل می تواند یک جامعه پشتیبانی فعال برای توسعه دهندگان بدون سرور ایجاد کند. این جامعه می تواند به عنوان منبعی برای اشتراک گذاری دانش، بهترین روش ها و کمک به حل مشکلات عمل کند.

کاهش تأخیر شروع سرد:

• استفاده از توابع گرم: گوگل می تواند از توابع گرم برای کاهش تأخیر شروع سرد استفاده کند. توابع گرم توابعی هستند که در حافظه پنهان نگه داشته می شوند و به طور مداوم اجرا می شوند، حتی زمانی که از آنها استفاده نمی شود. این تضمین می کند که توابع بلافاصله پس از فعال شدن آماده اجرا هستند.
• استفاده از پیش گرم کردن: گوگل می تواند از پیش گرم کردن برای کاهش تأخیر شروع سرد استفاده کند. پیش گرم کردن شامل فعال کردن توابع و بارگذاری آنها در حافظه قبل از نیاز به آنها است. این به کاهش زمان لازم برای شروع توابع در هنگام فعال شدن کمک می کند.
• استفاده از تکنیک های auto-scaling: گوگل می تواند از تکنیک های auto-scaling برای اطمینان از اینکه تعداد کافی از توابع برای پاسخگویی به تقاضا در دسترس هستند استفاده کند. این به کاهش تأخیر شروع سرد در هنگام افزایش ناگهانی ترافیک کمک می کند.

پیشنهاداتی برای رفع مشکلات معماری چند لایه در گوگل:

کاهش پیچیدگی:

• استفاده از ابزارهای مدیریت API: گوگل می تواند از ابزارهای مدیریت API مانند Google Cloud API Gateway استفاده کند تا مدیریت و نظارت API ها را ساده کند.
• ایجاد مستندات جامع: گوگل می تواند مستندات جامع و به روز شده ای را برای API های خود ارائه دهد تا توسعه دهندگان بتوانند به راحتی آنها را درک و استفاده کنند.
• ارائه آموزش و منابع: گوگل می تواند آموزش و منابع جامعی را برای کمک به توسعه دهندگان در یادگیری نحوه استفاده از API های خود ارائه دهد.

بهبود کارایی:

• استفاده از حافظه پنهان: گوگل می تواند از حافظه پنهان برای ذخیره سازی داده های frequently accessed استفاده کند تا از بارگذاری مجدد داده ها از پایگاه داده جلوگیری شود.
• بهینه سازی پایگاه داده: گوگل می تواند پایگاه داده خود را برای بهبود عملکرد و کاهش زمان پاسخگویی بهینه کند.
• استفاده از CDN: گوگل می تواند از CDN برای توزیع محتوای خود به کاربران در سراسر جهان استفاده کند تا زمان بارگذاری را کاهش دهد.

ایجاد یک معماری چند لایه انعطاف پذیر: گوگل می تواند یک معماری چند لایه انعطاف پذیر طراحی کند که بتواند به راحتی با نیازهای در حال تغییر سازگار شود.

• استفاده از میکروسرویس ها: گوگل می تواند از میکروسرویس ها برای تجزیه برنامه های خود به اجزای کوچکتر و قابل مدیریت تر استفاده کند.
• استفاده از تکنیک های DevOps: گوگل می تواند از تکنیک های DevOps برای بهبود همکاری و ارتباط بین تیم های توسعه و عملیات خود استفاده کند.

سازمان فیلیمو

فیلیمو، به عنوان یک سرویس ویدئو به درخواست (VOD) محبوب، تجربه تماشای آنلاین فیلم و سریال‌های ایرانی و خارجی را برای کاربران فراهم می‌کند. با استفاده از معماری نرم افزار مبتنی بر وب، فیلیمو به طور موثری نیازهای مختلف کاربران خود را در پلتفرم‌های متنوع پوشش می‌دهد. در ادامه، جزئیات بیشتری در مورد لایه‌های معماری، نیازهای عملکردی و غیرعملکردی، و روش‌های بهینه‌سازی ارائه‌شده در فیلیمو بررسی خواهد شد.

معماری نرم افزار فیلیمو

لایه ارائه: این لایه، که با تکنولوژی‌هایی نظیر HTML، CSS، و JavaScriptو فریمورک‌های React و React Native همراه با توسعه نرم افزار برای سیستم‌عامل‌های Android و iOSطراحی شده، واسط کاربری جذاب و قابل دسترسی را برای دستگاه‌های مختلف فراهم می‌آورد.

لایه منطق: این لایه با استفاده از زبان‌های برنامه‌نویسی مانند PHP، Node.js، و Python و فریمورک‌های Laravelو Django، پردازش درخواست‌های کاربران و ارائه خدمات مورد نیاز را به عهده دارد.

لایه داده: این لایه از پایگاه‌داده‌های MySQLو MongoDB برای ذخیره‌سازی و دسترسی به داده‌های کاربران و محتوا استفاده می‌کند، و با Redisو Elasticsearch، عملکرد و جستجوی سریع‌تری را تضمین می‌کند.

نیازهای عملکردی و غیرعملکردی

برای توضیح دقیق‌تر نیازهای عملکردی و غیرعملکردی سیستمی مانند فیلیمو، می‌توان از مثال‌های زیر استفاده کرد:

نیازهای عملکردی (Functional Requirements)

نیازهای عملکردی به قابلیت‌ها و عملیات‌هایی اشاره دارند که سیستم باید بتواند انجام دهد. در مورد فیلیمو، این نیازها عبارتند از:

1. ثبت‌نام و ورود کاربران: کاربران باید قادر به ایجاد حساب کاربری جدید، ورود و خروج از سیستم، و بازیابی رمز عبور خود باشند.

2. مدیریت اشتراک: کاربران باید بتوانند برای اشتراک‌های مختلف ثبت‌نام کرده، آن‌ها را تمدید و مدیریت کنند.

3. جستجو و مشاهده محتوا: کاربران باید قادر به جستجو، انتخاب و تماشای فیلم‌ها و سریال‌ها باشند. همچنین باید امکان دانلود محتوا برای تماشای آفلاین وجود داشته باشد.

4. تعامل با محتوا: کاربران باید بتوانند به محتوا امتیاز دهند، نظرات خود را ارسال کنند، و محتوا را به لیست علاقه‌مندی‌های خود اضافه یا حذف کنند.

5. کنترل والدین: امکان ایجاد محیطی امن برای کودکان با انتخاب محتوای مناسب سن.

نیازهای غیرعملکردی (Non-Functional Requirements)

نیازهای غیرعملکردی به کیفیت و معیارهایی اشاره دارند که سیستم باید بر اساس آن‌ها عمل کند. برای فیلیمو، این نیازها شامل موارد زیر است:

1. امنیت: سیستم باید اطلاعات کاربران و تراکنش‌های مالی را ایمن نگه دارد، شامل رمزنگاری داده‌ها و محافظت در برابر نفوذهای غیرمجاز.

2. قابلیت مقیاس‌پذیری: سیستم باید توانایی پاسخ‌گویی به افزایش تعداد کاربران و درخواست‌ها را داشته باشد بدون آنکه عملکرد آن به طور قابل توجهی کاهش یابد.

3. کارایی: زمان پاسخ‌گویی سیستم باید کم باشد، حتی در زمان‌های اوج استفاده.

4. قابلیت استفاده: رابط کاربری باید ساده، کاربرپسند و قابل دسترس برای افراد با توانایی‌های مختلف باشد.

5. قابلیت اطمینان: سیستم باید پایدار بوده و بتواند خطاها را به گونه‌ای مدیریت کند که تأثیر کمتری بر تجربه کاربر داشته باشد.

6. پشتیبانی از دستگاه‌های مختلف: سیستم باید قابلیت نمایش محتوا بر روی انواع دستگاه‌ها از جمله موبایل، تبلت، کامپیوتر و تلویزیون‌های هوشمند را داشته باشد.

این نیازها زیربنای توسعه و بهبود مستمر فیلیمو را فراهم می‌آورند، به طوری که سرویسی امن، قابل اعتماد و کاربرپسند ارائه دهد.

بهینه‌سازی‌ها

برای نمایش ویدئو، فیلیمو از اپلیکیشن‌های اختصاصی برای تمام دستگاه‌ها و وب‌سایتی که از HTML5 و JavaScriptاستفاده می‌کند، بهره می‌برد. امکان اتصال دستگاه‌های موبایل به تلویزیون‌ها از طریق Chromecast یا Miracastو تبدیل تلویزیون‌های عادی به هوشمند با استفاده از دستگاه‌هایی مانند فیلیموباکس فراهم شده است.

بهینه‌سازی فایل‌ها شامل استفاده از الگوریتم‌های فشرده‌سازی پیشرفته، اداپتیو بیت‌ریت استریمینگ برای تطبیق با پهنای باند کاربر، و کشینگ محتوا در سرورهای مختلف با استفاده از CDN می‌باشد. همچنین، کاربران می‌توانند کیفیت ویدئو را بر اساس نیاز خود انتخاب کنند و امکان دانلود ویدئوها برای تماشای آفلاین نیز وجود دارد.

پیشنهاد هایی برای بهبود معماری نرم افزار فیلیمو

1. میکروسرویس‌ها: به جای یک معماری تک‌لایه‌ای، می‌توان از معماری میکروسرویس استفاده کرد. به این صورت که هر بخش از منطق کسب‌وکار به صورت یک سرویس مجزا و مستقل پیاده‌سازی شود. مزایای این کار عبارتند از: توسعه‌پذیری و نگهداری آسان‌تر، امکان مقیاس‌پذیری مستقل هر سرویس، انتشار مداوم و انعطاف‌پذیری بیشتر.

2. CQRS: در این الگو، ماژول‌های مجزایی برای عملیات خواندن (Query) و نوشتن (Command) از پایگاه‌داده در نظر گرفته می‌شود تا کارایی و بهره‌وری بهبود یابد. همچنین با استفاده از ذخیره‌سازی کشی می‌توان زمان دسترسی به داده‌ها را کاهش داد. البته این الگو هم ممکن است باعث افزایش پیچیدگی و هزینه‌های توسعه و نگهداری شود. اما با تعیین معیارهای مناسب برای انتخاب بخش‌هایی که از این الگو استفاده می‌کنند و استفاده از ابزارهای مدرن می‌توان این مشکلات را کنترل کرد.

3. معماری بدون‌سرور: با ذخیره‌سازی توزیع‌شده محتوا در شبکه‌ای همتا به همتا (P2P) بر پایه IPFSمی‌توان نیاز به سرورهای متمرکز را کاهش داده و مقیاس‌پذیری، تحمل‌پذیری خطا و امنیت را بهبود بخشید. البته که در شرایط ایران قابل اجرا نیست. چون برای این کار نیاز به دسترسی به اینترنت پایدار و سریع و شبکه‌های همتا به همتا مطمئن و امن است. اما در ایران، اینترنت دارای محدودیت‌های زیادی است و شبکه‌های همتا به همتا نیز ممکن است تحت سانسور و فیلترینگ قرار گیرند. بنابراین، این روش برای فیلیمو مناسب نیست. ولی با فرض اینکه اگر فیلیمو در کشوری غیر از ایران بارگزاری شود میتواند از این پیشنهاد استفاده

4. تحلیل الگوها: با به کارگیری الگوریتم‌های یادگیری ماشینی و داده‌کاوی می‌توان الگوهای رفتاری کاربران را شناسایی کرده و بر اساس آن‌ها خدمات شخصی‌سازی‌شده و توصیه محتوا ارائه نمود. این کار نیاز به داده‌های کافی و کیفی از رفتار کاربران و الگوریتم‌های مناسب برای تحلیل آن‌ها دارد. اما با استفاده از روش‌های جمع‌آوری داده‌ها و یادگیری ماشینی می‌توان این کار را انجام داد.

5. معماری رویداد-محور: استفاده از یک لایه ارتباطی مبتنی بر رویداد بین سرویس‌ها که امکان همگام‌سازی آنی داده‌ها و وضعیت کاربران را فراهم می‌کند. این معماری هم نیاز به ابزارهای مناسب برای انتقال و مدیریت رویدادها دارد. اما با استفاده از تکنولوژی‌های مدرن مانند Kafkaو RabbitMQ می‌توان این کار را انجام داد.

برخی از منابع مورد استفاده :

https://www.britannica.com/topic/Amazoncom

https://en.wikipedia.org/wiki/History_of_Amazon

https://www.techaheadcorp.com/knowledge-center/history-of-aws/

https://www.simplilearn.com/tutorials/cloud-computing-tutorial/cloud-computing-architecture

https://aws.amazon.com/architecture

https://medium.com/@eyupcebe/aws-cloud-architecture-8ea9a99fe8fa

https://dl.acm.org/doi/fullHtml/10.1145/3624486.3624492

http://unikernel.org

https://www.morethanseven.net/2015/08/21/operating-unikernel-challenges

https://dl.acm.org/doi/fullHtml/10.1145/3624486.3624492

http://unikernel.org/

https://www.morethanseven.net/2015/08/21/operating-unikernel-challenges/

https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html

https://blog.nuclino.com/two-pizza-teams-the-science-behind-jeff-bezos-rule

https://www.geeksforgeeks.org/monolithic-architecture/

https://dzone.com/articles/evolution-of-software-architecture-from-monoliths

https://www.mdpi.com/2076-3417/10/17/5797

https://blog.dreamfactory.com/microservices-examples

https://www.youtube.com/watch?v=_azoxefUs_Y

https://insights.sei.cmu.edu/blog/8-steps-for-migrating-existing-applications-to-microservices/

https://cloud.google.com/architecture/microservices-architecture-refactoring-monoliths

https://www.gooddata.com/blog/multi-tenant-architecture/

https://medium.com/@e0324913/multilayered-software-architecture-1eaa97b8f49e

https://www.stackbit.com/blog/content-driven-architecture

https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven

https://www.britannica.com/topic/Netflix-Inc

https://www.geeksforgeeks.org/system-design-netflix-a-complete-architecture/

https://www.codingninjas.com/studio/library/system-design-netflix-a-complete-architecture

https://en.wikipedia.org/wiki/History_of_Google

https://www.spiceworks.com/tech/cloud/articles/what-is-distributed-computing/

https://www.serverless.com/blog/serverless-architecture

https://www.vmware.com/topics/glossary/content/cloud-architecture.html.html

https://cloud.google.com/learn/what-is-cloud-architecture

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است