Călătoria Shoprocket către microservicii: Partea 1

Câteva luni după ce am început să lucrez la Shoprocket, am început să fiu frustrat. Aveam o aplicație PHP care era dezvoltată de echipa noastră mică de programatori talentați, repartizați în întreaga lume. De ce eram frustrat? Pentru mine, părea că repararea bug-urilor genera mai multe bug-uri, integrarea de noi funcționalități nu era la fel de simplă pe cât ar fi putut fi, iar desfășurările erau rare și stresante. Motivul acestor probleme: cod foarte strâns legat.

Aveam o aplicație monolitică și aproape tot codul nostru se afla într-un singur repository GitHub. Actualizările sau corecturile unei funcționalități apăreau adesea în mai multe locuri. Pentru testare, aveam un proces de revizuire, în care cel puțin doi dezvoltatori trebuiau să aprobe o ramură înainte de a fi fuzionată în ramura principală și desfășurată. Toate acestea însemnau că, atunci când bug-urile reușeau să se strecurie pe sub radar, era adesea dificil să localizăm schimbările care provocau probleme. Și odată ce le localizam, corecturile trebuiau să urmeze același proces și întreaga aplicație trebuia să fie desfășurată din nou.

Fiind un dezvoltator tânăr și dornic să găsească noul, când am dat peste microservicii, am crezut că acest stil arhitectural va rezolva toate problemele noastre. Nu există o definiție formală a microserviciilor, dar din cercetarea mea am înțeles că arhitectura microserviciilor este o modalitate de a proiecta aplicații software ca sisteme distribuite de servicii independente, fiecare foarte specializată și cu propriul ciclu de viață. Pentru cititorii care doresc o introducere mai detaliată în concept, recomand excelentul articol al lui Martin Fowler.

Existau multe aspecte ale microserviciilor care mă interesau, dar două în special: În primul rând, ideea de a împărți aplicația în servicii cu limite foarte stricte. Acest lucru reduce șansele ca logica specifică unei contexte de afaceri să se strecoare între componente, deoarece interfețele dintre limite trebuie să fie planificate cu atenție. Nu este la fel de simplu ca apelurile locale de funcții; În al doilea rând, fiecare componentă poate avea propriul ciclu de viață independent. Acest lucru permite echipelor să își asumă responsabilitatea pentru codul lor și să utilizeze un stack tehnologic cel mai potrivit pentru serviciul individual. De asemenea, permite un control mai detaliat asupra aplicației, deoarece modificările pot fi desfășurate pentru un serviciu la un moment dat și retrase fără a afecta restul aplicației, dacă ceva nu merge bine.

Așadar, eram convins. Shoprocket ar rupe monolitul! Acesta este primul dintr-o scurtă serie de postări pe blog care urmează această călătorie. Speranța mea este că cititorii care plănuiesc sau trec printr-o tranziție similară vor învăța din succesele și eșecurile noastre și se vor simți mai bine pregătiți să abordeze această provocare în propriile proiecte.

Prima mea provocare nu a fost tehnică, ci umană. A trebuit să vând ideea celorlalți membri ai echipei. Păreau curioși, dar nu împărtășeau aceeași entuziasm și erau reticenți să renunțe la orele de dezvoltare în această etapă timpurie a vieții produsului nostru. Din fericire, CTO-ul a vrut să investigheze gestionarea sesiunilor noastre și am profitat de ocazie, convingându-l că pot separa un serviciu de sesiuni.

Privind în retrospectivă, aceasta a fost poate o alegere proastă de componentă pentru primul serviciu. Produsul nostru include un plugin javascript care permite commerce-ul pe orice website. Tratăm sesiunile ca o resursă, persistând informațiile sesiunii în baza de date pentru analiza detaliată a KPI-urilor, cum ar fi ratele de abandon ale coșului. Cu toate acestea, această resursă nu este la fel de tangibilă ca ceva precum comenzile sau articolele de linie. În plus, foloseam resursa de sesiune cu aproape fiecare schimbare în starea aplicației. Acest lucru însemna că serviciul ar fi inevitabil comunicativ cu restul aplicației, ceea ce nu am prevăzut, dar a făcut sarcina mea dificilă.

