Hallo, habr. De inschrijving voor een nieuwe cursusstroom is momenteel geopend bij OTUS . Aan de vooravond van de start van de cursus wil ik mijn originele artikel met je delen.
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.
Een beetje geschiedenis
Als je aan ontwikkelaars vraagt: “Waarom hebben we microservices nodig?”, krijg je verschillende antwoorden. U zult horen dat microservices de schaalbaarheid verbeteren, code begrijpelijker maken, de fouttolerantie verbeteren, en soms hoort u dat u hiermee 'uw code kunt opschonen'. Laten we naar de geschiedenis kijken om het doel achter de opkomst van microservices te begrijpen.
Kort gezegd ontstonden microservices in onze huidige opvatting als volgt: in 2011 vestigde James Lewis, die het werk van verschillende bedrijven analyseerde, de aandacht op de opkomst van een nieuw ‘micro-app’-patroon, dat SOA optimaliseerde in termen van het versnellen van de inzet van Diensten. Iets later, in 2012, tijdens een architectuurtop, werd het patroon omgedoopt tot microservice. Het oorspronkelijke doel van de introductie van microservices was dus om de beruchte te verbeteren time to market.
Microservices waren in 2015 in opkomst. Volgens sommige onderzoeken was geen enkele conferentie compleet zonder een rapport over het onderwerp microservices. Bovendien waren sommige conferenties uitsluitend aan microservices gewijd. Tegenwoordig gebruiken veel projecten deze architecturale stijl, en als het project tonnen oude code bevat, wordt de migratie naar microservices waarschijnlijk actief uitgevoerd.
Ondanks al het bovenstaande kan een vrij klein aantal ontwikkelaars nog steeds het concept van ‘microservice’ definiëren. Maar we zullen hier later over praten...
Monoliet
De architecturale stijl die microservices contrasteert, is de monoliet (of alles-in-één). Het heeft waarschijnlijk geen zin om te vertellen wat een monoliet is, dus ik zal meteen de nadelen opsommen van deze bouwstijl, die de verdere ontwikkeling van bouwstijlen in gang heeft gezet: omvang, connectiviteit, inzetbaarheid, schaalbaarheid, betrouwbaarheid en stijfheid. Hieronder stel ik voor om elk van de tekortkomingen afzonderlijk te bekijken.
maat
De monoliet is erg groot. En het communiceert meestal met een zeer grote database. De applicatie wordt te groot voor één ontwikkelaar om überhaupt te begrijpen. Alleen degenen die veel tijd aan deze code hebben besteed, kunnen goed met de monoliet werken, terwijl beginners veel tijd zullen besteden aan het proberen de monoliet te achterhalen en er geen garantie is dat ze er ook achter zullen komen. Als je met een monoliet werkt, is er meestal altijd een 'voorwaardelijke' senior die de monoliet min of meer goed kent en binnen anderhalf jaar de handen van andere nieuwe ontwikkelaars verslaat. Uiteraard is zo'n voorwaardelijke senior een enkel punt van mislukking, en zijn vertrek kan leiden tot de dood van de monoliet.
Verbondenheid
De monoliet is een ‘grote modderbal’, waarbij veranderingen tot onvoorspelbare gevolgen kunnen leiden. Door op de ene plek wijzigingen aan te brengen, kun je de monoliet op een andere plek beschadigen (hetzelfde "je krabde aan je oor, *@ viel eraf"). Dit komt door het feit dat de componenten in de monoliet zeer complexe en vooral niet voor de hand liggende relaties hebben.
Inzet
Het inzetten van een monoliet is vanwege de complexe relaties tussen de componenten een lang proces met een eigen ritueel. Zo’n ritueel is meestal niet volledig gestandaardiseerd en wordt “mondeling” doorgegeven.
Schaalbaarheid
Monolith-modules kunnen conflicterende resourcebehoeften hebben, waardoor een compromis moet worden gesloten op het gebied van hardware. Stel je voor dat je een monoliet hebt die bestaat uit services A en B. Service A stelt hoge eisen aan de grootte van de harde schijf en service B stelt hoge eisen aan het RAM-geheugen. In dit geval moet de machine waarop de monoliet is geïnstalleerd de vereisten van beide services ondersteunen, of moet u een van de services handmatig kunstmatig uitschakelen.
Nog een voorbeeld (klassieker): dienst A is veel populairder dan dienst B, dus je wilt dat er 100 diensten A zijn, en 10 diensten B. Nogmaals, twee opties: ofwel zetten we 100 volwaardige monolieten in, of op sommige dan services B moeten handmatig worden uitgeschakeld.
Betrouwbaarheid
Omdat alle diensten zich bij elkaar bevinden, vallen alle diensten in één keer als de monoliet valt. In feite is dit misschien niet zo erg, er zullen in ieder geval geen gedeeltelijke storingen optreden in een gedistribueerd systeem, maar aan de andere kant kun je, als gevolg van een bug in de functionaliteit die door 0.001% van de gebruikers wordt gebruikt, alle gebruikers kwijtraken. van uw systeem.
Luiheid
Door de omvang van de monoliet is het lastig om over te stappen op nieuwe technologieën. Het behouden van diezelfde senior is daardoor een aparte opgave. De technologiestapel die bij de start van een project wordt gekozen, kan een blok worden dat de ontwikkeling van het product belemmert.
Conclusie
De volgende keer zullen we het hebben over hoe mensen hebben geprobeerd deze problemen op te lossen door over te stappen op componenten en SOA.
Lees verder:
Bron: www.habr.com