Mikrotjänster

En mikrotjänstarkitektur – en variant av den serviceorienterade arkitekturens strukturstil – är ett arkitektoniskt mönster som arrangerar en applikation som en samling av löst kopplade , finkorniga tjänster som kommunicerar genom lättviktsprotokoll. Ett av dess mål är att team kan utveckla och distribuera sina tjänster oberoende av andra. Detta uppnås genom att minska flera beroenden i kodbasen, vilket gör det möjligt för utvecklare att utveckla sina tjänster med begränsade begränsningar från användarna, och för att ytterligare komplexitet döljs för användarna. Som en följd av detta kan organisationer utveckla mjukvara med snabb tillväxt och storlek, samt att lättare använda off-the-shelf-tjänster. Kommunikationskraven minskar. Dessa fördelar kommer till en kostnad för att upprätthålla frikopplingen. Gränssnitt måste utformas noggrant och behandlas som ett offentligt API . En teknik som används är att ha flera gränssnitt på samma tjänst, eller flera versioner av samma tjänst, för att inte störa befintliga användare av koden.

Introduktion

Det finns ingen enskild definition för mikrotjänster. En konsensussyn har utvecklats över tiden i branschen. Några av de definierande egenskaperna som ofta nämns inkluderar:

  • Tjänster i en mikrotjänstarkitektur är ofta processer som kommunicerar över ett nätverk för att uppfylla ett mål med teknikagnostiska protokoll som HTTP.
  • Tjänsterna är organiserade kring affärsmöjligheter.
  • Tjänster kan implementeras med olika programmeringsspråk , databaser , hård- och mjukvarumiljöer, beroende på vad som passar bäst.
  • Tjänsterna är små i storleken, meddelandefunktioner, avgränsade av sammanhang, autonomt utvecklade, oberoende driftsättningsbara, decentraliserade och byggda och släppta med automatiserade processer .

En mikrotjänst är inte ett lager i en monolitisk applikation (exempelvis webbkontrollern eller backend-for-frontend). Snarare är det en fristående del av affärsfunktionalitet med tydliga gränssnitt, och kan, genom sina egna interna komponenter, implementera en skiktad arkitektur. Ur ett strategiskt perspektiv följer mikrotjänstarkitekturen i huvudsak Unix-filosofin "Gör en sak och gör det bra". Martin Fowler beskriver en mikrotjänstbaserad arkitektur som har följande egenskaper:

Det är vanligt att mikrotjänsters arkitekturer används för molnbaserade applikationer , serverlös datoranvändning och applikationer som använder lättviktscontainrar . Enligt Fowler, på grund av det stora antalet (jämfört med monolitiska applikationsimplementeringar) tjänster, är decentraliserad kontinuerlig leverans och DevOps med holistisk tjänsteövervakning nödvändiga för att effektivt utveckla, underhålla och driva sådana applikationer. En konsekvens av (och skäl för) att följa detta tillvägagångssätt är att de individuella mikrotjänsterna kan skalas individuellt. I det monolitiska tillvägagångssättet skulle en applikation som stöder tre funktioner behöva skalas i sin helhet även om bara en av dessa funktioner hade en resursbegränsning. Med mikrotjänster behöver endast mikrotjänsten som stöder funktionen med resursbegränsningar skalas ut, vilket ger resurs- och kostnadsoptimeringsfördelar.

Historia

Det finns många påståenden om ursprunget till termen mikrotjänster. Medan han var vicepresident för ThoughtWorks 2004, började Fred George arbeta med prototyparkitekturer baserade på vad han kallade "Baysean Principles" uppkallad efter Jeff Bay.

Redan 2005 introducerade Peter Rodgers termen "Micro- Web-Services " under en presentation på Web Services Edge-konferensen. Mot konventionellt tänkande och på höjden av SOAP SOA-arkitekturhypekurvan argumenterade han för " REST -tjänster" och på bild #4 av konferenspresentationen diskuterar han " Mjukvarukomponenter är mikrowebbtjänster". Han fortsätter med att säga "Mikrotjänster är sammansatta med hjälp av Unix-liknande pipelines ( webben möter Unix = sann lös koppling ). Tjänster kan anropa tjänster (+ körtider på flera språk). Komplexa tjänstesammansättningar abstraheras bakom enkla URI - gränssnitt . Alla tjänster, oavsett granularitet, kan exponeras." Han beskrev hur en väldesignad mikrotjänstplattform "tillämpar de underliggande arkitektoniska principerna för webben och REST-tjänsterna tillsammans med Unix-liknande schemaläggning och pipelines för att ge radikal flexibilitet och förbättrad enkelhet i tjänsteorienterade arkitekturer.

