Construirea viitorului: arhitectura microserviciilor

Când discutăm despre o foaie de parcurs de arhitectură de 2-3 ani pentru un sistem de comerț electronic care funcționează deja de câțiva ani, întrebarea tipică este: trebuie să mergem la arhitectura de microservicii?

Microservicii sunt un cuvânt de interes în acest moment, așa că este firesc să le luăm în considerare pentru evoluția sistemului. Cu toate acestea, factorii principali pentru re-arhitectarea unui sistem monolitic în microservicii sunt într-adevăr de natură comercială și operațională, cum ar fi:

1. Arhitectură pentru creșterea afacerii: pe măsură ce sistemul deservește mai mulți clienți și procesează mai multe tranzacții, are nevoie de mai multă capacitate și resurse. Cu toate acestea, nu toate părțile sistemului pot crește cu aceeași viteză.
2. Gestionarea vârfurilor de trafic: în mod ideal, sistemul ar trebui să poată scala automat, sau cel puțin dinamic, astfel încât infrastructura să nu fie împinsă la capacitatea maximă pentru a suporta traficul de vârf în orice moment.
3. Timp mai rapid de lansare pe piață: există o valoare semnificativă pentru afacere atunci când adăugarea sau modificarea unei funcții durează zile sau săptămâni în loc de luni și nu necesită teste de regresie excesive (și adesea costisitoare) și repornirea tuturor aplicațiilor care rulează întregul mediu. Răspunsul la aceasta este modularitatea și proiectarea pentru înlocuire, care este facilitată de microservicii.
4. Modificări rapide, instantanee ale conținutului și experienței utilizatorului: multe sisteme online tradiționale generează conținutul în mod dinamic la nivelul serverului, din aceeași aplicație web care conține, de asemenea, funcționalități pentru checkout, contul meu și alte caracteristici (adică monolitul). Aceasta înseamnă că, în timp ce conținutul orientat către clienți poate fi actualizat, potențial personalizat și gestionabil, regenerarea constantă a conținutului consumă o cantitate mare de cicluri CPU, creând dependențe online de depozitele de date și posibil de alte subsisteme.

Scopul final al arhitecturii de microservicii este de a împărți această aplicație în servicii relativ independente care servesc conținut implicit, oferă informații despre starea inventarului și oferă oferte și recomandări personalizate. Aceste servicii pot fi apoi reglate, scalate și gestionate pentru a obține cea mai bună experiență de utilizator.

Ideea aici este de a avea un sistem compus din mai multe servicii autonome, scalabile, înlocuibile.

Cărămidă cu cărămidă: Mișcarea treptat a sistemului

Atunci întrebarea este, cum executăm acest plan? Rescrierea sistemului de la zero este de obicei inacceptabilă. Există o investiție în platforma actuală, funcționalitatea este testată și dovedită sau există alte îmbunătățiri funcționale care trebuie finalizate în sistemul actual.

Poate fi o abordare mai bună să ajungeți la un acord asupra arhitecturii țintă și să începeți să mutați treptat sistemul către țintă prin includerea activităților de re-arhitectură în planul de dezvoltare a foii de parcurs:

1. Identificați o schimbare care ar aborda preocuparea de afaceri prioritară și planificați refactorizarea/migrarea. De exemplu , „decuplarea managementului conținutului de părțile tranzacționale ale sistemului ”, astfel încât modificările să poată fi împinse mai rapid pe site.
2. Când adăugați o funcție (de exemplu, „S-ar putea să vă placă” sau „Dacă cheltuiți un X suplimentar...”) în loc să o amestecați în aplicația curentă, luați în considerare dacă este ceva care poate oferi valoare ca serviciu independent care expune o interfață și poate fi gestionat independent. Nu trebuie să ruleze ca proces autonom sau să fie implementat singur la început, dar ar trebui să fie bine încapsulat cu dependențe minime bine înțelese.
3. Când faceți o modificare semnificativă a unui subsistem, de exemplu MyAccount, luați în considerare dacă acesta ar putea fi momentul potrivit pentru a face din aceasta o aplicație sau un serviciu pe cont propriu. Din nou, factorul important este să luați în considerare dependențele - atât de cod, cât și de nivelul de rulare.

