🥇Keuze van architectonische stijl (deel 3)

Hallo, Habr. Vandaag ga ik door met de serie artikelen die ik speciaal heb geschreven voor de lancering van de nieuwe cursus. ‘Software Architect’.

Inleiding

Het kiezen van een architecturale 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 architecturale stijlen van applicaties te bespreken en te beantwoorden wanneer welke architecturale stijl het meest wenselijk is. In het verloop van deze uitleg zal ik proberen een logische keten te schetsen die de ontwikkeling van architecturale stijlen van monolieten tot microservices verklaart.

De vorige keer hebben we gesproken over verschillende soorten monolieten en het gebruik van componenten voor hun bouw, zowel bouwcomponenten als implementatiecomponenten. We hebben het gehad over service-georiënteerde architectuur.

Nu zullen we eindelijk de belangrijkste kenmerken van microservice-architectuur definiëren.

Architecturale relaties

Het is noodzakelijk om te begrijpen dat, op basis van de gegevens in de voorgaande artikelen, elke service een component is, maar niet elke service een microservice is.

Kenmerken van microservice-architectuur

De belangrijkste kenmerken van microservice-architectuur zijn:

Organisatie rondom zakelijke mogelijkheden (Organized around Business Capabilities)
Producten, niet projecten (Products not Projects)
Slimme toegangspunten en domme leidingen (Smart endpoints and dumb pipes)
Gedecentraliseerd beheer (Decentralized Governance)
Gedecentraliseerd databeheer (Decentralized Data Management)
Infrastructuurautomatisering (Infrastructure Automation)
Bescherming tegen uitval (Design for failure)
Architectuur met evolutionaire ontwikkeling (Evolutionary Design)

Het eerste punt komt voort uit service-georiënteerde architectuur, omdat microservices een bijzonder geval zijn van services. De andere punten verdienen een aparte bespreking.

Organisatie rondom zakelijke mogelijkheden (Organized around Business Capabilities)

Het is nu belangrijk om de wet van Conway te herinneren: organisaties die systemen creëren, organiseren hun architectuur op een manier die de communicatiestructuur binnen deze organisaties weerspiegelt. Als voorbeeld kan de creatie van een compiler worden genoemd: een team van zeven mensen ontwikkelde een zevenpass-compilateur, terwijl een team van vijf een vijfpass-compilateur ontwikkelde.

Als we het hebben over monolithen en microservices, dan ontstaat er een klassiek monolith wanneer de ontwikkeling is georganiseerd in functionele afdelingen (backend, frontend, databasebeheerders).

Om microservices te verkrijgen, moeten teams worden georganiseerd rond zakelijke mogelijkheden (bestelteam, verzendingsteam, catalogus). Deze organisatie stelt teams in staat zich te concentreren op het creëren van specifieke delen van de applicatie.

Producten, niet projecten (Products not Projects)

De projectaanpak waarbij een team de ontwikkelde functionaliteit overdraagt aan andere teams in het geval van een microservicesarchitectuur is volkomen ongepast. Een team moet het systeem ondersteunen gedurende de hele levenscyclus. Amazon, een van de koplopers in de implementatie van microservices, heeft verklaard: "je bouwt een product, en jij draait het" ("you build, you run it"). De productgerichte aanpak laat het team de behoeften van het bedrijf voelen.

Slimme toegangspunten en domme leidingen (Smart endpoints and dumb pipes)

SOA-architectuur besteedde veel aandacht aan communicatiemiddelen, met name de Enterprise Service Bus. Dit leidt vaak tot Erroneous Spaghetti Box, wat betekent dat de complexiteit van de monoliet overgaat in de complexiteit van de relaties tussen de services. In de microservicesarchitectuur worden alleen eenvoudige interactiemethoden gebruikt.

Gedecentraliseerd beheer (Decentralized Governance)

Belangrijke beslissingen over microservices moeten worden genomen door de mensen die daadwerkelijk microservices ontwikkelen. Hier worden met belangrijke beslissingen zaken als de keuze van
programmeertalen, implementatiemethodologieën, contracten voor publieke interfaces, enz.

Gedecentraliseerd databeheer (Decentralized Data Management)

De standaardaanpak waarbij de applicatie op één database vertrouwt, kan de specificiteit van elke afzonderlijke service niet in aanmerking nemen. MSA staat gedecentraliseerd databeheer toe, tot het punt van het gebruik van verschillende technologieën.

Infrastructuurautomatisering (Infrastructure Automation)

MSA ondersteunt processen voor continue implementatie en levering. Dit kan alleen worden bereikt door de processen te automatiseren. Hierdoor lijkt het implementeren van een groot aantal services al minder angstaanjagend. Het implementatieproces moet saai worden. Een tweede aspect is het beheer van services in een productomgeving. Zonder automatisering wordt het beheren van processen die in verschillende operationele omgevingen zijn gestart, onmogelijk.

Bescherming tegen uitval (Design for failure)

Talrijke MSA-diensten zijn kwetsbaar voor storingen. Het verwerken van fouten in een gedistribueerd systeem is een behoorlijk gecompliceerde taak. De architectuur van applicaties moet bestand zijn tegen dergelijke storingen. Rebecca Parsons vindt het uiterst belangrijk dat we zelfs geen inter-process communicatie tussen diensten meer gebruiken; in plaats daarvan maken we gebruik van HTTP voor communicatie, wat nooit zo betrouwbaar is.

Architectuur met evolutionaire ontwikkeling (Evolutionary Design)

De architectuur van een MSA-systeem moet evolutionair ontwikkeld worden. Het is wenselijk om de benodigde veranderingen te beperken tot de grenzen van één dienst. Ook moet rekening gehouden worden met de impact op andere diensten. De traditionele aanpak is om deze uitdaging met versiebeheer op te lossen, maar MSA stelt voor om versiebeheer te gebruiken als
een ultieme maatregel.

Conclusie

Na al het bovenstaande kan worden vastgesteld wat microservices zijn. Microservices-architectuur is een benadering voor het ontwikkelen van een enkele applicatie als een set van kleine diensten, waarvan elke dienst in zijn eigen proces draait en communiceert via eenvoudige mechanismen, vaak met behulp van HTTP API's. Deze diensten zijn gebouwd rond zakelijke mogelijkheden en kunnen onafhankelijk worden ingezet met behulp van een volledig
geautomatiseerd implementatiemechanisme. Er is een minimaal niveau van centrale controle over deze diensten, die in verschillende programmeertalen kunnen zijn geschreven en verschillende databasetechnologieën kunnen gebruiken.