Rodgers arbete uppstod 1999 med Dexter-forskningsprojektet vid Hewlett Packard Labs , vars mål var att göra koden mindre skör och göra storskaliga, komplexa mjukvarusystem robusta för förändringar. I slutändan ledde denna forskningsväg till utvecklingen av resursorienterad beräkning (ROC), en generaliserad beräkningsabstraktion där REST är en speciell delmängd.

2007 efterlyste Juval Löwy i sitt skrivande och sitt tal att bygga system där varje klass var en tjänst. Löwy insåg att detta krävde användningen av en teknik som kan stödja sådan granulär användning av tjänster, och han utökade Windows Communication Foundation (WCF) för att göra just det, ta varje klass och behandla den som en tjänst samtidigt som den konventionella programmeringsmodellen av klasser bibehölls.

2005 skrev Alistair Cockburn om Hexagonal architecture (mjukvara) som är ett mjukvarudesignmönster som används tillsammans med mikrotjänsterna. Detta mönster gör designen av mikrotjänsten möjlig eftersom den i lager isolerar affärslogiken från de hjälptjänster som behövs för att distribuera och köra mikrotjänsten helt oberoende av andra.

En workshop av mjukvaruarkitekter som hölls nära Venedig i maj 2011 använde termen "mikroservice" för att beskriva vad deltagarna såg som en vanlig arkitektonisk stil som många av dem nyligen hade utforskat. I maj 2012 beslutade samma grupp om "mikrotjänster" som det lämpligaste namnet. James Lewis presenterade några av dessa idéer som en fallstudie i mars 2012 vid 33rd Degree i Kraków i Microservices - Java, the Unix Way, liksom Fred George ungefär samtidigt. Adrian Cockcroft, tidigare direktör för Cloud Systems på Netflix, beskrev detta tillvägagångssätt som "finkornig SOA", banade väg för stilen på webbskala, liksom många av de andra som nämns i den här artikeln - Joe Walnes, Dan North, Evan Bottcher och Graham Tackley.

Microservices är en specialisering av en implementeringsmetod för tjänsteorienterade arkitekturer (SOA) som används för att bygga flexibla, oberoende driftsättbara programvarusystem . Microservices-metoden är den första realiseringen av SOA som följde introduktionen av DevOps och blir mer populär för att bygga kontinuerligt distribuerade system.

I februari 2020 förutspådde Cloud Microservices Market Research Report att den globala mikroservicearkitekturens storlek kommer att öka med en CAGR på 21,37 % från 2019 till 2026 och nå 3,1 miljarder USD 2026.

Servicegranularitet

Ett nyckelsteg i att definiera en mikrotjänstarkitektur är att ta reda på hur stor en enskild mikrotjänst måste vara. Det finns ingen konsensus eller lackmustest för detta, eftersom det rätta svaret beror på affärs- och organisationskontexten. Till exempel Amazon en tjänsteorienterad arkitektur där tjänsten ofta kartlägger 1:1 med ett team på 3 till 10 ingenjörer. I allmänhet är terminologin som sådan: tjänster som är dedikerade till en enskild uppgift, som att anropa ett visst backend-system eller göra en viss typ av beräkning, kallas atomtjänster . På liknande sätt kallas tjänster som anropar sådana atomtjänster för att konsolidera en produktion, sammansatta tjänster .

Det anses vara dålig praxis att göra tjänsten för liten, eftersom drifttiden och den operativa komplexiteten då kan överväldiga fördelarna med tillvägagångssättet. När saker och ting blir för finkorniga måste alternativa tillvägagångssätt övervägas – som att paketera funktionen som ett bibliotek, flytta funktionen till andra mikrotjänster.

Om den domändrivna designen används för att modellera domänen för vilken systemet byggs, kan en mikrotjänst vara så liten som ett aggregat eller lika stor som en avgränsad kontext.

