Hallo, Habr. Vandaag vervolg ik een reeks publicaties die ik speciaal schreef voor de start van een nieuwe stroom van de cursus. .
Introductie
De keuze van de architectonische stijl is een van de fundamentele technische beslissingen bij het bouwen van een informatiesysteem. In deze serie artikelen stel ik voor om de meest populaire bouwstijlen voor bouwtoepassingen te analyseren en de vraag te beantwoorden wanneer welke bouwstijl de meeste voorkeur heeft. Tijdens het presentatieproces zal ik proberen een logische keten te tekenen die de ontwikkeling van architecturale stijlen verklaart, van monolieten tot microservices.
De vorige keer hadden we het over de verschillende soorten monolieten en het gebruik van componenten om ze te bouwen, zowel bouwcomponenten als implementatiecomponenten. Wij begrijpen servicegerichte architectuur.
Nu zullen we eindelijk de belangrijkste kenmerken van een microservice-architectuur definiëren.
Relatie van architecturen
Het is noodzakelijk om te begrijpen dat op basis van de definities in eerdere artikelen elke service een component is, maar niet elke service een microservice.
Kenmerken van Microservice-architectuur
De belangrijkste kenmerken van microservice-architectuur zijn:
- Georganiseerd rond zakelijke mogelijkheden
- Producten, geen projecten
- Slimme eindpunten en domme pijpen
- Gedecentraliseerd bestuur
- Gedecentraliseerd gegevensbeheer
- Automatisering van de infrastructuur
- Ontwerp voor mislukking
- Architectuur met evolutionaire ontwikkeling (Evolutionary Design)
Het eerste punt komt voort uit de servicegerichte architectuur, omdat microservices een speciaal geval van services zijn. Andere punten verdienen een afzonderlijke behandeling.
Georganiseerd rond zakelijke mogelijkheden
Nu is het nodig om de wet van Conway in gedachten te houden: organisaties die systemen creëren, organiseren hun architectuur en kopiëren de structuur van de interactie binnen deze organisaties. Als voorbeeld kunnen we ons het geval herinneren van het maken van een compiler: een team van zeven mensen ontwikkelde een zeven-pass-compiler, en een team van vijf ontwikkelde een vijf-pass-compiler.
Als we het hebben over monolieten en microservices, en als de ontwikkeling wordt georganiseerd door functionele afdelingen (backend, frontend, databasebeheerders), dan krijgen we een klassieke monoliet.
Om microservices te verkrijgen, moeten teams worden georganiseerd op basis van zakelijke capaciteiten (bestellingen, verzendingen, catalogusteam). Dankzij deze organisatie kunnen teams zich concentreren op het bouwen van specifieke delen van de applicatie.
Producten, geen projecten
Een projectaanpak waarbij een team de ontwikkelde functionaliteit overdraagt aan andere teams is bij een microservice architectuur volstrekt ongeschikt. Het team moet het systeem gedurende de hele levenscyclus ondersteunen. Amazon, een van de leiders op het gebied van de implementatie van microservices, verklaarde: “you build, you run it.” Door de productbenadering kan het team de behoeften van het bedrijf aanvoelen.
Slimme eindpunten en domme pijpen
SOA-architectuur besteedde veel aandacht aan communicatiekanalen, in het bijzonder de Enterprise Service Bus. Wat vaak leidt tot een foutieve Spaghetti Box, dat wil zeggen dat de complexiteit van de monoliet verandert in de complexiteit van verbindingen tussen diensten. Microservice-architectuur maakt alleen gebruik van eenvoudige communicatiemethoden.
Gedecentraliseerd bestuur
Belangrijke beslissingen over microservices moeten worden genomen door de mensen die de microservices daadwerkelijk ontwikkelen. Belangrijke beslissingen betekenen hier keuzes
programmeertalen, implementatiemethodologie, openbare interfacecontracten, enz.
Gedecentraliseerd gegevensbeheer
De standaardaanpak, waarbij de applicatie afhankelijk is van één database, kan geen rekening houden met de specifieke kenmerken van elke specifieke dienst. MSA omvat gedecentraliseerd gegevensbeheer, inclusief het gebruik van verschillende technologieën.
Automatisering van de infrastructuur
MSA ondersteunt continue implementatie- en leveringsprocessen. Dit kan alleen worden bereikt door processen te automatiseren. Tegelijkertijd lijkt het inzetten van een groot aantal diensten niet langer iets engs. Het implementatieproces zou saai moeten worden. Het tweede aspect heeft betrekking op servicemanagement in een productomgeving. Zonder automatisering wordt het beheren van processen die in verschillende besturingsomgevingen plaatsvinden onmogelijk.
Ontwerp voor mislukking
Talrijke MSA-services zijn gevoelig voor storingen. Tegelijkertijd is foutafhandeling in een gedistribueerd systeem geen triviale taak. Applicatiearchitectuur moet bestand zijn tegen dergelijke fouten. Rebecca Parsons vindt het heel belangrijk dat we zelfs niet langer gebruik maken van in-process communicatie tussen services; in plaats daarvan nemen we onze toevlucht tot HTTP voor communicatie, die lang niet zo betrouwbaar is.
Architectuur met evolutionaire ontwikkeling (Evolutionary Design)
De architectuur van het MSA-systeem zou zich evolutionair moeten ontwikkelen. Het is raadzaam om de noodzakelijke wijzigingen te beperken tot de grenzen van één dienst. Er moet ook rekening worden gehouden met de impact op andere diensten. De traditionele aanpak is om dit probleem op te lossen met versiebeheer, maar MSA stelt voor om versiebeheer te gebruiken
als laatste redmiddel.
Conclusie
Na al het bovenstaande kunnen we formuleren wat microservices zijn. Microservice-architectuur is een benadering voor het ontwikkelen van een enkele applicatie als een verzameling kleine services, die elk in hun eigen proces draaien en met elkaar communiceren via lichtgewicht mechanismen, vaak een HTTP-bron-API. Deze services zijn gebaseerd op zakelijke mogelijkheden en kunnen volledig onafhankelijk worden ingezet
geautomatiseerd implementatiemechanisme. Er is een minimaal niveau van gecentraliseerd beheer van deze services, die in verschillende programmeertalen kunnen worden geschreven en verschillende technologieën voor gegevensopslag kunnen gebruiken.
Bron: www.habr.com