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.
В we hebben de monoliet behandeld en kwamen tot de conclusie dat de monoliet een aantal problemen kent: omvang, connectiviteit, implementatie, schaalbaarheid, betrouwbaarheid en stijfheid.
Deze keer stel ik voor om te praten over de mogelijkheden om een systeem te organiseren als een reeks modules/bibliotheken (component-georiënteerde architectuur) of diensten (service-georiënteerde architectuur).
Component-georiënteerde architectuur
Component-georiënteerde architectuur omvat het uitvoeren van een systeem als een reeks componenten die in zowel huidige als toekomstige projecten kunnen worden gebruikt. Bij het opsplitsen van een systeem in componenten wordt rekening gehouden met: hun herbruikbaarheid, hun vervangbaarheid, contextonafhankelijkheid, uitbreidbaarheid, inkapseling en onafhankelijkheid.
Met het juiste gebruik van componenten wordt het probleem van de “grote vuilbol” (groot formaat + hoge koppeling) opgelost en kunnen de componenten zelf zowel assemblage-eenheden (modules, bibliotheken) als implementatie-eenheden (diensten) zijn. Implementatie-eenheden worden niet altijd toegewezen aan het lopende proces: een webapplicatie en een database worden bijvoorbeeld samen geïmplementeerd.
Meestal worden monolieten ontwikkeld als een reeks modules. Deze aanpak leidt tot onafhankelijke ontwikkeling, maar de problemen van onafhankelijke schaalvergroting en implementatie, fouttolerantie en onafhankelijkheid van de algehele technologiestapel blijven bestaan. Daarom is de module een gedeeltelijk zelfstandig onderdeel.
Het grootste probleem met zo’n monoliet is dat de indeling in modules puur logisch is en gemakkelijk door ontwikkelaars kan worden geschonden. Er kan een kernmodule verschijnen, die geleidelijk verandert in een vuilnisbelt, de grafiek van afhankelijkheden tussen modules kan groter worden, enzovoort. Om dergelijke problemen te voorkomen, moet de ontwikkeling worden uitgevoerd door een zeer volwassen team, of onder leiding van een 'architect' die zich fulltime bezighoudt met codebeoordeling en de handen verslaat van ontwikkelaars die de logische structuur schenden.
De ‘ideale’ monoliet is een reeks logisch gescheiden modules, die elk in hun eigen database kijken.
Servicegerichte architectuur
Als het systeem georganiseerd moet zijn in de vorm van een reeks services, dan hebben we het over een servicegerichte architectuur. De principes zijn gebruikersgerichte applicatie-interoperabiliteit, hergebruik van zakelijke diensten, onafhankelijkheid van de technologiestapel en autonomie (onafhankelijke evolutie, schaalbaarheid en implementatie).
Service-georiënteerde architectuur (SOA = service-georiënteerde architectuur) lost alle geïdentificeerde problemen van een monoliet op: slechts één service wordt beïnvloed wanneer er een verandering plaatsvindt, en een goed gedefinieerde API ondersteunt een goede inkapseling van componenten.
Maar niet alles verloopt zo soepel: SOA zorgt voor nieuwe problemen. Gesprekken op afstand zijn duurder dan lokale gesprekken, en het herverdelen van verantwoordelijkheden tussen componenten is aanzienlijk duurder geworden.
Overigens is de mogelijkheid tot onafhankelijke inzet een zeer belangrijk kenmerk van de dienst. Als diensten gezamenlijk of bovendien in een bepaalde volgorde moeten worden ingezet, kan het systeem niet als servicegericht worden beschouwd. In dit geval hebben ze het over een gedistribueerde monoliet (niet alleen beschouwd als een antipatroon vanuit het oogpunt van SOA, maar ook vanuit het oogpunt van microservice-architectuur).
Servicegerichte architectuur wordt goed ondersteund door de architectengemeenschap en leveranciers. Dit impliceert de aanwezigheid van veel cursussen en certificeringen, goed ontwikkelde patronen. Onder deze laatste valt bijvoorbeeld de bekende enterprise service bus (ESB = enterprise service bus). Tegelijkertijd is ESB een bagage van leveranciers; het hoeft niet noodzakelijkerwijs in SOA te worden gebruikt.
De populariteit van servicegerichte architectuur bereikte een hoogtepunt rond 2008, waarna deze begon af te nemen, wat aanzienlijk dramatischer werd na de komst van microservices (~2015).
Conclusie
Nadat we de mogelijkheden hebben besproken om informatiesystemen in de vorm van services en modules te organiseren, stel ik voor om uiteindelijk over te gaan naar de principes van microservice-architectuur en in het volgende deel speciale aandacht te besteden aan het verschil tussen microservice-architectuur en servicegerichte architectuur.
Bron: www.habr.com