I granulariteten i diskussionen om mikrotjänster finns det ett spektrum, i ena änden finns anemic Services, som inte har ett stort antal ansvarsområden, och i den andra änden, Modular Monolith, som är stora moduler i ett system.

Fördelar

Fördelarna med att dela upp en applikation till olika mindre tjänster är många:

  • Modularitet : Detta gör applikationen lättare att förstå, utveckla, testa och bli mer motståndskraftig mot arkitekturerosion. Denna fördel argumenteras ofta i jämförelse med komplexiteten hos monolitiska arkitekturer.
  • Skalbarhet : Eftersom mikrotjänster implementeras och distribueras oberoende av varandra, dvs de körs inom oberoende processer, kan de övervakas och skalas oberoende.
  • Integration av heterogena och äldre system : mikrotjänster anses vara ett hållbart sätt att modernisera befintlig monolitisk mjukvaruapplikation. Det finns erfarenhetsrapporter från flera företag som framgångsrikt har ersatt (delar av) sin befintliga programvara med mikrotjänster eller håller på att göra det. Processen för mjukvarumodernisering av äldre applikationer görs med en inkrementell metod.
  • Distribuerad utveckling: den parallelliserar utvecklingen genom att göra det möjligt för små autonoma team att utveckla, distribuera och skala sina respektive tjänster oberoende. Det tillåter också arkitekturen för en enskild tjänst att växa fram genom kontinuerlig refactoring . Mikrotjänstbaserade arkitekturer underlättar kontinuerlig integration , kontinuerlig leverans och driftsättning.

Kritik och oro

Mikroservicemetoden är föremål för kritik för ett antal frågor:

  • Tjänster utgör informationsbarriärer.
  • Samtal mellan tjänster över ett nätverk har en högre kostnad i termer av nätverkslatens och meddelandebehandlingstid än pågående samtal inom en monolitisk serviceprocess.
  • Testning och driftsättning är mer komplicerad.
  • Att flytta ansvar mellan tjänster är svårare. Det kan handla om kommunikation mellan olika team, att skriva om funktionaliteten på ett annat språk eller att passa in i en annan infrastruktur. Mikrotjänster kan dock distribueras oberoende av resten av applikationen, medan team som arbetar med monoliter måste synkroniseras för att distribuera tillsammans.
  • Att se storleken på tjänster som den primära struktureringsmekanismen kan leda till för många tjänster när alternativet med intern modularisering kan leda till en enklare design. Detta kräver förståelse av applikationernas övergripande arkitektur och ömsesidiga beroenden mellan komponenter.
  • Tvåfasiga åtaganden betraktas som ett antimönster i mikrotjänstebaserade arkitekturer eftersom detta resulterar i en tätare koppling av alla deltagare i transaktionen. Emellertid orsakar bristen på denna teknik obekväma danser som måste implementeras av alla transaktionsdeltagare för att upprätthålla datakonsistens.
  • Utveckling och support av många tjänster är mer utmanande om de byggs med olika verktyg och teknologier – detta är särskilt ett problem om ingenjörer ofta flyttar mellan projekt.
  • Protokollet som vanligtvis används med mikrotjänster (HTTP) har utformats för tjänster som riktar sig till allmänheten, och är som sådant olämpligt för fungerande interna mikrotjänster som ofta måste vara oklanderligt tillförlitliga.
  • Även om den inte är specifik för mikrotjänster, använder nedbrytningsmetoden ofta funktionell nedbrytning, som inte hanterar förändringar i kraven samtidigt som tjänsternas komplexitet ökar.
  • Själva konceptet med mikroservice är missvisande eftersom det bara finns tjänster. Det finns ingen bra definition av när en tjänst startar eller slutar vara en mikrotjänst.
  • Dataaggregation. För att få en fullständig bild av ett fungerande system krävs det att man extraherar datamängder från mikrotjänsters förråd och aggregerar dem i ett enda schema. Till exempel för att kunna skapa verksamhetsrapporter som inte är möjliga med hjälp av ett enda microservice repository.

Kognitiv belastning

