Microservices-tutorial: wat is, Architectie en voorbeeld

Wat zijn microservices?

Microservices is een service-georiënteerd architectuurpatroon waarbij applicaties worden gebouwd als een verzameling van verschillende kleinste onafhankelijke service-eenheden. Het is een software engineering benadering die zich richt op het ontleden van een applicatie in modules met één functie en goed gedefinieerde interfaces. Deze modules kunnen onafhankelijk worden geïmplementeerd en bediend door kleine teams die eigenaar zijn van de volledige levenscyclus van de service.

De term 'micro' verwijst naar de omvang van een microservice, die beheersbaar moet zijn door één ontwikkelteam (5 tot 10 ontwikkelaars). Bij deze methodologie worden grote applicaties opgedeeld in de kleinste, onafhankelijke eenheden.

Wat is monolithisch Archistructuur?

Simpel gezegd is een monolithische architectuur te vergelijken met een grote container waarin alle softwarecomponenten van een applicatie zijn ondergebracht. Laten we een voorbeeld van een webwinkel bekijken in de context van een monolithische architectuur.

monolitisch Archistructuur van e-commerce-applicatie

In elke e-commercetoepassing zijn er enkele standaardfuncties zoals Zoeken, RevWeergaven en beoordelingen, en betalingen. Deze functies zijn toegankelijk voor klanten via hun browser of apps. Wanneer de ontwikkelaar van de e-commercewebsite de applicatie implementeert, is dit één monolithische eenheid. De code voor verschillende functies, zoals zoeken, RevDe weergave van beoordelingen en de betalingsverwerking bevinden zich op dezelfde server. Om de applicatie te schalen, moet u meerdere instanties (servers) van deze applicaties draaien.

Wat is Microservice Archistructuur?

Microservice Architectuur is een architecturale ontwikkelingsstijl die het mogelijk maakt om applicaties te bouwen als een verzameling kleine autonome services die zijn ontwikkeld voor een bedrijfsdomein. Het is een variant van de structurele stijlarchitectuur die helpt om applicaties te ordenen als een losjes gekoppelde servicecollectie. De Microservice Architecture bevat fijnmazige services en lichtgewicht protocollen.

Laten we een voorbeeld nemen van een e-commerce-applicatie die is ontwikkeld met een microservice-architectuur. In dit voorbeeld van een microservice-architectuur is elke microservice gericht op één specifieke bedrijfsfunctionaliteit. Zoeken, beoordelen & Review en Payment hebben elk hun eigen instantie (server) en communiceren met elkaar.

Microservices Architectuur

In het Monolithicum ArchiIn een traditionele architectuur vloeien alle componenten samen tot één module. Maar in microservices... ArchiIn de architectuur zijn ze opgesplitst in afzonderlijke modules (microservices) die met elkaar communiceren, zoals te zien is in het bovenstaande voorbeeld van microservices.

De communicatie tussen microservices is een staatloze communicatie waarbij elk paar verzoeken en antwoorden onafhankelijk is. Daarom kunnen Microservices moeiteloos communiceren. In de Microservice ArchiIn deze structuur zijn de gegevens gefedereerd. Elke microservice heeft zijn eigen gegevensopslag.

Microservices versus monolithisch Architectuur

Microservices	monolitisch Architectuur
Elke eenheid van de gehele applicatie moet de kleinste zijn en één specifiek bedrijfsdoel moeten kunnen verwezenlijken.	Eén codebasis voor alle bedrijfsdoelstellingen.
De opstart van de service verloopt relatief snel.	Het opstarten van een dienst kost meer tijd.
Foutisolatie is eenvoudig. Zelfs als één service uitvalt, kunnen andere services blijven functioneren.	Foutisolatie is lastig. Als een specifieke functie niet werkt, valt het hele systeem uit. Om dit probleem op te lossen, moet de applicatie opnieuw worden gebouwd, getest en geïmplementeerd.
Alle microservices moeten losjes gekoppeld zijn, zodat wijzigingen in de ene service geen invloed hebben op de andere.	Monolithische architecturen kenmerken zich door een sterke onderlinge afhankelijkheid. Wijzigingen in één codemodule hebben invloed op de andere modules.
Bedrijven kunnen meer middelen inzetten voor diensten die een hoger rendement opleveren.	Omdat de diensten niet geïsoleerd zijn, is individuele toewijzing van middelen niet mogelijk.
Er zouden meer hardwarebronnen kunnen worden toegewezen aan de service die het meest wordt gebruikt. In het bovenstaande e-commercevoorbeeld bekijken meer gebruikers de productlijst en de zoekfunctie dan dat ze betalen, dus er zouden meer resources kunnen worden toegewezen aan de microservice voor zoeken en productlijsten.	Het opschalen van applicaties is zowel uitdagend als verspillend.
Microservices blijven altijd consistent en continu beschikbaar.	Ontwikkeltools raken overbelast omdat het proces helemaal opnieuw moet beginnen.
De gegevens worden gefedereerd. Hierdoor kunnen individuele microservices een datamodel kiezen dat het beste aansluit bij hun behoeften.	Gegevens zijn gecentraliseerd.
Kleine, gefocuste teams. Parallelle en snellere ontwikkeling.	Een groot team en aanzienlijke inspanningen op het gebied van teammanagement zijn vereist.
Wijziging in het datamodel van de ene Microservice heeft geen invloed op andere Microservices.	Een wijziging in het datamodel heeft gevolgen voor de gehele database.
Communiceert met andere microservices door gebruik te maken van goed gedefinieerde interfaces.	Niet toepasbaar.
Microservices werken volgens het principe dat de focus ligt op producten, niet op projecten.	Legt de nadruk op het gehele project.
Geen onderlinge afhankelijkheden tussen codebases. U kunt verschillende technologieën gebruiken voor verschillende Microservices.	Eén functie of programma is afhankelijk van andere.

