Hallo kollegas.
Vandag bied ons vir u oorweging 'n vertaling van 'n artikel deur Tugberk Ugurlu, wat onderneem het om in 'n relatief klein volume die beginsels van die ontwerp van moderne sagtewarestelsels uiteen te sit. Hier is wat die skrywer opsommend oor homself sê:
Aangesien dit absoluut onmoontlik is om in 'n habro-artikel so 'n kolossale onderwerp soos argitektoniese patrone + ontwerppatrone vanaf 2019 te dek, beveel ons nie net die teks van mnr. Uruglu self aan nie, maar ook die talle skakels wat hy vriendelik daarin ingesluit het. As jy daarvan hou, sal ons 'n meer hoogs gespesialiseerde teks oor die ontwerp van verspreide stelsels publiseer.
Kiekie van Unsplash
As jy nog nooit sulke uitdagings moes trotseer soos om 'n sagtewarestelsel van nuuts af te ontwerp nie, dan is dit soms nie eens duidelik waar om te begin wanneer jy met sulke werk begin nie. Ek glo dat jy eers grense moet trek sodat jy 'n min of meer selfversekerde idee het van presies wat jy gaan ontwerp, en dan jou moue moet oprol en binne daardie grense werk. As 'n beginpunt kan jy 'n produk of diens (ideaal een waarvan jy regtig hou) neem en uitvind hoe om dit te implementeer. Jy sal dalk verbaas wees oor hoe eenvoudig hierdie produk lyk, en hoeveel kompleksiteit dit eintlik bevat. Moenie vergeet nie: , en dit is oukei.
Ek dink die beste raad wat ek aan enigiemand kan gee wat 'n stelsel begin ontwerp, is dit: moenie enige aannames maak nie! Van die begin af moet jy die feite wat bekend is oor hierdie stelsel en die verwagtinge wat daarmee geassosieer word, spesifiseer. Hier is 'n paar goeie vrae om te vra om jou te help om met jou ontwerp te begin:
- Wat is die probleem wat ons probeer oplos?
- Wat is die hoogste aantal gebruikers wat met ons stelsel sal kommunikeer?
- Watter patrone van skryf en lees van data sal ons gebruik?
- Wat is die verwagte mislukkingsake, hoe gaan ons dit hanteer?
- Wat is die verwagtinge vir stelselkonsekwentheid en beskikbaarheid?
- Moet jy enige vereistes wat verband hou met eksterne verifikasie en regulering in ag neem wanneer jy werk?
- Watter tipe sensitiewe data gaan ons stoor?
Hierdie is net 'n paar vrae wat nuttig was vir beide my en die spanne waaraan ek deelgeneem het oor die jare van professionele aktiwiteit. As jy die antwoorde op hierdie vrae ken (en enige ander wat relevant is tot die konteks waarin jy moet werk), dan kan jy geleidelik in die tegniese besonderhede van die probleem delf.
Stel die aanvanklike vlak
Wat bedoel ek hier met "basislyn"? Eintlik, in ons tyd, kan die meeste probleme in die sagteware-industrie opgelos word deur bestaande metodes en tegnologieë te gebruik. Gevolglik, deur hierdie landskap te navigeer, kry jy 'n sekere voorsprong wanneer jy gekonfronteer word met probleme wat iemand anders voor jou moes oplos. Moenie vergeet dat programme geskryf is om besigheids- en gebruikersprobleme op te los nie, daarom streef ons daarna om die probleem op die mees reguit en eenvoudige (uit die gebruiker se oogpunt) manier op te los. Hoekom is dit belangrik om te onthou? Miskien soek jy in jou koördinaatstelsel graag unieke oplossings vir alle probleme, want jy dink, "watter soort programmeerder is ek as ek oral patrone volg"? In werklikheid, die kuns hier is om besluite te neem oor waar en wat om te doen. Elkeen van ons moet natuurlik van tyd tot tyd met unieke probleme te doen kry, wat elkeen 'n ware uitdaging is. As ons aanvanklike vlak egter duidelik gedefinieer is, dan weet ons waaraan ons ons energie moet bestee: soek na gereedgemaakte opsies om die probleem wat voor ons lê op te los, of verder te bestudeer en 'n dieper begrip te kry.
Ek dink ek kon jou oortuig dat as 'n spesialis met selfvertroue verstaan wat die argitektoniese komponent van sommige wonderlike sagtewarestelsels is, dan sal hierdie kennis onontbeerlik wees om die kuns van 'n argitek te bemeester en 'n stewige basis in hierdie veld te ontwikkel.
Goed, so waar om te begin? U Daar is 'n bewaarplek op GitHub genaamd , waaruit jy kan leer hoe om grootskaalse stelsels te ontwerp, asook om voor te berei vir onderhoude oor hierdie onderwerp. Die bewaarplek het 'n afdeling met voorbeelde , waar veral oorweeg word hoe hulle die ontwerp van hul stelsels benader bv Twitter, Uber, ens.
Voordat ons egter na hierdie materiaal oorgaan, kom ons kyk die belangrikste argitektoniese uitdagings wat ons in die praktyk in die gesig staar van naderby. Dit is belangrik omdat jy BAIE aspekte van 'n hardnekkige en veelvlakkige probleem moet spesifiseer, en dit dan binne die raamwerk van die regulasies wat in 'n gegewe stelsel geld, moet oplos. , 'n voormalige Facebook-werknemer, geskryf , waar hy sy eie ervaring van die keuring van honderde aansoekers gedeel het. Terwyl die video baie fokus op groot stelselontwerp en die sukseskriteria wat belangrik is wanneer 'n kandidaat vir so 'n pos gesoek word, sal dit steeds dien as 'n omvattende hulpbron oor watter dinge die belangrikste is wanneer stelsels ontwerp word. Ek stel ook voor hierdie video.
Bou kennis oor die berging en herwinning van data
Tipies het jou besluit oor hoe jy jou data berg en op lang termyn herwin 'n kritieke impak op stelselwerkverrigting. Daarom moet jy eers die verwagte skryf- en leeskenmerke van jou stelsel verstaan. Dan moet jy in staat wees om hierdie aanwysers te evalueer en keuses te maak gebaseer op die assesserings wat gemaak is. U kan egter slegs hierdie werk effektief hanteer as u bestaande databergingspatrone verstaan. In beginsel impliseer dit vaste kennis wat verband hou met .
Databasisse kan beskou word as datastrukture wat uiters skaalbaar en duursaam is. Daarom behoort kennis van datastrukture vir jou baie nuttig te wees wanneer jy 'n spesifieke databasis kies. Byvoorbeeld, is 'n datastruktuurbediener wat verskeie tipes waardes ondersteun. Dit laat jou toe om met datastrukture soos lyste en stelle te werk, en data te lees met behulp van bekende algoritmes, byvoorbeeld, , organisering van sulke werk in 'n duursame en hoogs toeganklike styl.
Kiekie van Unsplash
Sodra jy 'n voldoende begrip van die verskillende databergingspatrone het, gaan voort om datakonsekwentheid en beskikbaarheid te bestudeer. Eerstens moet jy verstaan ten minste in algemene terme, en poets dan hierdie kennis deur gevestigde patrone van nader te bekyk и . Op hierdie manier sal jy 'n begrip van die veld ontwikkel en verstaan dat lees en skryf van data eintlik twee baie verskillende probleme is, elk met sy eie unieke uitdagings. Gewapen met 'n paar konsekwentheid- en beskikbaarheidspatrone, kan jy stelselwerkverrigting aansienlik verhoog terwyl jy gladde datavloei na jou toepassings verseker.
Ten slotte, om die gesprek oor databergingskwessies af te sluit, moet ons ook kas noem. Moet dit gelyktydig op die kliënt en bediener loop? Watter data sal in jou kas wees? En waarom? Hoe organiseer jy kas ongeldigmaking? Sal dit gereeld gedoen word, met sekere tussenposes? Indien wel, hoe gereeld? Ek beveel aan om hierdie onderwerpe te begin bestudeer met die voorgenoemde stelselontwerp-onderlaag.
Kommunikasiepatrone
Stelsels bestaan uit verskeie komponente; dit kan verskillende prosesse wees wat binne dieselfde fisiese nodus loop, of verskillende masjiene wat op verskillende dele van jou netwerk loop. Sommige van hierdie bronne binne jou netwerk kan privaat wees, maar ander moet publiek wees en oop wees vir verbruikers wat toegang daartoe van buite af verkry.
Dit is nodig om kommunikasie van hierdie hulpbronne met mekaar te verseker, asook die uitruil van inligting tussen die hele stelsel en die buitewêreld. In die konteks van stelselontwerp word ons hier weer gekonfronteer met 'n stel nuwe en unieke uitdagings. Kom ons kyk hoe hulle nuttig kan wees , en wat bl.
Kiekie van Unsplash
Wanneer kommunikasie met die buitewêreld georganiseer word, is dit altyd baie belangrik , waarvan die voorsiening ook ernstig opgeneem moet word en aktief nagestreef moet word.
Verbinding verspreiding
Ek is nie seker dat dit vir almal geregverdig sal lyk om hierdie onderwerp in 'n aparte afdeling te plaas nie. Nietemin sal ek hierdie konsep in detail hier aanbied, en ek glo dat die materiaal in hierdie afdeling die akkuraatste beskryf word deur die term "verbindingsverspreiding".
Stelsels word gevorm deur baie komponente behoorlik te verbind, en hul kommunikasie met mekaar word dikwels georganiseer op grond van gevestigde protokolle, byvoorbeeld, TCP en UDP. Hierdie protokolle as sodanig is egter dikwels onvoldoende om aan al die behoeftes van moderne stelsels te voldoen, wat dikwels onder hoë las bedryf word en ook hoogs afhanklik is van gebruikersbehoeftes. Dit is dikwels nodig om maniere te vind om verbindings te versprei om sulke hoë vragte op die stelsel te hanteer.
Hierdie verspreiding is gebaseer op die bekende (DNS). So 'n stelsel laat domeinnaamtransformasies toe, soos geweegde round robin en latency-gebaseerde metodes om te help om die vrag te versprei.
is fundamenteel belangrik, en feitlik elke groot internetstelsel waarmee ons vandag te doen het, is agter een of meer lasbalanseerders geleë. Lasbalanseerders help om kliëntversoeke oor verskeie beskikbare gevalle te versprei. Lasbalanseerders kom in beide hardeware en sagteware, maar in die praktyk het jy meer dikwels te doen met sagteware, byvoorbeeld и . konseptueel ook baie soortgelyk aan load balancers, hoewel daar 'n reeks tussen die eerste en tweede is . Hierdie verskille moet in ag geneem word wanneer 'n stelsel op grond van jou behoeftes ontwerp word.
Jy moet ook weet oor (CDN). 'n CDN is 'n wêreldwye verspreide netwerk van instaanbedieners wat inligting lewer vanaf nodusse wat geografies nader aan 'n spesifieke gebruiker geleë is. CDN's is verkieslik om te gebruik as jy werk met statiese lêers wat in JavaScript, CSS en HTML geskryf is. Boonop is wolkdienste wat verkeersbestuurders verskaf vandag algemeen, bv. , gee jou globale verspreiding en verminderde latensie wanneer jy met dinamiese inhoud werk. Sulke dienste is egter gewoonlik nuttig in gevalle waar jy met staatlose webdienste moet werk.
Kom ons praat oor besigheidslogika. Strukturering van besigheidslogika, taakvloei en komponente
Ons het dus daarin geslaag om verskeie infrastruktuuraspekte van die stelsel te bespreek. Waarskynlik dink die gebruiker nie eers aan al hierdie elemente van jou stelsel nie en gee eerlikwaar glad nie om daaroor nie. Die gebruiker stel belang in hoe dit is om met jou stelsel te kommunikeer, wat daardeur bereik kan word, en ook hoe die stelsel gebruikersopdragte uitvoer, wat en hoe dit met gebruikersdata doen.
Soos die titel van hierdie artikel aandui, gaan ek oor sagteware-argitektuur en stelselontwerp praat. Gevolglik het ek nie beplan om sagteware-ontwerppatrone te dek wat beskryf hoe sagtewarekomponente geskep word nie. Hoe meer ek egter daaroor dink, hoe meer lyk dit vir my of die lyn tussen sagteware-ontwerppatrone en argitektoniese patrone baie vaag is, en die twee konsepte is nou verwant. Kom ons neem byvoorbeeld (gebeurtenisverkryging). Sodra jy hierdie argitektoniese patroon aangeneem het, sal dit byna elke aspek van jou stelsel beïnvloed: langtermynberging van data, die vlak van konsekwentheid wat in jou stelsel aangeneem word, die vorm van die komponente daarin, ens., ens. Daarom het ek besluit om 'n paar argitektoniese patrone te noem wat direk verband hou met besigheidslogika. Al sal hierdie artikel homself tot 'n eenvoudige lys moet beperk, moedig ek jou aan om daarmee kennis te maak en na te dink oor die idees wat met hierdie patrone geassosieer word. Hier is jy:
- konsep , in die besonder, ,
Samewerkende benaderings
Dit is uiters onwaarskynlik dat jy jouself op 'n projek sal bevind as die deelnemer wat alleen verantwoordelik is vir die stelselontwerpproses. Inteendeel, jy sal heel waarskynlik interaksie moet hê met kollegas wat binne en buite jou taak werk. In hierdie geval moet jy dalk die geselekteerde tegnologie-oplossings saam met kollegas evalueer, besigheidsbehoeftes identifiseer en verstaan hoe om take die beste te paralleliseer.
Kiekie van Unsplash
Die eerste stap is om 'n akkurate en gedeelde begrip te ontwikkel van wat die besigheidsdoelwit is wat jy probeer bereik en watter bewegende dele jy sal moet hanteer. Veral groepmodelleringstegnieke (gebeurtenisstorm) help om hierdie proses aansienlik te bespoedig en jou kanse op sukses te verhoog. Hierdie werk kan gedoen word voor of na u uiteensetting , en verdiep dit dan soos die produk verouder. Op grond van die vlak van konsekwentheid wat hier bereik sal word, kan jy ook formuleer vir die beperkte konteks waarin jy werk. Wanneer jy oor die argitektuur van jou stelsel moet praat, kan jy dit nuttig vind , voorgestelde , veral wanneer dit kom by die begrip van hoeveel jy in detail oor die probleem sal moet ingaan, deur die dinge te visualiseer wat jy wil kommunikeer.
Daar is waarskynlik 'n ander volwasse tegnologie oor hierdie onderwerp wat nie minder nuttig is as Domain Driven Design nie. Ons keer egter op een of ander manier terug na die begrip van die vakgebied, dus kennis en ervaring in die veld behoort vir jou nuttig te wees.
Bron: will.com