https://virgool.ir/feed/@arashalam78fa2026-11-12 01:30:16https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@arashalam78https://virgool.ir/@arashalam78/بررسی-معماری-نرم-افزار-netflix-و-spotify-reedwyyv1fgfهمه ما با خدماتی که Netflix ارائه می‌دهد، آشنا هستیم. فیلم‌هایی در دسته‌بندی‌های بزرگ و متنوع و همین‌طور محتوای تلویزیونی را این نرم‌افزار مدیریت می‌کند. Netflix در ازای پرداخت هزینه‌ی ماهانه از طرف کاربران، اجازه دسترسی به این محتواها را می‌دهد. Netflix بیش از 180 میلیون کاربر در بیش از 200 کشور جهان دارد. Netflix روی دو ابر AWS و Open Connect کار می‌کند. این دو ابر به عنوان ستون فقرات Netflix با هم کار می‌کنند و هر دو مسئولیت بالایی در ارائه بهترین ویدیو به کاربران دارند. در شکل زیر معماری این نرم‌افزار محبوب را در سطح بالا مشاهده می‌کنید.شکل1 - نمای کلی معماری NetflixClient : رابط کاربری که برای پخش ویدیوهای Netflix استفاده می‌شود. مانند تلویزیون، XBOX، لپ‌تاپ یا تلفن همراه.OC or Netflix Content delivery network(CDN) :شبکه‌ای از سرورهای توزیع شده در مکان‌های جغرافیایی مختلف است وOpen Connect ، CDN جهانی سفارشی خود Netflix است. OC، همه چیزهایی را که مستلزم پخش ویدئو است را مدیریت می‌کند. در مکان‌های مختلف توزیع می‌شود و با فشار دادن دکمه پخش توسط کاربر، ویدیو از این مؤلفه در دستگاه کاربر نمایش داده می‌شود. بنابراین برای مثال اگر می‌خواهید ویدیو را در آفریقای شمالی پخش کنید، ویدیو از نزدیک‌ترین OC (یا سرور) به جای سرور اصلی (به علت پاسخ سریع‌تر از نزدیک‌ترین سرور) ارائه می‌شود.Database :این بخش همه چیزهایی را که شامل پخش ویدیو نمی‌شود (قبل از زدن دکمه پخش) مانند نصب محتوای جدید، پردازش ویدیوها، توزیع آنها در سرورهای واقع در نقاط مختلف جهان و مدیریت ترافیک شبکه انجام می‌دهد. اکثر فرآیندها توسط خدمات وب آمازون انجام می‌شود.حال وقت آن رسیده به مولفه‌ها و نحوه کار Netflix بپردازیم.چگونه Netflix یک فیلم را نمایش می‌دهد؟ویدیوها و محتوای بسیار باکیفیتی را از تولیدکنندگان دریافت می‌کند و نمایش می‌دهد، بنابراین قبل از ارائه ویدیوها به کاربران، پیش پردازش‌هایی را قاعدتا انجام می‌دهد. Netflix از بیش از 2200 دستگاه پشتیبانی می‌کند و هر یک از آنها به وضوح تصویر و فرمت‌های متفاوتی نیاز دارند. برای اینکه ویدیوها در دستگاه‌های مختلف قابل مشاهده باشند، Netflix رمزگذاری را انجام می‌دهد، که شامل یافتن خطاها و تبدیل ویدیوی اصلی به فرمت‌ها و وضوح‌های تصویر مختلف است. Netflix بهینه‌سازی فایل را برای سرعت های مختلف شبکه ایجاد می‌کند. کیفیت یک ویدیو زمانی خوب است که ویدیو را با سرعت بالای شبکه تماشا می‌کنید. Netflix چندین کپی برای یک فیلم با وضوح های مختلف ایجاد می‌کند. این کپی‌ها نیاز به رمزگذاری و پیش پردازش زیادی دارند. Netflix ویدیوی اصلی را به تکه‌های کوچک‌تر تقسیم می‌کند و با استفاده از کارگران موازی در AWS، این تکه‌ها را به فرمت‌های مختلف (مانند mp4، gp3 و غیره) در وضوح‌های تصویر مختلف (مانند 4k، 1080p و غیره) تبدیل می‌کند. پس از رمزگذاری، فایل‌های ‌کپی‌ ساخته شده، به تمام سرورهای مختلف که در مکان‌های جغرافیایی متفاوت توزیع شده‌اند منتقل می‌شوند.هنگامی که کاربر، Netflix را روی دستگاه خود اجرا می‌کند، ابتدا نمونه های AWS نمایش داده می‌شوند که برخی از وظایف مانند ورود به سیستم، جستجو، سابقه کاربر، صفحه اصلی، صورت‌حساب، پشتیبانی مشتری و غیره را انجام می‌دهند. پس از آن، زمانی که کاربر دکمه پخش را روی یک ویدیو می‌زند، Netflix سرعت شبکه یا ثبات اتصال را تجزیه و تحلیل می‌کند و سپس بهترین سرور Open Connect را در نزدیکی کاربر تشخیص می‌دهد. بسته به اندازه دستگاه و صفحه نمایش، فرمت ویدیویی مناسب در دستگاه کاربر پخش می‌شود. در حین تماشای یک ویدیو، ممکن است ویدیو به صورت نقطه‌ای به نظر برسد و پس از مدتی به حالت HD باز می‌گردد. این به این دلیل اتفاق می‌افتد که برنامه بهترین سرور اتصال باز جریان را بررسی می‌کند و در صورت نیاز بین فرمت‌ها (برای بهترین تجربه مشاهده) جابجا می‌شود.داده‌های کاربر مانند جستجوها، مشاهده ‌شده‌ها، مکان، دستگاه مورد استفاده، بررسی‌ها و موارد پسندیده شده در AWS ذخیره می‌شوند، Netflix از آن برای ایجاد پیشنهاد فیلم برای کاربرانی که از مدل یادگیری ماشین یا Hadoop استفاده می‌کنند، استفاده می‌کند. شاید برای شما سوال باشد Hadoop چیست؟یک برنامه متن باز است، که برای ذخیره و پردازش مجموعه داده‌های بزرگ در اندازه های مختلف از گیگابایت تا پتابایت داده استفاده می‌شود.نقاط مثبت Open connect :مقیاس پذیری بالاکم هزینه بودنکیفیت بالا حال نوبت آن رسیده یک مقدار وارد جزئیات ابزار و برنامه‌های مورد استفاده در Netflix شویم.Elastic Load Balancing (ELB) :به طور خودکار ترافیک ورودی برنامه را در چندین هدف، در یک یا چند منطقه در دسترس توزیع می‌کند. بر سلامت نقاط هدف ثبت شده خود نظارت می‌کند و ترافیک را فقط به نقاط هدف سالم هدایت می‌کند. در Netflix مسئول مسیریابی ترافیک است. ELB یک طرح تعادل بار دو لایه را انجام می‌دهد که در آن بار ابتدا بر روی مناطق در دسترس و سپس نمونه‌ها (سرورها) متعادل می‌شود.شکل 2 - نمای کار تعادل بار دولایه در Netflixسطح اول شامل متعادل سازی با الگوریتم Round Robin پایه مبتنی بر DNS است. هنگامی که درخواست در اولین بار متعادل کننده فرود می‌آید (شکل را ببینید)، در یکی از مناطق (با استفاده از الگوریتم دور چرخشی) که ELB شما برای استفاده از آن پیکربندی شده است (z1 to z3)، متعادل می شود.سطح یا لایه دوم آرایه‌ای از نمونه‌های متعادل‌کننده بار است و باز هم الگوریتم Round Robin را برای توزیع درخواست در بین نمونه‌هایی که پشت آن در همان منطقه یکسان هستند، انجام می‌دهد.ZULL :یک سرویس gateway است که مسیریابی پویا، نظارت، انعطاف پذیری و امنیت را فراهم می کند. ZULL مسیریابی آسانی را، بر اساس پارامترهای پرس و جو، URL و مسیر فراهم می‌کند. حال بیایید عملکرد قسمت های مختلف آن را تحلیل کنیم.سرور Netty مسئولیت رسیدگی به پروتکل شبکه، وب سرور، مدیریت اتصال و کار پروکسی را بر عهده می‌گیرد. هنگامی که درخواست به سرور Netty برخورد می‌کند، درخواست را به فیلتر ورودی پروکسی می‌کند.فیلتر ورودی مسئول احراز هویت، مسیریابی درخواست است. سپس درخواست را به فیلتر نقطه پایانی ارسال می‌کند.فیلتر نقطه پایانی برای بازگرداندن یک پاسخ ایستا یا ارسال درخواست به سرویس Backend استفاده می‌شود. هنگامی که پاسخ را از سرویس Backend دریافت کرد، درخواست را به فیلتر خروجی ارسال می‌کند.یک فیلتر خروجی برای فشرده‌سازی محتوا، محاسبه سنجه‌ها یا افزودن/حذف هدرها استفاده می‌شود. پس از آن، پاسخ به سرور Netty ارسال می‌شود و سپس توسط مشتری دریافت می‌شود.مزایای ZULL:می‌توان درخواست‌های بد را با تنظیم قوانین سفارشی در فیلتر نقطه پایانی یا فایروال فیلتر کنیم.می‌توان سرویس های جدید را تست کرد. وقتی سرویسی را ارتقا می‌دهید و می‌خواهید نحوه رفتار آن با درخواست‌های API بلادرنگ بررسی کنید، در آن صورت، می‌توانید سرویس خاص را روی یک سرور مستقر کنید و می‌توانید بخشی از ترافیک را به سرویس جدید جهت بررسی در زمان واقعی هدایت کنید.می‌توان قوانینی ایجاد کرد و با توزیع بخش های مختلف ترافیک در سرورهای مختلف، ترافیک را به اشتراک گذاشت.توسعه دهندگان همچنین می توانند آزمایش بار را روی سرورهای تازه مستقر شده در برخی ماشین ها انجام دهند. آنها می‌توانند برخی از ترافیک موجود در این سرورها را هدایت کنند و بررسی کنند که یک سرور خاص چقدر می‌تواند بار را تحمل کند.Hystrix :در یک سیستم توزیع شده پیچیده، یک سرور x، ممکن است به پاسخ سرور y متکی باشد. وابستگی‌های بین این سرورها می‌تواند تأخیر ایجاد کند و اگر یکی از سرورها به ناچار در نقطه‌ای از کار بیفتد، کل سیستم ممکن است از کار بیفتد. برای حل این مشکل می‌توان برنامه میزبان را از این خرابی‌های خارجی جدا کنیم. کتابخانه Hystrix برای انجام این کار طراحی شده است. این به شما کمک می کند تا تعاملات بین این سرویس های توزیع شده را با افزودن منطق تحمل تاخیر و تحمل خطا کنترل کنید. Hystrix این کار را با جداسازی نقاط دسترسی بین سرویس‌ها، سیستم از راه دور و کتابخانه‌های دیگر انجام می‌دهد.این کتابخانه در موارد زیر کمک می‌کند:ذخیره‌سازی درخواست با آگاهی همزمان. دسته‌بندی خودکار از طریق جمع‌کردن درخواستبرگشتی و در صورت امکان به زیبایی تنزل دهید.سریع شکست بخورد و به سرعت بهبود یابد.خرابی های آبشاری را در یک سیستم توزیع پیچیده متوقف کنید.کنترل تأخیر و شکست ناشی از وابستگی های قابل دسترسی (معمولاً از طریق شبکه) از طریق کتابخانه‌های مشتری شخص ثالث.معماری میکروسرویس Netflixسبک معماری نتفلیکس به عنوان مجموعه‌ای از سرویس‌ها ساخته شده‌است، که به عنوان معماری میکروسرویس شناخته می‌شود. تمام API های مورد نیاز برای برنامه‌ها و برنامه‌های وب را قوت می‌دهد. هنگامی که درخواست به نقطه پایانی می‌رسد، میکروسرویس‌های دیگر را برای داده‌های مورد نیاز فرا می‌خواند و این میکروسرویس ها نیز می‌توانند داده ها را از میکروسرویس‌های مختلف درخواست کنند. پس از آن، یک پاسخ کامل برای درخواست API به نقطه پایانی ارسال می‌شود. در معماری میکروسرویس، سرویس‌ها باید مستقل از هم باشند، به عنوان مثال، سرویس ذخیره‌سازی ویدیو از سرویسی که وظیفه رمزگذاری ویدیوها را بر عهده دارد جدا می‌شود. حالا در ادامه می‌خواهیم بفهمیم که چگونه آن را قابل اعتماد کنیم.همانطور که اشاره شد استفاده از کتابخانه Hystrix(که قبلا شرح داده شد)میکروسرویس‌های حیاتی و مهم به صورت جداگانه: می‌توانیم برخی از سرویس‌های حیاتی (یا نقطه پایانی یا API ها) را جدا کنیم و آن را کمتر وابسته یا مستقل از سایر سرویس‌ها کنیم. همچنین می‌توانید برخی از سرویس‌های مهم را تنها به سایر سرویس‌های قابل اعتماد وابسته کنید. در حین انتخاب میکروسرویس‌های حیاتی، می‌توانید تمام قابلیت‌های اساسی مانند جستجوی ویدیو، پیمایش یا مسیریابی به ویدیوها، پخش ویدیو و غیره را در بر داشته باشید. به این ترتیب می‌توانید نقاط پایانی را بسیار در دسترس قرار دهید و حتی در بدترین سناریوها حداقل یک کاربر قادر به انجام کارهای اساسی خواهد بود.با سرورها به عنوان بدون حالت رفتار کنید: این مثال ممکن است برای شما خنده دار به نظر برسد، اما برای درک این مفهوم، سرورهای خود را مانند یک گله گاو در نظر بگیرید و به اینکه روزانه چند گالن شیر دریافت می‌کنید اهمیت دهید. اگر روزی متوجه شدید که از یک گاو شیر کمتری دریافت می‌کنید، فقط باید آن گاو را (که شیر کمتری تولید می‌کند) با گاو دیگری جایگزین کنید. برای دریافت مقدار مورد نیاز شیر، نیازی به وابستگی به گاو خاصی ندارید. می‌توانیم مثال ذکر شده را با برنامه خود مرتبط کنیم. ایده این است که سرویس را به گونه‌ای طراحی کنید که اگر یکی از نقاط پایانی خطا می‌دهد یا اگر درخواست را به موقع انجام نمی‌دهد، می توانید به سرور دیگری بروید و کار خود را انجام دهید. به جای تکیه بر یک سرور خاص و حفظ وضعیت در آن سرور، می توانید درخواست را به نمونه سرویس دیگری هدایت کنید و می توانید به طور خودکار یک گره جدید را برای جایگزینی آن بچرخانید. پس اگر سروری از کار بیفتد، با سرور دیگری جایگزین می‌شود.EV Cache :در اکثر برنامه‌ها، مقداری از داده‌ها اغلب استفاده می‌شود. برای پاسخ سریع‌تر، این داده‌ها را می‌توان در بسیاری از نقاط پایانی کش کرد و می‌توان آن ها را به جای سرور اصلی از حافظه پنهان واکشی کرد. این باعث کاهش بار سرور اصلی می‌شود، اما مشکل این است که اگر گره پایین بیاید، تمام حافظه پنهان پایین می‌آید و این می‌تواند به عملکرد برنامه ضربه بزند. برای حل این مشکل Netflix لایه کش سفارشی خود را به نام کش EV ساخته است. کش EV بر اساس Memcached است و در واقع یک بسته بندی در اطراف Memcached است. نتفلیکس خوشه‌های زیادی را در تعدادی از نمونه‌های AWS EC2 مستقر کرده‌است و این خوشه‌ها دارای گره‌های Memcached زیادی هستند و همچنین کلاینت‌های کش دارند. داده‌ها در سراسر خوشه در همان منطقه به اشتراک گذاشته می‌شوند و چندین نسخه از کش در گره‌های خرد‌ شده ذخیره می‌شوند. هر بار که write برای client اتفاق می‌افتد، تمام گره‌ها در همه خوشه‌ها به‌روزرسانی می‌شوند، اما زمانی که read برای حافظه پنهان اتفاق می‌افتد، فقط به نزدیک‌ترین خوشه (نه همه خوشه‌ها و گره‌ها) و گره‌های آن ارسال می‌شود. در صورتی که یک گره در دسترس نباشد، از یک گره موجود دیگر خوانده شود. این رویکرد عملکرد، در دسترس بودن و بحث قابلیت اطمینان را افزایش می‌دهد.Database : نتفلیکس از دو پایگاه داده متفاوت یعنی MySQL (RDBMS) و Cassandra (NoSQL) برای اهداف و دلایل مختلف استفاده می‌کند. MySQL، EC2 را مستقر کرد: Netflix داده‌هایی مانند اطلاعات صورت‌حساب، اطلاعات کاربر و اطلاعات تراکنش‌ها را در MySQL ذخیره می‌کند زیرا نیاز به انطباق با خواص ACID دارد. Netflix یک تنظیمات master-master برای MySQL دارد و در نمونه‌های بزرگ EC2 آمازون با استفاده از InnoDB مستقر شده است.شکل 3 - نمای پایگاه داده MySQL در پایگاه دادهاین تنظیمات از «پروتکل تکرار همزمان» پیروی می‌کند که در آن اگر نویسنده گره اصلی master باشد، به گره master دیگری نیز کپی می‌شود. تأیید فقط در صورتی ارسال می‌شود که نوشتن گره اصلی و از راه دور master تأیید شده باشد. این در دسترس بودن بالای داده‌ها را تضمین می‌کند.نتفلیکس نسخه خواندنی را برای هر گره (محلی و همچنین بین منطقه‌ای) تنظیم کرده است. این امر در دسترس بودن و مقیاس پذیری بالا را تضمین می‌کند. تمام query های read به کپی‌های خوانده شده هدایت می‌شوند و فقط query های write به گره‌های اصلی هدایت می‌شوند. در صورت خرابی اصلی MySQL، گره اصلی ثانویه نقش اصلی را بر عهده خواهد گرفت و ورودی route53 (پیکربندی DNS) برای پایگاه داده به این گره اصلی جدید تغییر خواهد کرد. این همچنین موجب می‌شود query های write را به این گره اصلی master جدید هدایت شوند.Cassandra :یک پایگاه داده NoSQL است که می‌تواند حجم زیادی از داده‌ها را مدیریت کند و همچنین می‌تواند نوشتن و خواندن سنگین را انجام دهد. هنگامی که Netflix شروع به جذب کاربران بیشتری کرد، مشاهده داده‌های سابقه برای هر عضو نیز شروع به افزایش کرد. این تعداد کل مشاهده داده‌های سابقه را افزایش می‌دهد و مدیریت این حجم عظیم داده برای Netflix چالش برانگیز می‌شود. Netflix ذخیره‌سازی تاریخچه مشاهده داده‌ها را افزایش داده و دو هدف اصلی را در ذهن خود نگه می‌دارد:فضای ذخیره سازی کوچکترعملکرد خواندن/نوشتن ثابت با افزایش مشاهده به ازای هر عضو (نسبت نوشتن به خواندن داده‌های تاریخ مشاهده در Cassandra حدود 9 به 1 است).در ابتدا، تاریخچه مشاهده در cassandra در یک ردیف ذخیره می‌شد. هنگامی که کاربران شروع به افزایش در Netflix کردند، اندازه ردیف و همچنین اندازه کلی داده افزایش یافت. این منجر به ذخیره‌سازی بالا، هزینه عملیاتی بیشتر و عملکرد کند برنامه شد. راه حل این مشکل فشرده‌سازی ردیف‌های قدیمی بود، که در نتیجه آن Netflix داده ها را به دو قسمت تقسیم کرد:تاریخچه مشاهده زنده (LiveVH): این بخش شامل تعداد کمی از داده‌های تاریخی مشاهده اخیر کاربران با به روزرسانی‌های مکرر است. داده ها اغلب برای کارهای ETL استفاده می‌شوند و به صورت فشرده نشده ذخیره می‌شوند.تاریخچه مشاهده فشرده (CompressedVH): تعداد زیادی از رکوردهای مشاهده قدیمی با به روز‌رسانی‌های نادر در این بخش دسته‌بندی شده است. داده‌ها در یک ستون در هر کلید ردیف، همچنین به صورت فشرده برای کاهش ذخیره‌سازی ذخیره می‌شوندپردازش داده در Netflix به کمک Kafka و Apache Chukwaفرض کنید آرش امروز وارد حساب کاربری خود در Netflix شده‌است، هنگامی که روی یک ویدیو کلیک می‌کند، Netflix شروع به پردازش داده‌ها در شرایط مختلف می‌کند و این عمل را در کمتر از یک نانو ثانیه طول می‌کشد. پس بیایید در مورد نحوه عملکرد خط لوله تکامل در Netflix بحث کنیم.نتفلیکس از Kafka و Apache Chukwe برای دریافت داده‌هایی که در بخش‌های مختلف سیستم تولید می‌شوند استفاده می‌کند. نتفلیکس تقریباً 500 میلیارد رویداد داده با مصرف 1.3 پتابایت در روز و 8 میلیون رویداد داده با مصرف 24 گیگابایت در ثانیه در زمان اوج مصرف ارائه می‌دهد. این رویدادها شامل اطلاعاتی از جمله:گزارش‌های خطافعالیت‌های رابط کاربریرویدادهای اجراییفعالیت‌های مشاهده ویدیوتشخیص و عیب‌یابی رویدادهامی‌باشد.Apache Chukwe :یک سیستم جمع‌آوری داده متن باز، برای جمع‌آوری گزارش‌ها یا رویدادها از یک سیستم توزیع شده‌است. این بر روی HDFS و Map-reduce ساخته شده‌است. دارای ویژگی‌های مقیاس‌پذیری و استحکام Hadoop است. همچنین، شامل بسیاری از ابزارهای قدرتمند و انعطاف‌پذیر برای نمایش، نظارت و تجزیه و تحلیل نتیجه است. Chukwe رویدادها را از قسمت های مختلف سیستم جمع‌آوری می‌کند و می‌توان نظارت و تجزیه و تحلیل را به کمکش انجام داد یا اینکه می‌توان از داشبورد برای مشاهده رویدادها استفاده کنید. Chukwe رویداد را در قالب توالی فایل Hadoop (S3) می‌نویسد. پس از آن تیم Big Data این فایل های S3 Hadoop را پردازش می‌کند و Hive را در قالب داده Parquet می‌نویسد. این فرآیند پردازش دسته ای نامیده می‌شود که اساساً کل داده‌ها را در فرکانس ساعتی یا روزانه اسکن می‌کند.برای آپلود رویدادهای آنلاین در EMR/S3، Chukwa همچنین ترافیکی را برای کافکا (دروازه اصلی در پردازش بی‌درنگ داده) فراهم می‌کند. کافکا مسئول انتقال داده‌ها از جلوی کافکا به حفره‌های مختلف است: S3، Elasticsearch و Secondary kafka. مسیریابی این پیام‌ها با استفاده از Apache Samja انجام می‌شود. ترافیک ارسال شده توسط Chukwe می‌تواند جریان‌های کامل یا فیلتر شده باشد، بنابراین گاهی اوقات ممکن است مجبور شوید فیلترهای بیشتری را در جریان‌های kafka اعمال کنید.Elastic Search :در سال های اخیر رشد گسترده‌ای در استفاده از Elasticsearch در Netflix مشاهده شده‌است. Netflix تقریباً 150 خوشه جستجوی الاستیک و 3500 میزبان با نمونه اجرا می‌کند. نتفلیکس از جستجوی الاستیک برای نمایش داده‌ها، پشتیبانی از مشتری و برای تشخیص برخی خطاها در سیستم استفاده می‌کند. به عنوان مثال، اگر مشتری نتواند ویدیو را پخش کند، مدیر خدمات مشتری این مشکل را با استفاده از جستجوی الاستیک حل می‌کند. تیم پخش به جستجوی الاستیک می‌رود و کاربر را جستجو می‌کند تا بداند چرا ویدیو در دستگاه کاربر پخش نمی‌شود. آنها با تمام اطلاعات و رویدادهایی که برای آن کاربر خاص اتفاق می‌افتد آشنا می‌شوند، و متوجه می‌شوند که چه چیزی باعث خطا در جریان ویدیو شده‌است. جستجوی الاستیک نیز توسط مدیر برای پیگیری برخی اطلاعات استفاده می‌شود. همچنین برای پیگیری استفاده از منابع و شناسایی مشکلات ثبت نام یا ورود مورد استفاده قرار می‌گیرد.استفاده از Apache Spark جهت پیشنهاد فیلمنتفلیکس از Apache Spark و Machine Learning برای توصیه فیلم استفاده می‌کند. بیایید با یک مثال بفهمیم که چگونه کار می کند. هنگامی که صفحه اول را بارگذاری می‌کنید، ردیف‌های متعددی از انواع مختلف فیلم را مشاهده می‌کنید. Netflix این داده‌ها را شخصی‌سازی می‌کند و تصمیم می‌گیرد که چه نوع ردیف‌هایی یا چه نوع فیلم‌هایی باید به یک کاربر خاص نمایش داده شوند. این داده ها بر اساس داده‌های تاریخچه و ترجیحات کاربر است. همچنین، برای آن کاربر خاص، Netflix مرتب‌سازی فیلم‌ها را انجام می‌دهد و رتبه‌بندی مرتبط (برای توصیه و پیشنهاد) این فیلم‌های موجود در بستر خود را محاسبه می‌کند.در Netflix ، Apache Spark برای توصیه‌های محتوا و شخصی‌سازی استفاده می‌شود. اکثر خطوط لوله یادگیری ماشین بر روی این خوشه‌های spark بزرگ اجرا می‌شوند. سپس از این خطوط لوله برای انتخاب ردیف، مرتب‌سازی، رتبه‌بندی ارتباط عنوان و شخصی‌سازی آثار هنری در میان سایر موارد استفاده می‌شود.شخصی‌سازی Artworkهنگامی که صفحه اول Netflix را باز می کنید، ممکن است متوجه تصاویر مربوط به هر ویدیو شده باشید. به این تصاویر، تصاویر تیتر (تصویر کوچک) می‌گویند. Netflix حداکثر کلیک را برای ویدیوها از کاربران می خواهد و این کلیک‌ها به تصاویر تیتر بستگی دارد. Netflix باید تصویر تیتر قانع‌کننده مناسبی را برای یک ویدیوی خاص انتخاب کند. برای انجام این کار، Netflix چندین اثر هنری را برای یک فیلم خاص ایجاد می کند و این تصاویر را به صورت تصادفی برای کاربران نمایش می‌دهد. برای یک فیلم، تصاویر می‌توانند برای کاربران مختلف متفاوت باشند. نتفلیکس بر اساس اولویت‌ها و سابقه تماشای شما پیش‌بینی می‌کند که چه نوع فیلم‌هایی را بیشتر دوست دارید یا چه بازیگرانی را در یک فیلم بیشتر دوست دارید. با توجه به سلیقه کاربران، تصاویر برای آنها نمایش داده می‌شود.سیستم پیشنهاد فیلماگر کاربری بخواهد محتوا یا ویدیویی را در Netflix کشف کند، سیستم توصیه Netflix به کاربران کمک می‌کند تا فیلم‌ها یا ویدیوهای مورد علاقه خود را پیدا کنند. برای ساخت این سیستم توصیه، Netflix باید علاقه کاربر را پیش‌بینی کند و انواع مختلفی از داده‌ها را از کاربران جمع‌آوری می‌کند، از جمله:تعامل کاربر با سرویس (مشاهده سابقه و نحوه امتیازدهی کاربر به عناوین دیگر)سایر اعضا با سلایق و ترجیحات مشابهاطلاعات فراداده از ویدیوهای قبلاً تماشا شده برای یک کاربر مانند عناوین، ژانر، دسته‌ها، بازیگران، سال انتشار و غیرهدستگاه کاربر، در چه زمانی کاربر فعال تر است و برای چه مدت کاربر فعال استنتفلیکس از دو الگوریتم مختلف برای ساخت یک سیستم توصیه استفاده می‌کند:فیلتر مشارکتی: ایده این فیلترینگ این است که اگر دو کاربر سابقه رتبه‌بندی مشابهی داشته باشند، در آینده نیز رفتار مشابهی خواهند داشت. به عنوان مثال، در نظر بگیرید دو نفر وجود دارد. یک نفر از فیلم خوشش آمد و امتیاز خوبی به فیلم داد. در حال حاضر، احتمال زیادی وجود دارد که فرد مقابل نیز الگوی مشابهی داشته باشد و همان کاری را انجام دهد که نفر اول انجام داده است.فیلتر مبتنی بر محتوا: ایده این است که آن ویدیوهایی را فیلتر کنید که مشابه ویدیویی است که کاربر قبلاً دوست داشته است. فیلترینگ مبتنی بر محتوا به شدت به اطلاعات محصولات مانند عنوان فیلم، سال انتشار، بازیگران، ژانر بستگی دارد. بنابراین برای پیاده‌سازی این فیلتر، دانستن اطلاعاتی که هر مورد را توصیف می‌کند مهم است و نوعی نمایه کاربر که توصیف کننده آنچه کاربر دوست دارد نیز مطلوب است.بررسی معماری نرم‌افزار Spotifyکوین گولداسمیت مدیر ارشد فناوری اسبق Spotify باور دارد برای یک نرم‌افزار مقیاس وسیع ویژگی‌های زیر باید وجود داشته باشد:امکان مقیاس‌پذیری تا میلیون‌ها کاربرپشتیبانی از چندین پلتفرمتوانایی مدیریت قوانین پیچیده تجارتیتوانایی ادامه در رقابت بازار جهانی واکنش سریع نوآوری کردنتخمینی از مقیاس بیش از 365 میلیون کاربر فعال (2021)ساخت 8 میلیون آهنگ در سالاضافه شدن 60000 آهنگ در روزپشتیبانی بیش از 30 زبان8 هزار هنرمند فعال قوانین به شدت پیچیده تجاریحجم بالای رقبانیازمندی‌های غیر‌ وظیفه‌مندی Spotify : قابلیت استفاده (usability)قابلیت اطمینان (reliability)کارایی (performance)تاخیر کم (Low latency)Load Balancer : برای نگهداری و مدیریت ترافیک ورودی به سرور زمانی که یک کاربر یک آهنگ را درخواست می‌کند، درخواست به LB می‌رود. تکنیکی که در اینجا استفاده می‌شود، تعادل بار Round Robin برای توزیع درخواست‌ها به سرور با کمترین ترافیک برای رسیدن به تاخیر کم است. The recommendation algorithm :سیستم توصیه‌گر شباهت عناصر (کاربر، موسیقی، فرکانس) را با استفاده از فیلتر مشارکتی ضمنی بر اساس مدل‌های عامل پنهان(Latent factor model, ) شناسایی می‌کند. بنابراین، آهنگ های مشابه به لیست پخش کاربران ارسال می شود.Autonomous full-stack teams :با تمام شرایط بالا گاها نیازمندی‌ها با هم متناقض‌اند. تیم‌های نرم‌افزاری وجود دارند که کنترل کامل بر کار آن‌ها وجود دارد. یک تیم باید تقریبا وابستگی به تیم دیگری نداشته باشد. و خب قاعدتا معماری بهتر از میکروسرویس به هدف وابستگی پایین قسمت‌های مختلف سیستم به هم وجود ندارد.چرا میکروسرویس، مزایا:مقیاس‌پذیری راحت با توجه به مشکلات و گلوگاه‌های دنیای واقعیآزمون و تست ساده‌ترپیاده‌سازی راحت‌تر(کوچک‌ترند)نظارت ساده‌تر(نمونه‌های کوچک و کارکرد مشخص)به طور مستقل و جداگانه نسخه‌سازی شوندخطاها و شکست‌های کوچکمشکلات میکروسرویس:مشکل نظارت(تعداد بالای نمونه‌ها و سرویس‌ها)نیازمند به مستند‌سازی خوب و مناسبافزایش تاخیر(فراخوانی سرویس‌ها به صورت تودرتو)Apollo Framework :اسپاتیفای از Apollo را توسعه داده‌است و به صورت متن‌باز در اختیار عموم قرار داده است، که به کمک آن فرآیندهایی از جمله ساخت یک سرویس جدید می‌باشد. جهتدر ادامه بحث معماری نرم‌افزار به موفقیت و محبوبیت Spotify که همه را شگفت‌زده کرده است می‌پردازیم. بله، از صنعت موسیقی و سرگرمی گرفته تا دنیای فناوری و تجارت.یک کاتالوگ بزرگ، شامل هزاران موسیقیدسترس‌پذیر در همه‌ جاتجربه کاربری عالیمناسب برای حقوق هنرمندسریع، قابل اعتماد، همیشه در دسترسمقیاس‌پذیر برای کاربرانی با تعداد بالااسپاتیفای برای مقابله با تهدید فزاینده دزدی در آهنگ‌ها راه‌اندازی شد. تخمین زده می‌شود که 30 تا 40 درصد از درآمدهای تولید شده توسط صنعت موسیقی به دلیل دزدی از بین رفته‌است و هنرمندانی که موسیقی اصیل خلق می‌کنند نتوانسته‌اند به طور عادلانه‌ای برای هنر خود به حقوق خود دست یابند. با درک این مشکلات، Daniel Ek و Martin Lorentzon از سوئد، Spotify را در سال 2006 راه‌اندازی کردند و بلافاصله به محبوب‌ترین سرویس پخش موسیقی در جهان تبدیل شدند. Spotify با بیش از 422 میلیون کاربر فعال و 182 میلیون کاربر پولی، در صدر جدول صنعت پخش موسیقی قرار گرفته‌است و در حال حاضر یکی از محبوب‌ترین و رایج‌ترین پلتفرم‌ها برای دسترسی آسان و یکپارچه به انواع موسیقی است.مقدمه کافی‌ست، بیاید به معماری این نرم‌افزار بپردازیم. معماری نرم‌افزار طرح و نقشه راه است که بر اساس آن کل نرم‌افزار ایجاد می‌شود و هر پلتفرم موبایل/دیجیتال برای شروع نیاز به معماری نرم‌افزاری دارد.اسپاتیفای کاملاً بر اساس معماری Microservices است که توسط Kevin Goldsmith که مدیر ارشد فناوری قبلی در Spotify بود تأیید و توضیح داده شده‌است. اما شاید سوالی پیش بیاید که اصلا چرا معماری میکروسرویس؟ معماری نرم‌افزار Spotify به شدت به سرویس‌ها وابسته است و به همین دلیل است که معماری مبتنی بر میکروسرویس برای Spotify نهایی شد و می‌توان گفت به خوبی کار کرد.در بطن Spotify، به صدها سرویس نیاز دارد که اکثر آنها کوچک و ساده هستند، اما باید در زمان اجرا و بدون هیچ تاخیری سرویس‌ بدهند.برای ارائه خدمات به این صدها سرویس، تیم فنی Spotify یک معماری مبتنی بر میکروسرویس‌ها را به کار گرفته‌است، جایی که در آن برای رفع یک نیاز به سرویس در یک زمان خدمت می‌کند: برای مثال بازیابی یک آهنگ، به اشتراک‌گذاری توصیه‌ها، جستجو، یا مثالی ساده مانند تأیید یک کاربر (برای مدل رایگان و پولی).شکل 4 - API برای شخصی سازی کاربرسرویس‌ها چگونه کار می‌کنند و پاسخ می‌دهند؟سرویس‌ها معمولاً به زبان پایتون و یا جاوا نوشته می‌شوند. و آن‌ها از طریق پروتکل Hermes با یکدیگر ارتباط برقرار می‌کنند که Spotify از ابتدا با استفاده از ZeroMQ و Protobuf توسعه داده است. با این حال، برخی از سرویس‌های قدیمی ایجاد شده در ابتدا هنوز از HTTP و XML/JSON برای ارتباط استفاده می‌کنند.برای سرویس‌های مبتنی بر پایگاه داده و ذخیره‌سازی، PostgreSQL و Cassandra توسط Spotify استفاده می‌شود. Cassandra برای خدمات مبتنی بر محتوا مانند جستجوی آهنگ‌ها یا بازیابی ابرداده آهنگ‌ها در زمان اجرا ترجیح داده می‌شود.یک سرویس پشتیبان بسیار تخصصی به نام «نقطه دسترسی» وجود دارد که برای ارتباط سریع و دقیق، دائماً با client های مختلف در تماس است. پروتکلی که ارتباط یکپارچه بین مشتریان و «نقطه دسترسی» را امکان‌پذیر می‌سازد نیز توسط مهندسان Spotify ساخته شده‌است و به صورت عمومی منتشر نشده‌است.زیرساخت نرم‌افزار در Spotify به شدت به Debian وابسته است، در حالی که نرم‌افزار متن‌باز برای فعالیت‌های مختلف ترجیح داده می‌شود.راز پخش سریع موسیقی در Spotifyدر معماری مبتنی بر Microservices، صدها توسعه‌دهنده نرم‌افزار به طور همزمان مشغول به کار هستند که انواع مختلف خدمات و ارتباطات آنها را مدیریت می‌کنند. حال، راز این نرم‌افزار این است که هر یک از این توسعه‌دهندگان نرم‌افزار در یک قلمرو بسته، با قابلیت‌ها و ماموریت‌های خاص کار می‌کنند. هر میکروسرویس فقط یک مسئولیت و هدف دارد و اکثریت این میکروسرویس‌ها پایگاه داده خصوصی خود را با منطق خاص خود دارند و دیگر پایگاه‌داده‌های میکروسرویس‌های دیگر نمی‌توانند در آن‌ها دخالت کنند. به همین دلیل است که Spotify بسیار سریع و دقیق است و نیازهای کاربر نهایی را به سرعت برآورده می‌کند. هنگامی که یک درخواست برای هر کار خاص ارسال شد، برنامه به سرعت پاسخ می‌دهد، سرویس‌های مختلف را در ماشین‌های مختلف مستقر می‌کند، و بسته به سرویس خاصی که فراخوانی می‌شود، پارامترهای عملکرد شخصی‌سازی شده و سفارشی‌سازی شده دارد.مدیریت تغییر بدون درز منطقحال، اگر توسعه‌دهنده نرم‌افزار نیاز به تغییر منطق هر feature داشته باشد، چه؟ هیچ مشکلی برای تاخیر زمانی یا اختلال در کل برنامه وجود ندارد، زیرا هر میکروسرویس منطق خاص خود را دارد و اجرای تغییرات بسیار آسان است. سرویس خاصی که با این ویژگی مرتبط است باید روی آن کار شود، ویرایش‌ها انجام می‌شود و سپس فقط آن سرویس آزمایش می‌شود و سپس فوراً مستقر می‌شود. از این رو، آن سرویس اکنون تغییر کرده است، منطق تغییر کرده است و این ویژگی اکنون عملکرد جدیدی خواهد داشت. این سرویس پس از اتمام استقرار با برنامه شروع به برقراری ارتباط می‌کند و مطلقاً نیازی به آزمایش مجدد و استقرار مجدد کل برنامه نیست. این ویژگی مدیریت تغییر میکروسرویس‌ها که به عنوان معماری نرم‌افزار Spotify مورد استفاده قرار می‌گیرد، یکی از قدرتمندترین قابلیت هاست که Spotify را سریع و کاربر پسند می‌کند.جالب اینجاست که معماری نرم‌افزار Spotify به گونه‌ای توسعه یافته است که همه مشتریان ممکن برنامه: موبایل، دسکتاپ(pc)/لپ‌تاپ، و libspotify (کتابخانه قابل جاسازی Spotify)، همه یک پایگاه کد مشترک دارند. با استفاده از این پایه کد مشترک، توسعه دهندگان می‌توانند عملکرد مشتری را تغییر داده یا ارتقا دهند و یک رابط کاربری منحصر به فرد برای کاربران نهایی ارائه دهند. از آنجایی که این پایه، یک کد به زبان C++ است، تغییرات و ویرایش‌ها در رابط کاربری اصلی نیز آسان و بدون درز است. پذیرش‌های پلتفرم خاص به زبان‌های مخصوص پلتفرم نوشته شده‌اند، به عنوان مثال، ObjC برای iOS.Hadoop :تجزیه و تحلیل log را با استفاده از Hadoop انجام می‌شود که به فرآیند توصیف شده قبلی باز می‌گردد. به عنوان مثال، محبوبیت آهنگ برای سنجش نتایج جستجو و صدر لیست‌ برتر استفاده می‌شود.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهید بهشتی است.آرش علمآرش علمThu, 09 Feb 2023 01:37:46 +0330https://virgool.ir/@arashalam78/api-gateway-pbt8ojfxdpi9دروازه API یا API Gateway چیست؟دروازه API یک الگوی نرم‌افزاری است، که در لایه front یک رابط برنامه‌نویسی کاربردی (API) یا گروهی از ریزسرویس‌ها قرار می‌گیرد، تا درخواست‌ها و تحویل داده‌ها و خدمات را تسهیل کند. نقش اصلی‌اش، این است که به عنوان یک نقطه ورودی واحد و فرآیند استاندارد شده برای تعاملات بین برنامه‌ها، داده‌ها و خدمات سازمان و مشتریان داخلی و خارجی عمل کند. دروازه API همچنین می‌تواند عملکردهای مختلفی را برای پشتیبانی و مدیریت استفاده از API انجام دهد، از احراز هویت گرفته تا محدود کردن نرخ و تجزیه و تحلیل.چگونه این دروازه‌ی API کار می‌کند؟این دروازه‌ها به برنامه‌های کاربردی جداگانه اجازه می‌دهند با یکدیگر ارتباط برقرار کنند و داده‌ها را در داخل و خارج از یک کسب و کار تبادل کنند. درخواست‌هایی را از منابع داخلی و خارجی دریافت می‌کند که «فراخوانی‌های API» نامیده می‌شوند و درخواست‌های متعدد را بسته‌بندی می‌کنند، آنها را به یک API یا APIهای مناسب هدایت و مسیریابی می‌کنند و پاسخ‌ها را به کاربر یا دستگاهی که درخواست کرده‌اند دریافت و تحویل می‌دهد.دروازه‌های API همچنین کلید معماری مبتنی بر میکروسرویس‌ها هستند، که در آن درخواست‌های داده، برنامه‌ها و سرویس‌های متعددی را فراخوانی می‌کنند که از چندین API متفاوت استفاده می‌کنند. در اینجا نقش دروازه API مشابه است: ارائه یک نقطه ورود واحد برای یک گروه تعریف شده از میکروسرویس ها، و اعمال سیاست هایی برای تعیین در دسترس بودن و رفتار آنها.دروازه های API اغلب سایر عملکردهای مرتبط با API ها و میکروسرویس‌ها را انجام می‌دهند، که به مواردی از آن‌ها اشاره می‌شود:ترجمه‌ی پروتکلکشف سرویسمنطق اساسی کسب و کاراحراز هویت و اجرای سیاست‌های امنیتیتثبیت و تعادل بارمدیریت cacheنظارت، ثبت log، تجزیه تحلیلدر این بخش قصد دارم که API gateway را با دو مفهوم API proxy و service mesh مقایسه کنیم.مقایسه API Gateway و API Proxyیک جایگزین برای دروازه API یک API Proxy است، که اساساً زیر مجموعه ای از دروازه API است که حداقل پردازش را برای درخواست های API ارائه می‌دهد. API Proxy ارتباطات، از جمله ترجمه پروتکل، بین پلتفرم های نرم‌افزاری خاص، مانند نقطه پایانی Proxy و API هدف را مدیریت می‌کند. همچنین می‌تواند جریان ترافیک بین نقاط ارسال و دریافت را کنترل کند. با این حال، دروازه‌های API معمولاً دارای قابلیت‌های تحلیل عملکرد و نظارت بهتری هستند.مقایسه API Gateway و service meshاساساً، service mesh همچنین ارتباطات به/ از خدمات یک سازمان را با برخی از تعادل بار و سایر عملکردها تسهیل می‌کند. با این حال، service mesh معمولاً ارتباطات داخلی را مدیریت می‌کند و نقش آن در سطح مدیریت شبکه است. یک دروازه API تعامل با کاربران و دستگاه های خارجی و همچنین منابع داخلی را تسهیل می کند و در لایه برنامه قرار دارد. به این ترتیب نقش‌های آن‌ها می‌توانند مکمل باشند -- برای مثال دروازه‌های API می‌توانند نقطه ورود به یک mesh باشند، در حالی که برخی از دروازه‌های API پلاگین‌هایی را ارائه می‌دهند تا خودشان یک service mesh را تشکیل دهند.چه کسانی از API Gateway استفاده می‌کنند، و چرا استفاده می‌کنند؟دروازه API نقطه کانونی برای پیام‌رسانی API‌، جهت سازماندهی و ساده‌سازی فعالیت‌های API و مبادلات با مشتریان داخلی و خارجی است. این مدیریت و نظارت همچنین به کسب‌وکار امکان می‌دهد تا دامنه وسیعی از APIها و ادغام‌ها را به‌جای تلاش برای ردیابی و مدیریت جداگانه APIها به صورت متمرکز ببیند و کنترل کند. دروازه‌های API معمولاً شامل قابلیت‌های نظارت و ثبت گزارش(log) برای ضبط و تجزیه و تحلیل فراخوان‌ها و پاسخ‌ها به منظور اطمینان از امنیت و ارزیابی خطاها هستند.دروازه‌های API همچنین می‌توانند از سایر عملکردهای حاکم بر APIها پشتیبانی کنند. به عنوان مثال، مدیران خط مشی از عبارات منطقی استفاده می کنند که از طریق یک دروازه API عمل می کند تا در دسترس بودن و رفتار API را تعیین کند، مانند نحوه کنترل جریان داده ها، یا کاهش تماس ها و توان عملیاتی فراخوانی های API.سازمان‌هایی که معماری مبتنی بر ریزسرویس‌ها را اتخاذ کرده‌اند به طور مشابه به دروازه‌های API برای تسهیل ارتباطات بین آن سرویس‌ها متکی هستند. مزایا و چالش‌هایی از API Gatewayمزیت اصلی دروازه API این است که ارائه خدمات را از طریق API یا میکروسرویس ها استاندارد و متمرکز می‌کند. فراتر از این، دروازه‌های API همچنین به ایمن‌سازی و سازماندهی ادغام‌های مبتنی بر API سازمان به روش‌های مختلفی کمک می‌کنند.تسهیل ارائه خدمات : دروازه‌های API می‌توانند چندین فراخوانی API را برای درخواست و بازیابی داده‌ها و خدمات ترکیب کنند، که حجم درخواست‌ها و ترافیک را کاهش می‌دهد. این فرآیند API را ساده می‌کند و می تواند تجربه کاربر را به ویژه برای برنامه‌های تلفن همراه بهبود بخشد.انعطاف پذیری : دروازه های API بسیار قابل تنظیم هستند. توسعه‌دهندگان می‌توانند ساختار داخلی یک برنامه کاربردی را به روش‌های مختلف کپسوله کنند تا چندین سرویس Back-end را فراخوانی کنند و نتایج را جمع‌آوری کنند.گسترش برنامه‌های قدیمی : شرکت‌هایی که به برنامه‌های قدیمی متکی هستند، می‌توانند از دروازه‌های API برای کار با آن برنامه‌ها و حتی گسترش عملکرد آنها، به عنوان جایگزینی برای مهاجرت گسترده‌تر و پیچیده‌تر (و گران‌تر) استفاده کنند.کمک به نظارت و مشاهده (بررسی) : بیشتر سازمان ها برای نظارت بر فعالیت ها از طریق API ها به ابزارهای خاصی متکی هستند، اما یک دروازه API می تواند به این تلاش ها کمک کند. گزارش‌های(log) دروازه API می‌توانند به شناسایی دقیق یک مشکل در طول یک رویداد خرابی نظارت کمک کنند. دروازه API، دروازه‌بان بین مصرف کنندگان و ارائه دهندگان API است و این نقش گسترده چالش های منحصر به فردی را ایجاد می کند.قالبیت اطمینان و حالت ارتجاعی : هر گونه اختلال یا مانعی برای عملکرد دروازه API ممکن است باعث شکست سرویس‌های مرتبط شود. شرکت‌ها باید مراقب اضافه کردن ویژگی‌هایی باشند که بر عملکرد تأثیر می‌گذارند، به‌ویژه که دروازه API یک مرحله فرآیند اضافی بین مشتریان و برنامه‌ها یا داده‌ها را نشان می‌دهد.امنیت : دروازه API یک منبع قابل اعتماد است که بسیاری از زوایای کسب و کار یک شرکت را لمس می‌کند. اگر به خطر بیفتد، این به طور بالقوه یک مشکل امنیتی جدی و گسترده است. کسب و کارها باید به دقت رابط های خارجی را از API ها و سیستم های داخلی جدا کرده و پارامترهای احراز هویت و مجوز را تعریف کنند.پیچیدگی و وابستگی‌ها : هر زمان که یک API یا میکروسرویس اضافه می‌شود، تغییر می‌کند یا حذف می‌شود، توسعه‌دهندگان باید دروازه API را به روز کنند. این امر به ویژه در مدلی چالش‌برانگیز است که در آن چند برنامه کاربردی می‌توانند به ده‌ها یا صدها میکروسرویس تبدیل شوند. ایجاد و رعایت قوانین طراحی API و میکروسرویس ها می‌تواند به کاهش این مشکلات کمک کند.انواع مختلف محصولات API Gateway چیست؟با توجه به اهمیت محوری دروازه API در اقتصاد API امروزی، بسیاری از ارائه دهندگان دروازه های API را به عنوان ابزار مستقل یا عملکردی همراه با پلتفرم های مدیریت API گسترده تر ارائه می‌دهند.نمونه هایی از فروشندگان پلتفرم مدیریت API که نوعی عملکرد دروازه API را در خود جای داده‌اند عبارتند از Akana، Mulesoft، Postman، Tibco، Workato و دیگر موارد.سازمان ها همچنین می توانند به طور جداگانه ابزارهای دروازه API خاصی را بدست آورند و استفاده کنند. به عنوان مثال می توان به Apigee (اکنون بخشی از Google Cloud)Express Gateway، Kong Gateway، Oracle API Gateway و Tyk API Gateway اشاره کرد.ارائه دهندگان عمده ابر عمومی پلتفرم های مدیریت API را ارائه می‌دهند: AWS API Gateway، Microsoft Azure API Management و Google Cloud Endpoints. آنها همچنین ابزارهای دروازه API مخصوص پلتفرم های خود را ارائه می دهند: Amazon API Gateway، Azure API Gateway و Google Cloud API Gateway (در نسخه بتا از ژانویه 2021).فاکتورهایی که باید هنگام ارزیابی یک دروازه API در نظر گرفت. کسب و کارها هنگام انتخاب یک دروازه API باید چندین معیار را بسنجید، از جمله موارد زیر:اختصاصی در مقابل متن باز : کسب‌ و کاری که دروازه API یک فروشنده را ارزیابی می‌کند، ممکن است از محصولات دیگری از آن فروشنده استفاده کند. به عنوان مثال می توان به Oracle یا ارائه دهندگان اصلی ابر عمومی (AWS، Microsoft Azure، Google Cloud) اشاره کرد. از سوی دیگر، بسیاری از شرکت ها با ابزارهای منبع باز و پشتیبانی داخلی راحت هستند.معماری : برخی از ابزارهای دروازه API بر سادگی تأکید دارند، در حالی که برخی دیگر بر توسعه پذیری تأکید دارند. آنها همچنین اغلب از سیستم های پایگاه داده مختلف مانند PostgreSQL، Cassandra، Redis یا MongoDB پشتیبانی می کنند. همانطور که در بالا ذکر شد، مشاغلی که قبلاً به یک ارائه دهنده ابر خاص متکی هستند، ممکن است دروازه API آن ارائه دهنده را ترجیح دهند.سفارشی‌سازی : برخی از دروازه‌های API، به‌ویژه گزینه‌های متن باز، ممکن است توانایی‌های بیشتری را برای سفارشی‌سازی ارائه دهند که به تخصص داخلی نیاز دارد. با این حال، برخی از دروازه های API به زبان های برنامه نویسی مختلفی مانند Golang یا Lua متکی هستند.بررسی 6 ابزار محبوب API Gateway و نحوه انتخاب یکی از آن‌هادروازه‌های API جنبه محوری توسعه نرم افزار هستند. زیرا برنامه ها را قادر می‌سازند تا با یکدیگر ارتباط برقرار کنند و به داده ها دسترسی داشته باشند. با این حال، در معماری میکروسرویس‌های توزیع‌شده، یک درخواست برای داده شامل تماس‌هایی با سرویس‌ها و برنامه‌های مستقل متعددی می‌شود و پیام‌هایی را ایجاد می‌کند که ردیابی، ایمن و مدیریت مناسب آن می‌تواند بسیار دشوار باشد.برای اطمینان از اینکه این فراخوان‌ها به‌موقع هدایت می‌شوند، شرکت‌ها می‌توانند یک مکانیزم پیام‌رسانی نوآورانه را پیاده‌سازی کنند: دروازه API. در اصل، دروازه API یک نقطه ورود به یک معماری توزیع شده را فراهم می‌کند، و تمام درخواست‌ها و پاسخ‌ها را مدیریت می‌کند، همانطور که API مسیرهای مناسب دروازه را فرا می‌خواند. علاوه بر این، یک ابزار دروازه API می‌تواند سیاست‌هایی را اعمال کند که در دسترس بودن و رفتار یک API را تعیین می‌کند، مانند نحوه پردازش فراخوان‌ها و کنترل جریان داده‌ها. بسیاری از دروازه‌های API دارای قابلیت‌های نظارت و ثبت گزارش برای ضبط و تجزیه و تحلیل فراخوان‌ها و پاسخ‌های API هستند. این امر به کسب و کارها این امکان را می دهد که API ها و ادغام ها را به طور متمرکز ردیابی و کنترل کنند، نه اینکه همه آنها را به صورت جداگانه مدیریت کنند.چگونه یک ابزار برای API Gateway استفاده کنیم؟بسیاری از ارائه دهندگان از فرصتی برای ارائه ابزارهای دروازه API استفاده کرده اند. گزینه های زیادی وجود دارد که از بین آنها انتخاب کنید، چه ابزارهای مستقل یا عملکردی که در یک پلتفرم مدیریت API گسترده تر گنجانده شده است. بیشتر پیشنهادات دروازه API موجود امروزه شامل گزینه های متعددی است که از احراز هویت، تجزیه و تحلیل، تعادل بار، مدیریت کش، وضوح وابستگی و موارد دیگر پشتیبانی می کنند.انتخاب مناسب هم به نیازهای خاص توسعه شما و هم به پلتفرم های توسعه که تیم های شما قبلاً استفاده می کنند بستگی دارد. برخی از عواملی که باید در نظر گرفته شوند عبارتند از:اختصاصی در مقابل متن باز : کاربران اوراکل ممکن است دروازه API کاملاً مدیریت شده اوراکل را مناسب بدانند. به طور مشابه، شرکتی که خدماتی را بر روی AWS، Microsoft Azure یا Google Cloud اجرا می‌کند، ممکن است دروازه API خاص آن پلتفرم را ترجیح دهد. شرکت‌هایی که با ابزارهای منبع باز راحت هستند، چندین گزینه دروازه API برای انتخاب دارند. پشتیبانی نیز مورد توجه است، چه از طرف یک ارائه دهنده اختصاصی باشد و چه از یک جامعه پیرامون یک ابزار منبع باز.معماری : برخی از ابزارهای دروازه API بر سادگی تأکید دارند، در حالی که برخی دیگر با در نظر گرفتن قابلیت توسعه ساخته شده اند. دروازه های API مختلف از سیستم های پایگاه داده مختلف مانند PostgreSQL، Cassandra، Redis یا MongoDB پشتیبانی می‌کنند. باز هم، این تا حد زیادی به آشنایی و اتکای یک سازمان به پایگاه های داده خارجی خاص بستگی دارد. همانطور که قبلاً ذکر شد، دروازه‌های API برای پلتفرم‌های ابری خاص به طور طبیعی به سایر سرویس‌های آن پلتفرم متصل می‌شوند.زبان برنامه‌نویسی : برخی از گزینه‌های دروازه API، به‌ویژه گزینه‌های منبع باز، ممکن است شامل برخی سفارشی‌سازی شوند. ممکن است مهم باشد که توسعه‌دهندگان شما از زبان‌های خاصی مانند Golang یا Lua آگاهی داشته باشند یا فاقد آن باشند. دروازه‌های API ممکن است پلاگین‌هایی را که به زبان‌های دیگر نوشته شده‌اند، در خود جای دهند تا تا حدی این مشکل را کاهش دهند. در قسمت زیر برخی از محبوب ترین ابزارهای دروازه API از ارائه دهندگان اختصاصی و منبع باز آورده شده است.ارائه دهندگان ابر دروازه های API را ارائه می‌دهند که برای ادغام با خدمات خود طراحی شده اند. از جمله این گزینه ها عبارتند از :دروازه API آمازون : بخشی از مجموعه ابزارهای پلتفرم ابری AWS، API Gateway یک سرویس کاملاً مدیریت شده است که برای ایجاد، استقرار، مدیریت، نظارت و ایمن APIها، از جمله موارد مبتنی بر پروتکل های REST، HTTP و WebSocket استفاده می‌شود. همچنین بر ویژگی‌هایی که به سمت انعطاف‌پذیری و مدیریت چرخه عمر تنظیم شده‌اند، تمرکز دارد. البته API Gateway به راحتی با سایر سرویس‌ها و ابزارهای AWS مانند CloudTrail برای ورود به سیستم، مدیریت هویت و دسترسی (IAM) برای احراز هویت و CloudFormation برای ایجاد API ادغام می‌شود. کاربران می توانند از طریق تعدادی از نقاط دسترسی AWS مانند مدیریت کنسول ، CLI یا SDK به دروازه API آمازون دسترسی داشته باشند.دروازه API اژور : سرویس مدیریت Azure API مایکروسافت دارای یک دروازه API به عنوان یکی از سه مؤلفه اصلی خود، در کنار پورتال Azure (رابط اداری) و پورتال توسعه دهنده (رابط توسعه دهنده) است. دروازه Azure تماس‌های HTTP را می‌پذیرد و مسیریابی می‌کند، محدودیت‌های استفاده و نرخ را اعمال می‌کند، پاسخ‌های پشتیبان را ذخیره می‌کند، فراخوان‌ها را ثبت می‌کند و تأیید را مدیریت می‌کند. Azure ویژگی‌های مختلفی را برای طیفی از سطوح قیمت‌گذاری تعریف‌شده ارائه می‌کند، که از یک گزینه در سطح مصرف‌کننده که یک دروازه API پرداخت به ازای استفاده را فراهم می‌کند تا یک لایه ممتاز که برای تولید در سطح سازمانی طراحی شده است که یکپارچه‌سازی اکتیو دایرکتوری، پشتیبانی از شبکه مجازی و پشتیبانی را فراهم می‌کند، متفاوت است. یک دروازه خود میزبان ابزار دروازه همچنین با سرویس‌های Azure مانند نظارت برای تشخیص و برنامه‌های منطقی برای گردش کار و هماهنگی یکپارچه می‌شود. دروازه API اوراکل : به عنوان بخشی از خدمات زیرساخت ابری Oracle، دروازه API کاملاً مدیریت شده اوراکل، APIهای RESTful را برای سرویس‌های Backend که از برنامه‌های بر پایه ابری پشتیبانی می‌کنند، ارائه می‌کند. توسعه دهندگان می توانند API هایی را با نقاط پایانی خصوصی منتشر کنند و از طریق شبکه خود به آنها دسترسی داشته باشند و همچنین آنها را در معرض آدرس های IP عمومی برای ترافیک اینترنت قرار دهند. این شامل ویژگی‌های کلیدی مانند اجرای سیاست، معیارها و گزارش‌گیری است. در کنار توابع Oracle، توسعه دهندگان می توانند API های RESTful بدون سرور ایجاد کنند. همچنین، برای امنیت، دروازه با Oracle Cloud Infrastructure IAM یکپارچه شده است.چندین گزینه محبوب دروازه API متن باز عملکرد و مقیاسی را ارائه می‌دهند که با نیازهای بیشتر شرکت‌ها مطابقت دارد. مثال‌ها عبارتند از:دروازه Kong : یک دروازه API متن باز و بسیار مقیاس پذیر است که برای میکروسرویس ها و معماری های توزیع شده بهینه شده است. Kong دروازه را در بالای سرور وب NGINX ساخته و با استفاده از مجوز Apache 2.0 آن را اداره می کند. Kong ابزارهای دروازه API را از طریق یک کتابخانه منبع باز از اجزای افزونه ارائه می دهد که مکانیزم‌های کنترل ترافیک، پشتیبانی تجزیه و تحلیل، روش‌های احراز هویت و عملکردهای بدون سرور را اضافه می‌کند که به تیم های نرم‌افزاری در ایجاد دامنه‌های سفارشی کمک می‌کند. این دروازه همچنین به توسعه دهندگان اجازه می‌دهد تا درخواست ها و پاسخ ها را در لحظه پیکربندی کنند.دروازه Tyk : یکی دیگر از گزینه های دروازه متن باز است که از سه جزء مجزا تشکیل شده است: داشبورد که رابطی برای معیارها و سازماندهی API فراهم می کند. pump، که پایداری داده و اتصالات پایگاه داده را فراهم می کند. و Gateway، که پروکسی است که تمام ترافیک را مدیریت می کند. Tyk API Gateway برای اجرا فقط به یک پایگاه داده Redis نیاز دارد و ویژگی های مشابه Kong را ارائه می دهد، از جمله روش های پروکسی ترافیک، کنترل های دسترسی و قابلیت های log.دروازه Express : یک گزینه منبع باز است که بر روی Express.js ساخته شده است. این از چهار جزء اصلی تشکیل شده است: یک پیکربندی اعلانی متمرکز که تنظیمات API را به عنوان یک فایل YAML یا JSON ذخیره می کند. یک ماژول مدیریت مصرف کننده و اعتبار برای دسترسی به API؛ یک ذخیره‌سازی دائمی داده توزیع‌شده که امکان دسترسی به داده‌های جهانی و مقیاس‌پذیری را در چندین نمونه فراهم می‌کند. و یک سیستم افزونه که به توسعه دهندگان اجازه می دهد تا سیاست ها، خطوط لوله، شرایط و اقدامات را گسترش دهند. برخی از ویژگی‌های افزونه شامل احراز هویت اضافی، سفارشی‌سازی API، محدودکننده‌های نرخ و قابلیت‌های بدون سرور هستند.آرش علمآرش علمFri, 30 Dec 2022 17:11:58 +0330https://virgool.ir/@arashalam78/آشنایی-با-عناصری-از-معماری-نرم-افزار-asp596mjqddsDDD - Domain Driven Designخب در ابتدا پیش از DDD، تصمیم دارم برای قسمت اول آن یعنی دامنه یک توضیح کوتاه و خلاصه ای به صورت جداگانه بدهم. دامنه، محیط یا حوزه موضوعی مورد هدف یک برنامه کامپیوتری است. به طور رسمی موضوع مورد نظر یک پروژه برنامه نویسی خاص را نشان می دهد، که یا به صورت محدود یا کلی تعریف شده است. برای مثال یک پروژه برنامه نویسی به طور خاص هدفش ایجاد برنامه ای برای یک مدرسه مشخص باشد. دامنه در اینجا آن مدرسه است. شما یک دامنه را با مشخص کردن مجموعه‌ای از الزامات، اصطلاحات و عملکردهای رایج برای هر برنامه نرم‌افزاری که برای حل آن ساخته شده است، تعریف می‌کنید.حالا به خود تعریف DDD می‌رسیم. یک نگرش یا رویکرد است، که سعی بر این دارد مدلی را ایجاد و طراحی کند که به دامنه مد نظر پروژه دقیقا نگاشت شود. به عبارتی دیگر، به مقابله مستقیم با پیچیدگی در قلب نرم‌افزار گفته می‌شود. هدف DDD ساده نمودن، ایجاد برنامه های پیچیده با اتصال قطعات نرم افزاری مرتبط به یک مدل همیشه در حال تکامل است. DDD بر 3 اصل زیر بنا می‌شود:تمرکز اصلی پروژه بر روی هسته ی دامنه (دامنه‌ی اصلی) و منطق دامنهآغاز یک همکاری خلاقانه بین 2 گروه یعنی متخصصان فنی و متخصصان دامنه، جهت اصلاح مکرر یک مدل مفهومی که به مشکلات دامنه خاصی می‌پردازد.طراحی های پیچیده بر اساس مدل یک دامنه.Hexagonal architectureمعماری شش ضلعی یا معماری پورت‌ها و آداپتورها، یک طرح معماری است که در طراحی نرم‌افزار استفاده می‌شود. هدف، ایجاد مؤلفه‌های برنامه‌ای با اتصال‌هایی سست و ضعیف است یعنی به گونه‌ای که از نظر ساختار نزدیک فشرده نباشد. این مورد کمک می‌کند به راحتی از طریق پورت‌ها و آداپتورها به محیط نرم‌افزار خود متصل شوند. این اتصال های تنک و سست باعث می‌شود اجزا در هر سطحی قابل تغییر و تعویض باشند و مورد دیگر فرایند آزمون خودکار را تسهیل می‌کند. پس می‌توان نتیجه گرفت این معماری برای ساختن سیستم های نرم افزاری است که قابل آزمایش، جدا شده، انعطاف پذیر و قابل نگهداری هستند. تا به اینجا فکر می‌کنم به مزایا این معماری پی برده باشید. این معماری با بیان مختصر منطق در لایه‌های مختلف برنامه، جداسازی نگرانی‌ها و مشکلات را ترویج می‌کند. این امکان سطح بالاتری از انزوا، آزمون پذیری و کنترل روی کد خاص کسب و کار را فراهم می کند، و قاعدتا با این طرح هر لایه از برنامه دارای مجموعه ای دقیق از مسئولیت ها و الزامات است. ویژگی های اساسی (چیزی) را به اختصار بیان می کند. شاید جالب باشد بدانید که کلمه شش ضلعی از قراردادهای گرافیکی می آید که مولفه برنامه را مانند یک سلول شش ضلعی نشان می دهد. هدف پیشنهاد این نبود که شش مرز/پورت وجود داشته باشد، بلکه این بود که فضای کافی برای نمایش رابط‌های مختلف مورد نیاز بین مولفه و دنیای بیرونی باقی بماند.CQRS - Command Query Responsibility Segregationدر بطن این اصطلاح این ایده وجود دارد که شما می توانید مدلی متفاوت برای به روزرسانی اطلاعات نسبت به مدلی که برای خواندن اطلاعات استفاده می کنید، به کار ببرید. برای برخی موقعیت‌ها، این جداسازی و مرز می‌تواند ارزشمند باشد، اما این مورد را هم باید اضافه کرد و مراقب بود که برای اکثر سیستم‌ها CQRS پیچیدگی خطرناکی را اضافه خواهد کرد. با حرکت به سوی CQRS، به مواردی چون عملکرد، مقیاس‌پذیری و امنیت بالاتری خواهیم رسید. انعطاف پذیری به وجود آمده در طول زمان جهت تکامل سیستم کمک می‌کند. همچنین از ایجاد تداخل ادغام در سطح دامنه توسط دستورات به روزرسانی جلوگیری می‌کند.حالا وقت آن رسیده به مواردی چون چالش‌های پیاده‌سازی و اینکه به طور خاص در چه مواردی CQRS پیاده‌سازی شود، مناسب‌تر است، بپردازیم. اولین مورد چالشی این است که شاید ایده‌ی روش ساده به نظر بیاید اما در نهایت به طراحی پیچیده در برنامه می‌تواند منجر شود. مورد دیگر این است که اگر چه این روش نیاز به ارسال و دریافت پیام ندارد، اما استفاده از پیام برای پردازش دستورات و انتشار رویدادهای به‌روزرسانی معمول است. پس در این صورت برنامه باید پیام‌های ناموفق و تکراری را نیز مدیریت کند. مورد دیگر پایداری نهایی است به این معنا که توجه داشته باشید که ما دو قسمت به‌روزرسانی و خواندن را از هم جدا کردیم، و ممکن است داده‌هایی که می‌خوانیم قدیمی یا به اصطلاحی کهنه و به‌روز نباشند، پس باید قسمت خوانده شده ما به روز شده و تغییراتی که قسمت update ایجاد می‌کند را انعکاس دهد، جدای از این تشخیص درخواست‌هایی از کاربر که بر اساس داده‌های قدیمی است، هم چالشی جداگانه است.به طور خلاصه CQRS بهتر است در مواردی چون دامنه‌های اشتراکی که کاربرانی به طور موازی به داده‌هایی مشابه دسترسی دارند مورد استفاده قرار گیرد، که به کمک این روش دستوراتی را با جزئیاتی تعریف کنیم و از تعارض در سطح دامنه جلوگیری صورت گیرد. اما در مواردی چون یک رابط کاربری ساده به سبک CRUD که عملیات دسترسی به داده کافی است، استفاده از این روش پیشنهاد نمی‌شود. به طور کلی استفاده از CQRS را در بخش های محدودی از سیستم خود اعمال کنید، که در آن بیشترین ارزش را دارد.MVVM (Model - View - ViewModel)MVVM یک الگوی طراحی ساختاری است که اشیاء را به سه دسته‌ی جداگانه تقسیم می‌کند.قسمت Model، داده های برنامه را نگه‌داری می‌کنند. مدل‌ها معمولا شامل ساختارها یا کلاس های ساده هستند. مثلا کلاس یک خودرو که متغیرهایی از ویژگی های خودرو دارد در نظر بگیرید، رنگ، سال ساخت و مواردی دیگر. به طور خاص می‌توان گفت این قسمت منطق برنامه را در خود جای داده‌است‌.View عناصر بصری و کنترل هایی که کاربر روی صفحه نمایش مشاهده می‌کند. پس کاربر مجموعه‌ای از عناصر را مشاهده می‌کند، و ورودی را نیز به View بدهد (مثلا رمز عبور صفحه ورود دیجی‌کالا).ViewModel لایه‌ای که می‌توان گفت بین دو لایه model و view قرار دارد. داده‌های برنامه که در model جای دارند را به مقادیری تبدیل می‌کنند که می‌توانند در یک View نمایش داده شوند.احتمال زیادی وجود دارد این الگو برای شما آشنا باشد، کاملا درست است این الگو مشابه الگوی MVC معروف است. ابتدا به طور خلاصه MVC را توضیح می‌دهیم سپس به مقایسه این دو خواهیم پرداخت. در mvc، حرف اول m، model است که شامل داده‌ و منطق مرتبط با آن است. قسمت دوم، view است که می‌توان گفت مدیریت تعامل کاربر را بر عهده دارد و از model درخواست داده می‌کند تا به کاربر نمایش می‌دهد. قسمت سوم، controller رابط بین اجزای model و view می‌باشد.mvc می‌توان گفت مدل قدیمی‌تری نسبت به mvvm می‌باشد. در mvvm نقطه شروع view است در حالی که در mvc، controller است. در mvvm فرآیند اشکال‌زدایی پیچیده خواهد شد زمانی که پیوندهای پیچیده داده‌ای داشته باشیم. در mvc، خواندن، تغییر، آزمون واحد و استفاده مجدد، مشکل است.Low code platformsرویکردهای ماژولار با کد کم و یا بدون کد، به توسعه دهندگان حرفه ای این امکان را می دهد که به سرعت برنامه ها را با بی نیازی از نوشتن کد خط به خط، بسازند. آنها همچنین به تحلیل گران تجاری، مدیران اداری، صاحبان مشاغل کوچک و دیگرانی که توسعه‌دهنده نرم‌افزار نیستند، قادر به ساخت و آزمایش برنامه‌ها می‌شوند. این افراد می‌توانند برنامه‌هایی را با دانش کم یا بدون دانش از زبان‌های برنامه‌نویسی سنتی، کد ماشین یا کارهای توسعه پشت اجزای قابل تنظیم پلت فرم ایجاد کنند. برای مثال در خود جاوا می‌توان پروژه های ساده گرافیکی توسط drag and drop پیاده سازی کرد حال چرا این مثال مطرح شد چون نیازی به تعریف textfeild, label ها با کد نیست صرفا موارد مختلف از پنل سمت چپ کاربر با موس انتخاب می‌شوند و در صفحه‌ی برنامه جای گیری می‌شوند. اجزای برنامه در این مدل ها کشیده و رها کنند، آنها را به یکدیگر متصل کنند و برنامه‌های موبایل یا وب ایجاد کنند.ESBیک ESB یا گذرگاه خدمات سازمانی، الگویی است که به موجب آن یک مؤلفه نرم‌افزاری متمرکز، ادغام‌هایی را با سیستم‌های پشتیبان (و ترجمه مدل‌های داده، اتصال عمیق، مسیریابی و درخواست‌ها) انجام می‌دهد و آن ادغام‌ها و ترجمه‌ها را به‌عنوان رابط‌های سرویس برای استفاده مجدد در دسترس قرار می‌دهد جهت برنامه های کاربردی. حالا شاید برای شما سوال باشد که چرا از ESB استفاده می‌شود، چون افزایش چابکی سازمانی با کاهش زمان برای بازاریابی برای ابتکارات جدید یکی از رایج ترین دلایلی است که شرکت ها ESB را به عنوان ستون فقرات زیرساخت فناوری اطلاعات خود پیاده سازی می کنند. یک معماری ESB با ارائه یک سیستم ساده، به خوبی تعریف شده و "قابل اتصال" که به خوبی مقیاس می شود، این امر را تسهیل می کند. مفهوم اصلی معماری ESB این است که شما برنامه های مختلف را با قرار دادن یک گذرگاه ارتباطی بین آنها یکپارچه می کنید و سپس هر برنامه را قادر می سازید تا با BUS صحبت کند. این سیستم‌ها را از یکدیگر جدا می‌کند و به آن‌ها اجازه می‌دهد بدون وابستگی یا آگاهی از سیستم‌های دیگر در BUS ارتباط برقرار کنند.API gatewayشما به یک دروازه API نیاز دارید زیرا یک نقطه ورودی یکپارچه را در بین APIهای داخلی فراهم می کند. این به شما امکان می دهد دسترسی کاربر را کنترل کنید. و اقدامات امنیتی مانند محدود کردن نرخ را فعال می کند. یک دروازه API همه فراخوان‌های API را از client ها دریافت می‌کند، سپس آنها را با مسیریابی درخواست، ترکیب و ترجمه پروتکل به میکروسرویس مناسب هدایت می‌کند. معمولاً یک درخواست را با فراخوانی چندین میکروسرویس و جمع‌آوری نتایج برای تعیین بهترین مسیر انجام می‌دهد. دروازه API درخواست ها را به یکی از دو روش مدیریت می کند. برخی از درخواست ها به سادگی به سرویس مناسب پروکسی/مسیر می شوند. سایر درخواست‌ها را با ارائه سرویس‌های متعدد انجام می‌دهد. نمونه محبوب دروازه API، Netflix APIاست. خدمات پخش Netflix در صدها نوع مختلف دستگاه مانند تلویزیون، ست تاپ باکس، گوشی های هوشمند، تبلت ها و غیره در دسترس است. این سرویس تلاش می کند یک API یک اندازه برای سرویس پخش خود ارائه دهد.آرش علمآرش علمMon, 28 Nov 2022 21:44:06 +0330