Apache Ignite Zero განლაგება: მართლა ნულოვანი?

ჩვენ ვართ საცალო ქსელის ტექნოლოგიების განვითარების განყოფილება. ერთ დღეს, მენეჯმენტმა დაავალა დააჩქაროს ფართომასშტაბიანი გამოთვლები Apache Ignite-ის გამოყენებით MSSQL-თან ერთად და აჩვენა ვებ-გვერდი ლამაზი ილუსტრაციებით და ჯავის კოდის მაგალითებით. მაშინვე მომეწონა საიტი ნულოვანი განლაგება, რომლის აღწერა სასწაულებს გვპირდება: თქვენ არ გჭირდებათ ხელით განათავსოთ თქვენი Java ან Scala კოდი ქსელის თითოეულ კვანძზე და ხელახლა განათავსოთ იგი ყოველ ჯერზე, როცა ის შეიცვლება. სამუშაოს წინსვლისას აღმოჩნდა, რომ Zero Deployment-ს აქვს სპეციფიკური გამოყენება, რომლის მახასიათებლებიც მინდა გაგიზიაროთ. ჭრილის ქვემოთ მოცემულია აზრები და განხორციელების დეტალები.

1. პრობლემის განცხადება

პრობლემის არსი შემდეგია. არსებობს გაყიდვების პუნქტების SalesPoint დირექტორია და Sku (სტოკების შენახვის ერთეული) პროდუქტის დირექტორია. გასაყიდ პუნქტს აქვს "მაღაზიის ტიპი" ატრიბუტი "პატარა" და "დიდი" მნიშვნელობებით. ასორტიმენტი (სარეალიზაციო წერტილის პროდუქტების სია) უკავშირდება თითოეულ გაყიდვის პუნქტს (ჩატვირთული 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 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 ამბობს, რომ შეცდომის მიზეზი არის ის, რომ არ არის მორგებული SalesPoint კლასი CentOs სერვერებზე. მივედით. რას იტყვით "თქვენ არ გჭირდებათ ხელით განათავსოთ თქვენი 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-ის პროდუქტის მართვის დირექტორი.

სტატია ჰაბრეზე მიკროსერვისების შესახებ მოხსენიებულია დენის მაგდას სამი სტატია: მიკროსერვისები ნაწილი I, მიკროსერვისები 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 ფაილს, რომელიც იწყებს "მონაცემთა კვანძს" ან "კლიენტის კვანძს" ბრძანების ხაზის არგუმენტის მიხედვით. ასამბლეა იწყება და მუშაობს. ნულოვანი განლაგება დამარცხდა.

მეგაბაიტი ტესტის მონაცემებიდან ათობით გიგაბაიტზე საბრძოლო მონაცემებზე გადასვლამ აჩვენა, რომ ორობითი ფორმატი არსებობს მიზეზის გამო. საჭირო იყო მეხსიერების მოხმარების ოპტიმიზაცია კვანძებზე და სწორედ აქ აღმოჩნდა BinaryObject ძალიან სასარგებლო.

4. დასკვნები

Apache Ignite პროექტის დოკუმენტაციის გაურკვევლობის შესახებ პირველი საყვედური სამართლიანი აღმოჩნდა; 2016 წლიდან ცოტა რამ შეიცვალა. დამწყებთათვის ადვილი არ არის მოქმედი პროტოტიპის შეკრება ვებსაიტზე და/ან საცავზე დაყრდნობით.

შესრულებული სამუშაოს შედეგებიდან გამომდინარე იქმნებოდა შთაბეჭდილება, რომ Zero Deployment მუშაობს, მაგრამ მხოლოდ სისტემის დონეზე. მსგავსი რამ: BinaryObject გამოიყენება დისტანციური კლასტერული კვანძების სწავლებისთვის, რათა იმუშაონ საბაჟო კლასებთან; Zero Deployment - შიდა მექანიზმი
Apache Ignite თავად ანაწილებს სისტემის ობიექტებს მთელს კლასტერში.

იმედი მაქვს, რომ ჩემი გამოცდილება სასარგებლო იქნება ახალი Apache Ignite მომხმარებლებისთვის.

წყარო: www.habr.com