Dacă efectuarea unei modificări în serviciul MyAccount necesită ca toate celelalte module să fie recompilate și redistribuite, atunci nu este un candidat bun pentru o migrare (încă). Dar pot exista și alte module candidate care acoperă propriile preocupări specifice domeniului:

• • Serviciu de comunicare prin e-mail pentru clienți
  • Checkout ca serviciu
  • Serviciu de disponibilitate articole
  • Motor de căutare pentru comerț
  • Diverse servicii de personalizare, consiliere sau recomandare
  • Evaluări/serviciu de evaluare a produselor

Scalați-vă proiectul în mod corect: definiți procesele și planurile arhitecturii de microservicii

După cum puteți vedea, această imagine poate începe rapid să se simtă ocupată, cu numărul de servicii în creștere și adăugând la sentimentul de complexitate crescută a soluției. Pentru a face față acestui lucru, echipele trebuie să acorde o atenție sporită următoarelor aspecte ale proiectului:

Claritatea arhitecturii: acest lucru nu înseamnă neapărat o abordare de „proiect mare în avans”, dar echipa trebuie să împărtășească o viziune și o înțelegere comune despre serviciile din care va fi compus sistemul și modul în care serviciile vor fi construite, implementate. , și monitorizat. Echipa trebuie să fie pregătită să adopte practici diferite (în primul rând API), cadre (Spring Cloud), elemente comune ale infrastructurii de aplicații — Gateway API, server de autentificare, registru de servicii etc. Nu toate sunt întotdeauna necesare, dar trebuie să fie o decizie arhitecturală conștientă dacă vor face sau nu parte din sistem.

DevOps: Acesta este un alt cuvânt popular, dar extrem de important în acest context. Pe măsură ce sistemul crește, numărul de servicii poate deveni copleșitor, așa că în lumea microserviciilor, DevOps este un element necesar. Aceasta înseamnă automatizarea și simplificarea versiunilor, testarea implementării, repornirile, scalarea automată, alertele etc. Nu avem de-a face cu un singur fișier binar implementat pe câteva servere de aplicații. Ar putea exista zeci de piese mai mici de funcționalitate, fiecare care poate rula în mai multe cazuri, nu este ceva pe care cineva dorește să îl susțină manual. Imaginați-vă să colectați manual jurnalele din toate aceste aplicații care rulează...

Arhitectura microserviciilor: cum trebuie

Există multe modalități de a greși migrarea către microservicii: pur și simplu urmărind noutățile tehnologice, fără un argument de afaceri real pentru aceasta, identificarea serviciilor nepotrivite care sunt prea dependente unele de altele, eșecul în adoptarea practicilor DevOps pentru a aborda complexitatea, nedezvoltarea abilități potrivite în cadrul echipei etc.

Cu toate acestea, cu o planificare adecvată și un management al riscului, după ceva timp (și stres, îndoieli și panica din partea PM) echipa ar trebui să înceapă să simtă un impact pozitiv:

• Sistemul sau părțile sale importante se scalează mai bine
• Este mai ușor să oferiți o nouă funcție fără a fi nevoie să reporniți totul în miezul nopții
• Componentele sistemului au un scop mai clar și, prin urmare, sunt mai ușor de dezvoltat, testat și înlocuit

Foaia de parcurs de arhitectură este instrumentul care ajută la stabilirea direcției pentru evoluția sistemului pentru doi-trei ani în viitor.

Trebuie să fie bine aliniat cu foaia de parcurs de afaceri, tehnologia strategică și direcția industriei și cu abilitățile și capacitățile echipei. Importanța sa este sporită în special odată cu introducerea de noi concepte arhitecturale și abordări precum microservicii.