Orchestration سرویس ها:
در گذشته معماری سرویس ها به صورت monolithic یا یکپارچه بود. به نحوی که تمام توسعه دهندگان یک پروژه روی یک سورس کد کار می کردند. مثلا اگر لازم بود که بخش مدیریت فاکتور ها تغییر پیدا کند، باید کل پروژه را دریافت کرده
و به صورت لوکالی پیکربندی کرده و شروع به کار بر روی آن قسمت خاص کرد.
این معماری مشکلات خاص خودش را دارد، مثلا یک تغییر کوچک در یکی از ماژول‌ها،
ممکن است عملکرد دیگر ماژول‌ها را تحت‌تأثیر خود قرار دهد.
یک باگ در یکی از ماژول‌ها، به احتمال زیاد کل پروژه را تحت‌الشعاع خود قرار خواهد داد.
تنوع تکنولوژی من‌جمله زبان‌های برنامه‌نویسی، دیتابیس‌های مختلف، لایبرری‌ها و فریمورک‌های مختلف وجود نخواهد داشت و اگر هم این‌گونه باشد،
ارتباط برقرار کردن مابین آنها بسیار دشوار خواهد بود.
در معماری میکروسرویس بخش های مختلف یک اپلیکیشن در قالب container ها اجرا می شوند. هر اپلیکیشن حاوی چندین سرویس می باشد و هر سرویس توسط چندین container در حال اجرا می باشد. زمانی که بحث سر تعداد محدودی از سرویس ها و container ها باشد، مشکل خاصی در مدیریت آنها دیده نمی شود.
منتنها زمانی که ما از پروژه های Enterprise صحبت می کنیم منظورمان چندیدن سرویس و چند صد یا حتی چند هزار container است. مدیریت این تعداد container قطعا به صورت manual امکان پذیر نیست.
اینجا مفهوم Orchestration و Orchestrator معنا پیدا می کند.
به فرایند مدیریت کانتینر ها که شامل حذف، ایجاد، تغییرات و ... آنها به صورت اتوماتیک می شود، Orchestration گفته می شود.
Orchestrator به آن ابزاری گفته می شود که این کارها را انجام می دهد. مانند swarm ,kubernetes, mesos
زمانبندی کانتینر ها، هماهنگی و مدیریت کلاستر:
در معماری میکروسرویس، زمانی که احتیاج به ایجاد تغییر در سرویس ایجاد می شود، در نهایت باید کانتینر های آن سرویس دچار تغییرات شوند.
یکی از بزرگ‌ترین مسئولیت‌های ابزار زمانبندی، انتخاب میزبان است. اگر یک Orchestrator تصمیم بگیرد که یک سرویس (کانتینر) را روی یک کلاستر اجرا کند، ابزار زمانبندی در اغلب موارد مسئول انتخاب خودکار یک میزبان می‌شود.
Orchestrator می‌تواند به طور اختصاصی بر اساس نیازها یا علاقه‌مندی، کانتینرهایی را به ابزار زمانبندی پیشنهاد کند؛ اما ابزار زمانبندی در نهایت مسئول اجرای این الزامات خواهد بود.
مدیریت کلاستر به فرایند کنترل کردن گروهی از Host ها گفته می‌شود. این مدیریت می‌تواند شامل افزودن و حذف Host از یک کلاستر، دریافت اطلاعات در مورد وضعیت کنونی Host و کانتینرها، و آغاز یا توقف پردازش‌ها باشند.
مدیریت کلاستر ارتباط نزدیکی با زمانبندی دارد، زیرا ابزارهای زمانبندی باید به همه Host در کلاستر دسترسی داشته باشند تا بتوانند سرویس‌ها را زمانبندی کنند. به این منظور در اغلب موارد از ابزار یکسانی استفاده می‌شود.
دسترس پذیری:
یکی از وظایف Orchestrator ها بررسی وضعیت کانتینر ها می باشد. علاوه بر بررسی سلامت کانتینر ها، دائما در دسترس بودن یک سرویس check می شود. به طور مثال اگر در هنگام پیکربندی یک سرویس شما مشخص کرده باشید که برای اجرای این سرویس به 5 کانتینر احتیاج است،
Orchestrator این تضمین را به شما می دهد که 5 کانتینر را در حالت Running برای این سرویس نگه دارد.
Orchestration سرویس ها:
در گذشته معماری سرویس ها به صورت monolithic یا یکپارچه بود. به نحوی که تمام توسعه دهندگان یک پروژه روی یک سورس کد کار می کردند. مثلا اگر لازم بود که بخش مدیریت فاکتور ها تغییر پیدا کند، باید کل پروژه را دریافت کرده
و به صورت لوکالی پیکربندی کرده و شروع به کار بر روی آن قسمت خاص کرد.
این معماری مشکلات خاص خودش را دارد، مثلا یک تغییر کوچک در یکی از ماژول‌ها،
ممکن است عملکرد دیگر ماژول‌ها را تحت‌تأثیر خود قرار دهد.
یک باگ در یکی از ماژول‌ها، به احتمال زیاد کل پروژه را تحت‌الشعاع خود قرار خواهد داد.
تنوع تکنولوژی من‌جمله زبان‌های برنامه‌نویسی، دیتابیس‌های مختلف، لایبرری‌ها و فریمورک‌های مختلف وجود نخواهد داشت و اگر هم این‌گونه باشد،
ارتباط برقرار کردن مابین آنها بسیار دشوار خواهد بود.
در معماری میکروسرویس بخش های مختلف یک اپلیکیشن در قالب container ها اجرا می شوند. هر اپلیکیشن حاوی چندین سرویس می باشد و هر سرویس توسط چندین container در حال اجرا می باشد. زمانی که بحث سر تعداد محدودی از سرویس ها و container ها باشد، مشکل خاصی در مدیریت آنها دیده نمی شود.
منتنها زمانی که ما از پروژه های Enterprise صحبت می کنیم منظورمان چندیدن سرویس و چند صد یا حتی چند هزار container است. مدیریت این تعداد container قطعا به صورت manual امکان پذیر نیست.
اینجا مفهوم Orchestration و Orchestrator معنا پیدا می کند.
به فرایند مدیریت کانتینر ها که شامل حذف، ایجاد، تغییرات و … آنها به صورت اتوماتیک می شود، Orchestration گفته می شود.
Orchestrator به آن ابزاری گفته می شود که این کارها را انجام می دهد. مانند swarm ,kubernetes, mesos
زمانبندی کانتینر ها، هماهنگی و مدیریت کلاستر:
در معماری میکروسرویس، زمانی که احتیاج به ایجاد تغییر در سرویس ایجاد می شود، در نهایت باید کانتینر های آن سرویس دچار تغییرات شوند.
یکی از بزرگ‌ترین مسئولیت‌های ابزار زمانبندی، انتخاب میزبان است. اگر یک Orchestrator تصمیم بگیرد که یک سرویس (کانتینر) را روی یک کلاستر اجرا کند، ابزار زمانبندی در اغلب موارد مسئول انتخاب خودکار یک میزبان می‌شود.
Orchestrator می‌تواند به طور اختصاصی بر اساس نیازها یا علاقه‌مندی، کانتینرهایی را به ابزار زمانبندی پیشنهاد کند؛ اما ابزار زمانبندی در نهایت مسئول اجرای این الزامات خواهد بود.
مدیریت کلاستر به فرایند کنترل کردن گروهی از Host ها گفته می‌شود. این مدیریت می‌تواند شامل افزودن و حذف Host از یک کلاستر، دریافت اطلاعات در مورد وضعیت کنونی Host و کانتینرها، و آغاز یا توقف پردازش‌ها باشند.
مدیریت کلاستر ارتباط نزدیکی با زمانبندی دارد، زیرا ابزارهای زمانبندی باید به همه Host در کلاستر دسترسی داشته باشند تا بتوانند سرویس‌ها را زمانبندی کنند. به این منظور در اغلب موارد از ابزار یکسانی استفاده می‌شود.
دسترس پذیری:
یکی از وظایف Orchestrator ها بررسی وضعیت کانتینر ها می باشد. علاوه بر بررسی سلامت کانتینر ها، دائما در دسترس بودن یک سرویس check می شود. به طور مثال اگر در هنگام پیکربندی یک سرویس شما مشخص کرده باشید که برای اجرای این سرویس به 5 کانتینر احتیاج است،
Orchestrator این تضمین را به شما می دهد که 5 کانتینر را در حالت Running برای این سرویس نگه دارد.
