Varför använda en mikrotjänstmetod för att skapa program
För programvaruutvecklare är det inget nytt att dela in ett program i komponentdelar. Vanligtvis används en nivåindelad metod, med ett serverdelslager, affärslogik på mellannivå och ett användargränssnitt (UI). Det som har förändrats under de senaste åren är att utvecklare skapar distribuerade program för molnet.
Här följer några föränderliga affärsbehov:
- En tjänst som har skapats och drivs i stor skala för att nå kunder i nya geografiska regioner.
- Snabbare leverans av funktioner och funktioner för att svara på kundernas krav på ett agilt sätt.
- Förbättrad resursanvändning för att minska kostnaderna.
Dessa affärsbehov påverkar hur vi skapar program.
Mer information om Azure-metoden för mikrotjänster finns i Mikrotjänster: En programrevolution som drivs av molnet.
Designmetod för monolitiska kontra mikrotjänster
Program utvecklas över tid. Framgångsrika program utvecklas genom att vara användbara för människor. Misslyckade program utvecklas inte och blir så småningom inaktuella. Här är frågan: hur mycket vet du om dina krav idag och vad de kommer att vara i framtiden? Anta till exempel att du skapar ett rapportprogram för en avdelning i ditt företag. Du är säker på att programmet endast gäller inom företagets omfång och att rapporterna inte kommer att behållas länge. Ditt tillvägagångssätt skiljer sig från till exempel att skapa en tjänst som levererar videoinnehåll till tiotals miljoner kunder.
Ibland är det den drivande faktorn att få ut något som ett konceptbevis. Du vet att programmet kan göras om senare. Det är ingen mening med att överkonstruera något som aldrig används. Å andra sidan, när företag bygger för molnet, är förväntningarna tillväxt och användning. Tillväxt och skala är oförutsägbara. Vi vill snabbt skapa prototyper samtidigt som vi vet att vi är på en väg som kan hantera framtida framgång. Det här är den magra startmetoden: skapa, mäta, lära och iterera.
Under klient-/server-eran tenderade vi att fokusera på att skapa nivåindelade program med hjälp av specifika tekniker på varje nivå. Termen monolitisk app har dykt upp för att beskriva dessa metoder. Gränssnitten tenderade att ligga mellan nivåerna och en mer sammankopplad design användes mellan komponenterna på varje nivå. Utvecklare har utformat och räknat in klasser som kompilerats till bibliotek och länkats ihop till några körbara filer och DLL:er.
Det finns fördelar med en monolitisk designmetod. Monolitiska program är ofta enklare att utforma, och anrop mellan komponenter går snabbare eftersom dessa anrop ofta sker via interprocesskommunikation (IPC). Dessutom testar alla en enskild produkt, vilket tenderar att vara en effektivare användning av mänskliga resurser. Nackdelen är att det finns en nära koppling mellan nivåindelade lager och du kan inte skala enskilda komponenter. Om du behöver utföra korrigeringar eller uppgraderingar måste du vänta tills andra har slutfört sina tester. Det är svårare att vara flexibel.
Mikrotjänster hanterar dessa nackdelar och överensstämmer närmare med de föregående affärskraven. Men de har också både fördelar och skulder. Fördelarna med mikrotjänster är att var och en vanligtvis kapslar in enklare affärsfunktioner, som du kan skala ut eller i, testa, distribuera och hantera separat. En viktig fördel med en mikrotjänstmetod är att team drivs mer av affärsscenarier än av teknik. Mindre team utvecklar en mikrotjänst baserat på ett kundscenario och använder valfri teknik.
Med andra ord behöver organisationen inte standardisera tekniken för att underhålla mikrotjänstprogram. Enskilda team som äger tjänster kan göra vad som är meningsfullt för dem baserat på teamexpertis eller vad som är mest lämpligt för att lösa problemet. I praktiken är en uppsättning rekommenderade tekniker, till exempel en viss NoSQL-butik eller ett webbprogramramverk, att föredra.
Nackdelen med mikrotjänster är att du måste hantera mer separata entiteter och hantera mer komplexa distributioner och versionshantering. Nätverkstrafiken mellan mikrotjänsterna ökar, liksom motsvarande nätverksfördröjningar. Massor av pratsamma, detaljerade tjänster kan orsaka en prestandamardröm. Utan verktyg som hjälper dig att visa dessa beroenden är det svårt att se hela systemet.
Standarder gör att mikrotjänstmetoden fungerar genom att ange hur du kommunicerar och tolererar endast de saker du behöver från en tjänst, snarare än stela kontrakt. Det är viktigt att definiera kontrakten i förväg eftersom tjänsterna uppdateras oberoende av varandra. En annan beskrivning som myntas för att utforma med en mikrotjänstmetod är "detaljerad tjänstorienterad arkitektur (SOA)."
Som enklast handlar designmetoden för mikrotjänster om en frikopplad federation av tjänster, med oberoende ändringar i varje och överenskomna standarder för kommunikation.
I takt med att fler molnprogram skapas har människor upptäckt att den här nedbrytningen av det övergripande programmet till oberoende, scenariofokuserade tjänster är en bättre långsiktig metod.
Jämförelse mellan programutvecklingsmetoder
Ett monolitiskt program innehåller domänspecifika funktioner och är normalt indelat i funktionella lager som webb, företag och data.
Du skalar ett monolitiskt program genom att klona det på flera servrar/virtuella datorer/containrar.
Ett mikrotjänstprogram separerar funktioner i separata mindre tjänster.
Mikrotjänstmetoden skalas ut genom att varje tjänst distribueras separat, vilket skapar instanser av dessa tjänster mellan servrar/virtuella datorer/containrar.
Att utforma med en mikrotjänstmetod är inte lämpligt för alla projekt, men det stämmer bättre överens med de affärsmål som beskrevs tidigare. Att börja med en monolitisk metod kan vara meningsfullt om du vet att du kommer att ha möjlighet att omarbeta koden senare till en mikrotjänstdesign. Vanligare är att du börjar med ett monolitiskt program och långsamt delar upp det i steg, och börjar med de funktionella områden som måste vara mer skalbara eller flexibla.
När du använder en mikrotjänstmetod skapar du ditt program för många små tjänster. Dessa tjänster körs i containrar som distribueras över ett kluster av datorer. Mindre team utvecklar en tjänst som fokuserar på ett scenario och oberoende test, version, distribution och skalning av varje tjänst så att hela programmet kan utvecklas.
Vad är en mikrotjänst?
Det finns olika definitioner av mikrotjänster. Men de flesta av dessa egenskaper hos mikrotjänster är allmänt accepterade:
- Kapsla in en kund eller ett affärsscenario. Vilket problem löser du?
- Utvecklad av ett litet ingenjörsteam.
- Skrivet på valfritt programmeringsspråk med valfritt ramverk.
- Består av kod och valfritt tillstånd, som båda är oberoende versioner, distribuerade och skalade.
- Interagera med andra mikrotjänster via väldefinierade gränssnitt och protokoll.
- Ha unika namn (URL:er) som används för att matcha deras plats.
- Förblir konsekvent och tillgänglig i närvaro av fel.
Så här summerar du det:
Mikrotjänstprogram består av små, oberoende versioner och skalbara kundfokuserade tjänster som kommunicerar med varandra via standardprotokoll med väldefinierade gränssnitt.
Skrivet på valfritt programmeringsspråk, med valfritt ramverk
Som utvecklare vill vi vara fria att välja ett språk eller ramverk, beroende på våra kunskaper och behoven hos den tjänst som vi skapar. För vissa tjänster kan du värdera prestandafördelarna med C++ framför allt annat. För andra kan den enkla hanterade utveckling som du får från C# eller Java vara viktigare. I vissa fall kan du behöva använda ett specifikt partnerbibliotek, datalagringsteknik eller metod för att exponera tjänsten för klienter.
När du har valt en teknik måste du överväga drifts- eller livscykelhantering och skalning av tjänsten.
Tillåter att kod och tillstånd versionshanteras, distribueras och skalas separat
Oavsett hur du skriver dina mikrotjänster bör koden och eventuellt tillståndet distribueras, uppgraderas och skalas separat. Det här problemet är svårt att lösa eftersom det handlar om ditt val av teknik. För skalning är det svårt att förstå hur du partitionerar (eller shard) både koden och tillståndet. När koden och tillståndet använder olika tekniker, vilket är vanligt idag, måste distributionsskripten för din mikrotjänst kunna skala dem båda. Den här separationen handlar också om flexibilitet och flexibilitet, så att du kan uppgradera några av mikrotjänsterna utan att behöva uppgradera dem alla samtidigt.
Låt oss gå tillbaka till vår jämförelse av monolitiska och mikrotjänster för ett ögonblick. Det här diagrammet visar skillnaderna i metoderna för lagringstillstånd:
Tillståndslagring för de två metoderna
Den monolitiska metoden till vänster har en enda databas och nivåer av specifika tekniker.
Mikrotjänstmetoden till höger har en graf över sammankopplade mikrotjänster där tillståndet vanligtvis är begränsat till mikrotjänsten och olika tekniker används.
I en monolitisk metod använder programmet vanligtvis en enkel databas. Fördelen med att använda en databas är att den finns på en enda plats, vilket gör det enkelt att distribuera. Varje komponent kan ha en enda tabell för att lagra dess tillstånd. Team måste strikt separera tillstånd, vilket är en utmaning. Oundvikligen frestas någon att lägga till en kolumn i en befintlig kundtabell, göra en koppling mellan tabeller och skapa beroenden på lagringsskiktet. När detta händer kan du inte skala enskilda komponenter.
I mikrotjänstmetoden hanterar och lagrar varje tjänst sitt eget tillstånd. Varje tjänst ansvarar för att skala både kod och tillstånd tillsammans för att uppfylla tjänstens krav. En nackdel är att när du behöver skapa vyer eller frågor för programmets data måste du fråga i flera tillståndslager. Det här problemet löses vanligtvis av en separat mikrotjänst som skapar en vy över en samling mikrotjänster. Om du behöver köra flera improviserade frågor på data bör du överväga att skriva varje mikrotjänsts data till en datalagertjänst för offlineanalys.
Mikrotjänster är versionshanterade. Det är möjligt för olika versioner av en mikrotjänst att köras sida vid sida. En nyare version av en mikrotjänst kan misslyckas under en uppgradering och måste återställas till en tidigare version. Versionshantering är också användbart för A/B-testning, där olika användare upplever olika versioner av tjänsten. Det är till exempel vanligt att uppgradera en mikrotjänst för en specifik uppsättning kunder för att testa nya funktioner innan du distribuerar den i större utsträckning.
Interagerar med andra mikrotjänster över väldefinierade gränssnitt och protokoll
Under de senaste 10 åren har omfattande information publicerats som beskriver kommunikationsmönster i tjänstorienterade arkitekturer. I allmänhet använder tjänstkommunikation en REST-metod med HTTP- och TCP-protokoll och XML eller JSON som serialiseringsformat. Ur ett gränssnittsperspektiv handlar det om att använda en webbdesignmetod. Men ingenting bör hindra dig från att använda binära protokoll eller dina egna dataformat. Tänk bara på att det blir svårare för användarna att använda dina mikrotjänster om dessa protokoll och format inte är öppet tillgängliga.
Har ett unikt namn (URL) som används för att matcha dess plats
Din mikrotjänst måste vara adresserbar var den än körs. Om du tänker på datorer och vilken som kör en viss mikrotjänst kan det gå dåligt snabbt.
På samma sätt som DNS löser en viss URL till en viss dator behöver mikrotjänsten ett unikt namn så att dess aktuella plats kan identifieras. Mikrotjänster behöver adresserbara namn som är oberoende av infrastrukturen de körs på. Detta innebär att det finns en interaktion mellan hur tjänsten distribueras och hur den identifieras, eftersom det måste finnas ett tjänstregister. När en dator misslyckas måste registertjänsten berätta var tjänsten har flyttats.
Förblir konsekvent och tillgänglig i närvaro av fel
Att hantera oväntade fel är ett av de svåraste problemen att lösa, särskilt i ett distribuerat system. Mycket av den kod som vi skriver som utvecklare är till för att hantera undantag. Under testningen lägger vi också mest tid på undantagshantering. Processen är mer involverad än att skriva kod för att hantera fel. Vad händer när datorn där mikrotjänsten körs misslyckas? Du måste identifiera felet, vilket är ett svårt problem på egen hand. Men du måste också starta om mikrotjänsten.
För tillgängligheten måste en mikrotjänst vara motståndskraftig mot fel och kunna startas om på en annan dator. Förutom dessa återhämtningskrav bör data inte gå förlorade och data måste förbli konsekventa.
Återhämtning är svår att uppnå när fel inträffar under en programuppgradering. Mikrotjänsten, som arbetar med distributionssystemet, behöver inte återställas. Den måste avgöra om den kan fortsätta att gå vidare till den nyare versionen eller återställa till en tidigare version för att upprätthålla ett konsekvent tillstånd. Du måste överväga några frågor, till exempel om tillräckligt många datorer är tillgängliga för att fortsätta framåt och hur du återställer tidigare versioner av mikrotjänsten. För att fatta dessa beslut behöver du mikrotjänsten för att generera hälsoinformation.
Rapporterar hälsa och diagnostik
Det kan verka uppenbart, och det förbises ofta, men en mikrotjänst måste rapportera sin hälsa och diagnostik. Annars har du liten insikt i dess hälsa ur ett driftsperspektiv. Det är svårt att korrelera diagnostikhändelser i en uppsättning oberoende tjänster och hantera maskinursnedvridningar för att förstå händelseordningen. På samma sätt som du interagerar med en mikrotjänst över överenskomna protokoll och dataformat måste du standardisera hur du loggar hälso- och diagnostikhändelser som slutligen hamnar i ett händelselager för frågor och visning. Med en mikrotjänstmetod måste olika team komma överens om ett enda loggningsformat. Det måste finnas en konsekvent metod för att visa diagnostikhändelser i programmet som helhet.
Hälsa skiljer sig från diagnostik. Hälsa handlar om att mikrotjänsten rapporterar sitt aktuella tillstånd för att vidta lämpliga åtgärder. Ett bra exempel är att arbeta med uppgraderings- och distributionsmekanismer för att upprätthålla tillgängligheten. Även om en tjänst för närvarande inte är felfri på grund av en processkrasch eller omstart av datorn, kan tjänsten fortfarande vara i drift. Det sista du behöver är att förvärra situationen genom att starta en uppgradering. Den bästa metoden är att undersöka först eller ge tid för mikrotjänsten att återställas. Hälsohändelser från en mikrotjänst hjälper oss att fatta välgrundade beslut och i själva verket hjälpa till att skapa självåterställningstjänster.
Vägledning för att utforma mikrotjänster i Azure
Besök Azure Architecture Center för vägledning om hur du utformar och skapar mikrotjänster i Azure.
Service Fabric som en plattform för mikrotjänster
Azure Service Fabric uppstod när Microsoft övergick från att leverera boxade produkter, som vanligtvis var monolitiska, till att leverera tjänster. Upplevelsen av att skapa och driva stora tjänster, till exempel Azure SQL Database och Azure Cosmos DB, formade Service Fabric. Plattformen utvecklades med tiden när fler tjänster antog den. Service Fabric måste köras inte bara i Azure utan även i fristående Windows Server-distributioner.
Syftet med Service Fabric är att lösa de svåra problemen med att skapa och köra en tjänst och använda infrastrukturresurser effektivt, så att teamen kan lösa affärsproblem med hjälp av en mikrotjänstmetod.
Service Fabric hjälper dig att skapa program som använder en mikrotjänstmetod genom att tillhandahålla:
- En plattform som tillhandahåller systemtjänster för att distribuera, uppgradera, identifiera och starta om misslyckade tjänster, identifiera tjänster, dirigera meddelanden, hantera tillstånd och övervaka hälsotillstånd.
- Möjligheten att distribuera program som antingen körs i containrar eller som processer. Service Fabric är en container och processorkestrerare.
- Api:er för produktiv programmering som hjälper dig att skapa program som mikrotjänster: ASP.NET Core, Reliable Actors och Reliable Services. Du kan till exempel hämta hälso- och diagnostikinformation eller dra nytta av inbyggd hög tillgänglighet.
Service Fabric är oberoende när det gäller hur du skapar din tjänst och du kan använda vilken teknik som helst. Men den tillhandahåller inbyggda programmerings-API:er som gör det enklare att skapa mikrotjänster.
Migrera befintliga program till Service Fabric
Med Service Fabric kan du återanvända befintlig kod och modernisera den med nya mikrotjänster. Det finns fem steg i programmoderniseringen och du kan starta och stoppa när som helst. Stegen är:
- Börja med ett traditionellt monolitiskt program.
- Migrera. Använd containrar eller körbara gästfiler som värd för befintlig kod i Service Fabric.
- Modernisera. Lägg till nya mikrotjänster tillsammans med befintlig containerbaserad kod.
- Skapa. Dela upp det monolitiska programmet i mikrotjänster baserat på behov.
- Omvandla program till mikrotjänster. Transformera befintliga monolitiska program eller skapa nya greenfield-program.
Kom ihåg att du kan starta och stoppa i något av dessa steg. Du behöver inte gå vidare till nästa steg.
Nu ska vi titta på exempel för vart och ett av dessa steg.
Migrera
Av två skäl migrerar många företag befintliga monolitiska program till containrar:
- Kostnadsminskning, antingen på grund av konsolidering och borttagning av befintlig maskinvara eller på grund av program som körs med högre densitet.
- Ett konsekvent distributionskontrakt mellan utveckling och drift.
Kostnadsminskningar är enkla. På Microsoft containeriseras många befintliga program, vilket leder till miljontals dollar i besparingar. Konsekvent distribution är svårare att utvärdera men lika viktigt. Det innebär att utvecklare kan välja de tekniker som passar dem, men driften accepterar endast en enda metod för att distribuera och hantera programmen. Det minskar verksamheten från att behöva hantera komplexiteten i att stödja olika tekniker utan att tvinga utvecklare att bara välja vissa. I princip är varje program containerindelat i fristående distributionsavbildningar.
Många organisationer stannar här. De har redan fördelarna med containrar, och Service Fabric ger den fullständiga hanteringsupplevelsen, inklusive distribution, uppgraderingar, versionshantering, återställningar och hälsoövervakning.
Modernisera
Modernisering är att lägga till nya tjänster tillsammans med befintlig containerbaserad kod. Om du ska skriva ny kod är det bäst att ta små steg i mikrotjänstsökvägen. Det kan innebära att du lägger till en ny REST API-slutpunkt eller ny affärslogik. På så sätt startar du processen med att skapa nya mikrotjänster och öva på att utveckla och distribuera dem.
Innovera
En mikrotjänstmetod tillgodoser föränderliga affärsbehov. I det här skedet måste du bestämma om du vill börja dela upp det monolitiska programmet i tjänster eller förnya. Ett klassiskt exempel här är när en databas som du använder som arbetsflödeskö blir en flaskhals för bearbetning. När antalet arbetsflödesbegäranden ökar måste arbetet distribueras för skalning. Ta den specifika delen av programmet som inte skalar, eller som måste uppdateras oftare och dela upp det som en mikrotjänst och innovation.
Omvandla program till mikrotjänster
I det här skedet består ditt program helt av (eller delas upp i) mikrotjänster. För att nå den här punkten har du gjort mikrotjänstresan. Du kan börja här, men för att göra det utan en mikrotjänstplattform som hjälper dig att kräva en betydande investering.
Är mikrotjänster rätt för mitt program?
Kanske. När fler team började bygga för molnet av affärsskäl på Microsoft insåg många av dem fördelarna med att använda en mikrotjänstliknande metod. Bing har till exempel använt mikrotjänster i flera år. För andra team var mikrotjänstmetoden ny. Teamen fann att det fanns svåra problem att lösa utanför deras kärnområden av styrka. Det är därför Service Fabric fick dragkraft som teknik för att bygga tjänster.
Målet med Service Fabric är att minska komplexiteten i att skapa mikrotjänstprogram så att du inte behöver gå igenom så många kostsamma omdesigner. Börja i liten skala när det behövs, inaktuella tjänster, lägg till nya och utveckla med kundanvändning. Vi vet också att det finns många andra problem som ännu inte har lösts för att göra mikrotjänster mer lättillgängliga för de flesta utvecklare. Containrar och aktörens programmeringsmodell är exempel på små steg i den riktningen. Vi är säkra på att fler innovationer kommer att uppstå för att göra en mikrotjänstmetod enklare.