მონაცემთა დიქოტომია: მონაცემთა და სერვისებს შორის ურთიერთობის გადახედვა

Სალამი ყველას! კარგი სიახლე გვაქვს, OTUS კურსს ისევ ივნისში იწყებს "პროგრამული უზრუნველყოფის არქიტექტორი", რასთან დაკავშირებითაც ტრადიციულად გიზიარებთ სასარგებლო მასალას.

თუ თქვენ წააწყდით ამ მთელ მიკროსერვისებს ყოველგვარი კონტექსტის გარეშე, გაპატიებთ, რომ ეს ცოტა უცნაურია. აპლიკაციის დაყოფა ქსელის მიერ დაკავშირებულ ფრაგმენტებად აუცილებლად ნიშნავს შეცდომის ტოლერანტობის რთული რეჟიმების დამატებას შედეგად განაწილებულ სისტემაში.

მიუხედავად იმისა, რომ ეს მიდგომა მოიცავს მის მრავალ დამოუკიდებელ სერვისად დაყოფას, საბოლოო მიზანი გაცილებით მეტია, ვიდრე უბრალოდ ამ სერვისების გაშვება სხვადასხვა მანქანებზე. აქ საუბარია გარე სამყაროსთან ინტერაქციაზე, რომელიც ასევე განაწილებულია თავისი არსით. არა ტექნიკური გაგებით, არამედ ეკოსისტემის გაგებით, რომელიც შედგება მრავალი ადამიანისგან, გუნდისგან, პროგრამებისგან და თითოეულმა ამ ნაწილმა როგორმე უნდა გააკეთოს თავისი საქმე.

კომპანიები, მაგალითად, არის განაწილებული სისტემების კრებული, რომლებიც ერთობლივად ხელს უწყობენ გარკვეული მიზნის მიღწევას. ჩვენ ამ ფაქტს ათწლეულების განმავლობაში უგულებელვყოფდით, ვცდილობთ მივაღწიოთ გაერთიანებას FTP ფაილების ან საწარმოს ინტეგრაციის ინსტრუმენტების გამოყენებით, ხოლო ფოკუსირებას ვაკეთებთ საკუთარ იზოლირებულ მიზნებზე. მაგრამ სერვისების მოსვლასთან ერთად ყველაფერი შეიცვალა. სერვისები დაგვეხმარა გავიხედოთ ჰორიზონტის მიღმა და დავინახოთ ურთიერთდამოკიდებული პროგრამების სამყარო, რომლებიც ერთად მუშაობენ. თუმცა, იმისთვის, რომ წარმატებით ვიმუშაოთ, აუცილებელია ორი ფუნდამენტურად განსხვავებული სამყაროს ამოცნობა და დიზაინი: გარე სამყარო, სადაც ჩვენ ვცხოვრობთ მრავალი სხვა სერვისის ეკოსისტემაში და ჩვენი პირადი, შიდა სამყარო, სადაც მარტო ვმართავთ.

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

ასე რომ, დღეს ჩვენ გადავხედავთ, როგორ შეიცვალა წესები, რატომ უნდა გადავხედოთ სერვისებს და მონაცემებს, რომლებიც ისინი ერთმანეთს გადასცემენ და რატომ დაგვჭირდება სრულიად განსხვავებული ინსტრუმენტები ამის გასაკეთებლად.

ინკაფსულაცია ყოველთვის არ იქნება თქვენი მეგობარი

მიკროსერვისებს შეუძლიათ ერთმანეთისგან დამოუკიდებლად მუშაობა. სწორედ ეს თვისება ანიჭებს მათ უდიდეს ღირებულებას. ეს იგივე ქონება საშუალებას აძლევს სერვისებს მასშტაბირება და ზრდა. არა იმდენად კვადრილიონების მომხმარებელზე ან პეტაბაიტამდე სკალირების გაგებით (თუმცა მათ შეუძლიათ იქაც დაგვეხმარონ), არამედ სკალირების გაგებით ადამიანების თვალსაზრისით, როგორც გუნდები და ორგანიზაციები მუდმივად იზრდება.

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

