Hallo collega's.
Vandaag bieden wij u ter overweging een vertaling aan van een artikel van Tugberk Ugurlu, die zich ertoe verbonden heeft in een relatief klein volume de principes van het ontwerpen van moderne softwaresystemen te schetsen. Dit is wat de auteur samengevat over zichzelf zegt:
Omdat het absoluut onmogelijk is om in een habro-artikel zo'n kolossaal onderwerp als architecturale patronen + ontwerppatronen uit 2019 te behandelen, raden we niet alleen de tekst van de heer Uruglu zelf aan, maar ook de talrijke links die hij zo vriendelijk was erin op te nemen. Als je het leuk vindt, zullen we een meer gespecialiseerde tekst publiceren over het ontwerp van gedistribueerde systemen.
Momentopname van Unsplash
Als je nog nooit met zulke uitdagingen te maken hebt gehad als het helemaal opnieuw ontwerpen van een softwaresysteem, dan is het bij het starten van dergelijk werk soms niet eens duidelijk waar je moet beginnen. Ik geloof dat je eerst grenzen moet trekken, zodat je een min of meer zelfverzekerd beeld hebt van wat je precies gaat ontwerpen, om vervolgens de handen uit de mouwen te steken en binnen die grenzen te werken. Als uitgangspunt kun je een product of dienst nemen (idealiter een die je echt leuk vindt) en uitzoeken hoe je deze kunt implementeren. U zult er misschien versteld van staan hoe eenvoudig dit product eruit ziet en hoeveel complexiteit het eigenlijk bevat. Niet vergeten: , en dat is oké.
Ik denk dat het beste advies dat ik kan geven aan iedereen die begint met het ontwerpen van een systeem dit is: maak geen aannames! Vanaf het allereerste begin moet u de bekende feiten over dit systeem en de verwachtingen die eraan verbonden zijn specificeren. Hier zijn enkele goede vragen die u kunt stellen om u op weg te helpen met uw ontwerp:
- Wat is het probleem dat we proberen op te lossen?
- Wat is het piekaantal gebruikers dat met ons systeem zal communiceren?
- Welke schrijf- en leespatronen gaan we gebruiken?
- Wat zijn de verwachte faalgevallen, hoe gaan we hiermee om?
- Wat zijn de verwachtingen ten aanzien van systeemconsistentie en beschikbaarheid?
- Moet u bij het werken rekening houden met eisen op het gebied van externe verificatie en regelgeving?
- Welke soorten gevoelige gegevens gaan we opslaan?
Dit zijn slechts enkele vragen die nuttig zijn geweest voor zowel mij als de teams waaraan ik in de loop der jaren van professionele activiteit heb deelgenomen. Als je de antwoorden op deze vragen kent (en eventuele andere vragen die relevant zijn voor de context waarin je moet werken), kun je je geleidelijk verdiepen in de technische details van het probleem.
Stel het beginniveau in
Wat bedoel ik hier met ‘basislijn’? In onze tijd ‘kunnen’ de meeste problemen in de software-industrie worden opgelost met behulp van bestaande methoden en technologieën. Door door dit landschap te navigeren, krijgt u dus een zekere voorsprong wanneer u wordt geconfronteerd met problemen die iemand anders vóór u moest oplossen. Vergeet niet dat programma's zijn geschreven om bedrijfs- en gebruikersproblemen op te lossen. Daarom streven wij ernaar het probleem op de meest duidelijke en eenvoudige manier (vanuit het gezichtspunt van de gebruiker) op te lossen. Waarom is dit belangrijk om te onthouden? Misschien zoek je in je coördinatensysteem graag naar unieke oplossingen voor alle problemen, omdat je denkt: “wat voor programmeur ben ik als ik overal patronen volg”? In werkelijkheid, de kunst hier is het nemen van beslissingen over waar en wat te doen. Natuurlijk heeft ieder van ons van tijd tot tijd te maken met unieke problemen, die allemaal een echte uitdaging zijn. Als ons beginniveau echter duidelijk is gedefinieerd, weten we waar we onze energie aan moeten besteden: het zoeken naar kant-en-klare opties om het probleem dat voor ons ligt op te lossen, of het verder bestuderen en een dieper begrip krijgen.
Ik denk dat ik je ervan heb kunnen overtuigen dat als een specialist met vertrouwen begrijpt wat de architecturale component van een aantal prachtige softwaresystemen is, deze kennis onmisbaar zal zijn voor het beheersen van de kunst van een architect en het ontwikkelen van een solide basis op dit gebied.
Oké, dus waar te beginnen? U Er is een repository op GitHub genaamd , van waaruit u kunt leren hoe u grootschalige systemen kunt ontwerpen en hoe u zich kunt voorbereiden op interviews over dit onderwerp. De repository heeft een sectie met voorbeelden , waar met name wordt gekeken naar de manier waarop zij het ontwerp van hun systemen benaderen bijvoorbeeld Twitter, Uber, enz.
Laten we echter, voordat we verder gaan met dit materiaal, eens nader kijken naar de belangrijkste architectonische uitdagingen waarmee we in de praktijk worden geconfronteerd. Dit is belangrijk omdat je VEEL aspecten van een hardnekkig en veelzijdig probleem moet specificeren, en dit vervolgens moet oplossen binnen het kader van de regelgeving die in een bepaald systeem van kracht is. , schreef een voormalige Facebook-medewerker , waar hij zijn eigen ervaringen deelde met het screenen van honderden sollicitanten. Hoewel de video zich sterk richt op het ontwerpen van grote systemen en de succescriteria die belangrijk zijn bij het zoeken naar een kandidaat voor een dergelijke functie, zal de video nog steeds dienen als een uitgebreide bron van informatie over wat het belangrijkst is bij het ontwerpen van systemen. Ik stel ook voor deze video.
Kennis opbouwen over het opslaan en ophalen van gegevens
Normaal gesproken heeft uw beslissing over hoe u uw gegevens op de lange termijn opslaat en ophaalt, een cruciale impact op de systeemprestaties. Daarom moet u eerst de verwachte schrijf- en leeskenmerken van uw systeem begrijpen. Vervolgens moet je deze indicatoren kunnen evalueren en keuzes kunnen maken op basis van de gemaakte beoordelingen. U kunt dit werk echter alleen effectief aankunnen als u de bestaande gegevensopslagpatronen begrijpt. In principe impliceert dit gedegen kennis met betrekking tot .
Databases kunnen worden gezien als datastructuren die uiterst schaalbaar en duurzaam zijn. Daarom zou kennis van datastructuren erg nuttig voor u moeten zijn bij het kiezen van een bepaalde database. Bijvoorbeeld, is een datastructuurserver die verschillende soorten waarden ondersteunt. Hiermee kunt u werken met datastructuren zoals lijsten en sets, en gegevens lezen met behulp van bekende algoritmen, bijvoorbeeld , het organiseren van dergelijk werk op een duurzame en zeer toegankelijke stijl.
Momentopname van Unsplash
Zodra u voldoende inzicht heeft in de verschillende gegevensopslagpatronen, kunt u verdergaan met het bestuderen van de consistentie en beschikbaarheid van gegevens. Allereerst moet je het begrijpen tenminste in algemene termen, en deze kennis vervolgens bijschaven door gevestigde patronen nader te bekijken и . Op deze manier ontwikkel je inzicht in het vakgebied en begrijp je dat het lezen en schrijven van gegevens eigenlijk twee heel verschillende problemen zijn, elk met zijn eigen unieke uitdagingen. Gewapend met een aantal consistentie- en beschikbaarheidspatronen kunt u de systeemprestaties aanzienlijk verhogen en tegelijkertijd een soepele gegevensstroom naar uw applicaties garanderen.
Tot slot moeten we ter afsluiting van het gesprek over problemen met gegevensopslag ook caching noemen. Moet het tegelijkertijd op de client en server draaien? Welke gegevens bevinden zich in uw cache? En waarom? Hoe organiseer je cache-invalidatie? Zal dit regelmatig gebeuren, met bepaalde tussenpozen? Zo ja, hoe vaak? Ik raad aan om deze onderwerpen te gaan bestuderen de bovengenoemde systeemontwerpprimer.
Communicatiepatronen
Systemen bestaan uit verschillende componenten; Dit kunnen verschillende processen zijn die binnen hetzelfde fysieke knooppunt draaien, of verschillende machines die op verschillende delen van uw netwerk draaien. Sommige van deze bronnen binnen uw netwerk kunnen privé zijn, maar andere moeten openbaar zijn en openstaan voor consumenten die er van buitenaf toegang toe hebben.
Het is noodzakelijk om de communicatie van deze bronnen met elkaar te garanderen, evenals de uitwisseling van informatie tussen het hele systeem en de buitenwereld. In de context van systeemontwerp worden we ook hier geconfronteerd met een reeks nieuwe en unieke uitdagingen. Laten we eens kijken hoe ze nuttig kunnen zijn en wat blz.
Momentopname van Unsplash
Bij het organiseren van de communicatie met de buitenwereld is dit altijd erg belangrijk , waarvan de verstrekking ook serieus moet worden genomen en actief moet worden nagestreefd.
Verbindingsdistributie
Ik ben er niet zeker van dat het voor iedereen gerechtvaardigd lijkt om dit onderwerp in een aparte sectie te plaatsen. Niettemin zal ik dit concept hier in detail presenteren, en ik ben van mening dat het materiaal in deze sectie het meest nauwkeurig wordt beschreven door de term ‘verbindingsdistributie’.
Systemen worden gevormd door veel componenten op de juiste manier met elkaar te verbinden, en hun communicatie met elkaar wordt vaak georganiseerd op basis van gevestigde protocollen, bijvoorbeeld TCP en UDP. Deze protocollen als zodanig zijn echter vaak onvoldoende om aan alle behoeften van moderne systemen te voldoen, die vaak onder hoge belasting worden gebruikt en bovendien sterk afhankelijk zijn van de behoeften van de gebruiker. Het is vaak nodig om manieren te vinden om verbindingen te verdelen om zulke hoge belasting van het systeem aan te kunnen.
Deze verdeling is gebaseerd op het bekende (DNS). Een dergelijk systeem maakt domeinnaamtransformaties mogelijk, zoals gewogen round robin en op latentie gebaseerde methoden om de belasting te helpen verdelen.
is van fundamenteel belang, en vrijwel elk groot internetsysteem waarmee we tegenwoordig te maken hebben, bevindt zich achter een of meer load balancers. Load balancers helpen clientverzoeken over meerdere beschikbare exemplaren te verdelen. Load balancers komen zowel in hardware als software voor, maar in de praktijk heb je vaker te maken met bijvoorbeeld software и . conceptueel ook erg vergelijkbaar met load balancers, hoewel er een bereik is tussen de eerste en de tweede . Met deze verschillen moet rekening worden gehouden bij het ontwerpen van een systeem op basis van uw behoeften.
Je moet er ook van weten (CDN). Een CDN is een wereldwijd gedistribueerd netwerk van proxyservers dat informatie levert vanaf knooppunten die zich geografisch dichter bij een specifieke gebruiker bevinden. CDN's verdienen de voorkeur als u werkt met statische bestanden geschreven in JavaScript, CSS en HTML. Bovendien zijn clouddiensten die verkeersmanagers leveren tegenwoordig gebruikelijk, bijvoorbeeld , waardoor u een wereldwijde distributie en verminderde latentie krijgt bij het werken met dynamische inhoud. Dergelijke services zijn echter meestal nuttig in gevallen waarin u met staatloze webservices moet werken.
Laten we het hebben over bedrijfslogica. Structureren van bedrijfslogica, taakstromen en componenten
We zijn er dus in geslaagd verschillende infrastructurele aspecten van het systeem te bespreken. Hoogstwaarschijnlijk denkt de gebruiker niet eens aan al deze elementen van uw systeem en geeft hij er eerlijk gezegd helemaal niets om. De gebruiker is geïnteresseerd in hoe het is om met uw systeem te communiceren, wat u hiermee kunt bereiken, en ook hoe het systeem gebruikersopdrachten uitvoert, wat en hoe het met gebruikersgegevens doet.
Zoals de titel van dit artikel suggereert, ging ik het hebben over software-architectuur en systeemontwerp. Daarom was ik niet van plan softwareontwerppatronen te behandelen die beschrijven hoe softwarecomponenten worden gemaakt. Hoe meer ik er echter over nadenk, hoe meer het mij lijkt dat de grens tussen softwareontwerppatronen en architecturale patronen erg vaag is, en dat de twee concepten nauw verwant zijn. Laten we een voorbeeld nemen (evenementenbronnen). Zodra u dit architecturale patroon adopteert, zal het bijna elk aspect van uw systeem beïnvloeden: de opslag van gegevens op lange termijn, het niveau van consistentie dat in uw systeem wordt aangenomen, de vorm van de componenten erin, enz., enz. Daarom besloot ik enkele architecturale patronen te noemen die rechtstreeks verband houden met bedrijfslogica. Hoewel dit artikel zich zal moeten beperken tot een eenvoudige lijst, moedig ik u aan er kennis mee te maken en na te denken over de ideeën die met deze patronen samenhangen. Hier ben je:
- concept , in het bijzonder, ,
Collaboratieve benaderingen
Het is uiterst onwaarschijnlijk dat u op een project terechtkomt als deelnemer die als enige verantwoordelijk is voor het systeemontwerpproces. Integendeel, u zult hoogstwaarschijnlijk te maken krijgen met collega's die zowel binnen als buiten uw taak werkzaam zijn. In dit geval moet u mogelijk de geselecteerde technologische oplossingen met collega's evalueren, de bedrijfsbehoeften identificeren en begrijpen hoe u taken het beste kunt parallelliseren.
Momentopname van Unsplash
De eerste stap is het ontwikkelen van een nauwkeurig en gedeeld begrip van wat het zakelijke doel is dat u probeert te bereiken en met welke bewegende delen u te maken krijgt. Groepsmodelleringstechnieken in het bijzonder (event storming) helpen dit proces aanzienlijk te versnellen en uw kansen op succes te vergroten. Dit werk kan vóór of na het schetsen worden uitgevoerd , en verdiep het vervolgens naarmate het product rijpt. Op basis van het consistentieniveau dat hier wordt bereikt, kunt u ook formuleren voor de beperkte context waarin je werkt. Als u over de architectuur van uw systeem wilt praten, vindt u dit wellicht nuttig , voorgesteld , vooral als u moet begrijpen hoeveel u op de details van het probleem moet ingaan en de dingen moet visualiseren die u wilt communiceren.
Er bestaat waarschijnlijk nog een volwassen technologie op dit gebied die niet minder nuttig is dan Domain Driven Design. Op de een of andere manier keren we echter terug naar het begrijpen van het vakgebied, dus kennis en ervaring in het veld zou nuttig voor je moeten zijn.
Bron: www.habr.com