Se pare că vârful hype-ului pentru microservicii este în urmă. Nu mai citim postări de mai multe ori pe săptămână „Cum mi-am mutat monolitul la 150 de servicii”. Acum aud mai multe gânduri de bun simț: „Nu urăsc monolitul, îmi pasă doar de eficiență”. Am observat chiar mai multe migrații . Când treceți de la o aplicație mare la mai multe servicii mai mici, va trebui să rezolvați câteva probleme noi. Să le enumerăm cât mai pe scurt posibil.
Cadre: de la chimia de bază la mecanica cuantică
Configurarea unei baze de date de bază și a unei aplicații cu un proces de fundal a fost un proces destul de simplu. Public readme-ul pe Github - și adesea într-o oră, cel mult câteva ore, totul funcționează și încep un nou proiect. Adăugarea și rularea codului, cel puțin pentru mediul inițial, se face în prima zi. Dar dacă ne aventurăm în microservicii, timpul inițial de lansare crește vertiginos. Da, acum avem Docker cu orchestrare și un cluster de mașini K8, dar pentru un programator începător toate acestea sunt mult mai complicate. Pentru mulți juniori, aceasta este o povară care este cu adevărat o complicație inutilă.
Sistemul nu este ușor de înțeles
Să ne concentrăm pentru un moment pe juniorul nostru. Cu aplicațiile monolitice, dacă a apărut o eroare, era ușor să o urmăriți și să treceți imediat la depanare. Acum avem un serviciu care vorbește cu un alt serviciu care pune ceva în coadă pe o magistrală de mesaje care procesează un alt serviciu – și apoi apare o eroare. Trebuie să punem toate aceste piese împreună pentru a afla în cele din urmă că Service A rulează versiunea 11, iar Service E deja așteaptă versiunea 12. Acesta este foarte diferit de jurnalul meu consolidat standard: trebuie să folosesc un terminal/depanator interactiv pentru a merge. prin proces pas cu pas. Depanarea și înțelegerea au devenit în mod inerent mai dificile.
Dacă nu poate fi depanat, poate le vom testa
Integrarea continuă și dezvoltarea continuă devin acum banale. Majoritatea aplicațiilor noi pe care le văd creează și rulează automat teste cu fiecare nouă lansare și necesită ca teste să fie efectuate și revizuite înainte de înregistrare. Acestea sunt procese grozave care nu ar trebui abandonate și au reprezentat o schimbare majoră pentru multe companii. Dar acum, pentru a testa cu adevărat serviciul, trebuie să scot o versiune completă funcțională a aplicației mele. Îți amintești acel nou inginer cu grupul K8 de 150 de servicii? Ei bine, acum vom învăța sistemul nostru CI cum să afișeze toate aceste sisteme pentru a verifica dacă totul funcționează cu adevărat. Acesta este probabil prea mult efort, așa că vom testa doar fiecare parte izolat: sunt încrezător că specificațiile noastre sunt suficient de bune, API-urile sunt curate și o defecțiune a serviciului este izolată și nu le va afecta pe altele.
Toate compromisurile au un motiv întemeiat. Dreapta?
Există multe motive pentru a trece la microservicii. Am văzut acest lucru făcut pentru o mai mare flexibilitate, pentru scalarea echipelor, pentru performanță, pentru a oferi o durabilitate mai bună. Dar, în realitate, am investit zeci de ani în instrumente și practici pentru a dezvolta monoliți care continuă să evolueze. Lucrez cu profesioniști în diferite tehnologii. De obicei vorbim despre scalare, deoarece acestea intră în limitele unui singur nod al bazei de date Postgres. Majoritatea conversațiilor sunt despre .
Dar sunt mereu interesat să aflu despre arhitectura lor. În ce stadiu al tranziției la microservicii se află? Este interesant să vezi mai mulți ingineri spunând că sunt mulțumiți de aplicația lor monolitică. Mulți oameni vor beneficia de microservicii, iar beneficiile vor depăși denivelările din calea de migrare. Dar personal, vă rog să-mi dați aplicația mea monolitică, un loc pe plajă - și sunt complet fericit.
Sursa: www.habr.com