După ce mi-am convins șeful, mi-am intensificat cercetarea asupra microserviciilor. Pe lângă articolul menționat anterior, am descoperit că 'Building Microservices' de Sam Newman a fost o resursă inestimabilă. Voi face referire la ambele adesea în postările mele.

În cartea sa, Newman recomandă mai întâi restructurarea unei aplicații existente în module care reflectă contexte limitate ale domeniului. Apoi, odată ce dezvoltatorii sunt mulțumiți, modulele pot fi separate în servicii proprii. Motivul pentru aceasta este că este mult mai ușor să descompui și să rescrii module dacă limitele lor au fost alese prost decât să descompui și să rescrii servicii întregi, cu tot codul lor de instalare suplimentar și resursele persistente. Cu toate acestea, din cauza constrângerilor de timp și a dorinței mele de a construi un component de unul singur, am continuat cu primul serviciu.

Am ales un stack doar marginal diferit de cel pe care îl foloseam pentru monolitul nostru și am început să construiesc. Construcția în sine a decurs destul de rapid, luând câteva săptămâni pentru a produce o aplicație autonomă cu un API REST. Abia apoi au început adevăratele provocări.

A trebuit să fac serviciul să comunice cu monolitul. A fost în acest moment că am învățat cât de strâns legată era gestionarea sesiunilor de restul codului. Mi-a luat ceva timp să descompun apelurile de funcții existente și să le traduc în apeluri API. Acest lucru a fost complicat. Deoarece serviciul de sesiuni și monolitul aveau propriile scheme de baze de date, a trebuit să rescriu orice logică în monolit care folosea resursele de sesiune din baza de date veche, restructurând datele la limita aplicației pentru a menține compatibilitatea cu clienți precum pluginul nostru javascript.

Integrând serviciul cu aplicația noastră existentă a durat mai mult decât a fost să scriu serviciul în sine, iar acest lucru nu includea o mare parte din suprasarcina suplimentară pe care microserviciile o aduc de obicei, cum ar fi descoperirea serviciilor, logarea și monitorizarea. În plus, din cauza legării strânse, modificările au fost făcute în multe zone ale codului. Deoarece echipa lucrase la diverse zone ale codului în paralel în timpul acestui timp, ar fi necesitat mult mai mult efort pentru a fuziona modificările și a aduce serviciul de sesiuni în producție.

Serviciul ar putea intra în curând în producție, totuși, acum simt că ar fi trebuit să urmez sfatul lui Newman și să îmi concentrez eforturile pe modularizarea aplicației noastre existente. Beneficiul de a avea un serviciu care funcționează pe cont propriu este marginal. Adevăratul beneficiu va veni din împărțirea întregului, cel puțin în servicii cu granularitate grosieră, care comunică cât mai puțin posibil. Acest lucru necesită limite de componentă foarte bine gândite, iar noi nu suntem încă acolo.

Încă mai cred în ideea microserviciilor și consider tentativa mea de a separa un serviciu ca un experiment de succes. Am învățat o mulțime despre arhitectura aplicațiilor și modelarea domeniului în acest proces, și mi-am îmbunătățit înțelegerea principiilor REST, printre altele. Acestea au avut un efect imediat în alte zone ale codului nostru.

Pentru cititorii care doresc să se convertească, aș fi sigur să citiți cât mai mult posibil despre subiect și să amânați lucrul până când sunteți foarte încrezători în baza de cod existentă și în modelul domeniului. Există alte modalități de a introduce stabilitate și reziliență într-o aplicație monolitică. Dezvoltarea dirijată de teste și testele automate unitare și funcționale ajută foarte mult. Scalarea orizontală ajută, de asemenea, la desfășurări ceva mai line.

Shoprocket va continua călătoria sa spre microservicii. Așteptăm cu nerăbdare să vă spunem mai multe în partea a 2-a!