Hallo collega's.
Vandaag bieden we u de vertaling aan van een artikel van Tugberk Ugurlu, waarin hij de principes van het ontwerpen van moderne softwaresystemen in een relatief klein formaat uiteenzet. Dit is wat de auteur over zichzelf te zeggen heeft:
Aangezien het absoluut onmogelijk is om in een hubreport zo'n enorm onderwerp als architecturale patronen + ontwerppatronen in de huidige stand van zaken in 2019 te behandelen, raden we niet alleen de tekst van de heer Ugurlu aan, maar ook de talrijke verwijzingen die hij daarin vriendelijk heeft opgenomen. Mocht het u bevallen, dan publiceren we ook een meer specifiek artikel over het ontwerpen van gedistribueerde systemen.
Foto van de website Unsplash
Als u nooit met uitdagingen bent geconfronteerd, zoals het ontwerpen van een softwaresysteem vanaf nul, kan het aan het begin van zo'n project soms moeilijk zijn om te weten waar te beginnen. Ik geloof dat je in eerste instantie de grenzen moet afbakenen om redelijk zeker te weten wat je van plan bent te ontwerpen, en daarna je mouwen opstropen en aan het werk gaan zonder deze grenzen te overschrijden. Een goed startpunt kan een product of dienst zijn (bij voorkeur eentje die je erg leuk vindt) en de implementatie daarvan te begrijpen. Misschien zult u verbaasd zijn hoe eenvoudig dit product eruitziet en hoeveel complexiteit er in werkelijkheid verborgen ligt. Vergeet niet: , en dat is prima.
Ik denk dat het beste advies dat ik kan geven aan degenen die beginnen met het ontwerpen van een systeem het volgende is: maak geen aannames! Vanaf het begin moeten de feiten die bekend zijn over dit systeem en de verwachtingen die eraan verbonden zijn, worden geconcretiseerd. Hier zijn enkele goede vragen waarvan de antwoorden u kunnen helpen met het ontwerp:
- Wat is het probleem dat we proberen op te lossen?
- Wat is het maximale aantal gebruikers dat met ons systeem zal interactieren?
- Welke patronen voor het schrijven en lezen van gegevens zullen we gebruiken?
- Wat zijn de verwachte fouten en hoe gaan we daarmee om?
- Welke verwachtingen zijn er met betrekking tot de consistentie en beschikbaarheid van het systeem?
- Moeten we bij ons werk rekening houden met externe audit- en reguleringseisen?
- Welke soorten vertrouwelijke gegevens willen we opslaan?
Dit zijn slechts enkele vragen die nuttig zijn geweest in mijn werk, zowel voor mij als voor de teams waarin ik in de loop der jaren heb samengewerkt. Als u de antwoorden op deze vragen kent (en op andere relevante vragen in de context waarin u werkt), kunt u geleidelijk dieper ingaan op de technische details van de taak.
Stel het uitgangsniveau vast
Wat ik hier onder "uitgangsniveau" begrijp? In onze tijd kunnen de meeste problemen in de software-industrie "opgelost" worden met bestaande methoden en technologieƫn. Dienovereenkomstig, door je in dit landschap te oriƫnteren, krijg je een bepaalde voorsprong als je geconfronteerd wordt met taken die eerder door iemand zijn opgelost. Vergeet niet dat programma's worden geschreven om bedrijfs- en gebruikersproblemen op te lossen, dus streven we ernaar de taak op de meest directe en eenvoudige manier (zowel voor de gebruiker als vanuit technisch perspectief) op te lossen. Waarom is het belangrijk om dit te onthouden? Misschien vindt u het leuk om unieke oplossingen voor elke taak te vinden binnen uw coƶrdinatensysteem, omdat u denkt: "Wat voor programmeur ben ik als ik overal patronen volg?" In werkelijkheid, ligt de kunst hierin in het nemen van beslissingen over waar en wat te doen. Natuurlijk wordt ieder van ons af en toe geconfronteerd met unieke problemen, elk een echte uitdaging. Maar als ons uitgangsniveau duidelijk is gedefinieerd, weten we waar we onze energie op moeten richten: op het zoeken naar bestaande oplossingen voor de ons gesteld taak, of op verdere studie en dieper begrip.
Ik denk dat ik u heb kunnen overtuigen dat als een specialist goed begrijpt wat de architectonische componenten zijn van enkele opmerkelijke softwaresystemen, deze kennis onontbeerlijk zal zijn voor het beheersen van de kunst van de architect en het opbouwen van een solide basis in dit gebied.
Goed, waar moeten we beginnen? Bij is er een repository op GitHub met de naam , waar je kunt leren over het ontwerpen van grootschalige systemen en je kunt voorbereiden op sollicitatiegesprekken over dit onderwerp. In de repository is er een sectie met voorbeelden van , waar onder andere wordt besproken hoe ze hun systemen ontwerpen , zoals Twitter, Uber, enz.
Echter, voordat we naar dit materiaal gaan, laten we dieper ingaan op de belangrijkste architectonische uitdagingen waarmee men in de praktijk wordt geconfronteerd. Dit is belangrijk omdat het noodzakelijk is om VEEL aspecten van een lastige en veelzijdige kwestie te concretiseren en deze vervolgens op te lossen binnen de regelgeving die in dit systeem van toepassing is. , voormalig Facebook-medewerker, heeft een , waarin hij zijn eigen ervaringen deelt na het bekijken van honderden kandidaten. Hoewel de video expliciet gericht is op het ontwerpen van grote systemen en de succescriteria die belangrijk zijn bij het zoeken naar een kandidaat voor zo'n positie, zal het toch een uitputtende bron zijn over wat het belangrijkst is bij systeemontwerp. Ik bied ook een van deze video aan.
Verzamel kennis over gegevensopslag en -verwerking
Over het algemeen heeft uw beslissing over hoe u uw gegevens op de lange termijn zult opslaan en verstrekken een kritische impact op de systeemprestaties. Daarom moet u in de eerste plaats de verwachte lees- en schrijfeigenschappen van uw systeem begrijpen. Vervolgens moet u in staat zijn om deze metrics te evalueren en keuzes te maken op basis van de uitgevoerde beoordelingen. U kunt echter alleen effectief met deze taak omgaan als u vertrouwd bent met de bestaande dataopslagpatronen. In feite impliceert dit solide kennis met betrekking tot .
Databases kunnen worden beschouwd als gegevensstructuren die uitzonderlijke schaalbaarheid en duurzaamheid hebben. Daarom zal kennis van gegevensstructuren zeer nuttig zijn bij het kiezen van een bepaalde database. Bijvoorbeeld, is een gegevensstructuurserver die verschillende soorten waarden ondersteunt. Het stelt u in staat om te werken met gegevensstructuren zoals lijsten en verzamelingen, gegevens te lezen met behulp van algemeen bekende algoritmen, zoals , waarbij dit werk op een duurzame en hoog beschikbare manier wordt georganiseerd.
Foto van de website Unsplash
Wanneer je een goed inzicht hebt gekregen in de verschillende datastorage patronen, ga je verder met het bestuderen van gegevensconsistentie en beschikbaarheid. Eerst moet je de minstens in grote lijnen begrijpen, en daarna deze kennis verfijnen door de gevestigde patronen en . Op deze manier breid je je kennis op dit gebied uit en begrijp je dat lezen en schrijven van gegevens eigenlijk twee heel verschillende problemen zijn, elk met hun eigen unieke uitdagingen. Door je te bewapenen met enkele patronen voor het waarborgen van consistentie en beschikbaarheid, kun je de prestaties van het systeem aanzienlijk verhogen, terwijl je tegelijkertijd een ononderbroken aanvoer van gegevens naar je applicaties garandeert.
Tot slot, als we het hebben over gegevensopslag, moeten we ook het cachen vermelden. Moet dit gelijktijdig aan de client- en serverzijde plaatsvinden? Welke gegevens wil je in de cache houden? En waarom? Hoe organiseer je cache-invalidering? Zal het regelmatig worden uitgevoerd, op bepaalde tijdsintervallen? Zo ja, hoe vaak? Ik raad aan om dit onderwerp te verkennen met de van het eerder genoemde handboek over systeemontwerp.
Communicatiepatronen
Systemen bestaan uit verschillende componenten; dit kunnen verschillende processen zijn die binnen dezelfde fysieke knoop werken, of diverse machines die in verschillende delen van je netwerk opereren. Sommige van deze hulpbronnen binnen je netwerk kunnen privatief zijn, maar andere moeten publiek en toegankelijk zijn voor consumenten die van buitenaf bij hen aankloppen.
Het is nodig om de communicatie tussen deze hulpbronnen onderling te waarborgen, evenals de uitwisseling van informatie tussen het hele systeem en de externe wereld. In de context van systeemontwerp komen we hier, wederom, een reeks nieuwe unieke uitdagingen tegen. Laten we kijken hoe , en welke diversiteit aan communicatiepatronen beschikbaar is.
Foto van de website Unsplash
waarbij ook serieus en actief aan gewerkt moet worden. Verbindingen verdelen
Verbindingen verdelen
Ik ben er niet zeker van of het gerechtvaardigd is om dit onderwerp in een afzonderlijke sectie te behandelen. Desondanks zal ik dit concept hier uitgebreid uiteenzetten en ik geloof dat het materiaal van deze sectie het beste wordt beschreven met de term 'verbinding distributie' (connection distribution).
Systemen worden gevormd door het juiste verbinden van vele componenten, en hun communicatie met elkaar is vaak georganiseerd op basis van gevestigde protocollen, zoals TCP en UDP. Echter, deze protocollen zijn vaak niet voldoende om aan de behoeften van moderne systemen te voldoen, die vaak onder hoge belasting werken en sterk afhankelijk zijn van de behoeften van de gebruikers. Het is vaak nodig om manieren te vinden om verbindingen te verdelen om met dergelijke hoge belasting in het systeem om te gaan.
De basis van dergelijke verdeling ligt in een goed bekend (DNS). Dit systeem maakt het mogelijk om een domeinnaam te vertalen, bijvoorbeeld naar een gewogen cyclisch algoritme (weighted round robin) en latency-gebaseerde methoden die helpen om de belasting te verdelen.
is principieel belangrijk, en praktisch elk groot systeem op het internet waar we vandaag mee te maken hebben, bevindt zich achter een of meerdere load balancers. Load balancers helpen klantverzoeken te verdelen over meerdere beschikbare instanties. Load balancers kunnen zowel hardware- als softwarematig zijn, maar in de praktijk hebben we vaker met softwarematige te maken, zoals en . zijn conceptueel ook zeer vergelijkbaar met load balancers, hoewel er tussen de eerste en de tweede een aantal . Deze verschillen moeten zeker in overweging worden genomen bij het ontwerpen van een systeem dat is afgestemd op uw behoeften.
Het is ook belangrijk om te weten over (CDN). Een CDN is een wereldwijd gedistribueerd netwerk van proxyservers dat informatie levert vanuit knooppunten die geografisch dichter bij de specifieke gebruiker zijn gelegen. CDN's worden bij voorkeur gebruikt als u werkt met statische bestanden, zoals JavaScript, CSS en HTML. Bovendien zijn er tegenwoordig populaire cloudservices die verkeersbeheerders aanbieden, zoals , wat u wereldwijde distributie en verminderde latenties biedt bij het werken met dynamische inhoud. Dergelijke diensten zijn echter meestal nuttig wanneer u werkt met stateless webservices.
Laten we het hebben over bedrijfslogica. De structurering van bedrijfslogica, taakstromen en componenten.
We hebben verschillende infrastructuuraspecten van het systeem besproken. Waarschijnlijk denkt de gebruiker Ć¼berhaupt niet na over al deze elementen van uw systeem en eerlijk gezegd, maakt hij zich daar helemaal geen zorgen over. De gebruiker wil weten hoe het is om met uw systeem om te gaan, wat je kunt bereiken door zo te handelen, en hoe het systeem de gebruikersopdrachten uitvoert, wat het doet met de gebruikersgegevens.
Zoals de titel van dit artikel aangeeft, wilde ik het hebben over software-architectuur en systeemontwerp. Daarom had ik niet van plan om ontwerppatronen voor software te bespreken, die beschrijven hoe softwarecomponenten worden gemaakt. Echter, naarmate ik hier meer over nadenk, lijkt de grens tussen ontwerppatronen voor software en architectuurpatronen erg vaag, en deze twee concepten zijn nauw met elkaar verbonden. Laten we bijvoorbeeld eens kijken naar (event sourcing). Zodra u deze architectuurpatroon omarmt, beĆÆnvloedt het bijna alle aspecten van uw systeem: langdurige opslag van gegevens, het niveau van consistentie dat in uw systeem is vastgesteld, de contouren van de componenten daarin, enzovoort. Daarom besloot ik enkele architectuurpatronen te vermelden die direct betrekking hebben op bedrijfslogica. Hoewel deze artikel zich misschien tot een eenvoudige lijst moet beperken, raad ik u aan om bekend te raken met deze ideeĆ«n en na te denken over de concepten die verband houden met deze patronen. Hier is het:
- Concepten , in het bijzonder, ,
Samenwerkingsbenaderingen
Het is uiterst onwaarschijnlijk dat u de enige bent die verantwoordelijk is voor het ontwerpen van het systeem. Waarschijnlijk moet u samenwerken met collega's die zowel binnen als buiten uw taak werken. In dit geval kan het nodig zijn om de gekozen technologische oplossingen samen met collega's te evalueren, zakelijke behoeften te identificeren en te begrijpen hoe u het beste taken kunt paralleliseren.
Foto van de website Unsplash
In de eerste plaats moet er een nauwkeurig en algemeen geaccepteerd begrip worden ontwikkeld van wat de zakelijke doelstelling is die u probeert te bereiken en met welke variabele elementen u te maken zult hebben. Groepsmodelleringstechnieken, met name (event storming) helpen dit proces aanzienlijk te versnellen en verhogen uw kansen op succes. Dit werk kan worden uitgevoerd voordat u de , en kan daarna verder worden uitgebreid naarmate het product volwassen wordt. Gebaseerd op het niveau van overeenstemming dat hier wordt bereikt, kunt u ook een voor de beperkte context waarin u werkt, formuleren. Wanneer u over de architectuur van uw systeem moet communiceren, kan een , voorgesteld door , bijzonder nuttig zijn, vooral wanneer u moet begrijpen hoe diep u in de details van het probleem moet duiken, terwijl u de dingen visualiseert die u wilt communiceren.
Waarschijnlijk bestaat er op dit gebied ook een andere volwassen technologie die net zo nuttig is als domeingestuurd ontwerp. Toch blijven we op de een of andere manier terugkomen op het begrijpen van het domein, zodat kennis en ervaring op het gebied van nuttig voor u zullen zijn.
Bron: habr.com
