Waarom een microservices-benadering gebruiken voor het bouwen van toepassingen
Voor softwareontwikkelaars is het instellen van een toepassing in onderdelen niets nieuws. Doorgaans wordt een gelaagde benadering gebruikt, met een back-endstore, bedrijfslogica in de middelste laag en een front-endgebruikersinterface (UI). Wat de afgelopen jaren is veranderd, is dat ontwikkelaars gedistribueerde toepassingen voor de cloud bouwen.
Hier volgen enkele veranderende zakelijke behoeften:
- Een service die op schaal wordt gebouwd en gebruikt om klanten in nieuwe geografische regio's te bereiken.
- Snellere levering van functies en mogelijkheden om op een flexibele manier te reageren op de behoeften van klanten.
- Verbeterd resourcegebruik om de kosten te verlagen.
Deze bedrijfsbehoeften zijn van invloed op de wijze waarop we toepassingen bouwen.
Zie Microservices: an application revolution powered by the cloud (Microservices: een toepassingsrevolutie die mogelijk wordt gemaakt door de cloud) voor meer informatie over de Azure-benadering van microservices.
Benadering van het ontwerp van monolithische versus microservices
Toepassingen ontwikkelen zich in de loop van de tijd. Succesvolle toepassingen ontwikkelen zich door nuttig te zijn voor mensen. Mislukte toepassingen ontwikkelen zich niet en worden uiteindelijk afgeschaft. Hier is de vraag: hoeveel weet u over uw vereisten vandaag en wat ze in de toekomst zullen zijn? Stel dat u een rapportagetoepassing bouwt voor een afdeling in uw bedrijf. U weet zeker dat de toepassing alleen van toepassing is binnen het bereik van uw bedrijf en dat de rapporten niet lang worden bewaard. Uw aanpak zal afwijken van die van bijvoorbeeld het bouwen van een service die video-inhoud levert aan tientallen miljoenen klanten.
Soms is iets uit de deur krijgen als bewijs van concept de drijvende factor. U weet dat de toepassing later opnieuw kan worden ontworpen. Het heeft weinig zin om iets over te maken dat nooit wordt gebruikt. Aan de andere kant, wanneer bedrijven bouwen voor de cloud, is de verwachting groei en gebruik. Groei en schaal zijn onvoorspelbaar. We willen snel prototypen, terwijl we ook weten dat we op een pad zijn dat toekomstige successen aankan. Dit is de lean-opstartbenadering: bouwen, meten, leren en herhalen.
Tijdens het client-/servertijdperk richten we ons meestal op het bouwen van gelaagde toepassingen met behulp van specifieke technologieën in elke laag. De term monolithische toepassing is ontstaan om deze benaderingen te beschrijven. De interfaces bevinden zich meestal tussen de lagen en er werd een nauwer gekoppeld ontwerp gebruikt tussen onderdelen binnen elke laag. Ontwikkelaars hebben klassen ontworpen en gefactoreerd die zijn gecompileerd in bibliotheken en aan elkaar zijn gekoppeld in enkele uitvoerbare bestanden en DLL's.
Een monolithische ontwerpbenadering biedt voordelen. Monolithische toepassingen zijn vaak eenvoudiger te ontwerpen en aanroepen tussen onderdelen zijn sneller omdat deze aanroepen vaak via interprocess communication (IPC) worden uitgevoerd. Bovendien test iedereen één product, wat meestal een efficiënter gebruik van human resources is. Het nadeel is dat er een nauwe koppeling is tussen gelaagde lagen en dat u afzonderlijke onderdelen niet kunt schalen. Als u oplossingen of upgrades moet uitvoeren, moet u wachten tot anderen hun test hebben voltooid. Het is moeilijker om flexibel te zijn.
Microservices pakken deze nadelen aan en komen nauwer overeen met de voorgaande bedrijfsvereisten. Maar ze hebben ook zowel voordelen als verplichtingen. De voordelen van microservices zijn dat elke service doorgaans eenvoudigere bedrijfsfunctionaliteit bevat, die u onafhankelijk kunt uitschalen of inschalen, testen, implementeren en beheren. Een belangrijk voordeel van een microservicesbenadering is dat teams meer worden gestuurd door bedrijfsscenario's dan door technologie. Kleinere teams ontwikkelen een microservice op basis van een klantscenario en kunnen hiervoor elke gewenste technologie gebruiken.
Met andere woorden, de organisatie hoeft technologie niet te standaardiseren om microservicetoepassingen te onderhouden. Individuele teams die over services beschikken, kunnen doen wat voor hen zinvol is op basis van teamexpertise of wat het meest geschikt is om het probleem op te lossen. In de praktijk verdient een set aanbevolen technologieën, zoals een bepaald NoSQL-archief of webtoepassingsframework, de voorkeur.
Het nadeel van microservices is dat u meer afzonderlijke entiteiten moet beheren en complexere implementaties en versiebeheer moet verwerken. Het netwerkverkeer tussen de microservices neemt toe, net als de bijbehorende netwerklatenties. Veel spraakmakende, gedetailleerde services kunnen een nachtmerrie voor prestaties veroorzaken. Zonder hulpprogramma's waarmee u deze afhankelijkheden kunt weergeven, is het moeilijk om het hele systeem te zien.
Standaarden zorgen ervoor dat de microservicesbenadering werkt door op te geven hoe u moet communiceren en alleen de dingen te tolereren die u nodig hebt van een service, in plaats van starre contracten. Het is belangrijk om deze contracten vooraf te definiëren in het ontwerp, omdat services onafhankelijk van elkaar worden bijgewerkt. Een andere beschrijving voor het ontwerpen met een microservicebenadering is 'fijnmazige servicegeoriënteerde architectuur (SOA).'
De eenvoudigste benadering van het ontwerp van microservices gaat over een ontkoppelde federatie van services, met onafhankelijke wijzigingen in elke service en overeengekomen standaarden voor communicatie.
Naarmate er meer cloudtoepassingen worden geproduceerd, hebben mensen ontdekt dat deze opsplitsing van de algehele toepassing in onafhankelijke, op scenario's gerichte services een betere langetermijnbenadering is.
Vergelijking tussen benaderingen voor toepassingsontwikkeling
Een monolithische toepassing bevat domeinspecifieke functionaliteit en is normaal gesproken onderverdeeld in functionele lagen zoals web, bedrijf en gegevens.
U kunt een monolithische toepassing schalen door deze te klonen op meerdere servers/virtuele machines/containers.
Een microservicetoepassing scheidt functionaliteit in afzonderlijke kleinere services.
De microservices-benadering wordt uitgeschaald door elke service afzonderlijk te implementeren en exemplaren van deze services te maken op servers/virtuele machines/containers.
Ontwerpen met een microservicesbenadering is niet geschikt voor alle projecten, maar het sluit wel nauwer aan bij de eerder beschreven bedrijfsdoelstellingen. Beginnen met een monolithische benadering kan zinvol zijn als u weet dat u de code later kunt aanpassen in een microservicesontwerp. Meestal begint u met een monolithische toepassing en breekt u deze langzaam op in fasen, te beginnen met de functionele gebieden die schaalbaarder of flexibeler moeten zijn.
Wanneer u een microservices-benadering gebruikt, stelt u uw toepassing samen met veel kleine services. Deze services worden uitgevoerd in containers die zijn geïmplementeerd op een cluster van machines. Kleinere teams ontwikkelen een service die zich richt op een scenario en elke service onafhankelijk testen, versien, implementeren en schalen, zodat de hele toepassing zich kan ontwikkelen.
Wat is een microservice?
Er zijn verschillende definities van microservices. Maar de meeste van deze kenmerken van microservices worden algemeen geaccepteerd:
- Een klant- of bedrijfsscenario inkapselen. Welk probleem los je op?
- Ontwikkeld door een klein technisch team.
- Geschreven in elke programmeertaal, met behulp van elk framework.
- Bestaan uit code en optioneel een status, die beide onafhankelijk van elkaar zijn geversied, geïmplementeerd en geschaald.
- Interactie met andere microservices via goed gedefinieerde interfaces en protocollen.
- Unieke namen (URL's) hebben die worden gebruikt om hun locatie op te lossen.
- Blijf consistent en beschikbaar in de aanwezigheid van fouten.
Samenvattend:
Microservicetoepassingen bestaan uit kleine, onafhankelijke, schaalbare, klantgerichte services die met elkaar communiceren via standaardprotocollen met goed gedefinieerde interfaces.
Geschreven in elke programmeertaal, met behulp van elk framework
Als ontwikkelaars willen we vrij zijn om een taal of framework te kiezen, afhankelijk van onze vaardigheden en de behoeften van de service die we maken. Voor sommige services kunt u de prestatievoordelen van C++ boven alles waarderen. Voor anderen is het gemak van beheerde ontwikkeling dat u krijgt van C# of Java mogelijk belangrijker. In sommige gevallen moet u mogelijk een specifieke partnerbibliotheek, technologie voor gegevensopslag of methode gebruiken om de service beschikbaar te maken voor clients.
Nadat u een technologie hebt gekozen, moet u rekening houden met het operationele of levenscyclusbeheer en het schalen van de service.
Hiermee kunnen code en status onafhankelijk van elkaar worden geversies, geïmplementeerd en geschaald
Het maakt niet uit hoe u uw microservices schrijft, de code en eventueel de status moeten onafhankelijk worden geïmplementeerd, bijgewerkt en geschaald. Dit probleem is moeilijk op te lossen omdat het gaat om uw keuze van technologieën. Voor schalen is het lastig om te begrijpen hoe u zowel de code als de status partitioneert (of shard). Wanneer de code en status verschillende technologieën gebruiken, wat tegenwoordig gebruikelijk is, moeten de implementatiescripts voor uw microservice beide kunnen schalen. Deze scheiding gaat ook over flexibiliteit en flexibiliteit, zodat u sommige microservices kunt upgraden zonder dat u ze allemaal tegelijk hoeft te upgraden.
Laten we even teruggaan naar onze vergelijking van de monolithische en microservicesbenaderingen. In dit diagram ziet u de verschillen in de benaderingen voor het opslaan van de status:
Statusopslag voor de twee benaderingen
De monolithische benadering, aan de linkerkant, heeft één database en lagen met specifieke technologieën.
De microservicesbenadering, aan de rechterkant, heeft een grafiek van onderling verbonden microservices waarbij de status doorgaans is gericht op de microservice en verschillende technologieën worden gebruikt.
In een monolithische benadering maakt de toepassing doorgaans gebruik van één database. Het voordeel van het gebruik van één database is dat deze zich op één locatie bevindt, waardoor deze eenvoudig kan worden geïmplementeerd. Elk onderdeel kan één tabel hebben om de status op te slaan. Teams moeten de status strikt scheiden, wat een uitdaging is. Het is onvermijdelijk dat iemand in de verleiding komt om een kolom toe te voegen aan een bestaande klanttabel, een join tussen tabellen uit te voeren en afhankelijkheden te maken in de opslaglaag. Nadat dit is gebeurd, kunt u afzonderlijke onderdelen niet meer schalen.
In de microservicesbenadering beheert en slaat elke service zijn eigen status op. Elke service is verantwoordelijk voor het samen schalen van code en status om te voldoen aan de vereisten van de service. Een nadeel is dat wanneer u weergaven of query's wilt maken van de gegevens van uw toepassing, u query's moet uitvoeren in meerdere statusarchieven. Dit probleem wordt meestal opgelost door een afzonderlijke microservice die een weergave maakt van een verzameling microservices. Als u meerdere ongeplande query's op de gegevens moet uitvoeren, kunt u overwegen om de gegevens van elke microservice naar een datawarehousingservice te schrijven voor offline analyse.
Microservices hebben versiebeheer. Het is mogelijk dat verschillende versies van een microservice naast elkaar worden uitgevoerd. Een nieuwere versie van een microservice kan mislukken tijdens een upgrade en moet worden teruggezet naar een eerdere versie. Versiebeheer is ook handig voor A/B-tests, waarbij verschillende gebruikers verschillende versies van de service ervaren. Het is bijvoorbeeld gebruikelijk om een microservice voor een specifieke set klanten te upgraden om nieuwe functionaliteit te testen voordat deze breder wordt geïmplementeerd.
Interactie met andere microservices via goed gedefinieerde interfaces en protocollen
In de afgelopen 10 jaar is uitgebreide informatie gepubliceerd over communicatiepatronen in servicegerichte architecturen. Over het algemeen maakt servicecommunicatie gebruik van een REST-benadering met HTTP- en TCP-protocollen en XML of JSON als serialisatie-indeling. Vanuit het perspectief van de interface gaat het om een webontwerpbenadering. Maar niets mag u ervan weerhouden binaire protocollen of uw eigen gegevensindelingen te gebruiken. Houd er rekening mee dat mensen het moeilijker hebben om uw microservices te gebruiken als deze protocollen en indelingen niet beschikbaar zijn.
Heeft een unieke naam (URL) die wordt gebruikt om de locatie op te lossen
Uw microservice moet adresseerbaar zijn, waar deze ook wordt uitgevoerd. Als u nadenkt over machines en welke een bepaalde microservice uitvoert, kan het snel slecht gaan.
Op dezelfde manier waarop DNS een bepaalde URL naar een bepaalde computer omgeeft, heeft uw microservice een unieke naam nodig, zodat de huidige locatie kan worden gedetecteerd. Microservices hebben adresseerbare namen nodig die onafhankelijk zijn van de infrastructuur waarop ze worden uitgevoerd. Dit impliceert dat er een interactie is tussen hoe uw service wordt geïmplementeerd en hoe deze wordt gedetecteerd, omdat er een serviceregister moet zijn. Wanneer een computer uitvalt, moet de registerservice u laten weten waar de service naartoe is verplaatst.
Blijft consistent en beschikbaar in de aanwezigheid van fouten
Het omgaan met onverwachte fouten is een van de moeilijkste problemen om op te lossen, met name in een gedistribueerd systeem. Veel van de code die we als ontwikkelaars schrijven, is bedoeld voor het verwerken van uitzonderingen. Tijdens het testen besteden we ook de meeste tijd aan het verwerken van uitzonderingen. Het proces is meer betrokken dan het schrijven van code voor het afhandelen van fouten. Wat gebeurt er wanneer de machine waarop de microservice wordt uitgevoerd, uitvalt? U moet de fout detecteren, wat op zichzelf al een moeilijk probleem is. Maar u moet ook uw microservice opnieuw opstarten.
Voor beschikbaarheid moet een microservice bestand zijn tegen fouten en opnieuw kunnen worden opgestart op een andere computer. Naast deze tolerantievereisten mogen gegevens niet verloren gaan en moeten gegevens consistent blijven.
Tolerantie is moeilijk te bereiken wanneer er fouten optreden tijdens een toepassingsupgrade. De microservice die met het implementatiesysteem werkt, hoeft niet te worden hersteld. Er moet worden bepaald of het kan doorgaan naar de nieuwere versie of kan worden teruggedraaid naar een eerdere versie om een consistente status te behouden. U moet rekening houden met een aantal vragen, zoals of er voldoende machines beschikbaar zijn om verder te gaan en hoe u eerdere versies van de microservice kunt herstellen. Als u deze beslissingen wilt nemen, hebt u de microservice nodig om statusinformatie te verzenden.
Rapporteert status en diagnostische gegevens
Het lijkt misschien voor de hand liggend en wordt vaak over het hoofd gezien, maar een microservice moet de status en diagnostische gegevens rapporteren. Anders hebt u weinig inzicht in de status ervan vanuit het perspectief van bewerkingen. Het correleren van diagnostische gebeurtenissen in een set onafhankelijke services en het omgaan met asymmetrische computerklokken om de volgorde van de gebeurtenis te begrijpen, is een uitdaging. Op dezelfde manier waarop u met een microservice communiceert via overeengekomen protocollen en gegevensindelingen, moet u standaardiseren hoe u status- en diagnostische gebeurtenissen registreert die uiteindelijk in een gebeurtenisarchief terechtkomen om query's uit te voeren en weer te geven. Bij een microservicesbenadering moeten verschillende teams het eens worden over één indeling voor logboekregistratie. Er moet een consistente benadering zijn voor het weergeven van diagnostische gebeurtenissen in de toepassing als geheel.
De status verschilt van diagnostische gegevens. Status gaat over de microservice die de huidige status rapporteert om de juiste acties te ondernemen. Een goed voorbeeld is het werken met upgrade- en implementatiemechanismen om de beschikbaarheid te behouden. Hoewel een service momenteel mogelijk niet in orde is vanwege een procescrash of het opnieuw opstarten van de machine, is de service mogelijk nog steeds operationeel. Het laatste wat u nodig hebt, is om de situatie erger te maken door een upgrade te starten. De beste aanpak is om eerst onderzoek te doen of tijd te geven voordat de microservice kan worden hersteld. Gezondheidsgebeurtenissen van een microservice helpen ons weloverwogen beslissingen te nemen en in feite zelfherstellende services te creëren.
Richtlijnen voor het ontwerpen van microservices in Azure
Ga naar het Azure-architectuurcentrum voor hulp bij het ontwerpen en bouwen van microservices in Azure.
Service Fabric als microserviceplatform
Azure Service Fabric is ontstaan toen Microsoft overstapte van het leveren van ingepakte producten, die doorgaans monolithisch waren, naar het leveren van services. De ervaring van het bouwen en gebruiken van grote services, zoals Azure SQL Database en Azure Cosmos DB, heeft Service Fabric gevormd. Het platform ontwikkelde zich in de loop van de tijd naarmate meer services het in gebruik namen. Service Fabric moest niet alleen in Azure worden uitgevoerd, maar ook in zelfstandige Windows Server-implementaties.
Het doel van Service Fabric is om de moeilijke problemen van het bouwen en uitvoeren van een service op te lossen en infrastructuurresources efficiënt te gebruiken, zodat teams zakelijke problemen kunnen oplossen met behulp van een microservicesbenadering.
Service Fabric helpt u bij het bouwen van toepassingen die gebruikmaken van een microservicesbenadering door het volgende te bieden:
- Een platform dat systeemservices biedt voor het implementeren, upgraden, detecteren en opnieuw starten van mislukte services, het detecteren van services, het routeren van berichten, het beheren van de status en het bewaken van de status.
- De mogelijkheid om toepassingen te implementeren die worden uitgevoerd in containers of als processen. Service Fabric is een container- en procesorchestrator.
- Api's voor productief programmeren om u te helpen toepassingen te bouwen als microservices: ASP.NET Core, Reliable Actors en Reliable Services. U kunt bijvoorbeeld status- en diagnostische gegevens ophalen of gebruikmaken van ingebouwde hoge beschikbaarheid.
Service Fabric is onafhankelijk van de manier waarop u uw service bouwt en u kunt elke technologie gebruiken. Maar het biedt wel ingebouwde programmeer-API's die het eenvoudiger maken om microservices te bouwen.
Bestaande toepassingen migreren naar Service Fabric
Met Service Fabric kunt u bestaande code opnieuw gebruiken en moderniseren met nieuwe microservices. Er zijn vijf fasen voor het moderniseren van toepassingen en u kunt in elke fase starten en stoppen. De fasen zijn:
- Begin met een traditionele monolithische toepassing.
- Migreren. Gebruik containers of uitvoerbare gastbestanden om bestaande code in Service Fabric te hosten.
- Moderniseren. Voeg nieuwe microservices toe naast bestaande in containers geplaatste code.
- Innoveren. De monolithische toepassing opsplitsen in microservices op basis van behoefte.
- Toepassingen transformeren in microservices. Bestaande monolithische toepassingen transformeren of nieuwe greenfield-toepassingen bouwen.
Vergeet niet dat u in elk van deze fasen kunt starten en stoppen. U hoeft niet door te gaan naar de volgende fase.
Laten we eens kijken naar voorbeelden voor elk van deze fasen.
Migreren
Om twee redenen migreren veel bedrijven bestaande monolithische toepassingen naar containers:
- Kostenreductie, hetzij door consolidatie en verwijdering van bestaande hardware, hetzij door actieve toepassingen met een hogere dichtheid.
- Een consistent implementatiecontract tussen ontwikkeling en bewerkingen.
Kostenbesparingen zijn eenvoudig. Bij Microsoft worden veel bestaande toepassingen in containers geplaatst, wat leidt tot miljoenen dollars aan besparingen. Consistente implementatie is moeilijker te evalueren, maar even belangrijk. Dit betekent dat ontwikkelaars de technologieën kunnen kiezen die bij hen passen, maar dat bewerkingen slechts één methode accepteren voor het implementeren en beheren van de toepassingen. Het vermindert bewerkingen die te maken hebben met de complexiteit van het ondersteunen van verschillende technologieën zonder ontwikkelaars te dwingen om alleen bepaalde technologieën te kiezen. In wezen wordt elke toepassing in een container geplaatst in zelfstandige implementatie-installatiekopieën.
Veel organisaties stoppen hier. Ze hebben al de voordelen van containers en Service Fabric biedt de volledige beheerervaring, inclusief implementatie, upgrades, versiebeheer, terugdraaiacties en statuscontrole.
Moderniseren
Modernisering is de toevoeging van nieuwe services naast bestaande containercode. Als u nieuwe code gaat schrijven, kunt u het beste kleine stappen in het pad naar de microservices uitvoeren. Dit kan betekenen dat u een nieuw REST API-eindpunt of nieuwe bedrijfslogica toevoegt. Op deze manier start u het proces van het bouwen van nieuwe microservices en oefent u met het ontwikkelen en implementeren ervan.
Innoveren
Een microservicesbenadering is geschikt voor veranderende bedrijfsbehoeften. In deze fase moet u beslissen of u de monolithische toepassing wilt splitsen in services of wilt gaan innoveren. Een klassiek voorbeeld hier is wanneer een database die u als werkstroomwachtrij gebruikt, een knelpunt wordt in de verwerking. Naarmate het aantal werkstroomaanvragen toeneemt, moet het werk worden gedistribueerd voor schaalaanpassing. Neem dat specifieke deel van de toepassing dat niet wordt geschaald of dat vaker moet worden bijgewerkt, en splits het uit als een microservice en innoveren.
Toepassingen transformeren in microservices
In dit stadium bestaat uw toepassing volledig uit (of gesplitst in) microservices. Om dit punt te bereiken, hebt u het microservicestraject gemaakt. U kunt hier beginnen, maar om dit te doen zonder een microservicesplatform om u te helpen, is een aanzienlijke investering vereist.
Zijn microservices geschikt voor mijn toepassing?
Misschien. Naarmate meer teams om zakelijke redenen voor de cloud begonnen te bouwen, realiseerden veel van hen zich de voordelen van een microservice-achtige benadering. Bing maakt bijvoorbeeld al jaren gebruik van microservices. Voor andere teams was de microservicebenadering nieuw. Teams ontdekten dat er moeilijk op te lossen problemen waren buiten hun kerngebieden van kracht. Dit is de reden waarom Service Fabric grip heeft gekregen als de technologie voor het bouwen van services.
Het doel van Service Fabric is om de complexiteit van het bouwen van microservicetoepassingen te verminderen, zodat u niet zoveel kostbare herontwerpen hoeft te doorlopen. Begin klein, schaal indien nodig, beëindig services, voeg nieuwe toe en ontwikkel mee met het gebruik van de klant. We weten ook dat er nog veel andere problemen zijn die nog moeten worden opgelost om microservices beter benaderbaar te maken voor de meeste ontwikkelaars. Containers en het actorprogrammeermodel zijn voorbeelden van kleine stappen in die richting. We zijn er zeker van dat er meer innovaties zullen ontstaan om een microservicesbenadering gemakkelijker te maken.