Microservice-architectuur:
Van mijn , moet u een basiskennis hebben van Microservice Architecture.Maar een professional zijn met vereist meer dan alleen de basis. In deze blog ga je dieper in op de architectuurconcepten en implementeer je deze aan de hand van een UBER-case study.
In deze blog leer je over het volgende:
- Definitie van microservice-architectuur
- Sleutelconcepten van microservice-architectuur
- Voors en tegens van microservice-architectuur
- UBER - Casestudy
U kunt verwijzen naar de , om de basisprincipes en voordelen van Microservices te begrijpen.
Het is alleen eerlijk als ik je de definitie van Microservices geef.
Definitie van microservices
Als zodanig is er geen goede definitie van Microservices oftewel Microservice Architecture, maar je kunt wel zeggen dat het een raamwerk is dat bestaat uit kleine, individueel inzetbare services die verschillende bewerkingen uitvoeren.
Microservices richten zich op één bedrijfsdomein dat kan worden geïmplementeerd als volledig onafhankelijk inzetbare services en deze op verschillende technologiestacks kunnen implementeren.
Figuur 1: Verschil tussen monolithische en microservice-architectuur - Microservice-architectuur
Raadpleeg het bovenstaande diagram om het verschil tussen monolithische en microservice-architectuur te begrijpen.Voor een beter begrip van de verschillen tussen beide architecturen, kun je mijn vorige blog raadplegen
Om u een beter begrip te geven, wil ik u enkele sleutelconcepten van microservice-architectuur vertellen.
Sleutelconcepten van microservice-architectuur
Voordat u uw eigen applicaties gaat bouwen met behulp van microservices, moet u duidelijk zijn over de omvang en functionaliteiten van uw applicatie.
Hieronder volgen enkele richtlijnen die moeten worden gevolgd bij het bespreken van microservices.
Richtlijnen bij het ontwerpen van microservices
- Als je als ontwikkelaar besluit om een applicatie te bouwen, moet je de domeinen scheiden en duidelijk zijn over de functionaliteiten.
- Elke microservice die u ontwerpt, zal zich alleen concentreren op één service van de applicatie.
- Zorg ervoor dat u de applicatie zo heeft ontworpen dat elke dienst afzonderlijk inzetbaar is.
- Zorg ervoor dat de communicatie tussen microservices verloopt via een stateless server.
- Elke service kan worden omgevormd tot kleinere services, met hun eigen microservices.
Nu u de basisrichtlijnen heeft gelezen bij het ontwerpen van microservices, gaan we de architectuur van microservices begrijpen.
Hoe werkt microservice-architectuur?
Een typische Microservice Architecture (MSA) moet uit de volgende componenten bestaan:
- Cliënten
- Identiteitsproviders
- Gateway-API
- Berichtformaten
- Databases
- Statische inhoud
- Beheer
- Dienstopsporing
Raadpleeg het onderstaande diagram.
Figuur 2: Architectuur van microservices - Microservice-architectuur
Ik weet dat de architectuur er een beetje ingewikkeld uitziet, maar laatikvereenvoudig het voor u.
1. Cliënten
De architectuur begint met verschillende soorten clients, vanaf verschillende apparaten die proberen verschillende beheermogelijkheden uit te voeren, zoals zoeken, bouwen, configureren enz.
2. Identiteitsproviders
Deze verzoeken van de clients worden vervolgens doorgegeven aan de identiteitsproviders die de verzoeken van clients verifiëren en de verzoeken doorgeven aan API Gateway. De verzoeken worden vervolgens via een goed gedefinieerde API-gateway naar de interne services gecommuniceerd.
3. API-gateway
Omdat clients de services niet rechtstreeks aanroepen, fungeert API Gateway als een toegangspunt voor de clients om verzoeken door te sturen naar de juiste microservices.
De voordelen van het gebruik van een API-gateway zijn:
- Alle services kunnen worden bijgewerkt zonder dat de klanten het weten.
- Services kunnen ook berichtenprotocollen gebruiken die niet webvriendelijk zijn.
- De API Gateway kan transversale functies uitvoeren, zoals het bieden van beveiliging, taakverdeling enz.
Na ontvangst van de verzoeken van klanten, bestaat de interne architectuur uit microservices die met elkaar communiceren via berichten om verzoeken van klanten af te handelen.
4. Berichtformaten
Er zijn twee soorten berichten waarmee ze communiceren:
hoe palindroom in java te controleren
- Synchrone berichten: In de situatie waarin klanten wachten op de reacties van een service, gebruiken microservices meestal REST (Representatieve staatsoverdracht) omdat het afhankelijk is van een staatloze client-server en de HTTP-protocol . Dit protocol wordt gebruikt omdat het een gedistribueerde omgeving is, waarbij elke functionaliteit wordt weergegeven met een hulpmiddel om bewerkingen uit te voeren
- Asynchrone berichten: In de situatie waarin clients niet wachten op de reacties van een service, gebruiken Microservices meestal protocollen zoals AMQP, STOMP, MQTT . Deze protocollen worden gebruikt in dit type communicatie, aangezien de aard van berichten is gedefinieerd en deze berichten interoperabel moeten zijn tussen implementaties.
De volgende vraag die bij u opkomt, is: hoe gaan de toepassingen die Microservices gebruiken om met hun gegevens?
5. Gegevensverwerking
Welnu, elke Microservice bezit een privédatabase om hun gegevens vast te leggen en de respectieve zakelijke functionaliteit te implementeren. Ook worden de databases van Microservices alleen bijgewerkt via hun service-API. Raadpleeg het onderstaande diagram:
Figuur 3: Vertegenwoordiging van microservices die gegevens verwerken - microservice-architectuur
De services die door Microservices worden geleverd, worden overgedragen naar elke externe service die communicatie tussen processen ondersteunt voor verschillende technologiestacks.
6. Statische inhoud
Nadat de microservices met zichzelf communiceren, implementeren ze de statische inhoud in een cloudgebaseerde opslagservice die deze rechtstreeks aan de klanten kan leveren via Content Delivery Networks (CDN's) .
Afgezien van de bovenstaande componenten, zijn er enkele andere componenten die voorkomen in een typische Microservices-architectuur:
7. Beheer
Dit onderdeel is verantwoordelijk voor het balanceren van de services op knooppunten en het identificeren van storingen.
8. Dienstopsporing
Fungeert als een gids voor microservices om de communicatieroute tussen hen te vinden, aangezien het een lijst bijhoudt met services waarop knooppunten zich bevinden.
Abonneer je op ons YouTube-kanaal om nieuwe updates te ontvangen ..!
Laten we nu eens kijken naar de voor- en nadelen van deze architectuur om een beter begrip te krijgen van wanneer u deze architectuur moet gebruiken.
Voors en tegens van microservice-architectuur
Raadpleeg de onderstaande tabel.
| Voordelen van microservice-architectuur | Tegens van Microservice Architectuur |
| Vrijheid om verschillende technologieën te gebruiken | Verhoogt de problemen bij het oplossen van problemen |
| Elke microservice richt zich op enkele zakelijke mogelijkheden | Verhoogt de vertraging door externe oproepen |
| Ondersteunt individuele inzetbare eenheden | Verhoogde inspanningen voor configuratie en andere bewerkingen |
| Staat frequente softwareversies toe | Het is moeilijk om de veiligheid van transacties te handhaven |
| Zorgt voor veiligheid van elke dienst | Moeilijk om gegevens over verschillende servicegrenzen heen te volgen |
| Meerdere services worden parallel ontwikkeld en geïmplementeerd | Moeilijk om code tussen services te verplaatsen |
Laten we meer over Microservices begrijpen door de vorige architectuur van UBER te vergelijken met de huidige.
UBER CASESTUDY
UBER's vorige architectuur
Zoals veel startups begon UBER zijn reis met een monolithische architectuur gebouwd voor een enkel aanbod in een enkele stad. Het hebben van één codebase leek op dat moment schoongemaakt en loste de kernproblemen van UBER op. Toen UBER echter wereldwijd begon uit te breiden, werden ze rigoureus geconfronteerd met verschillende problemen met betrekking tot schaalbaarheid en continue integratie.
Figuur 4: Monolithische architectuur van UBER - Microservice-architectuur
Het bovenstaande diagram toont de eerdere architectuur van UBER.
- Er is een REST API aanwezig waarmee de passagier en chauffeur verbinding maken.
- Er worden drie verschillende adapters gebruikt met API erin, om acties uit te voeren zoals facturering, betalingen, het verzenden van e-mails / berichten die we zien wanneer we een taxi boeken.
- Een MySQL-database om al hun gegevens op te slaan.
Dus, als u hier opmerkt, werden alle functies zoals passagiersbeheer, facturering, meldingsfuncties, betalingen, ritbeheer en chauffeursbeheer binnen één kader samengesteld.
Probleemstelling
Terwijl UBER wereldwijd begon uit te breiden, introduceerde dit soort raamwerk verschillende uitdagingen. De volgende zijn enkele van de belangrijkste uitdagingen
- Alle functies moesten opnieuw worden gebouwd, geïmplementeerd en opnieuw en opnieuw worden getest om een enkele functie bij te werken.
- Het oplossen van bugs werd buitengewoon moeilijk in een enkele repository omdat ontwikkelaars de code keer op keer moesten wijzigen.
- Het gelijktijdig schalen van de functies met de introductie van nieuwe functies wereldwijd was best moeilijk om samen te behandelen.
Oplossing
Om dergelijke problemen te voorkomen, besloot UBER zijn architectuur te veranderen en de andere hypergroeiende bedrijven zoals Amazon, Netflix, Twitter en vele anderen te volgen. Daarom besloot UBER zijn monolithische architectuur op te splitsen in meerdere codebases om een microservice-architectuur te vormen.
Raadpleeg het onderstaande diagram om de microservicearchitectuur van UBER te bekijken.
Figuur 5: Microservice-architectuur van UBER - Microservice-architectuur
- De belangrijkste verandering die we hier zien, is de introductie van API Gateway waarmee alle chauffeurs en passagiers zijn verbonden. Vanaf de API Gateway zijn alle interne punten met elkaar verbonden, zoals passagiersbeheer, bestuurdersbeheer, ritbeheer en andere.
- De eenheden zijn afzonderlijke, afzonderlijk inzetbare eenheden met afzonderlijke functionaliteiten.
- Bijvoorbeeld: als u iets wilt wijzigen in de factureringsmicroservices, hoeft u alleen de factureringsmicroservices te implementeren en hoeft u de andere niet te implementeren.
- Alle functies zijn nu afzonderlijk geschaald, d.w.z. de onderlinge afhankelijkheid tussen elke functie is verwijderd.
- We weten bijvoorbeeld allemaal dat het aantal mensen dat naar taxi's zoekt, relatief meer is dan het aantal mensen dat daadwerkelijk een taxi boekt en betalingen verricht. Dit levert ons de conclusie op dat het aantal processen dat aan de microservice voor passagiersbeheer werkt, groter is dan het aantal processen dat aan betalingen werkt.
In dezemanier, UBER profiteerde door te schakelenhaararchitectuur van monolithisch tot microservices.
Ik hoop dat je deze post over Microservice Architecture met plezier hebt gelezen.Ik ga met meer blogs komen, die ook hands-on zullen bevatten.
Wilt u meer weten over microservices?
Als je Microservices wilt leren kennen en je eigen applicaties wilt bouwen, bekijk dan onze die wordt geleverd met live training onder leiding van een instructeur en real-life projectervaring. Deze training zal u helpen Microservices diepgaand te begrijpen en u te helpen het onderwerp onder de knie te krijgen.
Heeft u een vraag voor ons? Vermeld het in het opmerkingengedeelte van ' Microservice-architectuur ”En ik neem contact met je op.
is hadoop gemakkelijk te leren