BPM სტილის ინტეგრაცია

გამარჯობა, ჰაბრ!

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

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

პასუხისმგებლობის უარყოფა

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

რა შუაშია BPM?

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

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

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

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

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

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

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

ასე გამოიყურება პროცესი პროექტის დასაწყისში

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

ასე გამოიყურება პროცესი მოთხოვნების დაზუსტების რამდენიმე განმეორების შემდეგ

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

რთული ბიზნეს პროცესის მცირე ნაწილი

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

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

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

სინქრონული ზარების, როგორც ინტეგრაციის ნიმუშის ნაკლოვანებები

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

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

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

• სისტემის პასუხისმგებლობა დაკარგულია, მომხმარებლები დიდხანს ელიან თხოვნებზე პასუხებს;
• სერვერი, როგორც წესი, წყვეტს პასუხს მომხმარებლის მოთხოვნებზე გადატვირთული ნაკადის აუზის გამო: ძაფების უმეტესობა „დგას“ ტრანზაქციის მიერ დაკავებული რესურსის საკეტზე;
• ჩიხები ჩნდება: მათი წარმოშობის ალბათობა ძლიერ არის დამოკიდებული ტრანზაქციის ხანგრძლივობაზე, ბიზნეს ლოგიკის ოდენობაზე და ტრანზაქციაში ჩართულ საკეტებზე;
• ჩნდება ტრანზაქციის ვადის ამოწურვის შეცდომები;
• სერვერი "ვარდება" OutOfMemory-ზე, თუ ამოცანა მოითხოვს დიდი რაოდენობით მონაცემების დამუშავებას და შეცვლას, ხოლო სინქრონული ინტეგრაციების არსებობა ძალიან ართულებს დამუშავების "მსუბუქ" ტრანზაქციებად დაყოფას.

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

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

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

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

„საგა“, როგორც ტრანზაქციების პრობლემის გადაწყვეტა

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

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

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

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

მაგრამ ასეთ გამოსავალს ასევე აქვს თავისი "ფასი":

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

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

ბიზნეს ლოგიკის ინკაპსულაცია მიკროსერვისებში

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

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

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

უფრო დეტალურმა კვლევამ გამოავლინა ამ მიდგომის მნიშვნელოვანი ნაკლოვანებები:

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

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

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

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

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

ბიზნეს პროცესების ინტეგრაცია აპლიკაციის შემქმნელის თვალით

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

შევეცადოთ გადავჭრათ საკმაოდ რთული ინტეგრაციის პრობლემა, რომელიც სპეციალურად სტატიისთვის არის გამოგონილი. ეს იქნება "თამაშის" დავალება, რომელიც მოიცავს სამ აპლიკაციას, სადაც თითოეული მათგანი განსაზღვრავს დომენის გარკვეულ სახელს: "app1", "app2", "app3".

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

თამაშის წესები:

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

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

app1 აპლიკაციაში იმუშავებს პირველი მოთამაშის ბიზნეს პროცესი (ის არის ასევე თამაშის ინიციატორი):

კლასი InitialPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

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

app2 მოიცავს სხვა მოთამაშის ბიზნეს პროცესს:

კლასის RandomPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

დიაგრამა:

app3 აპლიკაციაში მოთამაშეს ვაქცევთ ოდნავ განსხვავებული ქცევით: იმის ნაცვლად, რომ შემთხვევით აირჩიონ შემდეგი მოთამაშე, ის იმოქმედებს მრგვალი რობინის ალგორითმის მიხედვით:

კლასი RoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

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

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

testGame ()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

ჩაატარეთ ტესტი, შეხედეთ ჟურნალს:

კონსოლის გამომავალი

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

ამ ყველაფრისგან რამდენიმე მნიშვნელოვანი დასკვნის გამოტანა შეიძლება:

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

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

ყველა შეტყობინება ერთ რიგში

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

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

ინტეგრაციის ავტობუსის საიმედოობის უზრუნველყოფა

საიმედოობა შედგება რამდენიმე რამისგან:

