Long-running processes — Run process run… — Part 1

Service system design edərkən xüsusi zövq aldığım process tipi long-running processlər nə dəməkdir nəzər yetirək.

Biznes istəyi:

Bəli tapşırıq alma vaxtıdır və budur biznes bizə öz dərdini danışır. Task management toolu açırsız və

Mən müştəri kimi istəyirəmki, bla bla…

İstənilən aydındır. Deyəkki hər hansı bir mağaza biznessidir və online şəkildə müştərindən məhsulun ödənişini almaq lazımdır. Sifarişlər üzrə məsul komanda ilə danışdıqdan sonra , sizə REST API üzərindən card ödənişlərini toplayan gözəl kiçir bir service məsulliyəti verilir.

Beləliklə design olunmuş sistem:

Deyəkki, siz tapşırığı tamamlayırsız və API 200 bir response model ilə işləyir.

Taskın sonuna yaxın gözəl arxitekturanı fəxrlə developer dostuna danışarkən, o deyir:

Bir dəqiqə, sən müştəridən ödənişi almaq üçün external card servisi işlədirsən və mən o servisi işlətmişəm. Bizim həmin servis ilə bağlı çoxlu timeout- larımız olurdu. Düzəlib həmin servis?

Bu sual sizi bir az təəcübləndirir, çünki bilirsiz ki bizim bu gözəl arxitekturamız bu SaaS service-ə görə dayanıqlı deyil.

Kodunuza tez əlavələr edirsiz: External servisdən timeout (və ya not avialable) aldıqda, 3 dəfə ‘retry’ məntiqi.

Daha sonra isə bu servislərdə ‘outage’-lərin saatlarla çekə bildiyini görürsüz. Bu yerdə siz başa düşürsizki sizə elə bir yol lazımdırki, uzun müddətli ‘retry’ məntiqi işləyə bilsin. Bu da təəssüf ki o deməkdirki, siz gözəl arxitekturanıza ‘state’ və ‘scheduler’ yanaşması gətirməlisiniz.

Lakin bu dəqiqə bu problemlə savaşmaq istəmirsiz. Deyirsizki sprintin axırıdır, məsulliyəti başqasının üstünə atmaq lazımdır. Backlogda issue yaradırsız və ümid edirsiz ki ‘Order fulfillment’ komandası öz başlarının çarəsinə baxacaqlar. İndi üçün isə qısa həll kimi external servis ‘available’ olmadıqda, exception throw edirsiz.

2 həftə production-da appiniz yaşayır və sifarişlər üzrə məsul komandadan bir əməkdaş şirkətin CEO-su ilə masanıza yaxınlaşır.

Nə baş verir?

Görünən odurki yazdığınız o sistem çoxlu “credit card service unavailable” xətası tullayır və CEO sifarişlər üzərində ödənişlər keçmədiyi üçün heç xoşbəxt deyil(təbiki deyil, gitdi paralar…)

Ağlımıza ilk gələn şey o olurki bəs sifarişlər komandasından istəyəkki, ödənişlər üçüm ‘retry’ məntiqi yazsınlar. Lakin onlar ya çox məşgul olurlar, ya da ki sizin servisin məsulliyəti olan bir şey üzərində aşırı məsulliyətə girmək istəmirlər.(məncə də haqlıdırlar)

Qaçaraq gedirsiz kodlamağa və statussütunu olan bir paymentadlı cədvəl yaradırsız. Hər ödəniş statusu openolmaqla bu cədvəldə saxlanılır. Bu open statuslu ödənişlər üzərində müəyyən əməliyyatlar etmək üçün bir neçə saniyədən bir çalışan sadə scheduler yazırsız. Bəli indi servisiniz external card service-nə uzun müddətli retry-lar edə bilər və ödəniş statusunu bu api çağırışın nəticəsinə uyğun olaraq dəyişə bilər. Əla!

Lakin sifariş komandası ilə danışmaq lazımdırki, siz arazında olan API contracti dəyişdiniz. Hazırda təmin etdiyiniz api ödənişləri ‘asynchronous’ şəkildə proses edir. Servisiniz HTTP 202 (Accepted) response qaytarır artıq və iki variant var:

• Sifarişlər servisinə callback olaraq ödənişin status barəsində məlumat ötürmək
• Sifarişlər servisinin vaxtaşırı çağırıb, ödənişin status barəsində məlumat alması üçün GET api təmin etmək

Hər hansı bir variantı seçdiniz və hazırda production xoşbəxt olduğu üçün CEO-da xoşbəxtdir və siz də :)

Lakin bəzi xoşbəxtliklər az sürür və sizə yazdığınız bu service üçün daha sonra başqa tapşırıqlar gəlir. Məsələn, Ödənişlər uzun müddətli keçmədikdə e-mail notification və bu uzanır gedir. Service sahibi sizsiniz :)

Uzun bir yorğun bir həftədən sonra məzuniyyətə getməyə hazırsınız.

Lakin görünən odurki sizin boss o şəkildə düşünmür, çünki düzəltdiyiniz servisinin tech stackini sizdən başqa kimsə bilmir.

Daha pis senariya biznesin bu ödəniş servisi barəsində əlavə istəkləri var. Onlar bilirlərki bu external card service stabil deyil və sizdən bu servisinin ‘availability’ və ‘response time’ üzərinə hesabat istəyirlər. (düşünəkki monitoring toolları yoxdur)

İndi siz hesabat üzərinə də bir şeylər düşünməlisiniz.

Yuxarıdakı şəkil vəziyyəti tam izah edir. Bu şəkildə bizness istəklərini həll etmək nə kimi durumlara gətirdi tanış olduq.

The Workflow Engine

Yuxarıda gördüyümüz bizness istəkləri ‘workflow engine’ olaraq adlandırdığımız stack-in əsasını təşkil edir: processin state-ni saxlamaq, ‘scheduling retries’, prosesin cari state üzrə hesabat və nəhayət long-running processləri idarə etmək.

İstənilən biznes probleminin həlli üzrə yeni bir stack yanaşması yaratmaqdansa, ‘workflow engine’ cari marketdəki tool-ları/həlləri yoxlaya bilərik.

‘Workflow engine’ olmadan long-running bizness processləri idarə etmək ya komplex kod ilə nəticələnir ya da özümüzü orda tapırıq ki prosesin state idarəsini bizness istəklərinin içinə kodlayırıq. Bu da bizness istəklərini/prosessləri kod içərisindən anlamağı çətinləşdirir.

Bizim yuxarıda sizin üçün yazdığımız hekayədə siz hardasa özünüzün ‘workflow engine’-nını yaratmaq üzərəydiniz. Bu kimi həllər isə görülən üzrə şirkətə development və maintanence effortu yaradır və marketdə olan cari tool-ların verdiyi əlavə özəlliklər ilə isə geri qalır.

Növbəti hissədə workflow engine-lar haqqında ətraflı danışacağıq.

#system-design #camunda #workflowengine