როგორც სტანდარტული მიდგომის ნაწილი, ისინი უბრალოდ ცდილობენ თავიდან აიცილონ შემაშფოთებელი ცვლილებები, რომლებიც აშკარად ანაწილებენ ფუნქციებს სერვისებს შორის. აქ კარგი მაგალითი შეიძლება იყოს ერთჯერადი შესვლის სერვისი. მას აქვს მკაფიოდ განსაზღვრული როლი, რომელიც განასხვავებს მას სხვა სერვისებისგან. ეს მკაფიო განცალკევება ნიშნავს, რომ სამყაროში, სადაც სწრაფად იცვლება მოთხოვნები მის გარშემო არსებულ სერვისებზე, ერთი შესვლის სერვისი ნაკლებად სავარაუდოა, რომ შეიცვალოს. ის არსებობს მკაცრად შეზღუდულ კონტექსტში.

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

ბიზნეს სერვისების უმეტესობა იზიარებს მონაცემთა ერთნაირ ნაკადს, ამიტომ მათი მუშაობა უცვლელად არის გადაჯაჭვული.

ამრიგად, მივედით მნიშვნელოვან საკითხამდე, რაზეც საუბარია. მიუხედავად იმისა, რომ სერვისები კარგად მუშაობს ინფრასტრუქტურის კომპონენტებზე, რომლებიც ძირითადად იზოლირებულად მუშაობენ, ბიზნეს სერვისების უმეტესობა უფრო მჭიდროდ არის გადაჯაჭვული.

მონაცემთა დიქოტომია

სერვისზე ორიენტირებული მიდგომები შეიძლება უკვე არსებობდეს, მაგრამ მათ ჯერ კიდევ აკლიათ იმის გაგება, თუ როგორ უნდა გაზიარონ დიდი რაოდენობით მონაცემები სერვისებს შორის.

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

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

და აქ ჩნდება დილემა. წინააღმდეგობა. დიქოტომია. ყოველივე ამის შემდეგ, საინფორმაციო სისტემები ეხება მონაცემთა მიწოდებას, ხოლო სერვისები - დამალვას.

ეს ორი ძალა ფუნდამენტურია. ისინი მხარს უჭერენ ჩვენი მუშაობის დიდ ნაწილს, მუდმივად იბრძვიან სრულყოფილებისთვის ჩვენს მიერ აშენებულ სისტემებში.

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

თავის მხრივ, ისეთი რამის შექმნა, რომელიც ჰგავს ლამაზი სახლის მონაცემთა ბაზას, გამოიწვევს უამრავ პრობლემას. რატომ არის ეს საშიში, დეტალებს არ შევეხებით გაზიარებული მონაცემთა ბაზა, ვთქვათ, რომ ის წარმოადგენს მნიშვნელოვან ძვირადღირებულ საინჟინრო და ოპერატიულ სირთულეები კომპანიისთვის, რომელიც ცდილობს გამოიყენოს იგი.

უარესი ის არის, რომ მონაცემთა მოცულობა ადიდებს სერვისის საზღვრის პრობლემებს. რაც უფრო მეტია გაზიარებული მონაცემები სერვისში, მით უფრო რთული გახდება ინტერფეისი და მით უფრო რთული იქნება სხვადასხვა სერვისებიდან მომდინარე მონაცემთა ნაკრების გაერთიანება.

მთელი მონაცემთა ნაკრების ამოღებისა და გადატანის ალტერნატიულ მიდგომასაც აქვს თავისი პრობლემები. ამ კითხვისადმი საერთო მიდგომა ჰგავს მთლიანი მონაცემთა ნაკრების უბრალოდ მოძიებას და შენახვას და შემდეგ ადგილობრივად შენახვას თითოეულ მომხმარებელ სერვისში.

პრობლემა ის არის, რომ სხვადასხვა სერვისი განსხვავებულად განმარტავს მათ მიერ მოხმარებულ მონაცემებს. ეს მონაცემები ყოველთვის ხელთ არის. ისინი მოდიფიცირებული და დამუშავებულია ადგილობრივად. საკმაოდ სწრაფად ისინი წყვეტენ რაიმე საერთოს წყაროს მონაცემებთან.