• შეტყობინებების არჩეული ბროკერი არის არქიტექტურის კრიტიკული კომპონენტი და წარუმატებლობის ერთი წერტილი: ის საკმარისად ტოლერანტული უნდა იყოს შეცდომების მიმართ. თქვენ უნდა გამოიყენოთ მხოლოდ დროში გამოცდილი განხორციელებები კარგი მხარდაჭერითა და დიდი თემით;
• აუცილებელია შეტყობინებების ბროკერის მაღალი ხელმისაწვდომობის უზრუნველყოფა, რისთვისაც იგი ფიზიკურად უნდა იყოს გამიჯნული ინტეგრირებული აპლიკაციებისგან (გამოყენებითი ბიზნეს ლოგიკის მქონე აპლიკაციების მაღალი ხელმისაწვდომობა გაცილებით რთული და ძვირია);
• ბროკერი ვალდებულია უზრუნველყოს მიწოდების გარანტია „ერთხელ მაინც“. ეს არის სავალდებულო მოთხოვნა ინტეგრაციის ავტობუსის საიმედო მუშაობისთვის. არ არის საჭირო "ზუსტად ერთხელ" დონის გარანტიები: ბიზნეს პროცესები, როგორც წესი, არ არის მგრძნობიარე შეტყობინებების ან მოვლენების განმეორებით მოსვლის მიმართ, ხოლო სპეციალურ დავალებებს, სადაც ეს მნიშვნელოვანია, უფრო ადვილია დამატებითი შემოწმებების დამატება ბიზნეს ლოგიკაში, ვიდრე მუდმივად გამოყენება. საკმაოდ "ძვირი"" გარანტიები;
• შეტყობინებების და სიგნალების გაგზავნა უნდა იყოს ჩართული საერთო ტრანზაქციაში ბიზნეს პროცესების მდგომარეობისა და დომენის მონაცემების ცვლილებით. სასურველი ვარიანტი იქნება ნიმუშის გამოყენება ტრანზაქციის გასასვლელი, მაგრამ საჭიროებს დამატებით ცხრილს მონაცემთა ბაზაში და რელეს. JEE აპლიკაციებში, ეს შეიძლება გამარტივდეს ადგილობრივი JTA მენეჯერის გამოყენებით, მაგრამ არჩეულ ბროკერთან კავშირი უნდა შეეძლოს რეჟიმში იმუშაოს. XA;
• შემომავალი შეტყობინებების და მოვლენების დამმუშავებლებმა ასევე უნდა იმუშაონ ბიზნეს პროცესის მდგომარეობის შეცვლის ტრანზაქციასთან: თუ ასეთი ტრანზაქცია უკან დაბრუნდა, მაშინ შეტყობინების მიღებაც უნდა გაუქმდეს;
• შეტყობინებები, რომლებიც ვერ მოხერხდა შეცდომების გამო, უნდა ინახებოდეს ცალკე მაღაზიაში DLQ (მკვდარი ასოების რიგი). ამისათვის ჩვენ შევქმენით ცალკე პლატფორმის მიკროსერვისი, რომელიც ინახავს ასეთ შეტყობინებებს თავის საცავში, ახდენს მათ ინდექსირებას ატრიბუტების მიხედვით (სწრაფი დაჯგუფებისა და ძიებისთვის) და ავლენს API-ს სანახავად, დანიშნულების მისამართზე ხელახლა გაგზავნისთვის და შეტყობინებების წასაშლელად. სისტემის ადმინისტრატორებს შეუძლიათ ამ სერვისთან მუშაობა თავიანთი ვებ ინტერფეისის საშუალებით;
• ბროკერის პარამეტრებში, თქვენ უნდა დაარეგულიროთ მიწოდების განმეორებითი ცდები და შეფერხებები მიწოდებებს შორის, რათა შეამციროთ შეტყობინებების DLQ-ში მოხვედრის ალბათობა (ოპტიმალური პარამეტრების გამოთვლა თითქმის შეუძლებელია, მაგრამ შეგიძლიათ ემპირიულად იმოქმედოთ და დაარეგულიროთ ისინი დროს ოპერაცია);
• DLQ მაღაზიის მუდმივი მონიტორინგი უნდა მოხდეს და მონიტორინგის სისტემამ უნდა აცნობოს სისტემის ადმინისტრატორებს, რათა მათ შეძლონ უმოკლეს დროში რეაგირება, როდესაც მოხდება მიუწოდებელი შეტყობინებები. ეს შეამცირებს წარუმატებლობის ან ბიზნეს ლოგიკის შეცდომის „დაზიანების ზონას“;
• ინტეგრაციის ავტობუსი არ უნდა იყოს მგრძნობიარე აპლიკაციების დროებითი არარსებობის მიმართ: თემის გამოწერა უნდა იყოს გამძლე, ხოლო აპლიკაციის დომენის სახელი უნდა იყოს უნიკალური, რათა სხვამ არ შეეცადოს მისი მესიჯის დამუშავება რიგიდან განაცხადის არყოფნის დროს.

ბიზნეს ლოგიკის ძაფების უსაფრთხოების უზრუნველყოფა

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

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

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

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

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

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

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

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

ჩვენს მაგალითებში, InitialPlayer ბიზნეს პროცესი შეიცავს დეკლარაციას

uniqueConstraint = UniqueConstraints.singleton

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

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

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

ცვლილების სიღრმიდან გამომდინარე, შეგიძლიათ იმოქმედოთ ორი გზით:

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

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

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

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

• მონაცემთა ბაზაში, ბიზნეს პროცესის მუდმივი მდგომარეობა ინახება ადვილად იკითხებადი და ადვილად დამუშავებული ფორმით: JSON ფორმატის სტრიქონში. ეს საშუალებას გაძლევთ განახორციელოთ მიგრაცია როგორც აპლიკაციის შიგნით, ასევე მის გარეთ. ექსტრემალურ შემთხვევებში, თქვენ ასევე შეგიძლიათ შეცვალოთ იგი სახელურებით (განსაკუთრებით სასარგებლოა განვითარების დროს გამართვისას);
• ინტეგრაციის ბიზნეს ლოგიკა არ იყენებს ბიზნეს პროცესების სახელებს, ასე რომ ნებისმიერ დროს შესაძლებელია ერთ-ერთი მონაწილე პროცესის განხორციელების შეცვლა ახლით, ახალი სახელით (მაგალითად, "InitialPlayerV2"). დაკავშირება ხდება შეტყობინებების და სიგნალების სახელების მეშვეობით;
• პროცესის მოდელს აქვს ვერსიის ნომერი, რომელსაც ვამატებთ, თუ ამ მოდელში შეუთავსებელი ცვლილებები შევაქვთ და ეს რიცხვი ინახება პროცესის ინსტანციის მდგომარეობასთან ერთად;
• პროცესის მუდმივი მდგომარეობა იკითხება ბაზიდან ჯერ მოსახერხებელ ობიექტის მოდელში, რომლითაც მიგრაციის პროცედურას შეუძლია იმუშაოს, თუ მოდელის ვერსიის ნომერი შეიცვალა;
• მიგრაციის პროცედურა მოთავსებულია ბიზნეს ლოგიკის გვერდით და ეწოდება „ზარმაცი“ ბიზნეს პროცესის თითოეული ინსტანციისთვის მონაცემთა ბაზიდან მისი აღდგენის დროს;
• თუ საჭიროა პროცესის ყველა ინსტანციის მდგომარეობის სწრაფად და სინქრონული მიგრაცია, გამოიყენება მონაცემთა ბაზის მიგრაციის უფრო კლასიკური გადაწყვეტილებები, მაგრამ იქ უნდა იმუშაოთ JSON-თან.

მჭირდება სხვა ჩარჩო ბიზნეს პროცესებისთვის?

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

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

მჭირდება სხვა ჩარჩო ბიზნეს პროცესებისთვის?

• 18,8%კი, დიდი ხანია ვეძებ მსგავს რამეს.

• 12,5%საინტერესოა მეტი გაიგოთ თქვენი განხორციელების შესახებ, ეს შეიძლება იყოს სასარგებლო2

• 6,2%ჩვენ ვიყენებთ ერთ-ერთ არსებულ ჩარჩოს, მაგრამ ვფიქრობთ მის შეცვლაზე1

• 18,8%ჩვენ ვიყენებთ ერთ-ერთ არსებულ ჩარჩოს, ყველაფერი ჯდება3

• 18,8%დაძლევა ჩარჩოს გარეშე3

• 25,0%დაწერე შენი 4

მისცა ხმა 16 მომხმარებელმა. 7-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com