Apache Ignite Zero տեղակայում. իսկապե՞ս զրո:

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

1. Խնդրի հայտարարություն

Խնդրի էությունը հետեւյալն է. Կա SalesPoint-ի վաճառքի կետերի գրացուցակ և Sku (Բաժնետոմսերի պահպանման միավոր) ապրանքների գրացուցակ: Վաճառքի կետն ունի «Խանութի տեսակ» հատկանիշ՝ «փոքր» և «մեծ» արժեքներով։ Տեսականին (վաճառքի կետի ապրանքների ցանկը) միացված է յուրաքանչյուր վաճառքի կետին (բեռնված է DBMS-ից) և տրամադրվում է տեղեկատվություն, որ նշված օրվանից նշված ապրանքը.
բացառված է տեսականուց կամ ավելացվել է տեսականին.

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

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

Ես դեռ փորձ չունեմ, ուստի սկսում եմ պարել վառարանից: Այսինքն՝ հրապարակումների վերանայումից։

Հոդված 2016թ Ներկայացնում ենք Apache Ignite. Առաջին քայլերը պարունակում է հղում 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-ին ? Դեռ պարզ չէ։

Ես վերամշակում եմ «Հաշվարկիչ» հավելվածը՝ իմ գործին համապատասխան: MSSQL-ում վաճառքի կետերի գրացուցակի առաջնային բանալին սահմանվում է որպես [id] [int] NOT NULL, ես ստեղծում եմ քեշը անալոգիայի միջոցով:

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

xml config-ում ես նշում եմ, որ քեշը բաժանված է

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

Ըստ վաճառքի կետի բաժանումը ենթադրում է, որ պահանջվող ագրեգատը կկառուցվի յուրաքանչյուր կլաստերային հանգույցի վրա այնտեղ առկա salesPointCache գրառումների համար, որից հետո հաճախորդի հանգույցը կկատարի վերջնական ամփոփումը։

Ես կարդում եմ ձեռնարկը Առաջին Ignite Compute հավելվածը, ես դա անում եմ անալոգիայով։ Յուրաքանչյուր կլաստերի հանգույցում ես գործարկում եմ 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-ն ասում է, որ սխալի պատճառն այն է, որ CentOs սերվերների վրա չկա SalesPoint-ի հատուկ դաս: Մենք հասել ենք։ Ի՞նչ կասեք «դուք պետք չէ ձեռքով տեղադրել ձեր Java կոդը յուրաքանչյուր հանգույցում» և այլն: Թե՞ «ձեր Java կոդը» 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é-ի մասին միկրոծառայությունների մասին հղում է կատարում Դենիս Մագդայի երեք հոդվածներին. Microservices Մաս I, Microservices Մաս II, Միկրոծառայություններ Մաս III 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-ը պարտվել է:

Թեստի մեգաբայթ տվյալներից տասնյակ գիգաբայթ մարտական ​​տվյալների անցումը ցույց տվեց, որ երկուական ձևաչափը գոյություն ունի ինչ-որ պատճառով: Անհրաժեշտ էր օպտիմիզացնել հիշողության սպառումը հանգույցների վրա, և հենց այստեղ էր, որ BinaryObject-ը շատ օգտակար դարձավ։

4: Եզրակացություններ

Apache Ignite նախագծի փաստաթղթերի անորոշության վերաբերյալ առաջին կշտամբանքը պարզվեց, որ 2016 թվականից քիչ բան է փոխվել: Սկսնակների համար հեշտ չէ վեբկայքի և/կամ պահեստի հիման վրա գործող նախատիպ հավաքել:

Կատարված աշխատանքի արդյունքներով տպավորություն էր, որ Zero Deployment-ն աշխատում է, բայց միայն համակարգի մակարդակով։ Նման մի բան. BinaryObject-ն օգտագործվում է հեռավոր կլաստերային հանգույցներին սովորեցնելու համար աշխատել մաքսային դասերի հետ; Zero Deployment - ներքին մեխանիզմ
Apache Ignite-ն ինքն է բաշխում համակարգի օբյեկտները ամբողջ կլաստերի վրա:

Հուսով եմ, որ իմ փորձը օգտակար կլինի Apache Ignite-ի նոր օգտվողների համար:

Source: www.habr.com