Nul
Martin Fowler.
(Billede: O ‘ Reilly OSCON 2015)
“Hvis du prøver at tænke over din software-system, og hvad er dens arkitektur,” forklarede Martin Fowler, software, design, konsulent, er krediteret med at skabe de fleste af microservices ideelle, “den første ting du skal gøre er at finde ud af, ‘Hvad er vigtigt? Hvad gør vi, som den tekniske ledelse af et projekt, anser for at være de mest vigtige ting i det? . . . Hvad er det ting, i den kode base, som jeg er nødt til at holde på toppen af mit hoved, når jeg arbejder på det?'”
Fowler, der taler til en O ‘ Reilly konference i 2015, var at definere “arkitektur”, del af “microservices arkitektur” i et forsøg på at gøre det lettere for sig selv at definere den forreste del af denne sætning. Selv for sin skaber, som stadig er den hårde del.
Hvad er top-of-mind for microservices arkitekter?
Der er mange fortolkninger af microservices, ligesom der er mange retninger, at “impressionisme” kan tage i maleriet. Hvad disse fortolkninger har en fælles forståelse af software, som udskiftelige dele, snarere end samlet helheder. Hvis du var til at acceptere en sådan forståelse af dig selv, i enhver form, at det kan tage, kan du finde dig selv at tænke på en af følgende måder:
Snarere end at fortsætte med at opbygge din centrale IT-funktioner som kolossale applikationer, som du har for at opgradere hvert år i massiv, exodus-lignende omvæltninger (stor nok til at retfærdiggøre jeres indsats, lille nok til fortsat at være muligt), skal du tænke på din virksomheds software i form af sin afmonterede dele. Et lille team kan være ansvarlig for vedligeholdelse, vedligeholdelse og udvikling af en eller flere dele. Den produktion cyklus for at opgradere eller, når det er nødvendigt, at udskifte hver del kan være meget kortere og lettere at fremskynde. Endnu udviklingen af programmet, de i fællesskab udgør, kan faktisk fortsætte i samme tempo-ikke nødvendigvis hurtigere, bare i mindre trin, der kan opnås med en mindre indsats, og (forhåbentlig) mindre bekostelig.
Hvorfor overhovedet gider med microservices?
Fordelene ved microservices arkitektur er ikke selvforklarende. Måske har du haft et familiemedlem, der har længtes efter evne, midler eller tid til at konstruere et helt landskab ud af Lego, og bemærk, åh please, vil du ikke lade hende? Udover at have det sjovt, er der andre fordele ved at microservices i en real-verden, “produktion” IT-miljø, måske dine egne? For nu er det, svaret-som svar på den appel om en milliard Legos — lyder som en forælder stå sit barn for tid: “Måske. Vi vil se.”
Også: 8 måder at gøre sikker på, at du virkelig har brug for microservices
Grunden microservices arkitektur bør være af interesse for dig alligevel, selvom du ikke er en software udvikler eller IT-operatøren, er fordi den befinder sig i centrum af de vigtigste globale debat, der påvirker IT-afdelinger i dag: Hvad er den mest omkostningseffektive og praktisk måde for en organisation at implementere sine programmer til sine brugere?
Du har set, hvor denne debat i gang. Du ved, hvordan offentlige cloud-infrastruktur, der virker, i det mindste generelt. Du kan have lejet en virtuel server selv fra en offentlig cloud-udbyder, såsom Microsoft, Amazon eller Google. Der kan stadig være fornuftigt, for at køre en hjemmeside på en Apache-eller NGINX server er installeret på en virtuel maskine (VM). Men hvis dit job indeholder håndtering af en software-platform for din produktion, design, forskning, eller marketing afdeling, du ved, den har brug for mere end én processor. Leasing som mange VMs, som du har brug for processorer, der ikke er omkostningseffektiv.
Containerization giver en løsning på dette dilemma, men du har set, at der allerede for. Du ved, det er muligt at lave et program, så det kører på et cluster af servere. Og du har måske kendt, eller lige har lært om, serverless deployment modeller. Serverless, der gør det muligt for din organisation til at betale for den service din ansøgning, snarere end den infrastruktur, der understøtter det.
Men på et tidspunkt ned af vejen, skal det i dag eller tre år fra nu, vil det komme tidspunkt for din organisation til at designe nye og yderst funktionelle programmer specifikt til, og sandsynligvis inden for disse nye modeller. Hvad er det design pattern, at ansøgningen bør tage, og skal din IT-arbejdskraft være uddannet til at arbejde med det lige nu?
Microservices arkitektur kan ikke helt være fyldestgørende svar endnu. Men det er stille alle de rigtige spørgsmål på det rigtige tidspunkt.
Hvad betyder en microservice gøre?
Udvikling af Software emner er ofte abstrakt, hvilket gør det svært at sælge til et generelt publikum uden først at concocting en attraktiv metafor. En populær bog om microservices arkitektur fra en stor udgiver behandlet læsere, at en 62-side optakt før nærmer sig det enkle spørgsmål om, hvad en microservice er. Og så er bogen fortsatte med næsten en undskyldning for, hvorfor det er så svært at forklare.
Snarere end at undskylde her, lad os give det et skud.
Gøre én ting godt
Antag, at du har en e-handel. En funktion inden for denne ansøgning, kan være at undersøge de elementer, der i kundens indkøbskurv, og opdatere deres profiler med de nuværende priser og forsendelse af data, især for de kunder, der har tendens til at opbygge lagre af elementer i deres vogne, og foretage indkøb, når de har lyst til det. En opdatering rutine som denne ville sandsynligvis allerede har været udtrykt som en genbrugelig kode modul.
En microservice, der udfører funktionen af det genanvendelige modul kan være et separat program, skrevet i samme sprog som resten af programmet eller en helt anden. Det er ikke tænkt som en del af ansøgningen, eller den er installeret med det samme server eller virtuel maskine. I stedet, det er bevaret som en separat enhed (Docker, der er en separat beholder) og udløst gennem nogle net-drevet mekanisme, såsom almindelig HTTP.
Også: Sådan planlægger du en microservice gennemførelse TechRepublic
På denne måde, microservice bliver en slags mønster for funktionalitet. Den orchestrator kan ikke engang kalde et eksempel på dette mønster i eksistens, indtil det er absolut nødvendigt, selv om en sådan strategi kan indføre ventetid. Helst med en standard antallet af tilfælde er sat til at gå på efterspørgslen. Når der bruger efterspørgslen stiger over et bestemt niveau, orchestrator kan vælge at kopiere microservices, ringer mange flere tilfælde til at være.
I retning af en mere konkret definition for microservices
Det er den uofficielle, tech-journalist definition af “microservices.” Den mest betroede formel definition blandt softwareudviklere faktisk stater, helt eksplicit, at det ikke bør behandles som en formel definition. Martin Fowler og James Lewis avancerede forestillingen om, at microservices:
Repræsentere business-processer, der enkeltvis Er beregnet til at køre sammen som en suite Er designet til at blive implementeret automaticallyCommunicate med hinanden med en “letvægts-mekanisme”, sådan som HTTP-for synkron operationer (der finder sted i rækkefølge), eller en rimeligt let message queue såsom APMQ for asynkrone operationer (der kan finde sted i parallel) Kan ikke nødvendigvis bruge de samme programmeringssprog eller rammer, som er en anden, for at arbejde sammen
Josh Evans var en ledende ingeniør med Netflix, den organisation, der har været pioner i udformningen og gennemførelsen af microservices i produktion. Som vidne til fødslen af den model, og nu er en ledende direktør af data service engineering på GitHub, Evans tilbudt nogle ekstra elementer til Fowler og Lewis’ model, under en præsentation til en developer’ s conference i slutningen af 2016:
En microservice kræver minimal, og helst ikke, koordinering med andre former for kode til komponenter, for at være helt funktionel. Det er, at det skal være selvkørende, kan bestemme dens formål i det øjeblik, det er indsat (“instantieres”). Snarere end at kopiere en hel server til at tilføje strøm til en ansøgning, en orchestrator bør være i stand til at instantiere så mange kopier af et microservice som applikation kan kræve, (“skalering ud”). Hvad mere er, flere sideløbende kører forekomster af samme microservice kan have forskellige funktioner, afhængigt af de data, de blev givet eller spidse til, eller de databaser, som de var forbundet. Så lidt manuel overvågning skal investeres i microservices miljøer som muligt, især da orchestrator kan gives rettigheder til, hvordan skala tilfælde ud, og hvor, hvilket resulterer i et system, hvis form og omfang på én gang kan være lidt uvant at den menneskelige observatører.
Også: Microservices og beholdere i service masker betyde mindre kaos
(Billede: QCon San Francisco 2016)
“Gå tilbage til dette tema i biologi, kan du tænke på microservices organer i et orgel,” forklarer Evans. “Disse systemer kommer sammen for at danne den samlede organisme” til At hjælpe med at gøre sin pointe, viste han sit publikum en animeret diagram af Netflix’ microservices organisme, som omfatter virksomhedens tidligere og mere traditionelle design, men var først og fremmest designet fra bunden til microservices. En service, der fungerer som proxy foran døren til ansøgningen. Det forsendelser anmodninger gennem en routing-lag (som Netflix kalder “Zuul”), som ikke bare planlægge en enkelt destination for anmodningen, men en hel række af tjenester, der er nødvendige for at opfylde dette krav. Routing lag ved, hvilken service, og i hvilken rækkefølge, vil opfylde efterspørgslen, og det er ikke alle anmodninger bliver nødt til at krydse den fulde dybde af systemet.
(Billede: Josh Evans, Netflix)
Twist i centrum af dette diagram, som et møl, der vandrede ind i et edderkoppespind, der repræsenterer API — den fælles komponent, som kommunikationen finder sted. Bemærk microservices ikke hver har deres egne Api ‘ er; i stedet stole på en anden tjeneste til at give meddelelse.
Dette er, hvad en forsætlig microservices arkitekturen ser ud. Det kunne se ud til at omfatte forskellige typer af esoterics med, hvor software-udviklere og politiske filosoffer, som elsker at spille. Men her er grunden til alt dette spørgsmål: Når en organisation forpligter sig til en fuld microservices arkitektur for sin DET, som Netflix har, er det ikke længere konstruerer sin ansøgning i versioner eller iscenesat udgivelser eller semi-årlige opdateringer. Det udvikler sig mere kontinuerligt, økologisk, og i Netflix’ gælder især, mere let.
Også: Microservices og invasionen af identitet enheder
Måske er der ingen anden virksomhed i verden, der har mandat af Netflix: At levere millioner af samtidige, high-definition, high-fidelity video-streams gennem de mest lunefulde system menneskeheden har der nogensinde er udtænkt, internettet. Så Netflix oplevelser vil simpelthen ikke omsætte for de fleste organisationer, medmindre de ville pleje at overgangen væk fra, siger, finansielle tjenesteydelser eller lægemidler og komme ind til streaming-medie levering. Netflix’ udvikling mønstre kan altid kun anvendelse på Netflix.
Endnu i søgen efter fællestræk — for nogen fragment af Netflix-oplevelse, der kan gælde for virksomheder i stor-der er visse aspekter af det mere komplekse, mere formelle definition af microservices, der synes at være mindre esoteriske og mere grundlæggende:
Distribution
I et distribueret software arkitektur, der omfatter en række servere, eller endda platforme samtidigt med, at placeringen af en funktion, der er angivet med en form for adresse, der kan løses gennem et netværk. En web-service, som du kan være bekendt, sådan en tjeneste, som bruger HTTP-for at løse denne adresse. En microservice er et trin videre i at træne med udviklingen. Ved design, er det ikke sammen med de andre genanvendelige komponenter, at det vil være at gøre brug af (“tidskrævende” i nogle udviklere’ lingo) i samme organ af kode. Så det har kontakt med de andre komponenter i sit netværk eller i dens domæne (som, hvis de er udformet, som den er tiltænkt, vil også være microservices) ved hjælp af samme metode.
Synlighed
Hvad mere er, hver microservice bør være i stand til at gøre sig selv synlig ved den proces, der er ansvarlig for koordinering, planlægning og/eller iscenesætte microservices. Ved “tilgængelig”, mener jeg, at orchestrator har et middel til rådighed, for at løse placering af en anmodning om microservice og til at komme i kontakt med det. I den tidligere tjenester havde svært steder, og HTTP-adresser, pegede på dem. I dag, hard-ledninger en service til en adresse, der virker imod hele princippet om distribuerede tjenester. Så nu, en orchestrator som Kubernetes kan bruge en reverse proxy, som NGINX til at løse den nuværende opholdssted for en tjeneste, der er overalt i netværket, givet en mere generel identifikator såsom HTTP-adresse (URI) oprindelse af denne komponent i det lager, der oprindeligt distribueret det. Her, NGINX stadig forhandler med et DNS (domain name service) for at se op, at den nuværende placering, men på denne måde, kan det knytte en kendt komponent ved hjælp af et permanent identifikator, med en midlertidig eller forbigående-adresse, der er tilbøjelige til at ændre i et par sekunder.
Også: Netflix ‘smart downloads” i kø for din næste offline episode CNET
Dette er den service discovery princip — garanti for, at dit program kan finde noget, der bevæger sig meget rundt.
Uafhængighed
Der lokaliseres gennem service discovery giver en microservice at være afkoblet fra applikationer, og derfor uafhængigt overskueligt. Genbrugelighed gennem indarbejdelse er slet ikke ny kode; moderne programmer i Windows, Mac OS X eller Linux-system ville være umuligt uden. Men afkobling, der gør det muligt for bindinger mellem uafhængige bestanddele af kode, der skal kortlægges ud lige før deres kode, er de faktisk udførte, som er helt forskelligt fra begrebet, som vi alle beskæftiger sig i dag, “installation” – programmer på systemer.
Fathoming en overgang til microservices
At være en microservice er at fungere som en meget anderledes type af program end en ansøgning. I de tidlige dage af computere, software var et produkt du kunne indpakket i en kasse fuld af diske og sætte på en hylde med en pris. I disse dage, en ansøgning var i en klasse for programmet, med et utal af indbyrdes forbundne funktioner — et tekstbehandlingsprogram, et business process modeler, en præsentation grafik værktøjskasse.
SOA var oprindeligt skabt til at lette den software, der svarer til de pågældende formål-indbyggede komponenter-ting med en funktion, der tilpasser sig til enhver tilstand inden for et givet område. Microservices er faktisk en form for SOA (selvom nogle vil være uenige med selv). “Micro-” del er på grund af en tidlig indsats for at betragte hver af disse komponenter, som myrer i en koloni. Det hjalp folk til at visualisere begrebet bedre, hvis den metafor, der sammenlignede disse dele til noget småt. I praksis er det dog, at der er ingen størrelse begrænsning til en microservice. Du tror måske, det er imod hele pointen med at have en stor microservice, og du ville have flere fremtrædende arkitekter enig med dig.
Det var objekt-orienteret programmering, især ved hjælp af C++ programming language”, der først bragte SOA i forgrunden, år, før Java. En organisation, der er anerkendt som en autoritet i SOA, den Åbne Gruppe, der definerer en “service” i denne sammenhæng som “en logisk repræsentation af en gentagelig erhvervsaktivitet, der har et bestemt resultat.” Bemærk, hvordan eftertænksomt denne definition blev udformet: Det er ikke den forretningsmæssige aktivitet i sig selv, der udgør tjenesten, men dens repræsentation kode. På denne måde, en anden repræsentation ved hjælp af en anden kode ville være-med rette-et separat service.
Opskrifter er lavet til at være gentagelig: Samle den nøjagtige andel af råvarer, tilberede dem og kombinere dem i en bestemt rækkefølge, og du er sikker på at gengive hvad kokken hånd i tankerne. Gentagelig kode er en anden udyr. Det afhænger af forhold, som kan ændre eller omdirigere strømmen, såsom:
Variabler i stand til at ændre hensigten med instruktionerne, En database , hvis indhold repræsenterer, blandt andre ting, staten arbejdet produkt (fx, huset bliver bygget, bil bliver designet, skibsruter, der plottes);Afkobling af gentagne kode, kontekst fra den kode, der kalder det, eller overgår kontrol til det, der sikrer, at den funktion, det udfører, kan udføres, måske på en anden måde, på noget andet.
I praksis, funktionel uafhængighed er den mest vanskelige aspekt af microservices ideel til at opnå. Det betyder udforme en uafhængig komponent, der, med minimal instruktion, kan væsentlige uddanne sig som sine egne formål, udføre en opgave i henhold til dette formål fejlfrit, og derefter ophæve sig selv. Sådan en komponent, ville det være relativt let at automatisere, i forbindelse med et system, var hver anden komponent, der arbejdede på nøjagtig samme måde.
Også for Dette område, og gør browsing Netflix simple igen CNET
Tænke på en robot, hvis eneste formål er at hamre et søm. Du giver det den vinkel af ankeret, længden af neglen, den procentdel af denne længde strækker sig over bunden bord, og det relative niveau af base board, hvor det kan stoppe med at hamre. Det lærer sine driftsforhold ved “fødslen.” Det udfører dets eneste funktion, og stopper derefter.
En funktionel samling af sådanne robotter ville være som de fleste sci-fi-film, der nogensinde er lavet: whisking dig væk til en utopic verden af fremtidige sociale ordrer, uden at betale nogen mening at det tvivlsomt, at sandsynligheden for, at den rækkefølge af begivenheder, der ville bringe sådan en ordre om. Måske er det ikke vigtigt for en film, men ingen virksomhed nogensinde har ændret sine principper uden en plan.
Hver teknologi, da den første opgradering, til hjulet har krævet sine adoptant til at planlægge en overgangsperiode. Ingen organisation vil være i stand til at vedtage en microservices-orienteret strategi uden at have planlagt et kursus for, hvordan IT-afdelinger-både sin kode og dens mennesker-kan gøre det metodiske overgang der, uanset hvor de er nu.
Hvad ville ændre microservices
Hvis nogen enterprise software platform har til formål at gøre det muligt microservices, dens opgave må være at maksimere mængden af gearing, der kan opnås gennem genbrug og omfordeling af små stykker kode. At gøre disse moduler så funktionel som de overhovedet kan være direkte konsekvenser af tre dele af den bredere IT-økosystem:
Arbejdet mønstre af software udviklere, der sætter dem i stand til hurtigere at opbygge moduler og applikationer, der udnytter arbejde for, at de og andre har allerede gjort;De strategier for forvaltning af IT-operatører, der kan nu implementere tjenester på tværs af flere platforme, mens du holder applikationer integreret mellem disse platforme, maksimere udnyttelsen og tænkes kørsel ned virkelige, fysiske omkostninger-herunder køling.De økonomiske aspekter af cloud-baserede implementering, der giver virksomheder til at fokusere på mindre, mere fleksible, mere overskuelig fakturering komponenter, der kan køre op effektivitet, mens man kører ned driftsudgifter.
Alligevel er der en underliggende antagelse med hensyn til enhver organisation, der vil vedtage en microservices model, enten som et engangsbeløb eller i faser: At dens udviklere og IT-personale vil være i stand til at udtænke, planlægge, og derefter producere tjenester, som dele af ansøgninger til at komme — som dele af en nyere maskine. Sagt på en anden måde, microservice udviklere nødt til at opfatte deres arbejde uafhængigt af den kontekst, som det vil senere blive sat til at bruge.
Dette er ikke en naturlig måde at tænke på — lidt ligesom en kunstner, der producerer et særskilt segment af et maleri, uden hensyn til resten af lærredet. Og dette er, hvor den microservices debat står nu: Hvordan kan en organisation lære sine folk til at tænke abstrakt, i et mål, som kun kan forklares abstrakt og ud i det abstrakte, mens på samme tid lovede fordele, der er både målbar og konkret?
Få Mere at vide-Fra CBS Interaktive Netværk
Microservices og invasionen af identitet enheder af Scott M. Fulton, III, ZDNet ScaleMicroservices: først nedbryde monolitisk tænkning, så monolitisk applikationer af Joe McKendrick, Service OrientedMicrosoft åbne kilder i sin Tjeneste Stof microservices platform af Mary Jo Foley, Alt Om Microsoft
Andre steder
Sammenhæng: Hvad “Normale Microservices’ Se Ud? [podcast], Scott M. Fulton, III, Den Nye StackContext: Hvordan Vil Alle Sikre Microservices? [podcast], Scott M. Fulton, III, Den Nye StackHow Vedtagelse Kubernetes Påvirker CI/CD-Krav til DevOps Hold-interview med Laura Frank, direktør for teknik, Codeship
Relaterede Emner:
Servere
Virksomhedens Software
Open Source
Mobil-OS
0