Microservice-uitdagingen

• Microservices zijn van elkaar afhankelijk en moeten met elkaar communiceren.
• Vergeleken met monolithische systemen zijn er meer services om te monitoren, die met behulp van verschillende services zijn ontwikkeld programmeertalen.
• Omdat het een gedistribueerd systeem is, is het een inherent complex model.
• Verschillende services hebben hun eigen mechanisme, wat resulteert in een grote hoeveelheid geheugen voor ongestructureerde data.
• Effectief management en teamwork zijn nodig om escalerende problemen te voorkomen.
• Het reproduceren van een probleem zal lastig zijn als het in de ene versie verdwenen is en in de nieuwste versie weer terugkomt.
• Onafhankelijke implementatie is gecompliceerd met microservices.
• Microservicesarchitectuur brengt veel operationele overhead met zich mee.
• Het beheer van de applicatie wordt lastig wanneer er nieuwe services aan het systeem worden toegevoegd.
• Een breed scala aan bekwame professionals is nodig om heterogeen gedistribueerde microservices te ondersteunen.
• Microservice is kostbaar, omdat u verschillende serverruimte nodig heeft voor verschillende bedrijfstaken.

SOA versus microservices

SOA-services worden binnen de organisatie beheerd door een register dat fungeert als een directory. Applicaties moeten de services in het register opzoeken en aanroepen. Met andere woorden: SOA is net als een orkest waarbij elke artiest optreedt met zijn/haar instrument terwijl de muziekdirecteur iedereen instructies geeft.

Aan de andere kant is microservices een vorm van servicegerichte architectuur waarbij applicaties worden opgebouwd als een verzameling van verschillende kleinere services in plaats van één software of applicatie. Microservices zijn net als een dansgroep waarbij elke danser onafhankelijk is en weet wat hij of zij moet doen. Dus als ze een stap overslaan, weten ze hoe ze weer in de juiste volgorde terechtkomen. Hieronder volgt een gedetailleerde vergelijking tussen SOA en microservices.

Parameter	SOA	Microservices
Ontwerptype	Bij SOA worden softwarecomponenten blootgesteld aan de buitenwereld voor gebruik in de vorm van services.	MicroService is een onderdeel van SOA. Het is een implementatie van SOA.
Afhankelijkheid	Bedrijfseenheden zijn afhankelijk.	Ze zijn onafhankelijk van elkaar.
Grootte van de software	De software is groter dan alle conventionele software.	De softwaregrootte is bij microservices altijd klein.
Technologie stapel	De technologiestapel is lager vergeleken met Microservice.	De microservice-technologiestack kan erg groot zijn.
Aard van de aanvraag	Monolithisch van aard.	Volledig geïntegreerd systeem.
Onafhankelijk en gefocust	SOA-applicaties zijn gebouwd om meerdere zakelijke taken uit te voeren.	Ze zijn gebouwd om één enkele zakelijke taak uit te voeren.
Deployment	Het implementatieproces is tijdrovend.	De implementatie is eenvoudig en minder tijdrovend.
Kosten effectiviteit	Kosteneffectiever.	Less kostenefficiënt.
Schaalbaarheid	Less vergeleken met microservices.	Zeer schaalbaar.
Bedrijfslogica	De bedrijfslogica-componenten worden opgeslagen in één servicedomein, met eenvoudige communicatieprotocollen (HTTP met XML of JSON) en API-gestuurde SDK's/clients.	Bedrijfslogica kan zich over meerdere domeinen uitstrekken, met servicebusachtige lagen (middleware) tussen de services.

Hulpmiddelen voor microservices

1) Wiremock: microservices testen

WireMock is een flexibele bibliotheek voor het simuleren en nabootsen van webservices. Hiermee kan de respons van de HTTP API op een specifiek verzoek worden geconfigureerd. Het wordt ook gebruikt voor het testen van microservices.

Download link: http://wiremock.org/

2) Dokwerker

Docker is een open-sourceproject waarmee we applicaties kunnen maken, implementeren en uitvoeren met behulp van containers. Door containers te gebruiken, kunnen ontwikkelaars een applicatie als één pakket uitvoeren. Het stelt je in staat om bibliotheken en andere afhankelijkheden in één pakket te bundelen.

Download link: https://www.docker.com/

3) Hystrix

Hystrix is ​​een fouttolerante technologie. Java bibliotheek. Deze tool is ontworpen om toegangspunten tot externe services, systemen en bibliotheken van derden te scheiden in een gedistribueerde omgeving zoals microservices. Het verbetert het algehele systeem door falende services te isoleren en het domino-effect van storingen te voorkomen.

Download Link: https://github.com/Netflix/Hystrix

Best practices van microservices Architectuur

• Een aparte datastore voor elke microservice.
• Zorg ervoor dat de code een vergelijkbaar volwassenheidsniveau behoudt.
• Voor elke microservice moet een aparte build worden gemaakt.
• Beschouw elke server altijd als stateless.

Veelgestelde vragen