Toate caracteristicile oferite de SDA necesită integrare cu diferite componente ale produselor Yandex și nu numai. În esență, SDA este un serviciu de integrare care reunește componente disparate sub controlul unui administrator de domeniu.
SDA începe cu domeniul: trebuie să fie conectat și să se verifice că proprietarul domeniului și administratorul regulilor de trafic sunt aceeași persoană. Se întâmplă că domeniile, dintr-un motiv sau altul, sunt deconectate de la regulile de trafic la nivelul DNS. Pentru a verifica proprietatea și pentru a confirma statutul domeniului, folosim o coadă de cecuri, constând din mai multe servere pentru a stoca coada cecurilor în baza de date relațională și un grup de blocări distribuite pe baza MongoDB.
Pentru a nu supraîncărca serverele cu site-uri de domeniu sau servere DNS de zonă, fiecare verificare ulterioară de confirmare are loc cu un interval de timp în creștere - de la cinci minute la 24 de ore. Controlul statutului domeniului are loc mai des - aproximativ o dată la patru ore în intervale de timp constante. Această abordare poate reduce semnificativ povara inspectorilor de coadă de supraveghere. După confirmarea domeniului, toate funcțiile de bază sunt accesibile administratorului său și pot crea casete.
Pentru a menține o abordare universală și pentru a reduce numărul de erori, am dezvoltat un API de e-mail intern pentru domenii, care pot fi folosite de alte componente ale Yandex pentru a face schimb de informații necesare. De exemplu, API-ul de e-mail public pentru domenii este o astfel de componentă. Apelurile API publice sunt traduse în apelurile universale ale API-ului intern. Orice acțiuni din interfața web a SDA apelează de asemenea metodele API-ului intern.
În funcție de acțiunile cerute, interfața internă pentru apelurile API poate accesa anumite componente Yandex. Principiul de bază în proiectarea noilor funcționalități este de a nu depozita informații pe marginea regulilor de trafic, care sunt deja stocate în altă parte. O excepție se face numai pentru interogările critice pentru timpul de execuție - acestea trebuie să fie stocate în memoria cache.
De exemplu, pentru a crea o nouă căsuță poștală, trebuie să creați un nou utilizator în Passport și apoi să inițializați stocarea de e-mail pentru acest utilizator în E-mail și să configurați noua cutie poștală exact așa cum a ales administratorul domeniului.
Cu o astfel de integrare, timpul de răspuns al serviciilor și prelucrarea eventualelor erori care apar sunt de o importanță deosebită. Practic, există două tipuri de erori: rețea și logică. Pentru completare, să analizăm lista serviciilor și caracteristicile integrării regulilor de trafic cu acestea.
De fapt, aceasta este sursa principală de date pentru regulile de trafic, nu mai puțin importantă decât baza de date și în locurile chiar mai mult. Cu Passport SDA comunică prin interfața API internă prin intermediul protocolului HTTP. Orice eroare la Passport este critică. Dacă pașaportul a trimis o eroare sau comunicarea cu pașaportul a eșuat, transmitem eroarea către utilizator și anulați acțiunile deja efectuate în baza de date sau alte servicii. Astfel, sunt susținute tranzacțiile dintre diferitele servicii integrate: pentru fiecare echipă există un antipod - comanda de anulare a operațiunii.
Acesta este serviciul cheie pe care un administrator de domeniu îl administrează prin SDA. Crearea unei căsuțe poștale necesită o cantitate mare de calcule, astfel încât să apară în fundal. O coadă de operații atomice este creată pentru a finaliza înregistrarea: creați o casetă, aplicați setările de bază specificate pentru domeniu și așa mai departe. Erori de rețea în acest caz nu sunt atât de critice, astfel încât, în caz de probleme, operația este amânată în liniște într-o altă coadă distribuită, operatorii acestei coadă încearcă cu sârguință să ajusteze cutia în termen de 24 de ore de la eșec.
Aproximativ fiecare al treilea domeniu al regulilor de trafic plasează o zonă DNS pe serverele Yandex. Erori de lucru cu backend-ul DNS sunt considerate critice numai în cazul unor defecțiuni de rețea și imposibilitatea completă de a scrie în baza de date. În toate celelalte cazuri, algoritmii care rezolvă problema utilizatorului sunt declanșați.
De exemplu, în momentul delegării domeniului, Yandex copiază unele înregistrări de pe serverul DNS anterior, astfel încât utilizatorul să nu trebuiască să efectueze o operație plictisitoare de mutare precisă a zonei. În acest caz, poate exista o situație în care înregistrarea domeniului rădăcină are tipul CNAME, ceea ce contravine standardului. Un utilizator cu o astfel de înregistrare CNAME nu poate include Yandex.Mail pe domeniul său, astfel că atunci când importați această intrare va fi omisă.
Înregistrarea și logarea
Ca și în orice fermă mare, nu există protocoale nicăieri. SDA menține jurnale detaliate pentru toate interacțiunile cu alte componente ale Yandex. Adesea, aceste jurnale reușesc să găsească problema înainte ca acestea să devină vizibile pentru utilizatori. Pentru a vă asigura că serviciul a lucrat rapid și eficient, urmează un software special pentru monitorizarea jurnalelor de sistem. În cazul accidentelor sau erorilor mari, când timpul de procesare al solicitărilor este semnificativ crescut sau apar erori în răspunsurile, administratorii de sistem observă acest lucru timp de câteva minute și încep să repare în orice moment al zilei sau al nopții. Dar despre următoarea dată.
Vă așteptăm la întrebările dvs.!
Articole similare
-
Utilizarea domeniilor fără cookie-uri pentru componente - cometa
-
Aer condiționat, de lucru în toate anotimpurile, i-cooler - aer condiționat pentru tine!
Trimiteți-le prietenilor: