{"id":38981,"date":"2019-10-31T22:27:10","date_gmt":"2019-10-31T19:27:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury\/"},"modified":"2019-10-31T22:27:10","modified_gmt":"2019-10-31T19:27:10","slug":"servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"Servicii orfane: reversul arhitecturii (micro)serviciilor","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Directorul de operare al portalului Banki.ru, Andrei Nikolsky, a vorbit la conferin\u021ba de anul trecut DevOpsDays Moscova<\/a><\/noindex> despre serviciile orfane: cum s\u0103 identifici o orphan \u00een infrastructur\u0103, de ce sunt proaste serviciile orfane, ce s\u0103 faci cu ele \u0219i ce s\u0103 faci dac\u0103 nimic nu ajut\u0103.<\/p>\n

\u00cen sec\u021biune, versiunea textual\u0103 a raportului. <\/p>\n

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nBun\u0103 ziua, colegi! M\u0103 numesc Andrei, conduc operarea \u00een compania Banki.ru.<\/p>\n

Avem servicii mari, cum ar fi monolitice, avem servicii \u00eentr-o \u00een\u021belegere mai clasic\u0103, avem servicii foarte mici. \u00cen terminologia mea de zi cu zi, spun c\u0103 dac\u0103 un serviciu este simplu \u0219i mic, atunci este un microserviciu, iar dac\u0103 nu este foarte simplu \u0219i nu este mic, atunci este pur \u0219i simplu un serviciu. <\/p>\n

Avantajele serviciilor<\/b><\/h3>\n

\nVoi trece rapid prin avantajele serviciilor. <\/p>\n

\"Servicii
\n
\nPrimul - scalabilitatea. Pute\u021bi face rapid ceva pe serviciu \u0219i s\u0103 \u00eencepe\u021bi \u00een produc\u021bie. A venit traficul, a\u021bi clonat serviciul. A venit din nou trafic, a\u021bi clonat din nou \u0219i tr\u0103i\u021bi cu asta. Este un bonus bun \u0219i, de fapt, c\u00e2nd am \u00eenceput, acesta era considerat cel mai important motiv pentru care facem toate aceste lucruri.<\/p>\n

\"Servicii
\n
\n\u00cen al doilea r\u00e2nd, dezvoltarea izolat\u0103, c\u00e2nd ave\u021bi mai multe echipe de dezvoltare, mai mul\u021bi dezvoltatori diferi\u021bi \u00een fiecare echip\u0103 \u0219i fiecare echip\u0103 lucreaz\u0103 la un serviciu al s\u0103u.<\/p>\n

Exist\u0103 o nuan\u021b\u0103 cu echipele. Dezvoltatorii sunt diferi\u021bi. \u0218i exist\u0103, de exemplu, oameni-z\u0103pad\u0103<\/a><\/noindex>. Am v\u0103zut asta prima dat\u0103 la Maxim Dorofeev. Uneori, oamenii-z\u0103pad\u0103 sunt \u00een unele echipe, iar \u00een altele nu sunt. Acest lucru face ca serviciile utilizate \u00een companie s\u0103 fie pu\u021bin inegale. <\/p>\n

\"Servicii
\n
\nPrivind imaginea: acesta este un bun dezvoltator, are m\u00e2ini mari, poate face multe. Problema principal\u0103 este de unde cresc aceste m\u00e2ini. <\/p>\n

\"Servicii
\n
\nServiciile ofer\u0103 posibilitatea de a folosi diferite limbaje de programare, mai potrivite pentru diferite sarcini. Un serviciu este pe Go, altul pe Erlang, altul pe Ruby, ceva pe PHP, ceva pe Python. \u00cen general, se poate extinde foarte mult. Aici sunt \u0219i nuan\u021be.<\/p>\n

\"Servicii
\n
\nArhitectura orientat\u0103 pe servicii este \u00eenainte de toate despre devops. Asta \u00eenseamn\u0103 c\u0103 dac\u0103 nu ave\u021bi automatizare, nu ave\u021bi un proces de deploy, dac\u0103 configura\u021bi manual, configura\u021biile pot varia de la un instan\u021b\u0103 de serviciu la alta \u0219i trebuie s\u0103 intra\u021bi acolo s\u0103 face\u021bi ceva, atunci sunte\u021bi \u00een iad. <\/p>\n

De exemplu, ave\u021bi 20 de servicii \u0219i trebuie s\u0103 le desf\u0103\u0219ura\u021bi manual, ave\u021bi 20 de console \u0219i ap\u0103sa\u021bi simultan \u201eenter\u201d, ca ni\u0219te ninja. Asta nu este prea bine. <\/p>\n

Dac\u0103 ave\u021bi un serviciu dup\u0103 testare (dac\u0103 exist\u0103 testare, desigur) \u0219i trebuie s\u0103-l mai ajusta\u021bi ca s\u0103 func\u021bioneze \u00een produc\u021bie, am \u0219i pentru voi ve\u0219ti proaste. <\/p>\n

Dac\u0103 depinde\u021bi de servicii specifice de la Amazon \u0219i lucra\u021bi \u00een Rusia, atunci acum dou\u0103 luni ave\u021bi \u0219i voi \u201eTotul \u00een jur arde, sunt bine, totul e grozav.\u201d<\/p>\n

\"Servicii
\n
\nFolosim Ansible pentru automatizarea desf\u0103\u0219ur\u0103rii, Puppet pentru convergen\u021b\u0103, Bamboo pentru automatizarea desf\u0103\u0219ur\u0103rii, Confluence pentru a documenta toate acestea cumva.<\/p>\n

Nu voi detalia acest aspect, deoarece prezentarea este mai degrab\u0103 despre practicile de interac\u021biune, nu despre implementarea tehnic\u0103. <\/p>\n

\"Servicii
\n
\nAm avut, de exemplu, probleme \u00een care Puppet pe server ruleaz\u0103 cu Ruby 2, iar o aplica\u021bie este scris\u0103 pentru Ruby 1.8 \u0219i nu func\u021bioneaz\u0103 \u00eempreun\u0103. Se \u00eent\u00e2mpl\u0103 o mic\u0103 eroare acolo. \u015ei c\u00e2nd trebuie s\u0103 p\u0103stra\u021bi mai multe versiuni de Ruby pe aceea\u0219i ma\u0219in\u0103, \u00een general apar probleme. <\/p>\n

De exemplu, fiecare dezvoltator prime\u0219te o platform\u0103 care are aproape tot ceea ce avem, toate serviciile pe care le putem dezvolta, astfel \u00eenc\u00e2t acesta s\u0103 aib\u0103 un mediu izolat, \u00een care s\u0103-l poat\u0103 distruge \u0219i construi cum dore\u0219te. <\/p>\n

Uneori, este necesar un pachet special compilat cu suport pentru anumite func\u021bionalit\u0103\u021bi. Este destul de strict. Am ascultat o prezentare unde imaginea Docker c\u00e2nt\u0103rea 45 GB. \u00cen Linux, desigur, e mai simplu, acolo totul e mai mic, dar oricum, nu vor fi suficiente resurse. <\/p>\n

\u0218i exist\u0103 dependen\u021be contradictorii, c\u00e2nd o parte a proiectului depinde de o bibliotec\u0103 \u00eentr-o anumit\u0103 versiune, alt\u0103 parte a proiectului depinde de o alt\u0103 versiune \u0219i bibliotecile nu se instaleaz\u0103 \u00eempreun\u0103 deloc. <\/p>\n

\"Servicii
\n
\nAvem site-uri \u0219i servicii pe PHP 5.6, ne e ru\u0219ine pentru ele, dar ce putem face. Aceasta este o platform\u0103 pentru noi. Avem mai multe site-uri \u0219i servicii pe PHP 7, pentru care nu ne e ru\u0219ine. \u0218i fiecare dezvoltator are baza lui, unde se bucur\u0103 c\u0103 poate lucra. <\/p>\n

Dac\u0103 scrie\u021bi \u00een companie \u00eentr-o singur\u0103 limb\u0103, atunci trei ma\u0219ini virtuale per dezvoltator sun\u0103 normal. Dac\u0103 ave\u021bi diferite limbaje de programare, atunci situa\u021bia devine mai complicat\u0103.<\/p>\n

\"Servicii
\n
\nApare site-uri \u0219i servicii pe acest, pe acest, apoi \u00eenc\u0103 o platform\u0103 pentru Go, o platform\u0103 pentru Ruby, \u0219i un Redis pe l\u00e2ng\u0103. \u00cen cele din urm\u0103, totul se transform\u0103 \u00eentr-un mare domeniu de suport, iar tot timpul ceva poate s\u0103 cedeze.<\/p>\n

\"Servicii
\n
\nDe aceea, am \u00eenlocuit avantajele limbajelor de programare cu utilizarea diferitelor framework-uri, deoarece framework-urile PHP sunt destul de variate, fiecare av\u00e2nd capacit\u0103\u021bi diferite, comunit\u0103\u021bi diferite, suport diferit. Astfel, po\u021bi scrie un serviciu astfel \u00eenc\u00e2t s\u0103 ai deja ceva preg\u0103tit pentru el. <\/p>\n

Fiecare serviciu are echipa sa<\/b><\/h3>\n

\n\"Servicii
\n
\nPrincipalul nostru avantaj, care s-a cristalizat de-a lungul anilor, este c\u0103 fiecare serviciu are echipa sa. Acest lucru este convenabil pentru un proiect mare, po\u021bi economisi timp pe documenta\u021bie, iar managerii cunosc bine proiectul lor. <\/p>\n

Sarcinile de suport pot fi delegat cu u\u0219urin\u021b\u0103. De exemplu, dac\u0103 serviciul de asigurare s-a stricat. \u0218i imediat echipa care se ocup\u0103 cu asigur\u0103rile merge s\u0103 repare. <\/p>\n

Func\u021biile noi sunt realizate rapid, deoarece atunci c\u00e2nd ai un anumit serviciu atomic, po\u021bi s\u0103 \u00eencorporezi rapid ceva. <\/p>\n

\u0218i c\u00e2nd \u021bi-ai stricat serviciul, iar asta se \u00eent\u00e2mpl\u0103 inevitabil, nu ai afectat celelalte servicii, \u0219i dezvoltatorii din alte echipe nu vin s\u0103-\u021bi spun\u0103: \u201eOoo, nu f\u0103 a\u0219a\u201d. <\/p>\n

\"Servicii
\n
\nCa \u00eentotdeauna, exist\u0103 nuan\u021be. Avem echipe stabile, managerii sunt adu\u0219i str\u00e2ns de echip\u0103. Exist\u0103 documente clare, managerii monitorizeaz\u0103 totul. Fiecare echip\u0103 are c\u00e2teva servicii \u00eempreun\u0103 cu managerul, \u0219i exist\u0103 un punct specific de competen\u021b\u0103. <\/p>\n

Dac\u0103 echipele sunt flotante (acest lucru este folosit uneori \u0219i la noi), exist\u0103 o metod\u0103 bun\u0103 numit\u0103 \u201ehart\u0103 stea\u201d.<\/p>\n

\"Servicii
\n
\nAi o list\u0103 de servicii \u0219i oameni. Steaua \u00eenseamn\u0103 c\u0103 persoana este expert \u00een acest serviciu, iar culegerea indic\u0103 c\u0103 persoana studiaz\u0103 acest serviciu. Sarcina persoanei este s\u0103 schimbe culegerea cu o stea. Iar dac\u0103 nimic nu este scris \u00een fa\u021ba serviciului, \u00eencep problemele, despre care voi vorbi mai departe. <\/p>\n

Cum apar serviciile orfane?<\/b><\/h3>\n

\n\"Servicii
\n
\nPrimul inconvenient, primul mod de a avea un serviciu orfan \u00een infrastructura ta este prin concedierea angaja\u021bilor. A avut cineva vreodat\u0103 o situa\u021bie \u00een care termenele vin \u00eenainte de a evalua sarcinile? Uneori se \u00eent\u00e2mpl\u0103 ca termenii s\u0103 fie stricte \u0219i s\u0103 nu fie suficient timp pentru documenta\u021bie. \u201eTrebuie s\u0103 pred\u0103m serviciul \u00een produc\u021bie, apoi vom completa detaliile.\u201d <\/p>\n

Dac\u0103 echipa este mic\u0103, poate exista un singur dezvoltator care scrie tot, ceilal\u021bi fiind doar de sprijin. \u201eAm realizat arhitectura principal\u0103, tu scrie interfe\u021bele.\u201d Apoi, \u00eentr-un anumit moment, managerul pleac\u0103. \u0218i \u00een perioada \u00een care managerul s-a dus \u0219i unul nou nu a fost \u00eenc\u0103 numit, dezvoltatorii decid singuri \u00een ce direc\u021bie se \u00eendreapt\u0103 serviciul \u0219i ce se \u00eent\u00e2mpl\u0103. \u0218i cum \u0219tim (s\u0103 ne \u00eentoarcem c\u00e2teva slide-uri \u00eenapoi), \u00een unele echipe exist\u0103 persoane unice, uneori un lider unic. Apoi acesta pleac\u0103 \u0219i ob\u021binem un serviciu orfan. <\/p>\n

\"Servicii
\n
\n\u00centre timp, sarcinile din suport \u0219i din afacere nu dispar nic\u0103ieri, ele se acumuleaz\u0103 \u00een backlog. Dac\u0103 \u00een timpul dezvolt\u0103rii serviciului au existat erori arhitecturale, acestea se acumuleaz\u0103 de asemenea \u00een backlog. Serviciul se degradeaz\u0103 \u00eencet. <\/p>\n

Cum recunoa\u0219tem un orfan?<\/b> <\/h3>\n

\nAceast\u0103 list\u0103 descrie bine situa\u021bia. Cine s-a recunoscut \u00een infrastructura sa?<\/p>\n

\"Servicii
\n
\nDespre solu\u021biile workaround documentate: exist\u0103 un serviciu \u0219i, \u00een general, func\u021bioneaz\u0103, are un manual de dou\u0103 pagini despre cum s\u0103 lucrezi cu el, dar cum func\u021bioneaz\u0103 \u00een interior, nimeni nu \u0219tie. <\/p>\n

Sau, de exemplu, exist\u0103 un scurt\u0103tor de linkuri. La noi, de exemplu, acum sunt utilizate trei scurt\u0103toare de linkuri pentru scopuri diferite \u00een servicii diferite. Acestea sunt consecin\u021bele. <\/p>\n

\"Servicii
\n
\nAcum voi deveni c\u0103pitanul evidentului. Ce trebuie s\u0103 facem? \u00cen primul r\u00e2nd, trebuie s\u0103 pred\u0103m serviciul unui alt manager, unei alte echipe. Dac\u0103 liderul vostru nu a plecat \u00eenc\u0103, atunci \u00een aceast\u0103 alt\u0103 echip\u0103, c\u00e2nd \u00een\u021belege\u021bi c\u0103 serviciul seam\u0103n\u0103 cu un orfan, trebuie s\u0103 include\u021bi pe cineva care \u0219tie m\u0103car ceva despre el. <\/p>\n

Cel mai important lucru: trebuie s\u0103 ave\u021bi proceduri de predare bine definite. \u00cen cazul nostru, eu sunt de obicei cel care urm\u0103re\u0219te acest lucru, pentru c\u0103 am nevoie s\u0103 func\u021bioneze totul. Managerii trebuie s\u0103 aib\u0103 totul predat rapid, iar ce se va \u00eent\u00e2mpla cu el mai t\u00e2rziu nu este at\u00e2t de important pentru ei. <\/p>\n

\"Servicii
\n
\nUrm\u0103toarea modalitate de a face o aplica\u021bie \u201eS\u0103 facem externalizare, va fi mai rapid, iar apoi o vom preda echipei\u201d. Este clar c\u0103 to\u021bi au planuri \u00een echip\u0103, o ordine. De multe ori, clientul de afaceri crede c\u0103 un externalizator va face totul la fel ca departamentul tehnic din companie. Cu toate acestea, motiva\u021biile lor sunt diferite. La externalizare pot exista solu\u021bii tehnologice bizare \u0219i algoritmi neobi\u0219nui\u021bi.<\/p>\n

\"Servicii
\n
\nDe exemplu, am avut un serviciu \u00een care Sphinx se g\u0103sea \u00een locuri nea\u0219teptate. Voi povesti mai t\u00e2rziu ce a trebuit s\u0103 facem. <\/p>\n

Externalizatorii au uneori framework-uri proprii. Este pur \u0219i simplu PHP brut cu copiat \u0219i lipit din proiectul anterior, unde po\u021bi g\u0103si de toate. Costuri mari \u00een scripturile de deploy, c\u00e2nd trebuie s\u0103 schimbi c\u00e2teva linii dintr-un fi\u0219ier folosind scripturi Bash complicate, aceste scripturi de deploy fiind apelate de un alt script. \u00cen final, schimbi sistemul de deploy, alegi ceva diferit, \u0219i hop, serviciul t\u0103u nu mai func\u021bioneaz\u0103. Pentru c\u0103 trebuiau ad\u0103ugate \u00eenc\u0103 8 linkuri \u00eentre diferite foldere. Sau se poate \u00eent\u00e2mpla c\u0103 o mie de \u00eenregistr\u0103ri func\u021bioneaz\u0103, iar o sut\u0103 de mii deja nu. <\/p>\n

Voi continua s\u0103 coordonez. Acceptarea serviciului din externalizare este o procedur\u0103 obligatorie. A avut cineva experien\u021ba \u00een care un serviciu din externalizare ajunge, dar nu este acceptat nic\u0103ieri? Nu este at\u00e2t de popular, desigur, ca aplica\u021bia orphan, dar totu\u0219i. <\/p>\n

\"Servicii
\n
\nServiciul trebuie verificat, serviciul trebuie revizuit, trebuie schimbate parolele. Am avut un caz c\u00e2nd ne-a fost oferit un serviciu, acolo adminul era \u00abif login == 'admin' && password == 'admin'...\u00bb, era scris direct \u00een cod. St\u0103m \u0219i ne g\u00e2ndim, iar asta este scris de oameni \u00een 2018?<\/p>\n

Testarea capacit\u0103\u021bii de stocare este, de asemenea, o chestiune necesar\u0103. Trebuie s\u0103 vezi ce se va \u00eent\u00e2mpla cu o sut\u0103 de mii de \u00eenregistr\u0103ri, \u00eenainte de a lansa acest serviciu \u00een produc\u021bie. <\/p>\n

\"Servicii
\n
\nNu ar trebui s\u0103-\u021bi fie ru\u0219ine s\u0103 trimi\u021bi serviciul pentru \u00eembun\u0103t\u0103\u021biri. C\u00e2nd spui: \u201eNu vom accepta acest serviciu, avem 20 de sarcini, face\u021bi-le, apoi accept\u0103m\u201d, este normal. Con\u0219tiin\u021ba nu ar trebui s\u0103 te fr\u0103m\u00e2nte c\u0103 pui managerul \u00eentr-o situa\u021bie nepl\u0103cut\u0103 sau c\u0103 afacerea va cheltui bani. Apoi, afacerea va cheltui mai mult.<\/p>\n

Am avut un caz c\u00e2nd am decis s\u0103 facem un proiect pilot la externalizare.<\/p>\n

\"Servicii
\n
\nA fost predat la timp, iar acesta a fost singurul criteriu de calitate. Prin urmare, s-a realizat un alt proiect pilot, care nu mai era chiar un pilot. Aceste servicii au fost acceptate, au fost date administrativ, uite codul vostru, uite echipa, uite managerul vostru. Serviciile au \u00eenceput deja s\u0103 genereze profit. Cu toate acestea, ele au r\u0103mas \u00een continuare orfane, nimeni nu \u00een\u021belege cum func\u021bioneaz\u0103, iar managerii se str\u0103duiesc s\u0103 se dezic\u0103 de sarcinile lor. <\/p>\n

\"Servicii
\n
\nExist\u0103 un alt concept excelent \u2014 dezvoltarea de tip partizan. C\u00e2nd un anumit departament, de regul\u0103, departamentul de marketing, dore\u0219te s\u0103 testeze o ipotez\u0103 \u0219i comand\u0103 un serviciu complet \u00een externalizare. \u00cencep s\u0103 curg\u0103 trafic pe el, \u00eenchid documentele, semneaz\u0103 actele cu contractorul, intr\u0103 \u00een exploatare \u0219i spun: \u201eB\u0103ie\u021bi, avem un serviciu aici, pe el deja exist\u0103 trafic, ne aduce bani, haide\u021bi s\u0103-l accept\u0103m!\u201d. Noi suntem: \u201eWow, cum a\u0219a?\u201d.<\/p>\n

\"Servicii
\n
\n\u0218i \u00eenc\u0103 un mod de a ob\u021bine un serviciu-orfan: c\u00e2nd o echip\u0103 se afl\u0103 brusc suprasolicitat\u0103, conducerea spune: \u201eHai s\u0103 transfer\u0103m serviciul acestei echipe c\u0103tre o alt\u0103 echip\u0103, care are o \u00eenc\u0103rcare mai mic\u0103\u201d. Apoi \u00eel transfer\u0103m unei a treia echipe \u0219i schimb\u0103m managerul. \u0218i, \u00een final, avem din nou un orfan.<\/p>\n

Care este problema cu orfanii?<\/b><\/h3>\n

\n\"Servicii
\n
\nCine nu \u0219tie, acesta este nava liniar\u0103 Wasa, ridicat\u0103 \u00een Suedia, celebr\u0103 pentru faptul c\u0103 s-a scufundat la numai 5 minute dup\u0103 lansarea pe ap\u0103. \u0218i regele Suediei, de altfel, nu a pedepsit pe nimeni pentru asta. A fost construit\u0103 de dou\u0103 genera\u021bii de ingineri care nu \u0219tiau s\u0103 construiasc\u0103 astfel de nave. Efectul este previzibil.<\/p>\n

Nava ar fi putut s\u0103 se scufunde, de altfel, mult mai r\u0103u, de exemplu, c\u00e2nd la bord se \u00eendrepta regele undeva \u00eentr-o furtun\u0103. Dar, \u00een acest fel, s-a scufundat imediat, conform agilit\u0103\u021bii, asta este bine \u2014 e\u0219ec devreme. <\/p>\n

Dac\u0103 am e\u0219uat devreme, de obicei nu sunt probleme. De exemplu, la recep\u021bie, am trimis-o pentru refacere. Dar dac\u0103 am e\u0219uat deja \u00een produc\u021bie, c\u00e2nd s-au investit bani, atunci pot ap\u0103rea probleme. Consecin\u021bele, a\u0219a cum le numesc \u00een afaceri.<\/p>\n

Ce este periculos \u00een cazul serviciilor-orfane:<\/p>\n