რაც უფრო ცვალებადია ასლები, მით მეტი იქნება მონაცემები დროთა განმავლობაში.

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

ამ პრობლემის მოსაგვარებლად, ჩვენ სხვაგვარად უნდა ვიფიქროთ გაზიარებულ მონაცემებზე. ისინი უნდა გახდნენ პირველი კლასის ობიექტები ჩვენს მიერ აშენებულ არქიტექტურაში. პეტ ჰელანდი ასეთ მონაცემებს „გარეგანს“ უწოდებს და ეს ძალიან მნიშვნელოვანი ფუნქციაა. ჩვენ გვჭირდება ინკაფსულაცია, რათა არ გამოვავლინოთ სერვისის შიდა ფუნქციები, მაგრამ ჩვენ უნდა გავუადვილოთ სერვისებს გაზიარებულ მონაცემებზე წვდომა, რათა მათ შეძლონ თავიანთი სამუშაოების სწორად შესრულება.

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

მონაცემთა წარუმატებლობის ციკლი

ნაკადები: დეცენტრალიზებული მიდგომა მონაცემთა და სერვისების მიმართ

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

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

ამ მიდგომის მიღწევის ერთ-ერთი გზაა ნაკადის პლატფორმის გამოყენება. ბევრი ვარიანტია, მაგრამ დღეს ჩვენ გადავხედავთ კაფკას, რადგან მისი Stateful Stream Processing-ის გამოყენება საშუალებას გვაძლევს ეფექტურად გადავჭრათ წარმოდგენილი პრობლემა.

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

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

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

აღმოფხვრა მონაცემთა დიქოტომია უცვლელი მდგომარეობის ნაკადის გამოყოფით. შემდეგ დაამატეთ ეს ფუნქცია ყველა სერვისს Stateful Stream Processing-ის გამოყენებით.

ამრიგად, თუ თქვენს სერვისს სჭირდება შეკვეთებთან მუშაობა, პროდუქტის კატალოგთან, საწყობთან, მას ექნება სრული წვდომა: მხოლოდ თქვენ გადაწყვეტთ რა მონაცემები დააკავშიროთ, სად დაამუშავოთ და როგორ უნდა შეიცვალოს დროთა განმავლობაში. იმისდა მიუხედავად, რომ მონაცემები გაზიარებულია, მასთან მუშაობა მთლიანად დეცენტრალიზებულია. ის იწარმოება თითოეულ სერვისში, სამყაროში, სადაც ყველაფერი თქვენი წესების მიხედვით მიდის.

გააზიარეთ მონაცემები მისი მთლიანობის დარღვევის გარეშე. ჩადეთ ფუნქცია და არა წყარო, ყველა სერვისში, რომელსაც ეს სჭირდება.

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

ასე რომ, დღეს განხილულ მიდგომას აქვს რამდენიმე უპირატესობა:

• მონაცემები გამოიყენება საერთო ნაკადების სახით, რომელთა შენახვა შესაძლებელია ჟურნალებში დიდი ხნის განმავლობაში, ხოლო საერთო მონაცემებთან მუშაობის მექანიზმი გამაგრებულია თითოეულ ინდივიდუალურ კონტექსტში, რაც საშუალებას აძლევს სერვისებს მარტივად და სწრაფად იმუშაონ. ამ გზით, მონაცემთა დიქოტომია შეიძლება დაბალანსდეს.
• სხვადასხვა სერვისებიდან მიღებული მონაცემები ადვილად შეიძლება გაერთიანდეს ნაკრებებად. ეს ამარტივებს ურთიერთქმედებას გაზიარებულ მონაცემებთან და გამორიცხავს მონაცემთა ბაზაში ადგილობრივი მონაცემთა ნაკრების შენარჩუნების აუცილებლობას.
• Stateful Stream Processing მხოლოდ ქეშირებს მონაცემებს, ხოლო სიმართლის წყარო რჩება ზოგადი ჟურნალები, ამიტომ მონაცემთა კორუფციის პრობლემა დროთა განმავლობაში არც ისე მწვავეა.
• მათი ძირითადი ნაწილი, სერვისები ეყრდნობა მონაცემებს, რაც იმას ნიშნავს, რომ მონაცემთა მუდმივად მზარდი მოცულობის მიუხედავად, სერვისებს შეუძლიათ სწრაფად რეაგირება მოახდინონ ბიზნეს მოვლენებზე.
• მასშტაბურობის საკითხები ბროკერზე მოდის და არა სერვისებზე. ეს მნიშვნელოვნად ამცირებს წერის სერვისების სირთულეს, რადგან არ არის საჭირო მასშტაბურობაზე ფიქრი.
• ახალი სერვისების დამატება არ საჭიროებს ძველის შეცვლას, ამიტომ ახალი სერვისების დაკავშირება უფრო ადვილი ხდება.

