Microservices Tutorial: Vad är, Architecture och exempel
⚡ Smart sammanfattning
Mikrotjänster är ett tjänsteorienterat arkitekturmönster där en applikation är byggd som en samling små, oberoende tjänstenheter. Den här resursen förklarar monolitisk kontra mikrotjänstarkitektur, deras skillnader, utmaningar, SOA-jämförelser, populära verktyg och bästa praxis.
Vad är mikrotjänster?
Microservices är ett tjänsteorienterat arkitekturmönster där applikationer byggs som en samling av olika minsta oberoende tjänsteenheter. Det är en mjukvaruutveckling tillvägagångssätt som fokuserar på att sönderdela en applikation i enfunktionsmoduler med väldefinierade gränssnitt. Dessa moduler kan distribueras oberoende av varandra och drivas av små team som äger tjänstens hela livscykel.
Termen ”mikro” hänvisar till storleken på en mikrotjänst, vilken måste kunna hanteras av ett enda utvecklingsteam (5 till 10 utvecklare). I denna metod delas stora applikationer upp i de minsta oberoende enheterna.
Vad är monolitiskt Architecture?
Enkelt uttryckt kan man säga att monolitisk arkitektur är som en stor behållare där alla programvarukomponenter i en applikation är samlade i ett enda paket. Låt oss diskutera ett exempel på en e-handelsbutik i samband med en monolitisk arkitektur.
Monolitisk Architecture av e-handelsapplikation
I alla e-handelsapplikationer finns det några standardfunktioner som sökning, RevVisning och betyg samt betalningar. Dessa funktioner är tillgängliga för kunder med hjälp av deras webbläsare eller appar. När utvecklaren av e-handelswebbplatsen driftsätter applikationen är det en enda monolitisk enhet. Koden för olika funktioner som sökning, RevVisning och betyg samt betalningar finns på samma server. För att skala applikationen måste du köra flera instanser (servrar) av dessa applikationer.
Vad är Microservice Architecture?
Mikrotjänst Architecture är en arkitektonisk utvecklingsstil som tillåter att bygga applikationer som en samling små autonoma tjänster utvecklade för en affärsdomän. Det är en variant av strukturell stilarkitektur som hjälper till att arrangera applikationer som en löst kopplad tjänstekollektion. Mikrotjänsten Architecture innehåller finkorniga tjänster och lätta protokoll.
Låt oss ta ett exempel på en e-handelsapplikation utvecklad med mikrotjänstarkitektur. I detta exempel på mikrotjänstarkitektur fokuserar varje mikrotjänst på en enda affärsfunktion. Sök, betyg & Review och Payment har varsin instans (server) och kommunicerar med varandra.
Microservices Architecture
I monolitiken Archistruktur, alla komponenter sammanfogas till en enda modul. Men i Microservices Archistruktur, de är spridda i individuella moduler (mikrotjänster) som kommunicerar med varandra, som visas i exemplet med mikrotjänster ovan.
Kommunikationen mellan mikrotjänster är en tillståndslös kommunikation där varje par av begäran och svar är oberoende. Därför kan Microservices kommunicera utan ansträngning. I mikrotjänsten Archistruktur, data är federerade. Varje mikrotjänst har sitt separata datalager.
Microservices vs. Monolithic Architecture
| Microservices | Monolitisk Architecture |
|---|---|
| Varje enhet i hela applikationen bör vara den minsta, och den bör kunna leverera ett specifikt affärsmål. | En enda kodbas för alla affärsmål. |
| Tjänstens uppstart går relativt snabbt. | Uppstart av tjänsten tar längre tid. |
| Felsökning är enkelt. Även om en tjänst går ner kan andra fortsätta fungera. | Felisolering är svårt. Om någon specifik funktion inte fungerar, går hela systemet ner. För att hantera detta problem måste applikationen byggas om, testas på nytt och distribueras på nytt. |
| Alla mikrotjänster bör vara löst kopplade så att ändringar som görs i den ena inte påverkar den andra. | Monolitisk arkitektur är tätt sammankopplad. Förändringar i en kodmodul påverkar den andra. |
| Företag kan avsätta mer resurser till tjänster som genererar högre avkastning på investeringen. | Eftersom tjänster inte är isolerade är individuell resursallokering inte möjlig. |
| Fler hårdvaruresurser skulle kunna allokeras till den tjänst som används ofta. I e-handelsexemplet ovan kontrollerar fler användare produktlistan och söker jämfört med betalningar, så fler resurser skulle kunna allokeras till mikrotjänsten för sökning och produktlistning. | Applikationsskalning är både utmanande och slösaktigt. |
| Mikrotjänster förblir alltid konsekventa och kontinuerligt tillgängliga. | Utvecklingsverktygen blir överbelastade eftersom processen måste börja om från början. |
| Data är federerade. Detta gör det möjligt för enskilda mikrotjänster att anta en datamodell som bäst passar deras behov. | Data är centraliserad. |
| Små fokuserade team. Parallell och snabbare utveckling. | Det krävs ett stort team och avsevärda insatser från teamledningen. |
| Ändring i datamodellen för en mikrotjänst påverkar inte andra mikrotjänster. | Förändringar i datamodellen påverkar hela databasen. |
| Interagerar med andra mikrotjänster genom att använda väldefinierade gränssnitt. | Inte tillämpbar. |
| Mikrotjänster fungerar utifrån principen att fokusera på produkter, inte projekt. | Lägger fokus på hela projektet. |
| Inga korsberoende mellan kodbaser. Du kan använda olika tekniker för olika mikrotjänster. | En funktion eller ett program beror på andra. |
Microservice utmaningar
- Mikrotjänster är beroende av varandra och de måste kommunicera med varandra.
- Jämfört med monolitiska system finns det fler tjänster att övervaka som utvecklas med olika programmeringsspråk.
- Eftersom det är ett distribuerat system är det en i sig komplex modell.
- Olika tjänster kommer att ha sina separata mekanismer, vilket resulterar i en stor mängd minne för ostrukturerad data.
- Effektiv ledning och lagarbete krävs för att förhindra kaskadproblem.
- Att reproducera ett problem kommer att vara en svår uppgift när det är borta i en version och kommer tillbaka i den senaste versionen.
- Oberoende distribution är komplicerat med mikrotjänster.
- Microservice-arkitektur medför massor av operationer.
- Det är svårt att hantera applikationen när nya tjänster läggs till i systemet.
- Ett brett spektrum av skickliga yrkesverksamma krävs för att stödja heterogent distribuerade mikrotjänster.
- Mikroservice är kostsamt, eftersom du behöver underhålla olika serverutrymmen för olika affärsuppgifter.
SOA vs Microservices
SOA-tjänster underhålls i organisationen av ett register som fungerar som en kataloglista. Applikationer behöver söka upp tjänsterna i registret och anropa tjänsten. Med andra ord, SOA är precis som en orkester där varje artist uppträder med sitt instrument medan musikledaren ger instruktioner till alla.
Å andra sidan är Microservices en form av tjänsteorienterad arkitektur där applikationer byggs som en samling av olika mindre tjänster istället för en enda programvara eller applikation. Microservices är precis som en grupp där varje dansare är oberoende och vet vad de behöver göra. Så om de missar några steg vet de hur de ska komma tillbaka till rätt sekvens. Här är en detaljerad jämförelse mellan SOA och Microservices.
| Parameter | SOA | Microservices |
|---|---|---|
| Designtyp | I SOA exponeras mjukvarukomponenter mot omvärlden för användning i form av tjänster. | Micro Service är en del av SOA. Det är en implementering av SOA. |
| Dependency | Affärsenheter är beroende. | De är oberoende av varandra. |
| Programvarans storlek | Programvarans storlek är större än någon konventionell programvara. | Programvarans storlek är alltid liten i Microservices. |
| Teknikstack | Teknikstacken är lägre jämfört med Microservice. | Microservice-teknologistacken kan vara mycket stor. |
| Applikationens art | Monolitisk till sin natur. | Full stack i naturen. |
| Självständig och fokuserad | SOA-applikationer är byggda för att utföra flera affärsuppgifter. | De är byggda för att utföra en enda affärsuppgift. |
| konfiguration | Distribueringsprocessen är tidskrävande. | Implementeringen är enkel och mindre tidskrävande. |
| Kostnadseffektivitet | Mer kostnadseffektivt. | Less kostnadseffektiv. |
| Skalbarhet | Less jämfört med Microservices. | Mycket skalbar. |
| Företagslogik | Affärslogikkomponenter lagras i en enda tjänstedomän, med enkla trådbundna protokoll (HTTP med XML eller JSON) och API-drivna med SDK:er/klienter. | Affärslogik kan leva över domäner, med Enterprise Service Bus-liknande lager mellan tjänster (Middleware). |
Verktyg för mikrotjänster
1) Wiremock: Testa mikrotjänster
WireMock är ett flexibelt bibliotek för att stubba och mocka webbtjänster. Det kan konfigurera svaret som returneras av HTTP API:et när det tar emot en specifik begäran. Det används också för att testa mikrotjänster.
Ladda länk: http://wiremock.org/
2) Hamnarbetare
Docker är ett öppen källkodsprojekt som låter oss skapa, driftsätta och köra applikationer med hjälp av containrar. Genom att använda dessa containrar kan utvecklare köra en applikation som ett enda paket. Det låter dig leverera bibliotek och andra beroenden i ett paket.
Ladda länk: https://www.docker.com/
3) Hystrix
Hystrix är en feltolerans Java bibliotek. Det här verktyget är utformat för att separera åtkomstpunkter till fjärrtjänster, system och tredjepartsbibliotek i en distribuerad miljö som Microservices. Det förbättrar systemet övergripande genom att isolera de felande tjänsterna och förhindra kaskadeffekten av fel.
Nedladdningslänk: https://github.com/Netflix/Hystrix
Bästa praxis för mikrotjänster Architecture
- Separat datalagring för varje mikrotjänst.
- Håll koden på en liknande mognadsnivå.
- Separat version för varje mikrotjänst.
- Behandla alltid varje server som tillståndslös.



