Ignite Service Grid - راه اندازی مجدد

در 26 فوریه، ما یک جلسه Apache Ignite GreenSource برگزار کردیم که در آن مشارکت کنندگان پروژه منبع باز صحبت کردند. آپاچی ایگنایت. یک رویداد مهم در زندگی این جامعه تغییر ساختار جزء بود Ignite Service Grid، که به شما امکان می دهد میکروسرویس های سفارشی را مستقیماً در یک کلاستر Ignite مستقر کنید. او در این نشست درباره این روند دشوار صحبت کرد ویاچسلاو دارادور، مهندس نرم افزار و مشارکت کننده Apache Ignite برای بیش از دو سال.

بیایید با آنچه Apache Ignite به طور کلی است شروع کنیم. این یک پایگاه داده است که یک ذخیره سازی کلید/مقدار توزیع شده با پشتیبانی از SQL، تراکنش پذیری و حافظه پنهان است. علاوه بر این، Ignite به شما امکان می دهد خدمات سفارشی را مستقیماً در یک کلاستر Ignite مستقر کنید. توسعه دهنده به تمام ابزارهایی که Ignite فراهم می کند دسترسی دارد - ساختارهای داده توزیع شده، پیام رسانی، جریان، محاسبه و شبکه داده. به عنوان مثال، هنگام استفاده از Data Grid، مشکل اداره یک زیرساخت جداگانه برای ذخیره سازی داده ها و در نتیجه، هزینه های سربار ناشی از آن ناپدید می شود.

با استفاده از Service Grid API، می توانید یک سرویس را به سادگی با تعیین طرح استقرار و بر این اساس، خود سرویس در پیکربندی مستقر کنید.

به طور معمول، یک طرح استقرار نشان دهنده تعداد نمونه هایی است که باید در گره های خوشه ای مستقر شوند. دو طرح معمولی استقرار وجود دارد. اولین مورد، Cluster Singleton است: در هر زمان، یک نمونه از یک سرویس کاربر تضمین شده است که در خوشه در دسترس باشد. مورد دوم Node Singleton است: یک نمونه از سرویس در هر گره خوشه مستقر می شود.

کاربر همچنین می تواند تعداد نمونه های سرویس را در کل خوشه مشخص کند و یک گزاره برای فیلتر کردن گره های مناسب تعریف کند. در این سناریو، Service Grid خود توزیع بهینه را برای استقرار خدمات محاسبه خواهد کرد.

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

اکنون که متوجه شدیم زیبایی Service Grid چیست، بیایید در مورد تاریخچه توسعه آن صحبت کنیم.

اتفاقی که قبلا افتاد

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

چه اتفاقی افتاد که کاربر می خواست سرویس را گسترش دهد؟

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

چیزی که به ما نمی خورد

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

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

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

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

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

مشکلات

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

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

• چگونه می توان سرویس های پیکربندی ایستا را در هنگام راه اندازی گره مستقر کرد؟
• ترک یک گره از خوشه - اگر گره خدمات میزبانی کند چه باید کرد؟
• اگر هماهنگ کننده تغییر کرد چه باید کرد؟
• اگر کلاینت دوباره به کلاستر وصل شود چه باید کرد؟
• آیا درخواست‌های فعال‌سازی/غیرفعال‌سازی نیاز به پردازش دارند و چگونه؟
• اگر آنها خواستار تخریب حافظه پنهان شوند، و ما سرویس‌های وابسته به آن را داشته باشیم، چه؟

و این تمام نیست.

تصمیم

به عنوان یک هدف، ما رویکرد رویداد محور را با اجرای ارتباطات فرآیندی با استفاده از پیام‌ها انتخاب کردیم. Ignite در حال حاضر دو مؤلفه را پیاده‌سازی کرده است که به گره‌ها اجازه می‌دهد پیام‌ها را بین خودشان ارسال کنند -communica-spi و Discovery-spi.

Communication-spi به گره‌ها اجازه می‌دهد مستقیماً پیام‌ها را با هم ارتباط برقرار کرده و پیام‌ها را فوروارد کنند. برای ارسال مقادیر زیاد داده مناسب است. Discovery-spi به شما این امکان را می دهد که به تمام گره های خوشه پیام ارسال کنید. در پیاده سازی استاندارد، این کار با استفاده از توپولوژی حلقه انجام می شود. همچنین ادغام با Zookeeper وجود دارد، در این مورد از توپولوژی ستاره استفاده می شود. نکته مهم دیگری که قابل ذکر است این است که Discovery-spi تضمین می کند که پیام قطعاً به ترتیب صحیح به همه گره ها تحویل داده می شود.

بیایید به پروتکل استقرار نگاه کنیم. تمام درخواست های کاربر برای استقرار و undeployment از طریق Discovery-spi ارسال می شود. این موارد زیر را به دست می دهد ضمانت ها:

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

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

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

1. هر گره به طور مستقل توزیع را به لطف یک تابع تخصیص قطعی جدید محاسبه می کند.
2. گره ها پیامی را با نتایج استقرار تولید کرده و به هماهنگ کننده ارسال می کنند.
3. هماهنگ کننده همه پیام ها را جمع می کند و نتیجه کل فرآیند استقرار را تولید می کند که از طریق Discovery-spi به همه گره های خوشه ارسال می شود.
4. با دریافت نتیجه، فرآیند استقرار به پایان می رسد و پس از آن وظیفه از صف حذف می شود.

طراحی جدید رویداد محور: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

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

تمام رویدادهای مهم در سرویس گرید با استفاده از این الگوریتم عملیاتی پردازش می شوند. به عنوان مثال، تغییر توپولوژی نیز یک پیام از طریق Discovery-spi است. و به طور کلی، در مقایسه با آنچه قبلا بود، پروتکل بسیار سبک و قابل اعتماد بود. برای کنترل هر موقعیتی در حین استقرار کافی است.

بعد از این چه خواهد شد

حالا در مورد برنامه ها هر تغییر عمده در پروژه Ignite به عنوان یک ابتکار بهبود Ignite تکمیل می شود که IEP نامیده می شود. طراحی مجدد Service Grid همچنین دارای یک IEP است - IEP شماره 17 با عنوان تمسخر آمیز "تعویض روغن در شبکه خدمات". اما در واقع ما روغن موتور را عوض نکردیم، بلکه کل موتور را عوض کردیم.

ما وظایف در IEP را به 2 مرحله تقسیم کردیم. اولین مرحله یک مرحله اصلی است که شامل کار مجدد پروتکل استقرار است. قبلاً در Master گنجانده شده است، می توانید Service Grid جدید را امتحان کنید که در نسخه 2.8 ظاهر می شود. مرحله دوم شامل بسیاری از وظایف دیگر است:

• باز استقرار داغ
• نسخه سرویس
• افزایش تحمل خطا
• مشتری لاغر
• ابزارهایی برای نظارت و محاسبه معیارهای مختلف

در نهایت، ما می‌توانیم به شما در مورد Service Grid برای ساختن سیستم‌های مقاوم در برابر خطا و در دسترس بودن بالا توصیه کنیم. ما همچنین از شما دعوت می کنیم که به ما مراجعه کنید لیست توسعه دهندگان и لیست کاربران تجربه خود را به اشتراک بگذارید تجربه شما برای جامعه واقعاً مهم است؛ این به شما کمک می‌کند بفهمید که کجا حرکت کنید، چگونه در آینده این مؤلفه را توسعه دهید.

منبع: www.habr.com