როგორც ხედავთ, ეს უფრო მეტია, ვიდრე უბრალოდ დასვენება. ჩვენ მივიღეთ ინსტრუმენტების ნაკრები, რომელიც საშუალებას გაძლევთ იმუშაოთ გაზიარებულ მონაცემებთან დეცენტრალიზებული გზით.

დღევანდელ სტატიაში ყველა ასპექტი არ იყო გაშუქებული. ჩვენ ჯერ კიდევ უნდა გავარკვიოთ, როგორ დავაბალანსოთ მოთხოვნა-პასუხის პარადიგმა და მოვლენაზე ორიენტირებული პარადიგმა. მაგრამ ამას შემდეგ ჯერზე გავუმკლავდებით. არის თემები, რომლებიც უნდა გაეცნოთ უკეთ, მაგალითად, რატომ არის Stateful Stream Processing ასე კარგი. ამის შესახებ მესამე სტატიაში ვისაუბრებთ. და არის სხვა ძლიერი კონსტრუქციები, რომლებითაც შეგვიძლია ვისარგებლოთ, თუ მათ მივმართავთ, მაგალითად, ზუსტად ერთხელ დამუშავება. ეს არის თამაშის ჩეინჯერი განაწილებული ბიზნეს სისტემებისთვის, რადგან ის უზრუნველყოფს ტრანზაქციის გარანტიებს XA მასშტაბირებადი ფორმით. ეს იქნება განხილული მეოთხე სტატიაში. და ბოლოს, ჩვენ უნდა გადავიდეთ ამ პრინციპების განხორციელების დეტალებზე.

მაგრამ ახლა, უბრალოდ გახსოვდეთ ეს: მონაცემთა დიქოტომია არის ძალა, რომელსაც ვაწყდებით ბიზნეს სერვისების შექმნისას. და ეს უნდა გვახსოვდეს. ხრიკი იმაში მდგომარეობს, რომ ყველაფერი თავდაყირა დაატრიალოთ და დაიწყოთ გაზიარებული მონაცემების, როგორც პირველი კლასის ობიექტების მკურნალობა. Stateful Stream Processing უზრუნველყოფს უნიკალურ კომპრომისს ამისათვის. ის თავიდან აიცილებს ცენტრალიზებულ „ღმერთის კომპონენტებს“, რომლებიც ხელს უშლიან პროგრესს. უფრო მეტიც, ის უზრუნველყოფს მონაცემთა ნაკადის მილსადენების სისწრაფეს, მასშტაბურობას და ელასტიურობას და ამატებს მათ ყველა სერვისში. აქედან გამომდინარე, ჩვენ შეგვიძლია ფოკუსირება ცნობიერების ზოგად ნაკადზე, რომელსაც ნებისმიერ სერვისს შეუძლია დაუკავშირდეს და იმუშაოს მის მონაცემებთან. ეს ხდის სერვისებს უფრო მასშტაბურ, ურთიერთშემცვლელად და ავტონომიურს. ასე რომ, ისინი არა მხოლოდ კარგად გამოიყურებიან დაფაზე და ჰიპოთეზის ტესტებზე, არამედ იმუშავებენ და განვითარდებიან ათწლეულების განმავლობაში.

შეიტყვეთ მეტი კურსის შესახებ.

წყარო: www.habr.com