Hallo, Habr. Op dit moment is er bij OTUS een nieuwe groep voor de cursus. . In aanloop naar de start van de cursus wil ik mijn auteursartikel met jullie delen.
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.
Een beetje geschiedenis
Als je de ontwikkelaars vraagt: 'Waarom zijn microservices nodig?', krijg je de meest uiteenlopende antwoorden. Je hoort dat microservices de schaalbaarheid verbeteren, de begrijpelijkheid van de code vergemakkelijken, de fouttolerantie verbeteren en soms kun je horen dat ze helpen om 'de code op te schonen'. Laten we teruggaan in de tijd om te begrijpen welk doel met het ontstaan van microservices werd nagestreefd.
Kort gezegd, microservices zoals we die nu begrijpen, zijn ontstaan als volgt: in 2011 merkte James Lewis, terwijl hij het werk van verschillende bedrijven analyseerde, een nieuw patroon op, de 'micro-app', dat SOA optimaliseerde op het gebied van versnelde service-implementatie. Enkele jaren later, in 2012, werd dit patroon op een architectuursummit omgedoopt tot microservice. De oorspronkelijke doelstelling van de invoering van microservices was dus om de beruchte time to market.
In de 'hype-golf' waren microservices in 2015 volop aanwezig. Uit verschillende studies blijkt dat geen enkele conferentie zonder een lezing over microservices voorbijging. Sterker nog, sommige conferenties waren uitsluitend aan microservices gewijd. Tegenwoordig beginnen veel projecten met het toepassen van deze architecturale stijl, en als een project veel legacy-code bevat, dan vindt er zeker een actieve migratie naar microservices plaats.
Ondanks het bovenstaande is er op dit moment nog steeds een relatief klein aantal ontwikkelaars dat het begrip 'microservice' kan definiëren. Maar daarover zullen we later spreken…
Monoliet
De architecturale stijl die wordt tegenovergesteld aan microservices, is de monoliet (of 'alles-in-één'). Het heeft waarschijnlijk geen zin om uit te leggen wat een monoliet is, dus ik zal meteen de nadelen van deze architecturale stijl opsommen, die verdere ontwikkeling van architecturale stijlen hebben geïnitieerd: grootte, onderlinge afhankelijkheid, implementatie, schaalbaarheid, betrouwbaarheid en starheid. Hieronder stel ik voor om met elk van de nadelen afzonderlijk kennis te maken.
Grootte
De monoliet is enorm. En meestal communiceert hij met een zeer grote database. De applicatie wordt te groot voor één ontwikkelaar om überhaupt te begrijpen. Alleen degene die veel tijd aan deze code heeft besteed, kan goed met de monoliet werken; nieuwkomers zullen veel tijd kwijt zijn met proberen de monoliet te doorgronden en het is niet zeker of ze dat zullen lukken. Gewoonlijk is er bij het werken met een monoliet altijd een soort 'onjuiste' senior die de monoliet min of meer goed kent en andere nieuwe ontwikkelaars gedurende een jaar tot anderhalf jaar op hun vingers tikt. Natuurlijk is zo'n onjuiste senior een enkelvoudig falen, en zijn vertrek kan leiden tot de ondergang van de monoliet.
Samenhang
De monoliet is als een 'grote klomp modder' (big ball of mud), waarbij wijzigingen op de ene plek onvoorspelbare gevolgen kunnen hebben op een andere plek. Door wijzigingen aan te brengen op de ene plek kan de monoliet op een andere plek beschadigd raken (waarbij je denkt 'ik jeuk op mijn oor, en *@ valt eraf'). Dit komt doordat de componenten in de monoliet zeer complexe en vooral niet voor de hand liggende onderlinge relaties hebben.
Implementatie
De implementatie van de monoliet, gezien de complexe onderlinge relaties tussen de componenten, is een langdurig proces met zijn eigen rituelen. Zo'n ritueel is meestal niet volledig gestandaardiseerd en wordt 'van mond tot mond' overgedragen.
Schaalbaarheid
De modules van de monoliet kunnen conflicterende behoeften qua middelen hebben, waardoor het noodzakelijk is om een compromis te zoeken vanuit hardwareperspectief. Stel je voor dat je monoliet bestaat uit de diensten A en B. Dienst A heeft hoge eisen aan de grootte van de harde schijf, terwijl dienst B dat aan het RAM heeft. In dit geval moet of de machine waarop de monoliet draait de eisen van beide diensten ondersteunen, of een van de diensten moet handmatig worden uitgeschakeld.
Een ander voorbeeld (meer klassiek): dienst A is veel populairder dan dienst B, dus je wilt dat er 100 van dienst A zijn en 10 van dienst B. Opnieuw zijn er twee opties: of we implementeren 100 volledige monolieten, of we moeten handmatig enkele van die monolieten de diensten B uitschakelen.
Betrouwbaarheid
Omdat alle services bij elkaar zijn, vallen alle services tegelijkertijd als de monoliet faalt. In werkelijkheid is het misschien niet zo erg, in ieder geval zijn er geen gedeeltelijke storingen in een gedistribueerd systeem, maar aan de andere kant, door een fout in een functionaliteit die door 0,001% van de gebruikers wordt gebruikt, kunt u al uw gebruikers verliezen.
Rigiditeit
Vanwege de grootte van de monoliet is het moeilijk om over te schakelen naar nieuwe technologieën. Als gevolg daarvan wordt het een aparte uitdaging om die ene zogenaamde senior vast te houden. De technologiestack die bij de start van het project is gekozen, kan een blok worden dat de ontwikkeling van het product belemmert.
Conclusie
Volgende keer gaan we het hebben over hoe mensen hebben geprobeerd de genoemde problemen op te lossen door over te stappen naar componenten en SOA.
Lees meer:
Bron: habr.com
