La construirea unui sistem de administrare multi-cont, primul lucru de stabilit nu este interfața, ci câmpurile și ciclul de viață al stratului de dispozitive. O abstractizare greșită produce refactorizări în lanț când cresc conturile sau se schimbă tipurile de dispozitive.
La dezvoltarea unui sistem de administrare multi-cont, prima versiune pornește de obicei de la interfață: se face o listă de conturi, fiecărui cont i se atașează un profil de browser, apoi sunt apelate interfețe pentru operațiuni. Pare suficient până când sistemul începe să ruleze în mod real.
Prima implementare este de regulă foarte directă. Contul A indică profilul 001, contul B profilul 002, iar contul C este legat de un telefon în cloud. Problemele apar în trei locuri: echipa de operațiuni spune că un dispozitiv s-a defectat și întreabă dacă contul A poate fi mutat pe telefonul în cloud, iar soluția înseamnă modificarea bazei de date, lucru manual și risc; este integrată o nouă sursă de dispozitive și întrebarea despre adăugarea ei duce la refactorizarea modulului de conturi; sau același cont trebuie să folosească dimineața un mediu de browser și după-amiaza un telefon în cloud, lucru aproape imposibil de programat curat pe intervale.
Cele trei situații par fără legătură, dar au o singură cauză: entitatea cont conține lucruri care nu îi aparțin. Dispozitivul conectat în prezent, dispozitivele folosite anterior, parametrii de amprentă și adresa de ieșire sunt toate stocate pe cont. Astfel, schimbarea dispozitivului devine echivalentă cu modificarea contului, iar o singură schimbare afectează întregul sistem.
Dispozitivul trebuie să fie un tip separat de obiect
După separare, conturile și dispozitivele ar trebui să aibă o relație mulți-la-mulți. Contul nu stochează amprenta, ci doar dispozitivul de care este legat în prezent. Schimbarea dispozitivului trebuie să fie o operațiune atomică, istoricul legăturilor să fie păstrat într-un tabel separat, iar fiecare dispozitiv să aibă un identificator unic, singurul identificator expus în exterior, cu stare disponibilă în timp real.
Nu este vorba despre un model mai elegant. Scopul este reducerea distanței dintre o ajustare dorită de operațiuni și o schimbare de cod necesară din partea dezvoltării, iar această distanță crește odată cu numărul de dispozitive.
Patru grupe de câmpuri pe care stratul de abstractizare trebuie să le definească clar
O abstractizare a dispozitivelor care poate scala trebuie să răspundă extern doar la patru întrebări.
- ID de mediu: unic și stabil. Straturile superioare fac referire la mediu doar prin acest ID; numerele interne, numele containerelor și ID-urile de proces nu trebuie expuse
- Legarea ieșirii: prin ce ieșire de rețea comunică mediul și dacă fusul orar, limba și DNS-ul asociate sunt configurate ca un set coerent. Separarea ieșirii permite schimbarea ei fără modificarea mediului
- Stare: în creare, gata de pornire, în execuție, ocupat de o sarcină, anormal, în așteptarea recuperării. Fără un model de stare nu se pot gestiona corect pooling-ul și recuperarea
- Ciclu de viață: cine declanșează crearea, pornirea, ocuparea, eliberarea și recuperarea; ce se întâmplă când o sarcină expiră; și cine finalizează curățarea când mediul are o problemă
Starea și ciclul de viață sunt adesea combinate într-un singur câmp. Este cea mai simplă și, în același timp, cea mai costisitoare abordare. Starea spune cum arată mediul acum; ciclul de viață spune cine poate interveni în pasul următor. În producție, problemele reale apar aproape întotdeauna în al doilea caz: o sarcină se blochează și nimeni nu eliberează mediul sau un mediu încă activ este recuperat, iar abia la următoarea pornire se descoperă că ieșirea s-a schimbat.
O abstractizare greșită își arată costul la scalare
Cu zece medii este posibil să nu se vadă nimic. La zeci sau sute, problemele apar simultan:
- Adăugarea unui nou tip de dispozitiv necesită modificarea modulului de conturi, extinzând regresia din stratul de dispozitive în stratul de conturi
- Schimbarea dispozitivului necesită modificarea bazei de date, astfel încât echipa de operațiuni evită operațiunea și sistemul ajunge treptat să poată fi întreținut doar de dezvoltatori
- Fără înregistrări de stare și ocupare, mediile rămase după ieșiri anormale nu sunt recuperate, iar mediile zombie se acumulează
- Sarcinile, conținutul și automatizarea din straturile superioare se bazează pe o relație unu-la-unu între cont și dispozitiv, astfel că o schimbare impune refacerea întregului lanț
Dispozitivele din surse diferite sunt foarte diferite ca implementare: mediile locale de browser și telefoanele în cloud folosesc interfețe complet diferite. Rolul stratului de abstractizare este să le plaseze în spatele aceluiași set de interfețe. Pentru a adăuga un tip nou de dispozitiv ar trebui să fie suficient un adaptor care implementează pornirea, oprirea și interogarea stării; logica din straturile superioare nu trebuie să se schimbe. Există și un test simplu pentru calitatea abstractizării: când adăugați un tip de dispozitiv, modificarea de cod rămâne într-un singur fișier?
În prima etapă, faceți cât mai puțin
După stabilirea modelului tehnic, interfața devine mult mai naturală. Meniurile ar trebui organizate după obiecte de business, cu zone separate pentru conturi, sarcini și dispozitive, nu după configurații, parametri și jurnale. Starea și excepțiile ar trebui să fie cele mai vizibile, deoarece utilizatorul caută probleme, nu numărul de înregistrări.
Funcțional, pentru prima etapă sunt suficiente o listă de dispozitive, adăugarea de dispozitive și un flux minim complet pentru o sarcină. Reduceți meniul cât mai mult, faceți mai întâi un singur proces să funcționeze complet și amânați tot ce nu este necesar.
Dacă nu doriți să implementați izolarea mediilor de la zero, puteți folosi capabilități existente. PurpleMark oferă medii independente și legare de ieșire, acceptă creare în lot pe grupuri și interogări de stare. Stratul superior trebuie să implementeze doar șabloanele, ocuparea și planificarea sarcinilor, astfel încât efortul de inginerie să rămână concentrat pe logica de business.
Complexitatea unui sistem multi-cont nu a fost niciodată dată de numărul de conturi, ci de gestionarea ciclului de viață al dispozitivelor. Tratați mai întâi fiecare dispozitiv ca pe o resursă cu identitate, ieșire, stare și ciclu de viață, iar funcțiile straturilor superioare nu vor trebui reconstruite la fiecare extindere.
