Dit blyk dat die hoogtepunt van hype vir mikrodienste agter die rug is. Ons lees nie meer plasings 'n paar keer per week "Hoe ek my monoliet na 150 dienste verskuif het nie." Nou hoor ek meer gesonde verstand gedagtes: "Ek haat nie die monoliet nie, ek gee net om oor doeltreffendheid." Ons het selfs verskeie migrasies waargeneem . Wanneer jy van een groot toepassing na verskeie kleiner dienste beweeg, sal jy verskeie nuwe probleme moet oplos. Kom ons lys hulle so kort as moontlik.
Omgewing: van basiese chemie tot kwantummeganika
Die opstel van 'n basiese databasis en toepassing met 'n agtergrondproses was 'n redelik eenvoudige proses. Ek publiseer die readme op Github - en dikwels binne 'n uur, 'n paar uur hoogstens, werk alles en begin ek 'n nuwe projek. Byvoeging en uitvoering van kode, ten minste vir die aanvanklike omgewing, word op dag een gedoen. Maar as ons mikrodienste aandurf, skiet die aanvanklike bekendstellingstyd die hoogte in. Ja, nou het ons Docker met orkestrasie en 'n groep K8-masjiene, maar vir 'n beginner programmeerder is dit alles baie meer ingewikkeld. Vir baie juniors is dit 'n las wat werklik 'n onnodige komplikasie is.
Die stelsel is nie maklik om te verstaan nie
Kom ons fokus vir 'n oomblik op ons junior. Met monolitiese toepassings, as 'n fout voorgekom het, was dit maklik om dit op te spoor en onmiddellik oor te gaan na ontfouting. Nou het ons 'n diens wat met 'n ander diens praat wat iets op 'n boodskapbus in tou staan wat 'n ander diens verwerk—en dan is daar 'n fout. Ons moet al hierdie stukke bymekaar sit om uiteindelik uit te vind dat Diens A weergawe 11 loop, en Diens E wag reeds vir weergawe 12. Dit is baie anders as my standaard gekonsolideerde log: om 'n interaktiewe terminaal/ontfouter te gebruik om te loop stap vir stap deur die proses. Ontfouting en begrip het inherent moeiliker geword.
As dit nie ontfout kan word nie, sal ons dit miskien toets
Deurlopende integrasie en deurlopende ontwikkeling word nou alledaags. Die meeste nuwe toepassings wat ek sien skep en laat outomaties toetse met elke nuwe vrystelling uitvoer en vereis dat toetse geneem en hersien word voor registrasie. Dit is wonderlike prosesse wat nie laat vaar moet word nie en was 'n groot verskuiwing vir baie maatskappye. Maar nou, om die diens regtig te toets, moet ek 'n volledige werkende weergawe van my toepassing opstel. Onthou jy daardie nuwe ingenieur met die K8-groep van 150 dienste? Wel, nou sal ons ons CI-stelsel leer hoe om al hierdie stelsels op te roep om te verifieer dat alles regtig werk. Dit is waarskynlik te veel moeite, so ons sal net elke deel in isolasie toets: ek is vol vertroue dat ons spesifikasies goed genoeg is, die API's skoon is, en 'n diensfout is geïsoleer en sal nie ander raak nie.
Alle kompromieë het 'n goeie rede. Reg?
Daar is baie redes om na mikrodienste oor te gaan. Ek het gesien hoe dit gedoen word vir groter buigsaamheid, om spanne te skaal, vir prestasie, om beter volhoubaarheid te bied. Maar in werklikheid het ons dekades in gereedskap en praktyke belê om monoliete te ontwikkel wat voortgaan om te ontwikkel. Ek werk saam met professionele persone in verskillende tegnologieë. Ons praat gewoonlik oor skaal omdat dit die grense van 'n enkele Postgres-databasisnodus raak. Die meeste van die gesprekke gaan oor .
Maar ek stel altyd belang om oor hul argitektuur te leer. In watter stadium van die oorgang na mikrodienste is hulle? Dit is interessant om meer ingenieurs te sien sê hulle is tevrede met hul monolitiese toepassing. Baie mense sal baat by mikrodienste, en die voordele sal swaarder weeg as die bulte in die migrasiepad. Maar persoonlik, gee my asseblief my monolitiese aansoek, 'n plek op die strand - en ek is heeltemal gelukkig.
Bron: will.com