Čini se da je vrhunac hypea za mikroservise iza nas. Više ne čitamo postove nekoliko puta tjedno "Kako sam premjestio svoj monolit na 150 usluga." Sada čujem više zdravorazumskih misli: "Ne mrzim monolit, samo mi je stalo do učinkovitosti." Čak smo primijetili nekoliko migracija . Prilikom prelaska s jedne velike aplikacije na više manjih usluga, morat ćete riješiti nekoliko novih problema. Nabrojimo ih što je moguće kraće.
Mjesto radnje: od temeljne kemije do kvantne mehanike
Postavljanje osnovne baze podataka i aplikacije s pozadinskim procesom bio je prilično jednostavan proces. Objavim readme na Githubu - i često nakon sat vremena, najviše par sati, sve radi i krenem u novi projekt. Dodavanje i pokretanje koda, barem za početno okruženje, obavlja se prvog dana. Ali ako se odvažimo na mikroservise, početno vrijeme pokretanja vrtoglavo raste. Da, sada imamo Docker s orkestracijom i klasterom K8 strojeva, ali za programera početnika sve je to puno kompliciranije. Za mnoge juniore to je teret koji je uistinu nepotrebna komplikacija.
Sustav nije lako razumjeti
Usredotočimo se na trenutak na našeg juniora. S monolitnim aplikacijama, ako se dogodi pogreška, bilo ju je lako pronaći i odmah prijeći na otklanjanje pogrešaka. Sada imamo uslugu koja razgovara s drugom uslugom koja nešto stavlja u red čekanja na sabirnici poruka koja obrađuje drugu uslugu - i tada dolazi do pogreške. Moramo sastaviti sve ove dijelove da bismo na kraju saznali da usluga A koristi verziju 11, a usluga E već čeka verziju 12. Ovo se jako razlikuje od mog standardnog konsolidiranog dnevnika: za hodanje treba koristiti interaktivni terminal/debuger kroz proces korak po korak. Otklanjanje pogrešaka i razumijevanje su inherentno postali teži.
Ako se ne može otkloniti pogreška, možda ćemo ih testirati
Kontinuirana integracija i kontinuirani razvoj sada postaju uobičajeni. Većina novih aplikacija koje vidim automatski stvaraju i pokreću testove sa svakim novim izdanjem i zahtijevaju provođenje i pregled testova prije registracije. To su sjajni procesi od kojih se ne smije odustati i koji su veliki pomak za mnoge tvrtke. Ali sada, kako bih stvarno testirao uslugu, moram pokrenuti punu radnu verziju svoje aplikacije. Sjećate se onog novog inženjera s K8 klasterom od 150 usluga? Pa, sada ćemo naučiti naš CI sustav kako pokrenuti sve te sustave kako bismo provjerili da sve stvarno radi. Ovo je vjerojatno previše truda, pa ćemo samo testirati svaki dio zasebno: uvjeren sam da su naše specifikacije dovoljno dobre, da su API-ji čisti, a kvar usluge izoliran je i neće utjecati na druge.
Svi kompromisi imaju dobar razlog. Pravo?
Mnogo je razloga za prelazak na mikroservise. Vidio sam da je to učinjeno za veću fleksibilnost, za skaliranje timova, za izvedbu, kako bi se osigurala bolja održivost. Ali u stvarnosti smo uložili desetljeća u alate i prakse za razvoj monolita koji se nastavljaju razvijati. Radim s profesionalcima u različitim tehnologijama. Obično govorimo o skaliranju jer nailazi na ograničenja jednog čvora Postgres baze podataka. Većina razgovora je o .
Ali uvijek sam zainteresiran za učenje o njihovoj arhitekturi. U kojoj su fazi prelaska na mikroservise? Zanimljivo je vidjeti više inženjera koji govore da su zadovoljni svojom monolitnom primjenom. Mnogi će ljudi imati koristi od mikrousluga, a koristi će nadmašiti neravnine na putu migracije. Ali osobno, dajte mi moju monolitnu aplikaciju, mjesto na plaži - i ja sam potpuno sretan.
Izvor: www.habr.com