آموزش هوش تجاری از ۰ تا ۱۰۰

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

• ارکستراتور خدماتی که سرویس های در حال اجرا بر روی گره های اختصاصی (VM) را مدیریت می کند.
• یک معماری بدون سرور با استفاده از توابع به عنوان یک سرویس (FaaS).

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

ارکسترهای خدمات
یک ارکستر وظایف مربوط به استقرار و مدیریت مجموعه ای از خدمات را انجام می دهد. این وظایف شامل قرار دادن سرویس‌ها بر روی گره‌ها، نظارت بر سلامت سرویس‌ها، راه‌اندازی مجدد سرویس‌های ناسالم، متعادل‌سازی بار ترافیک شبکه در بین نمونه‌های سرویس، کشف سرویس، مقیاس‌بندی تعداد نمونه‌های یک سرویس، و اعمال به‌روزرسانی‌های پیکربندی است. ارکسترهای معروف عبارتند از Kubernetes، Service Fabric، DC/OS، و Docker Swarm.

در پلتفرم Azure، گزینه های زیر را در نظر بگیرید:

• سرویس Azure Kubernetes (AKS) یک سرویس Kubernetes مدیریت شده است. AKS Kubernetes را فراهم می کند و نقاط پایانی Kubernetes API را در معرض دید قرار می دهد، اما صفحه کنترل Kubernetes را میزبانی و مدیریت می کند، ارتقاهای خودکار، وصله خودکار، مقیاس خودکار و سایر وظایف مدیریتی را انجام می دهد. شما می توانید AKS را به عنوان "API های Kubernetes به عنوان یک سرویس" در نظر بگیرید.
• Azure Container Apps یک سرویس مدیریت شده است که بر روی Kubernetes ساخته شده است که پیچیدگی های هماهنگ سازی کانتینر و سایر وظایف مدیریتی را خلاصه می کند. Container Apps استقرار و مدیریت برنامه های کاربردی و میکروسرویس های کانتینری را در یک محیط بدون سرور ساده می کند و در عین حال ویژگی های Kubernetes را ارائه می دهد.
• Service Fabric یک پلت فرم سیستم های توزیع شده برای بسته بندی، استقرار و مدیریت میکروسرویس ها است. میکروسرویس‌ها را می‌توان به‌عنوان کانتینر، به‌عنوان فایل‌های اجرایی باینری یا به‌عنوان خدمات قابل اطمینان در Service Fabric مستقر کرد. با استفاده از مدل برنامه نویسی Reliable Services، سرویس ها می توانند مستقیماً از API های برنامه نویسی Service Fabric برای پرس و جو از سیستم، گزارش سلامت، دریافت اعلان های مربوط به پیکربندی و تغییرات کد و کشف سایر خدمات استفاده کنند. یک تمایز کلیدی با Service Fabric تمرکز قوی آن بر ایجاد سرویس‌های دولتی با استفاده از مجموعه‌های قابل اعتماد است.
• گزینه های دیگری مانند Docker Enterprise Edition و Mesosphere DC/OS می توانند در محیط IaaS در Azure اجرا شوند. شما می توانید قالب های استقرار را در Azure Marketplace بیابید.

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

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

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

Azure Functions یک سرویس محاسباتی بدون سرور است که از راه‌اندازهای عملکرد مختلف، از جمله درخواست‌های HTTP، صف‌های سرویس اتوبوس و رویدادهای Event Hubs پشتیبانی می‌کند. برای فهرست کامل، به مفاهیم محرک‌ها و اتصالات توابع Azure مراجعه کنید. همچنین Azure Event Grid را در نظر بگیرید، که یک سرویس مسیریابی رویداد مدیریت شده در Azure است.

ارکستراتور یا بدون سرور؟
در اینجا چند فاکتور برای انتخاب بین رویکرد ارکستراتور و رویکرد بدون سرور وجود دارد.

قابلیت مدیریت یک برنامه بدون سرور به راحتی قابل مدیریت است، زیرا پلتفرم تمام منابع محاسباتی را برای شما مدیریت می کند. در حالی که یک ارکستراتور برخی از جنبه‌های مدیریت و پیکربندی یک خوشه را انتزاعی می‌کند، VMهای زیربنایی را کاملاً پنهان نمی‌کند. با یک ارکستراتور، باید به مسائلی مانند تعادل بار، استفاده از CPU و حافظه و شبکه فکر کنید.

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

قابل حمل بودن همه ارکسترهای لیست شده در اینجا (Kubernetes، DC/OS، Docker Swarm و Service Fabric) می‌توانند در محل یا در چندین ابر عمومی اجرا شوند.

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

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

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

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