Apache Ignite Zero Deployment: واقعا صفر؟

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

1. بیان مسئله

اصل مسئله به شرح زیر است. یک فهرست راهنمای نقاط فروش SalesPoint و یک فهرست محصول Sku (واحد نگهداری سهام) وجود دارد. نقطه فروش دارای ویژگی "نوع فروشگاه" با مقادیر "small" و "large" است. مجموعه ای (فهرست محصولات نقطه فروش) به هر نقطه فروش (بارگیری شده از DBMS) متصل می شود و اطلاعاتی ارائه می شود که از تاریخ مشخص شده محصول مشخص شده
از مجموعه حذف شده یا به مجموعه اضافه شده است.

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

2. مطالعه ادبیات

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

ماده 2016 معرفی Apache Ignite: First Steps حاوی پیوندی به مستندات پروژه Apache Ignite و در عین حال سرزنش مبهم بودن این مستندات. من آن را چند بار دوباره خواندم، واضح نیست. من به آموزش رسمی مراجعه می کنم شروع شدنکه
خوش بینانه قول می دهد "در یک لحظه آماده خواهید شد!" من در حال کشف تنظیمات متغیر محیطی هستم، دو ویدیوی Apache Ignite Essentials را تماشا می کنم، اما آنها برای کار خاص من چندان مفید نبودند. من با موفقیت Ignite را از خط فرمان با فایل استاندارد "example-ignite.xml" راه اندازی کردم و اولین برنامه را ساختم. برنامه محاسبه با استفاده از Maven این برنامه کار می کند و از Zero Deployment استفاده می کند، چه زیبایی!

من بیشتر مطالعه کردم و در آنجا مثال بلافاصله از affinityKey (که قبلاً از طریق یک پرس و جوی SQL ایجاد شده بود) استفاده می کند و حتی از BinaryObject مرموز استفاده می کند:

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

خواندن کمی: فرمت باینری - چیزی شبیه بازتاب، دسترسی به فیلدهای یک شی با نام. می تواند مقدار یک فیلد را بدون اینکه به طور کامل شی مورد نظر را از بین ببرد (صرفه جویی در حافظه) بخواند. اما چرا از BinaryObject به جای Person استفاده می شود، زیرا Zero Deployment وجود دارد؟ چرا IgniteCache به IgniteCache منتقل شد ? هنوز مشخص نیست.

من در حال بازسازی برنامه Compute Application هستم تا مناسب مورد من باشد. کلید اصلی دایرکتوری نقاط فروش در MSSQL به صورت [id] [int] NOT NULL تعریف شده است، من یک کش با قیاس ایجاد می کنم.

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

در پیکربندی xml نشان می‌دهم که کش پارتیشن بندی شده است

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

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

دارم آموزش رو میخونم اولین برنامه محاسباتی Ignite، من آن را به قیاس انجام می دهم. در هر گره خوشه ای IgniteRunnable()، چیزی شبیه به این را اجرا می کنم:

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

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

من دو سرور آزمایشی CentOs را راه‌اندازی می‌کنم، آدرس‌های IP را در default-config.xml مشخص می‌کنم، روی هر کدام اجرا می‌کنم.

./bin/ignite.sh config/default-config.xml

هر دو گره Ignite در حال اجرا هستند و می توانند یکدیگر را ببینند. من آدرس های مورد نیاز را در پیکربندی xml برنامه مشتری مشخص می کنم، شروع می شود، یک گره سوم به توپولوژی اضافه می کند و بلافاصله دوباره دو گره وجود دارد. گزارش "ClassNotFoundException: model.SalesPoint" را در خط نشان می دهد

SalesPoint sp=salesPointCache.get(spId);

StackOverflow می گوید که دلیل این خطا این است که کلاس SalesPoint سفارشی در سرورهای CentOs وجود ندارد. ما رسیدیم در مورد "شما لازم نیست کد جاوا خود را به صورت دستی در هر گره مستقر کنید" و غیره چطور؟ یا «کد جاوای شما» مربوط به SalesPoint نیست؟

احتمالاً چیزی را از دست داده ام - دوباره شروع به جستجو می کنم، دوباره می خوانم و دوباره جستجو می کنم. بعد از مدتی احساس می کنم که همه چیز را در مورد موضوع خوانده ام، دیگر چیز جدیدی وجود ندارد. در حین جستجو، نظرات جالبی پیدا کردم.

والنتین کولیچنکو، معمار اصلی در GridGain Systems، پاسخ در StackOverflow، آوریل 2016:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

نظر معتبر دیگر: دنیس ماگدا، مدیر مدیریت محصول، GridGain Systems.

مقاله در Habré در مورد میکروسرویس ها به سه مقاله دنیس ماگدا ارجاع می دهد: بخش اول میکروسرویس ها, بخش دوم میکروسرویس ها, بخش سوم میکروسرویس ها 2016-2017. در مقاله دوم، دنیس پیشنهاد می کند که یک گره کلاستر را از طریق MaintenanceServiceNodeStartup.jar شروع کنید. همچنین می‌توانید از راه‌اندازی با پیکربندی xml و خط فرمان استفاده کنید، اما پس از آن باید به‌طور دستی کلاس‌های سفارشی را روی هر گره کلاستر مستقر قرار دهید:

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

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

3.SingleJar

دنیس رتبه اول را در رتبه بندی شخصی من کسب کرد، IMHO مفیدترین آموزش در دسترس است. در او MicroServicesExample Github حاوی یک مثال کاملاً آماده از راه اندازی گره های خوشه ای است که بدون هیچ گونه چمباتمه اضافی کامپایل می شود.

من این کار را به همین ترتیب انجام می دهم و یک فایل jar دریافت می کنم که بسته به آرگومان خط فرمان، "گره داده" یا "گره مشتری" را راه اندازی می کند. مونتاژ شروع می شود و کار می کند. Zero Deployment شکست خورده است.

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

4. نتیجه گیری

اولین سرزنش در مورد مبهم بودن مستندات پروژه Apache Ignite منصفانه بود؛ از سال 2016 کمی تغییر کرده است. برای یک مبتدی آسان نیست که یک نمونه اولیه کارآمد را بر اساس یک وب سایت و/یا مخزن جمع آوری کند.

بر اساس نتایج کار انجام شده، تصور این بود که Zero Deployment کار می کند، اما فقط در سطح سیستم. چیزی شبیه به این: BinaryObject برای آموزش گره های خوشه راه دور برای کار با کلاس های سفارشی استفاده می شود. استقرار صفر - مکانیزم داخلی
Apache Ignite خودش است و اشیاء سیستم را در سراسر خوشه توزیع می کند.

امیدوارم تجربه من برای کاربران جدید Apache Ignite مفید باشد.

منبع: www.habr.com