Hej, Habr. Lige nu er der åbent for tilmelding til et nyt hold i OTUS-kurset . Forud for kursusstart vil jeg dele min egen artikel med dig.
Introduktion
Valget af arkitektonisk stil er en af de grundlæggende tekniske beslutninger, når man bygger et informationssystem. I denne række artikler vil jeg undersøge de mest populære arkitektoniske stilarter for applikationsopbygning og besvare spørgsmålet om, hvornår hvilken arkitektonisk stil er mest foretrukken. Undervejs vil jeg forsøge at føre en logisk tråd, der forklarer udviklingen af arkitektoniske stilarter fra monolitter til mikroservices.
Lidt historie
Hvis du prøver at stille spørgsmålet til udviklerne: "Hvorfor er microservices nødvendige?", så får du de mest forskellige svar. Du vil høre, at microservices forbedrer skalérbarhed, gør koden lettere at forstå, forbedrer fejltolerance, og nogle gange kan man høre, at de tillader at "rydde op i koden". Lad os se tilbage i historien for at forstå, hvilket mål der lå bag fremkomsten af microservices.
Kort sagt, blev microservices i vores nuværende forståelse til på følgende måde: I 2011, mens James Lewis analyserede forskellige virksomheders arbejde, bemærkede han fremkomsten af et nyt mønster kaldet "micro-app", som optimerede SOA med hensyn til hurtigere udrulning af tjenester. Senere, i 2012, blev mønsteret omdøbt til microservice på en arkitekturkonference. Dermed var det oprindelige mål med implementeringen af microservices at forbedre den berygtede time to market.
I "buzz-perioden" var microservices fremtrædende i 2015. Ifølge nogle undersøgelser gik ingen konference uden et indlæg om microservices. Desuden var nogle konferencer udelukkende dedikeret til microservices. I dag starter mange projekter med anvendelse af denne arkitektoniske stil, og hvis projektet indeholder tonsvis af legacy-kode, er der helt sikkert gang i migreringen til microservices.
På trods af alt dette er der stadig et forholdsvis lille antal udviklere, der kan definere begrebet "microservice". Men det vil vi tale om lidt senere…
Monolit
Den arkitektoniske stil, der modsættes microservice-stilen, er monolit (eller "alt i ét"). Det giver nok ikke mening at fortælle, hvad en monolit er, så jeg vil straks liste ulemperne ved denne arkitektoniske stil, som initierede yderligere udvikling af arkitektoniske stilarter: størrelse, sammenhæng, udrulning, skalérbarhed, pålidelighed og stivhed. Nedenfor foreslår jeg at se nærmere på hver af ulemperne.
Størrelse
Monolitten er meget stor. Og den kommunikerer som regel med en meget stor database. Applikationen bliver for stor til, at én udvikler overhovedet kan forstå den. Kun dem, der har brugt meget tid på denne kode, kan arbejde godt med monolitten, mens nybegyndere vil bruge meget tid på at forsøge at forstå monolitten, og det er ikke sikkert, at de lykkes. Normalt er der altid en slags 'senior', der kender monolitten nogenlunde godt, og som holder øje med de nye udviklere i løbet af et år til halvandet. Det er klart, at en sådan senior er det eneste svage led, og hans eller hendes fravær kan føre til monolittens undergang.
Sammenhæng
Monolitten kan beskrives som en "stor klump mudder" (big ball of mud), hvor ændringer kan føre til uforudsigelige konsekvenser. At ændre én ting et sted kan skade monolitten et andet sted (det er den klassiske 'klø øret og *@ det falder af'). Dette skyldes, at komponenterne i monolitten har meget komplekse og, vigtigst af alt, ikke-åbenlyse interrelationer.
Udrulning
Udrulning af monolitten, på grund af de komplekse relationer mellem dens komponenter, er en lang proces med sine egne ritualer. Et sådant ritual er normalt ikke fuldstændig standardiseret og videregives "mund til mund".
Skalering
Modulerne i monolitten kan have konflikte behov for ressourcer, hvorfor det er nødvendigt at søge kompromis fra et hardware-perspektiv. Forestil dig, at din monolit består af tjenester A og B. Tjeneste A kræver meget diskplads, mens tjeneste B kræver meget RAM. I så fald skal maskinen, som monolitten installeres på, enten opfylde kravene fra begge tjenester, eller det bliver nødvendigt at slukke for den ene tjeneste manuelt.
Et andet eksempel (mere klassisk): Tjeneste A er meget mere populær end tjeneste B, så du ønsker, at der er 100 af tjeneste A og 10 af tjeneste B. Igen er der to muligheder: enten udruller vi 100 fuldgyldige monolitter, eller på nogle af dem må vi manuelt slukke for tjenesterne B.
Pålidelighed
Da alle tjenester er samlet, falder alle tjenester samtidigt, hvis monolitten fejler. Faktisk er det måske ikke så skidt, da der i det mindste ikke vil være delvise fejl i et distribueret system. Men på den anden side kan en fejl i funktionaliteten, som 0,001% af brugerne anvender, føre til tab af alle brugere i dit system.
Stivhed
På grund af monolitten er det svært at overgå til nye teknologier. Som følge heraf bliver det en specifik opgave at fastholde den samme senior udvikler. Den valgte teknologistak ved projektets start kan blive en blokade for produktets udvikling.
Konklusion
Næste gang vil vi tale om, hvordan folk har forsøgt at løse de nævnte problemer ved at gå over til komponenter og SOA.
Læs mere:
Kilde: habr.com