Arkitekturen introducerar ytterligare komplexitet och nya problem att hantera, såsom nätverkslatens , meddelandeformatdesign , Backup /Availability/Consistency (BAC), lastbalansering och feltolerans . Alla dessa problem måste lösas i stor skala. Komplexiteten i en monolitisk applikation försvinner inte om den återimplementeras som en uppsättning mikrotjänster. En del av komplexiteten översätts till operationell komplexitet. Andra platser där komplexiteten visar sig är ökad nätverkstrafik och resulterar i långsammare prestanda. Dessutom har en applikation som består av ett valfritt antal mikrotjänster ett större antal gränssnittspunkter för att komma åt sitt respektive ekosystem , vilket ökar den arkitektoniska komplexiteten. Olika organiseringsprinciper (såsom HATEOAS , gränssnitts- och datamodelldokumentation inhämtad via Swagger , etc.) har tillämpats för att minska effekten av sådan ytterligare komplexitet.

Teknologier

Datormikrotjänster kan implementeras i olika programmeringsspråk och kan använda olika infrastrukturer. Därför är de viktigaste teknikvalen sättet som mikrotjänster kommunicerar med varandra (synkron, asynkron, UI-integration) och de protokoll som används för kommunikationen (RESTful HTTP, meddelandehantering, GraphQL ... ) . I ett traditionellt system påverkar de flesta teknikval som programmeringsspråket hela systemet. Därför är tillvägagångssättet för att välja teknik ganska annorlunda.

Eclipse Foundation har publicerat en specifikation för utveckling av mikrotjänster, Eclipse MicroProfile.

Servicenät

Se även: Servicenät

I ett servicenät är varje tjänsteinstans ihopparad med en instans av en omvänd proxyserver, kallad tjänsteproxy, sidvagnsproxy eller sidovagn. Tjänsteinstansen och sidovagnsproxyn delar en container, och behållarna hanteras av ett containerorkestreringsverktyg som Kubernetes , Nomad, Docker Swarm eller DC/OS . Tjänstefullmakterna ansvarar för kommunikation med andra tjänsteinstanser och kan stödja funktioner som tjänste(instans)upptäckt, lastbalansering, autentisering och auktorisering, säker kommunikation och annat.

I ett servicenät sägs tjänsteinstanserna och deras sidovagnsproxies utgöra dataplanet, vilket inte bara inkluderar datahantering utan även begäran om bearbetning och svar. Servicenätet inkluderar också ett kontrollplan för att hantera interaktionen mellan tjänster, förmedlad av deras sidovagnsproxies. [ citat behövs ]

En jämförelse av plattformar

Att implementera en mikrotjänstarkitektur är mycket svårt. Det finns många problem (se tabellen nedan) som alla mikrotjänsterarkitekturer måste lösa. Netflix utvecklade ett ramverk för mikrotjänster för att stödja deras interna applikationer och öppnade sedan många delar av det ramverket med öppen källkod. Många av dessa verktyg har populariserats via Spring Framework – de har återimplementerats som Spring-baserade verktyg under paraplyet av Spring Cloud-projektet. Tabellen nedan visar en jämförelse av en implementeringsfunktion från Kubernetes ekosystem med en motsvarighet från Spring Cloud-världen. En anmärkningsvärd aspekt av Spring Cloud-ekosystemet är att de alla är Java-baserade teknologier, medan Kubernetes är en polyglot runtime-plattform.

