Apache Ignite Zero Deployment: իսկապե՞ս Zero՞:

Մենք տեխնոլոգիական զարգացման բաժինն ենք. Մի օր ղեկավարությունը հարցադրեց՝ արագացնել զանգվածային հաշվարկները, օգտագործելով Apache Ignite և MSSQL, ցույց տվեց հրաշալի օրինակի կայք և Java կոդի օրինակներ: Կայքում անմիջապես դուրեկան բաներ էին Zero Deployment, որի նկարագրությունը խոստանում է հրաշքներ. դուք պետք չէ ձեռքով տեղադրել ձեր Java կամ Scala կոդը ցանցի յուրաքանչյուր հանգույցում և կրկին տեղադրել այն, երբ այն փոխվում է: Աշխատանքի ընթացքում պարզվեց, որ Zero Deployment-ը ունի հատուկ օգտագործման բնույթ, որի մասին ուզում եմ կիսվել: Հոդվածի մեջ մտածումներ և իրականացման մանրամասներ:

1. Հայտնի խնդիր

Փ Problema essentia հետևյալն է. Ունենք վաճառքի կետեր SalesPoint և ապրանքների ցուցակ Sku (Stock Keeping Unit): Վաճառքի կետն ունի «մասնազատ» հատկություն, որը կարող է լինել «փոքր» կամ «մեծ»: Ամեն վաճառքի կետին միակցվում է (բեռնվում տվյալների բազայից) assortment (վաճառքի կանոնակարգի ապրանքների ցուցակ) և մատուցվում է տեղեկություն, որ նշված ամսաթվից նշված ապրանքը
կոչվում է վաճառքի ցուցակից կամ ավելացվում է վաճառքի ցուցակին:

Պետք է կազմակերպել վաճառքի կետերի բաժանված կեշ և պահել նրա մեջ կապակցված ապրանքների տեղեկությունը մեկ ամիս առաջ: Հակամարտության համակարգը նշանակում է, որ Ignite հաճախորդի հանգույցը պետք է բեռնեին տվյալները, հաշվել (ավագի ձևը (մասնազատ, ապրանքի ծածկագիր, օր, վաճառքի կետերի թիվ)) և արտահանեն դա տվյալների բազա:

2. Ե վարակման ուսումնասիրություն

Հաշվի առնելով, որ փորձարկում ինձ դեռ չունենք, սկսում եմ հիմքերից: Կամ՝ հրապարակումների վերանայումից:

2016 թվականի հոդվածը Apache Ignite-ի հետ ծանոթության առաջին քայլեր պարունակում է հղում Apache Ignite նախագծի փաստաթղթերին և նաև վերադառնալ այն փաստի մասին, որ այդ փաստաթղթերը հստակ չեն: Որպեսզի ցանկության դեպքում մի քանի անգամ կարդացել եմ, պարզություն չկա: Հիմա անցնում եմ պաշտոնական դասընթացին getting-started, որը
ապահովում է «Կ Скоро եք օգտվելու օժանդակությամբ». Կարող եմ դեպի միջավայրի փոփոխականների կարգավորումները, դիտում եմ երկու տեսանյութ Apache Ignite Essentials, հատուկ իմ խնդիրների համար դրանք այնքան օգտակար չեն: Ջնջում եմ Ignite-ը սովորական ֆայլով «example-ignite.xml», հավաքվում է առաջին ծրագիրը Compute Application Maven-ի միջոցով: Ծրագիրը աշխատում է և օգտագործում Zero Deployment, ինչ գեղեցկություն է:

Այնուհետև կարդում եմ, և այնտեղ առաջարկվում է նախընտրություն affinityKey (առաջին անգամ ստեղծված SQL-ով), ինչպես նաև կիրառվում է գեհենային BinaryObject:

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

Ես կարդում եմ մանրամասների: բինարային ձևաչափը — մի բան, որը նման է անդրադարձի, առարկայի դաշտերին մուտք գործել անունով: Կարող է կարդալ դաշտի արժեքը առանց ամբողջական դեսերիալիզացիայի (հիշողության խնայողություն): Բայց ինչու է BinaryObject են անվանում Person, երբ Zero Deployment-ը կա? Ինչու IgniteCache<Key,Person> կոչվում է IgniteCache<BinaryObject, BinaryObject>? Այս պահին հստակ չէ:

Խմբագրում եմ Compute Application իմ դեպքի համար: Վաճառքի կետերի բառարանում առաջին հիմքը MSSQL-ում սահմանված է որպես [id] [int] NOT NULL, ստեղծում եմ կեշ аналогично

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

XML կարգավորիչում նշում եմ, որ կեշը բաժանված է

Վաճառքի կետերով բաժանումը ենթադրում է, որ կիրառվող ագրեգատը կկառուցվի յուրաքանչյուր խմբավորիչում موجود վաճառքի կետերի տվյալների վրա, ինչից հետո հաճախորդի կետը կկատարի ընդհանուր հաշվարկումը:

