Cum se construiește un motor de reguli de afaceri modern, o scurtă prezentare generală
Aceasta este o prezentare conceptuală de nivel înalt a arhitecturii motorului de reguli de afaceri. Este deasupra codului real. Dacă construiți un motor de reguli de afaceri – este foarte probabil ca acest text să vă fie util.
Cu ceva timp în urmă, am construit un motor de reguli de afaceri care a permis automatizarea afacerilor pentru companiile mici și mijlocii și, de asemenea, avea toate capacitățile și potențialul de a servi bine întreprinderilor mari. A fost o cale de trecere de la o aplicație software obișnuită la o soluție sofisticată și complexă care îndeplinea cerințele dure de scalabilitate, mentenabilitate și extensibilitate. Acest text va oferi o privire de ansamblu asupra a ceea ce este Business Rules Engine și va descrie una dintre abordările moderne de construire a acestuia, pe care o puteți lua în considerare atunci când construiți acest tip de software.
Pentru început este important să definim termenii de bază. Motoarele de reguli de afaceri sunt prezente în industrie de destul de mult timp, într-o formă sau alta, și există câteva definiții date pentru aproape fiecare termen pe care îl vom folosi. Să începem cu o „regulă de afaceri” – există o definiție bine cunoscută pentru acest termen. Așadar, o „regulă de afaceri” este:
O declarație care definește sau constrânge un anumit aspect al afacerii. Este menită să afirme structura afacerii sau să controleze sau să influențeze comportamentul afacerii.
T. Morgan, Reguli de afaceri și sisteme informatice. Boston: Addison-Wesley Publishing, 2002
Reguli de afaceri au un domeniu de aplicare foarte larg și pot fi aplicate la orice aspect al afacerii. De exemplu, regula „Când intră un client, întâmpină-l cu un zâmbet cald și un „Bună ziua” prietenos” este aplicată de către angajatul companiei atunci când se întâlnește cu clienții. O altă regulă poate defini sau constrânge abordările de rezolvare a sarcinilor de rutină de către un anumit rol din cadrul unei companii. Odată cu creșterea constantă a popularității soluțiilor software, cum ar fi sistemele CRM, și cu integrarea totală a software-ului într-o varietate de domenii de afaceri, majoritatea proceselor de afaceri au devenit parțial sau total orientate către date. Acest lucru a dus la transformarea regulilor de afaceri astfel încât acestea au devenit orientate către software, de exemplu, regula de afaceri „Atunci când un client cumpără ceva din magazinul nostru, sunați-l mai târziu pentru a-l întreba dacă dorește să cumpere și alte bunuri conexe” s-a transformat într-o regulă mai modernă „Atunci când un client cumpără ceva din magazinul nostru online, trimiteți-i mai târziu un e-mail cu lista altor bunuri conexe”. În prezent, multe companii se ocupă în principal de date în operațiunile lor zilnice. Ținând cont de faptul că majoritatea întreprinderilor de toate mărimile au soluții software integrate în activitățile lor de afaceri, definiția termenului „regulă de afaceri” poate fi definită într-o manieră mai specifică prin adăugarea unei clarificări (este în bold) la definiția menționată mai sus de T. Morgan:
O regulă de afaceri este o afirmație care definește sau constrânge un anumit aspect al afacerii. Ea este menită să afirme structura afacerii sau să controleze sau să influențeze comportamentul afacerii. Este stocată ca o construcție de date în memoria persistentă și conține un pachet atomic de logică de afaceri. Este gestionată și aplicată proceselor de afaceri ale companiei în mod automat prin intermediul unei soluții software.
După definirea termenului „regulă de afaceri”, termenul „Business Rules Engine Management System” (BRMS) se definește după cum urmează:
BRMS este o soluție software pentru gestionarea (stocarea, editarea și ștergerea, etc.) regulilor de afaceri, precum și pentru aplicarea acestora la procesele de afaceri ale companiei.
Standardele BRMS comerciale pot fi extrem de costisitoare pentru achiziționarea licenței și pentru integrarea lor în infrastructura IT a companiei, de aceea companiile implementează adesea soluții interne atunci când întâmpină o nevoie de automatizare a proceselor de afaceri sau a altor tipuri de procese.
BRMS-urile pot deveni o parte esențială și vitală a oricărei afaceri. Uneori, succesul unei afaceri poate depinde de regulile de afaceri pe care le are și de modul în care aceste reguli de afaceri sunt gestionate și aplicate.
Construcția de date a regulilor de afaceri
O regulă de afaceri poate fi reprezentată ca o serie consecventă de comenzi atomice. Comenzile pot include analiza condiționată a datelor, comenzi de așteptare a timpului, comenzi de execuție a acțiunilor etc. Exemplul de regulă de afaceri „Când un client cumpără ceva de la magazinul nostru online, trimiteți-i mai târziu un e-mail cu lista altor bunuri conexe” este unul bun și generic și multe alte reguli de afaceri pot avea o structură logică foarte asemănătoare:
Fluxul de procesare a regulii este inițiat atunci când a fost efectuată o achiziție și se aplică o anumită logică de afaceri prin executarea comenzii „Trimiteți cumpărătorului un e-mail cu oferte de bunuri relevante”. Se poate întâmpla ca cumpărătorul să fi dezactivat abonarea la e-mail. În acest caz, trebuie adăugată condiția suplimentară la regula de afaceri – „dacă cumpărătorul are activat abonamentul de e-mail”:
Comenzile sunt executate în consecință și există acum o comandă de analiză a datelor pentru a verifica dacă cumpărătorul are un abonament de e-mail activ. Dacă da – se trece la executarea următoarei comenzi a regulii de afaceri. Iar dacă nu – nu se continuă, regula de afaceri este considerată încheiată, fluxul de procesare se oprește, comenzile ulterioare nu sunt executate.
Este posibil ca cumpărătorul să aibă și un abonament SMS, iar dacă acesta este activ, ar trebui să existe și o altă comandă – „Trimite un SMS cu oferta promoțională aferentă”. Prin aceasta, se introduce ramificarea în logica regulii de afaceri:
Branșele regulii sunt procesate independent una de cealaltă. Prelucrarea uneia dintre ramuri se poate opri la comanda de evaluare a condiției și o altă ramură poate fi prelucrată până la sfârșit.
Interfața de utilizator a aplicației BRMS client-side pentru reprezentarea unei reguli de afaceri poate fi implementată în diverse moduri (orice tip de reprezentare grafică arborescentă va funcționa):
Construcția de date a regulilor de afaceri este un graf arborescent cu rădăcini dirijate (un graf aciclic dirijat, care are un arbore ca graf nedirijat subiacent). Verticile grafului regulilor de afaceri sunt reprezentate cu diferite tipuri de comenzi: comenzi de analiză a datelor, comenzi de execuție a acțiunilor, comenzi de așteptare a timpului etc. Fiecare arbore cu rădăcini direcționate are o rădăcină – un vârf de la care pornesc toate marginile. Astfel, fiecare regulă începe cu un vertex special (sau vertexul rădăcină în termenii teoriei grafurilor) – vertexul care desemnează punctul de intrare pentru procesarea regulilor.
Operații CRUD asupra construcției de date a regulilor de afaceri
Din moment ce construcția de date este reprezentată cu un arbore cu rădăcini direcționate și nicidecum cu orice alt tip de graf, acest lucru ne scutește de inconvenientele care însoțesc stocarea structurilor grafice generale cu RDBMS (cum ar fi stocarea vârfurilor și a marginilor în tabele diferite, ceea ce poate duce la un număr mai mare de căutări pentru recuperarea unei singure reguli, etc.). Iar acest lucru este esențial, deoarece este clar că în timpul operațiunilor normale ale BRMS, căutările de date se întâmplă mult mai des, decât alte operațiuni, cum ar fi inserțiile, actualizările sau ștergerile de date.
Doar ca o reamintire – fiecare vârf al regulii de afaceri reprezintă o comandă atomică. Aceasta este salvată în tabelul RDBMS sub forma unei înregistrări cu atribute precum tipul comenzii, descrierea și alte date suplimentare. Într-un arbore, fiecare vertex are un singur părinte (cu excepția vertexului rădăcină, care nu are părinți), astfel încât fiecare înregistrare trebuie să conțină un ID al vertexului părinte. De asemenea, este convenabil să existe un alt tabel care să găzduiască înregistrările regulilor cu datele relevante pentru regula de afaceri în sine. Nu există nicio problemă în ceea ce privește stocarea construcțiilor de date ale regulilor de afaceri de orice complexitate cu această abordare.
Operațiile CRUD sunt destul de simple. Modificările regulilor de afaceri pot necesita actualizări la unul sau la ambele tabele – regulă sau comandă. Atunci când se șterg sau se inserează comenzi, este necesar să se mențină referințele între comenzi (aceasta este, în esență, ștergerea sau inserarea de noduri într-un arbore).
Una dintre componentele BRMS, să o numim manager, ar trebui să efectueze operațiile descrise ale bazei de date și să furnizeze un API pentru operațiile CRUD asupra regulilor de afaceri.
Procesarea regulilor de afaceri
Procesarea regulilor de afaceri începe atunci când are loc un anumit eveniment de afaceri. Acesta poate fi orice – un utilizator s-a logat, a fost efectuată o achiziție, a fost transferată o anumită sumă de bani etc. Acest tip de activitate ar trebui să fie urmărit și BRMS ar trebui să fie informat cu privire la aceasta prin intermediul unui mijloc de transport. AMQP este, cel mai probabil, cel mai potrivit pentru acest tip de sarcină.
1. Întregul concept este construit pe o arhitectură de microservicii. Microserviciul consumator de evenimente de afaceri ascultă toate evenimentele de afaceri prin declararea unei cozi de așteptare și legarea acesteia la un schimb specific pe un server de schimb RabbitMQ. Atunci când o activitate de afaceri (care este considerată semnificativă și este urmărită) are loc în sistemul software principal, mesajul este trimis către serverul de schimb RabbitMQ. Acesta conține informații despre ceea ce s-a întâmplat, precum și unele date suplimentare relevante. Evenimentul comercial poate fi identificat cu un atribut de orice fel transmis în mesaj sau utilizat ca o cheie de rutare, de exemplu, un șir de caractere purchase.completed. Mesajul este apoi consumat de microserviciul consumator de evenimente de afaceri BRMS.
2. Atunci când microserviciul consumator de evenimente de afaceri primește mesajul de la sistemul software principal, acesta interoghează microserviciul manager dacă există reguli de afaceri în baza de date care au declanșatorul de reguli adecvat pentru evenimentul de activitate de afaceri. În cazul în care există o astfel de regulă comercială corespunzătoare, microserviciul managerului returnează microserviciului consumator de evenimente comerciale datele comenzii inițiale. Această preluare a datelor de la manager se realizează prin gRPC și este vizualizată cu o linie punctată.
3. Imediat după ce microserviciul manager răspunde cu datele inițiale de comandă, microserviciul consumator de evenimente de afaceri este pregătit să inițializeze procesarea regulii de afaceri. Consumatorul de evenimente de afaceri formează un alt mesaj care încapsulează datele comenzii inițiale (primite de la microserviciul managerului) și datele din evenimentul de afaceri, primite de la sistemul software principal. Acesta îl trimite prin AMQP către un schimb BRMS intern. Cheia de rutare a mesajului corespunde tipului de comandă.
4. Microserviciul de procesare a comenzii inițiale consumă mesajul (ascultă coada de așteptare în care sunt stivuite mesajele cu cheia de rutare initial). Apoi își face logica (într-un caz de bază, blocul inițial nu găzduiește nicio logică) și interoghează managerul dacă există comenzi ulterioare în regula de afaceri (acestea sunt comenzile cu parent_id egală cu id a comenzii care este procesată în prezent). În caz afirmativ, primește datele următoarei comenzi și trimite atât datele evenimentului de afaceri, cât și datele următoarei comenzi către serverul RabbitMQ intern. Da, acum arată ca o traversare a unei liste legate, iar atunci când regula are ramuri, este o traversare a unui arbore! Acesta este modul în care regula de afaceri este procesată comandă cu comandă. Un alt lucru important aici – în acest context, datele evenimentului de afaceri sunt transmise fiecărei comenzi copil. Este un context al execuției unice a regulii de afaceri. Acesta poate fi utilizat ulterior în procesorul de comenzi de analiză a datelor și în procesorul de comenzi de acțiune.
În scop ilustrativ, să presupunem că regula de exemplu are o structură ca aceasta: comandă inițială -> comandă condiționată de analiză a datelor -> comandă de acțiune de afaceri. Apoi, următoarea comandă după comanda inițială este comanda de analiză a datelor.
5. Procesorul de comenzi de analiză consumă mesajul cu cheia de rutare analysis din schimbul intern. Pe baza evaluării condițiilor, care sunt descrise în comanda de analiză a regulii de afaceri și utilizând datele evenimentului de afaceri, fluxul de execuție a regulii poate continua sau se poate opri aici. În cazul în care se oprește, nu se mai execută alte comenzi ale regulii de afaceri. Dacă fluxul de execuție continuă, procesorul comenzii de analiză interoghează managerul pentru următoarele comenzi ale regulii de afaceri, le recuperează și publică un alt mesaj pe serverul de schimb intern.
6. În cele din urmă, există un mesaj în schimbul intern, care este pregătit pentru a fi consumat de procesorul de comenzi de acțiune. Dacă fluxul de execuție a regulii de afaceri a ajuns până la această comandă, înseamnă că în această ramură a regulii fiecare condiție care a existat în comanda de analiză a datelor a fost adevărată și fluxul de execuție nu a fost întrerupt. Procesorul de comenzi de acțiune execută acțiunea, de exemplu, trimite un e-mail.
Acest tip de parcurgere a grafului este de tip „depth-first”, iar atunci când se întâlnește o comandă cu 2 sau mai multe comenzi copil, parcurgerea simultană de tip „depth-first” începe pentru fiecare ramură, datorită naturii asincrone a procesării regulilor de afaceri în sistemul descris.
Scalare
Abordarea descrisă permite nu numai o mare separare a preocupărilor, dar poate, de asemenea, să economisească o mulțime de bani atunci când vine vorba de plata facturilor IaaS. Utilizatorii finali creează o varietate de reguli de afaceri cu un număr diferit de comenzi de diferite tipuri și un număr diferit de ramuri. Dar scenariile comune de scalare sunt următoarele:
1. Numărul de evenimente de afaceri crește – consumatorul de evenimente de afaceri se scalează.
2. Numărul de reguli de afaceri asociate (declanșate) de evenimentele de afaceri crește – procesorul de comenzi inițiale se scalează împreună cu managerul.
3. Există multe comenzi de analiză în regulile de afaceri – procesorul de comenzi de analiză se scalează
4. Trebuie executate prea multe comenzi de acțiune – procesorul de comenzi de acțiune se scalează.
Fiabilitatea
Vascul de sânge al sistemului este transportul. Pentru ca sistemul să rămână operațional în condiții de sarcină mare, schimbul intern de mesaje trebuie să fie foarte fiabil. RabbitMQ oferă clusterizare și satisface bine cerințele de fiabilitate (https://www.rabbitmq.com/clustering.html).
Alte tipuri de comenzi
Se poate introduce în sistem orice altă logică de afaceri. Unul dintre tipurile de comenzi populare și solicitate este o comandă de așteptare a timpului (de exemplu, „Așteptați 45 de minute, apoi continuați”). Odată cu introducerea comenzii „time-wait”, procesarea regulii de afaceri nu mai este o procesare în timp real, deoarece aceasta poate fi suspendată pentru o anumită perioadă de timp. Astfel de modificări necesită procesoare de comenzi suplimentare și câteva modificări ale structurilor de date care nu intră în sfera de aplicare a prezentului text. A te juca cu timpul poate fi dificil, iar scrierea unui serviciu care operează programele și timpul poate fi o provocare, iată un exemplu de serviciu bun: https://github.com/nextiva/krolib
Alternative terțe
Există alternative bine cunoscute de motoare de reguli/motoare de fluxuri de lucru, iată care sunt primele 3 dintre ele (IMHO):
1. Comunda – este un produs matur, cu versiuni comunitare și de întreprindere, pe care ați putea dori să îl utilizați. Evident, versiunea de întreprindere este plătită.
2. Luigi – este un instrument de motor de fluxuri de lucru dezvoltat de Spotify pentru nevoile lor interne, dar deja folosit de zeci de alte companii.
3. Apache Airflow – acesta este un alt produs bine cunoscut care s-a dovedit a fi capabil, convenabil și personalizabil.
Ceea ce unește aceste instrumente, este că toate folosesc grafuri aciclice directe ca structură de date care reprezintă regulile de afaceri sau fluxurile de lucru. Nu este o surpriză.
Este posibil să existe și alte produse care merită atenție, dar orice investigație ar trebui să înceapă cu aceste trei.
Concluzie
Construirea propriului motor de reguli de afaceri poate fi o provocare, dar este plină de satisfacții. Nu numai că obțineți un sistem propriu, dar acesta este construit în funcție de cerințele specifice ale afacerii dumneavoastră. O echipă DevOps bună este o necesitate atunci când vine vorba de menținerea fiabilității, a scalabilității și a monitorizării. La urma urmei, obțineți un produs fantastic de care puteți fi mândru.
.