Microservices oro Spring Cloud och Netflix OSS Kubernetes
Konfigurationshantering: konfiguration för en mikrotjänstapplikation måste externiseras från koden och kunna hämtas via ett enkelt serviceanrop. Spring Config Server, Netflix Archaius stöder båda en Git-repository-baserad plats för konfiguration. Archaius stöder datatypning av konfiguration. Kubernetes ConfigMaps exponerar konfigurationen lagrad i etcd via tjänster. Kubernetes Secrets stöder tjänstebaserad säker distribution och användning av känslig konfigurationsinformation (som lösenord, certifikat, etc.).
Service discovery : underhålla en lista över tjänsteinstanser som är tillgängliga för arbete inom en mikrotjänstdomän. Spring Cloud Eureka tillåter klienter att registrera sig till det, upprätthåller ett hjärtslag med registrerade klienter och mappar tjänstnamn till värdnamn för klienter som söker tjänster efter tjänstnamn. Kubernetes Services tillhandahåller implementeringstidsregistrering av instanser av tjänster som är internt tillgängliga inom klustret. Ingress är en mekanism där en tjänst kan exponeras för klienter utanför klustret.
Lastbalansering: Nyckeln till att skala ett distribuerat system är att kunna köra mer än en instans av en komponent. Belastningen måste sedan fördelas över dessa instanser via en lastbalanserare. Spring Cloud Ribbon ger tjänsteklienter möjlighet att belasta balans mellan instanser av tjänsten. Kubernetes Service ger möjligheten för tjänsten att vara belastningsbalanserad över tjänsteinstanser. Detta är inte motsvarigheten till vad Ribbon tillhandahåller.
API-gateway: Granulariteten hos API:er som tillhandahålls av mikrotjänster är ofta annorlunda än vad en tjänsteklient behöver. API Gateways implementerar fasader och tillhandahåller ytterligare tjänster som proxy och protokollöversättning och andra hanteringsfunktioner. Spring Cloud Zuul tillhandahåller konfigurationsbaserade API-fasader Kubernetes Service och Ingress-resurser, Istio, Ambassador är lösningar som tillhandahåller API-gatewayfunktioner för både nord–syd (trafik till och ut från datacenter) samt öst–väst (trafik över datacenter eller moln eller regioner). Zuul kan också implementeras tillsammans med Kubernetes, vilket ger konfiguration på individuell servicenivå.
Säkerhetsproblem: Många säkerhetsproblem skjuts till API-gatewayimplementeringen. Med distribuerade mikrotjänstapplikationer är det vettigt att inte uppfinna säkerhetshjulet på nytt och möjliggöra policydefinition och implementering i komponenter som delas av alla tjänster. Spring Cloud Security löser många säkerhetsproblem genom Spring Cloud Zuul Kubernetes ekosystem tillhandahåller tjänstenät som Istio, som kan tillhandahålla säkerhet genom sina API-gatewaymekanismer.
Centraliserad loggning: Det är viktigt att ha en centraliserad logginsamlings- och analysinfrastruktur för att hantera en uppsjö av tjänster – av vilka många fungerar på ett distribuerat sätt. ELK Stack ( Elasticsearch , Logstash , Kibana ) EFK Stack ( Elasticsearch , Fluentd , Kibana )
Centraliserade mätetal: Ett centraliserat område där hälsan och prestanda för de enskilda tjänsterna och det övergripande systemet kan övervakas är avgörande för en korrekt verksamhet. Vårskådare & Atlas Heapster, Prometheus och Grafana
Distribuerad spårning: Loggning per process och metrisk övervakning har sin plats, men ingen av dem kan rekonstruera de komplexa vägar som transaktioner tar när de sprider sig över ett distribuerat system. Distribuerad spårning är ett viktigt verktyg för en mikrotjänstplattform. Spring Cloud Sleuth Hawkular, Jaeger
Motståndskraft och feltolerans: Distribuerade system måste kunna dirigera automatiskt runt fel och kunna dirigera förfrågningar till tjänsteinstansen som ger ett optimalt svar. Fjäder Hystrix, Turbin och Ribbon Hälsokontroll, servicenät (exempel: Istio)
Autoskalning och självläkande: Distribuerade system svarar på högre belastning genom att skala horisontellt: plattformen måste upptäcka och automatiskt reagera på sådana förhållanden. Dessutom måste systemet upptäcka fel och försöka starta om automatiskt utan operatörsinmatning. - Hälsokontroll, självläkning och automatisk skalning
Paketering, distribution och schemaläggning: Storskaliga system kräver robust pakethantering och distributionssystem för att hantera rullande eller blågröna distributioner och återställningar om det behövs. En schemaläggare hjälper till att bestämma vilken speciell exekveringsnod en ny uppsättning tjänster kan distribueras till baserat på nuvarande förhållanden. Spring Boot, Apache Maven. Spring Cloud-systemet har inte en riktig schemaläggare. Docker, Rkt, Kubernetes Scheduler & Deployment, Helm
Jobbhantering: schemalagda beräkningar bortkopplade från enskilda användarförfrågningar. Vårsats Kubernetes jobb och schemalagda jobb
Singleton-applikation: begränsa en specifik tjänst att köras som den enda instansen av den tjänsten i hela systemet. Vårmolnkluster Kubernetes Pods

Se även

Vidare läsning

Hämtad från " https://en.wikipedia.org/w/index.php?title=Microservices&oldid=1137915117 "