Ունեմ ուսուցում First Ignite Compute Application, անում եմ նմանության հիման վրա: Յուրաքանչյուր խմբավորիչում գործարկում եմ IgniteRunnable(), մոտավորապես այսպես:

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

Ավելացնում եմ ագրեգացման և արտահանման տրամաբանությունը, գործարկում եմ փորձնական տվյալների հավաքածուի վրա: Լոկալ հասցեջում everything works.

Գործարկում եմ երկու փորձնական սերվեր CentOs, ցույց եմ տալիս IP հասցեները default-config.xml-ում, կատարում եմ յուրաքանչյուր

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

Երկու узла Ignite գործարկվում են և մեկը մյուսին տեսնում են: Ցույց եմ տալիս անհրաժեշտ հասցեները XML կարգավորիչում հաճախորդի ծրագրի, այն գործարկվում է, ավելացնում է երրորդ узла топոլոգիային և անմիջապես узлов становится снова два: Տվյալներում նշված է «ClassNotFoundException: model.SalesPoint» մեջ տողի

SalesPoint sp=salesPointCache.get(spId);

StackOverflow-ը ասում է, որ սխալների պատճառը այն է, որ CentOs սերվերներում չկա SalesPoint օգտվողի դասը: Դա խնդիր է: Ինչպես կարող է «you don’t have to manually deploy your Java code on each node» և այլն? Թե արդյո՞ք «your Java code» նշանակում է SalesPoint-ի մասին:

Կանհավանական է, որ ինչ-որ բան բաց տող եմ թողել — սկսում եմ որոնել, կարդալ և նորից որոնել: Ամեն ինչ, որ գտնում եմ կապված թեմայի շուրջ, արդեն չկա: Այդ ընթացքում մի քանի հետաքրքիր նկատառում եմ գտել:

Valentin Kulichenko, GridGain Systems-ի Lead Architect-ը, պատասխանը StackOverflow-ում, ապրիլ 2016:

Model class-ները չեն ներդնում նույն աշխարհագրության մեջ, բայց կարող եք օգտագործել withKeepBinary() լոկտորը
կեշում և հարցնել BinaryObjects: Այս կերպ կխուսափել եք սկիզբի կողմում deserialization
և չեք ստանա ClassNotFoundException:

Մեկ այլ հեղինակավոր կարծիք: Denis Magda, GridGain Systems-ի արտադրանքի կառավարման տնօրեն:

Հոդված Հաբրում միացյալ միկրոսերվիսների մասին պատասխանել է երեք հոդվածներին Denis Magda-ի: Microservices Part I, Microservices Part II, Microservices Part III 2016-2017 թվականների: Երկրորդ հոդվածում Denis-ն առաջարկում է սկսել խմբավորիչի узла գործողությունը 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.

Նմանապես, that's it. Ի՞նչ է սա, որ այդ առեղծվածային բինարային ձևաչափը նշանակություն ունի!

3. SingleJar

Denis-ին զբաղեցնում է իմ անձնական դասակարգման առաջին տեղը, իմ կարծիքով ամենաեկեղեցական այս պահին ամենից օգտակար ուսուցումը: Նրա MicroServicesExample գիտափորձի վրա լիովին պատրաստ գործի օրինակ է, որը կոմպլեկտ է արված առանց որևէ լրացուցիչ դժվարությունների:

Ես կատարում եմ ըստ պատկերի և նմանության, ստանում եմ միավորված jar ֆայլ, որը գործարկում է «data node» կամ «client node» կախված հրամանային ունիվերսալի արգումենտից: Կազմակերպումը մեկնարկվեց և աշխատում է: Zero Deployment-ը հաղթահարված է:

Մեգաբայթների փորձնական տվյալներից անցումը տասնյակ ԳԲ մարտական նվիրվածությանը ցույց տվեց, որ բինար ձևաչափը գոյություն ունի այլևս։ Տեղին էր օպտիմալացնել հիշողության ծախսը նոդերի վրա, և այստեղ BinaryObject-ը շատ օգտակար դարձավ:

4. Արխիքում

Ապաչե Ignite նախագծի անորոշության առաջին անգամ հանդիպած քննադատությունը արդարացի էր, 2016 թվականից հետո ոչինչ շատ չի փոխվել։ Նորեկին դժվար է գործարկման աշխատանքային նմուշ հավաքել կայքի և/թ կամ ռեպոզիտարի հիման վրա:

Անցած աշխատանքի արդյունքում առաջացավ զգացում, որ Zero Deployment-ը գործում է, սակայն միայն համակարգային մակարդակում: Հրապարակորեն, BinaryObject-ը օգտագործվում է հեռահար узլերի կլաստերում օգտագործողի դասեր սովորելու համար; Zero Deployment-ը — ապաչիխ Ignite-ի ներքին մեխանիզմ է և տարածում է համակարգային օբյեկտներ կլաստերում:
ապա Apache Ignite-ի կանխատեսելի մարմնով:

Համոզված եմ, որ իմ փորձը օգտակար կլինի Apache Ignite նոր օգտատերերին:

Ընտանիք: habr.com