Hallo, Habr. Vandaag ga ik door met de serie artikelen die ik speciaal heb geschreven voor de lancering van de nieuwe cursus. .
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.
In We hebben ons verdiept in de monolith en zijn tot de conclusie gekomen dat deze een aantal problemen heeft: grootte, samenhang, implementatie, schaalbaarheid, betrouwbaarheid en inflexibiliteit.
Deze keer stel ik voor om te praten over de mogelijkheden van het organiseren van een systeem in de vorm van een set modules/bibliotheken (componentgeoriënteerde architectuur) of diensten (servicegeoriënteerde architectuur).
Componentgeoriënteerde architectuur
Componentgeoriënteerde architectuur houdt in dat het systeem wordt uitgevoerd in de vorm van een set componenten die in zowel huidige als toekomstige projecten kunnen worden gebruikt. Bij het opdelen van het systeem in componenten worden de volgende aspecten in overweging genomen: geschiktheid voor hergebruik, vervangbaarheid, onafhankelijkheid van context, uitbreidbaarheid, encapsulatie en onafhankelijkheid.
Bij juist gebruik van componenten wordt het probleem van de ‘grote klomp ellende’ (grote grootte + hoge samenhang) opgelost. De componenten kunnen zowel bouwunits (modules, bibliotheken) als implementatie-eenheden (diensten) zijn. Implementatie-eenheden komen niet altijd overeen met het uitvoerende proces: bijvoorbeeld, een webapplicatie en een database worden gezamenlijk geïmplementeerd.
Monolieten worden het vaakst ontwikkeld als een set modules. Deze aanpak zorgt voor onafhankelijkheid in ontwikkeling, maar de problemen van onafhankelijke schaalbaarheid en implementatie, failover en afhankelijkheid van de algemene technologische stack blijven bestaan. Daarom is een module een gedeeltelijk onafhankelijke component.
Het grootste probleem van zo'n monolith is dat de scheiding in modules puur logisch is en gemakkelijk kan worden verstoord door ontwikkelaars. Er kan een core-module ontstaan die langzaam in een rommel verandert, de afhankelijkheidsgrafieken tussen modules kunnen groeien, enzovoort. Om dergelijke problemen te voorkomen, moet de ontwikkeling plaatsvinden door ofwel een zeer volwassen team of onder leiding van een ‘architect’ die fulltime bezig is met codebeoordeling en de ontwikkelaars die de logische structuur verstoren, op de vingers tikt.
Een 'ideale' monolith bestaat uit een set logisch gescheiden modules, waarvan elke module naar zijn eigen database kijkt.
Servicegeoriënteerde architectuur
Als er toch een systeem moet worden opgezet in de vorm van een set diensten, dan spreken we van een service-georiënteerde architectuur. De principes ervan zijn: compatibiliteit van applicaties, gericht op gebruikers, herbruikbaarheid van bedrijfsdiensten, onafhankelijkheid van technologieën en autonomie (onafhankelijke evolutie, schaalbaarheid en implementatie).
Service-georiënteerde architectuur (SOA = service oriented architecture) lost alle aangeduide problemen van monolithische systemen op: bij wijzigingen wordt slechts één dienst getroffen, en een duidelijk gedefinieerde API ondersteunt een goede encapsulatie van componenten.
Maar het is niet allemaal zo eenvoudig: SOA leidt tot nieuwe problemen. Distant calls zijn duurder dan lokale, en de herschikking van verantwoordelijkheden tussen componenten is aanzienlijk duurder geworden.
Overigens, de mogelijkheid van onafhankelijke implementatie is een zeer belangrijke eigenschap van de dienst. Als diensten gezamenlijk of, nog erger, in een bepaalde volgorde moeten worden geïmplementeerd, kan het systeem niet als service-georiënteerd worden beschouwd. In dat geval spreken we van een gedistribueerde monoliet (wat niet alleen vanuit het SOA-perspectief, maar ook vanuit het oogpunt van microservices als antipatroon wordt beschouwd).
Service-georiënteerde architectuur wordt goed ondersteund door de architectuurcommunity en leveranciers. Dit leidt tot de beschikbaarheid van vele cursussen en certificeringen, evenals goed uitgewerkte patronen. Onder deze laatste valt bijvoorbeeld de bekende enterprise service bus (ESB). Daarbij is ESB een erfenis van leveranciers, en hoeft niet per se in SOA te worden gebruikt.
De piek van de populariteit van service-georiënteerde architectuur lag rond 2008, waarna het begon te dalen, en de daling steeg aanzienlijk na de opkomst van microservices (~2015).
Conclusie
Nadat we de mogelijkheden van het organiseren van informatiesystemen in de vorm van diensten en modules hebben besproken, stel ik voor om nu over te gaan naar de principes van microservicesarchitectuur en bijzondere aandacht te besteden aan het verschil tussen microservicesarchitectuur en service-georiënteerde architectuur in het volgende deel.
Bron: habr.com
