Mikroservicearkitektur

Mikrotjänstarkitektur  är en variant av tjänsteorienterad mjukvaruarkitektur som syftar till att interagera så små som möjligt, löst kopplade och lätt modifierade moduler - mikrotjänster , som fick stor spridning i mitten av 2010-talet i samband med utvecklingen av agila utvecklingsmetoder och DevOps [1] [2 ] [3] .

Medan moduler i traditionella tjänsteorienterade arkitekturer kan vara ganska komplexa programvarusystem i sig själva, och interaktion mellan dem bygger ofta på standardiserade tungviktsprotokoll (som SOAP , XML-RPC ), i en mikrotjänstarkitektur byggs system av komponenter som presterar relativt elementära funktioner och interagerar med hjälp av kostnadseffektiva nätverkskommunikationsprotokoll ( REST -stil med till exempel JSON , Protocol Buffers , Thrift ). Genom att öka modulernas granularitet syftar arkitekturen till att minska graden av engagemang och öka anslutningsmöjligheterna ., vilket gör det lättare att lägga till och ändra funktioner i systemet när som helst [4] .

Egenskaper

Egenskaper specifika för mikrotjänstarkitektur [1] :

Filosofin för mikrotjänster kopierar faktiskt Unix-filosofin att varje program ska "göra en sak och göra det bra" och interagera med andra program på enkla sätt: mikrotjänster är minimala och dedikerade till en enda funktion. De viktigaste förändringarna i detta avseende åläggs organisationskulturen, som bör inkludera automatisering av utveckling och testning, såväl som designkulturen, som krävs för att lösa tidigare fel, uteslutande av äldre kod, om möjligt (mikrotjänster ersätts ofta helt, eftersom deras funktioner är elementära).

Den mest populära miljön för att köra mikrotjänster är containeriserade applikationshanteringssystem (som Kubernetes och dess tillägg OpenShift och CloudFoundry , Docker Swarm , Apache Mesos ), i vilket fall var och en av mikrotjänsterna vanligtvis är isolerade i en separata behållare eller små gruppbehållare, tillgängliga över nätverket för andra mikrotjänster och externa konsumenter, och hanteras av en orkestreringsmiljö som ger feltolerans och lastbalansering. En typisk praxis är att inkludera ett kontinuerligt integrationssystem i runtime-loopen för att automatisera uppdateringen och distributionen av mikrotjänster.

Historik

Även om termen "mikrotjänster" har funnits sedan mitten av 2000-talet, går konceptets ursprung tillbaka till den årliga Software Architects Workshop i Venedig 2011. Under 2012 presenterades mikrotjänster på 33d Degree-konferensen i Krakow, och det fanns också ett antal publikationer om "granulär SOA", som beskriver mikroservicemetoden. Under 2012-2014 tillkännagavs introduktionen av mikrotjänster inom deras egen mjukvaruutveckling av specialister från företag som Amazon , Netflix , Twitter , sedan 2015 har böcker om mikrotjänstarkitektur regelbundet publicerats i ledande förlag, flera regelbundna konferenser hålls helt och hållet ägnas åt mikrotjänster.

Kritik

Arkitekturen har ständigt kritiserats från ögonblicket av dess bildande, bland de nya problemen som uppstår under dess implementering noteras:

Anteckningar

  1. 12 Martin Fowler . mikrotjänster . martinfowler.com (10 mars 2014). Hämtad 29 juni 2016. Arkiverad från originalet 14 februari 2018.
  2. Balalaie, A.; Heydarnoori, A.; Jamshidi, P. Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture   // IEEE Software : journal. - 2016. - 1 maj ( vol. 33 , nr 3 ). - S. 42-52 . — ISSN 0740-7459 . - doi : 10.1109/MS.2016.64 .
  3. Kontinuerlig utplacering: Strategier . Hämtad 7 oktober 2016. Arkiverad från originalet 9 oktober 2016.
  4. Oliver Wolf. Introduktion till mikrotjänster . Hämtad 29 juni 2016. Arkiverad från originalet 11 juni 2016.
  5. 12 jan Stenberg . Erfarenheter från att misslyckas med Microservices (11 augusti 2014). Hämtad 29 juni 2016. Arkiverad från originalet 3 mars 2016.

Litteratur