Därför bör du använda en mikrotjänstmetod för att skapa program
För programvaruutvecklare är det inget nytt att räkna in ett program i komponentdelar. Vanligtvis används en nivåindelad metod med ett serverdelsarkiv, affärslogik på mellannivå och ett användargränssnitt (UI) på klientsidan. 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 skapas och drivs i stor skala för att nå kunder i nya geografiska regioner.
- Snabbare leverans av funktioner för att svara på kundernas krav på ett smidigt 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 med tiden. 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 rapporteringsprogram 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 sparas länge. Din metod skiljer sig från till exempel att skapa en tjänst som levererar videoinnehåll till tiotals miljoner kunder.
Ibland är det drivande 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 skapa prototyper snabbt samtidigt som vi vet att vi är på en väg som kan hantera framtida framgångar. 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 monolitiska program har utvecklats 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 utformade och vägde in klasser som kompilerades till bibliotek och länkades 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 över kommunikation mellan processer (IPC). Dessutom testar alla en enda produkt, vilket tenderar att vara en effektivare användning av personalresurser. 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 testningen. Det är svårare att vara flexibel.
Mikrotjänster hanterar dessa nackdelar och överensstämmer bättre 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 in, testa, distribuera och hantera separat. En viktig fördel med en mikrotjänstmetod är att teamen 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 det som passar 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, t.ex. ett visst NoSQL-arkiv eller 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. Många trafikintensiva, 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 fasta kontrakt. Det är viktigt att definiera dessa kontrakt direkt i designen 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)."
På det enklaste sättet handlar designmetoden för mikrotjänster om en frikopplad federation av tjänster, med oberoende ändringar i var och en av de överenskomna kommunikationsstandarderna.
I takt med att fler molnprogram skapas har människor upptäckt att den här uppdelningen av det övergripande programmet i 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 vanligtvis 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 distribuera varje tjänst oberoende av varandra och skapa 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 överensstämmer bättre 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 smidiga.
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 med datorer. Mindre team utvecklar en tjänst som fokuserar på ett scenario och oberoende testar, version, distribuerar och skalar 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 i valfritt programmeringsspråk med valfritt ramverk.
- Består av kod och eventuellt 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ängligt i händelse av fel.
Så här summerar du det:
Mikrotjänstprogram består av små, enskilt versionsbaserade och skalbara kundfokuserade tjänster som kommunicerar med varandra via standardprotokoll med väldefinierade gränssnitt.
Skrivet i 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 oberoende av varandra
Oavsett hur du skriver dina mikrotjänster bör koden och eventuellt tillståndet distribuera, uppgradera och skala oberoende av varandra. 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 fragmenterar) 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å du kan uppgradera några av mikrotjänsterna utan att behöva uppgradera alla samtidigt.
Nu ska vi gå tillbaka till vår jämförelse av de monolitiska metoderna och mikrotjänstmetoderna en stund. Det här diagrammet visar skillnaderna i metoder 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 ett diagram ö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 att olika versioner av en mikrotjänst körs 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 den lanseras i större utsträckning.
Interagerar med andra mikrotjänster över väldefinierade gränssnitt och protokoll
Under de senaste tio å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 inget 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 människor 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 den infrastruktur som 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 ägnar vi också mest tid åt 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årt 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 lite 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 maskinklockans skevhet 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 mikrotjänsten som 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 är felaktig 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 tillåta att mikrotjänsten återställs. Hälsohändelser från en mikrotjänst hjälper oss att fatta välgrundade beslut och i själva verket bidra 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 mikrotjänstplattform
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älsa.
- Möjligheten att distribuera program som antingen körs i containrar eller som processer. Service Fabric är en container och processerkestrerare.
- 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 av 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.
- Innovera. 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 är många befintliga program containerbaserade, 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 åtgärderna accepterar bara 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 kod i containrar. Om du ska skriva ny kod är det bäst att ta små steg nedåt i sökvägen till mikrotjänster. Detta kan innebära att lägga till en ny REST API-slutpunkt eller ny affärslogik. På så sätt startar du processen med att skapa nya mikrotjänster och övar på att utveckla och distribuera dem.
Förnya
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 behöver uppdateras oftare och dela upp det som en mikrotjänst och förnya.
Omvandla program till mikrotjänster
I det här skedet består programmet 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 kräver 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 med 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örsprogrammeringsmodellen ä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.