Hei kollegat.
Tänään tarjoamme harkittavaksi käännöksen Tugberk Ugurlun artikkelista, joka sitoutui hahmottamaan suhteellisen pienessä määrässä nykyaikaisten ohjelmistojärjestelmien suunnittelun periaatteet. Tässä on mitä kirjoittaja sanoo itsestään yhteenvetona:
Koska habro-artikkelissa on täysin mahdotonta kattaa niin kolossaalia aihetta kuin arkkitehtoniset kuviot + suunnittelumallit vuodesta 2019 lähtien, suosittelemme paitsi itse herra Uruglun tekstiä myös lukuisia linkkejä, jotka hän ystävällisesti sisällytti siihen. Jos pidät siitä, julkaisemme hajautettujen järjestelmien suunnittelusta erikoistuneen tekstin.
kuva Unsplashista
Jos et ole koskaan joutunut kohtaamaan sellaisia haasteita kuin ohjelmistojärjestelmän suunnittelu tyhjästä, niin tällaista työtä aloitettaessa ei joskus ole edes selvää, mistä aloittaa. Uskon, että sinun täytyy ensin vetää rajat, jotta sinulla on enemmän tai vähemmän varma käsitys siitä, mitä aiot suunnitella, ja sitten kääriä hihat ja työskennellä näiden rajojen sisällä. Lähtökohtana voit ottaa tuotteen tai palvelun (mieluiten sellaisen, josta todella pidät) ja miettiä, miten se toteutetaan. Saatat olla hämmästynyt siitä, kuinka yksinkertaiselta tämä tuote näyttää ja kuinka monimutkainen se itse asiassa sisältää. Älä unohda: , ja se on okei.
Mielestäni paras neuvo, jonka voin antaa jokaiselle, joka alkaa suunnitella järjestelmää, on tämä: älä tee mitään oletuksia! Alusta alkaen sinun on täsmennettävä tästä järjestelmästä tunnetut tosiasiat ja siihen liittyvät odotukset. Tässä on muutamia hyviä kysymyksiä, jotka auttavat sinua aloittamaan suunnittelun:
- Mikä on ongelma, jota yritämme ratkaista?
- Mikä on suurin määrä käyttäjiä, jotka ovat vuorovaikutuksessa järjestelmämme kanssa?
- Mitä kirjoitus- ja lukemismalleja käytämme?
- Mitkä ovat odotetut epäonnistumistapaukset, miten aiomme käsitellä niitä?
- Mitä odotuksia järjestelmän johdonmukaisuudesta ja saatavuudesta on?
- Onko työskennellessään otettava huomioon ulkoiseen todentamiseen ja säätelyyn liittyvät vaatimukset?
- Millaisia arkaluonteisia tietoja aiomme tallentaa?
Nämä ovat vain muutamia kysymyksiä, joista on ollut hyötyä sekä minulle että tiimeille, joissa olen ollut mukana vuosien ammatillisen toiminnan aikana. Jos tiedät vastaukset näihin kysymyksiin (ja kaikkiin muihin, jotka liittyvät työskentelykontekstiin), voit vähitellen syventyä ongelman teknisiin yksityiskohtiin.
Aseta alkutaso
Mitä tarkoitan tässä "perustilanteella"? Itse asiassa meidän aikanamme useimmat ohjelmistoteollisuuden ongelmat "voidaan" ratkaista olemassa olevilla menetelmillä ja teknologioilla. Näin ollen navigoimalla tässä maisemassa saat tietyn etumatkan, kun kohtaat ongelmia, jotka jonkun muun oli ratkaistava ennen sinua. Älä unohda, että ohjelmat on kirjoitettu ratkaisemaan yritysten ja käyttäjien ongelmia, joten pyrimme ratkaisemaan ongelman yksinkertaisimmalla ja yksinkertaisimmalla (käyttäjän näkökulmasta) tavalla. Miksi tämä on tärkeää muistaa? Ehkä haluat koordinaattijärjestelmästäsi etsiä ainutlaatuisia ratkaisuja kaikkiin ongelmiin, koska ajattelet, "mikä ohjelmoija minä olen, jos seuraan malleja kaikkialla"? Itse asiassa, taide täällä tekee päätöksiä siitä, missä ja mitä tehdä. Tietenkin jokainen meistä joutuu ajoittain käsittelemään ainutlaatuisia ongelmia, joista jokainen on todellinen haaste. Kuitenkin, jos alkutasomme on selkeästi määritelty, tiedämme, mihin energiamme kuluttaa: etsimään valmiita vaihtoehtoja edessämme olevan ongelman ratkaisemiseksi vai tutkimaan sitä edelleen ja saamaan syvempää ymmärrystä.
Luulen, että pystyin vakuuttamaan sinut siitä, että jos asiantuntija ymmärtää varmuudella, mikä on joidenkin upeiden ohjelmistojärjestelmien arkkitehtoninen komponentti, niin tämä tieto on välttämätön arkkitehdin taiteen hallitsemiseksi ja vankan perustan kehittämiseksi tällä alalla.
Okei, joten mistä aloittaa? U GitHubissa on arkisto nimeltään , josta voit oppia suunnittelemaan suuria järjestelmiä ja valmistautua haastatteluihin tästä aiheesta. Arkistossa on esimerkkejä sisältävä osio , jossa erityisesti pohditaan, kuinka he suhtautuvat järjestelmiensä suunnitteluun esim. Twitter, Uber jne.
Ennen kuin siirrymme tähän materiaaliin, tarkastellaan kuitenkin lähemmin tärkeimpiä käytännössä kohtaamiamme arkkitehtonisia haasteita. Tämä on tärkeää, koska itsepäisessä ja monitahoisessa ongelmassa on määriteltävä MONTA näkökohtaa ja sitten ratkaistava se tietyssä järjestelmässä voimassa olevien määräysten puitteissa. , entinen Facebook-työntekijä, kirjoitti , jossa hän jakoi oman kokemuksensa satojen hakijoiden seulonnasta. Vaikka video keskittyykin vahvasti isojen järjestelmien suunnitteluun ja menestyskriteereihin, jotka ovat tärkeitä hakijaa haettaessa tällaiseen tehtävään, se toimii silti kattavana resurssina siitä, mitkä asiat ovat tärkeimpiä järjestelmiä suunniteltaessa. minäkin ehdotan Tämä video.
Kasvata tietoa tietojen tallentamisesta ja hakemisesta
Yleensä päätökselläsi siitä, kuinka tallennat ja noutat tietojasi pitkällä aikavälillä, on kriittinen vaikutus järjestelmän suorituskykyyn. Siksi sinun on ensin ymmärrettävä järjestelmäsi odotetut kirjoitus- ja lukuominaisuudet. Sitten sinun on osattava arvioida näitä indikaattoreita ja tehdä valintoja tehtyjen arvioiden perusteella. Voit kuitenkin selviytyä tästä työstä tehokkaasti vain, jos ymmärrät olemassa olevat tiedontallennustavat. Periaatteessa tämä tarkoittaa vankkaa tietoa liittyen .
Tietokannat voidaan ajatella tietorakenteina, jotka ovat erittäin skaalautuvia ja kestäviä. Siksi tietorakenteiden tuntemuksesta pitäisi olla sinulle hyötyä valittaessa tiettyä tietokantaa. Esimerkiksi, on tietorakennepalvelin, joka tukee erityyppisiä arvoja. Sen avulla voit työskennellä tietorakenteiden, kuten luetteloiden ja joukkojen, kanssa ja lukea tietoja käyttämällä tunnettuja algoritmeja, esim. , järjestämällä tällaiset työt kestävällä ja helposti saavutettavalla tyylillä.
kuva Unsplashista
Kun olet ymmärtänyt riittävän hyvin eri tiedon tallennustapoja, siirry tietojen johdonmukaisuuden ja saatavuuden tutkimiseen. Ensinnäkin sinun on ymmärrettävä ainakin yleisellä tasolla, ja hio sitten tätä tietoa tarkastelemalla lähemmin vakiintuneita malleja и . Tällä tavalla kehität alan ymmärrystä ja ymmärrät, että tietojen lukeminen ja kirjoittaminen ovat itse asiassa kaksi hyvin erilaista ongelmaa, joista jokaisella on omat ainutlaatuiset haasteensa. Muutaman johdonmukaisuuden ja saatavuuden mallin avulla voit parantaa merkittävästi järjestelmän suorituskykyä ja varmistaa samalla sujuvan tiedonkulun sovelluksiisi.
Lopuksi, lopuksi keskustelun tietojen tallennusongelmista, meidän on mainittava myös välimuisti. Pitäisikö sen toimia samanaikaisesti asiakkaalla ja palvelimella? Mitä tietoja välimuistissasi on? Ja miksi? Kuinka järjestät välimuistin mitätöinnin? Tehdäänkö se säännöllisesti, tietyin väliajoin? Jos kyllä, kuinka usein? Suosittelen aloittamaan näiden aiheiden opiskelun edellä mainittu järjestelmäsuunnittelupohjamaali.
Viestintämallit
Järjestelmät koostuvat erilaisista komponenteista; nämä voivat olla eri prosesseja, jotka ovat käynnissä samassa fyysisessä solmussa, tai erilaisia koneita, jotka toimivat verkon eri osissa. Jotkut näistä verkkosi resursseista voivat olla yksityisiä, mutta toisten tulee olla julkisia ja avoimia kuluttajille, jotka voivat käyttää niitä ulkopuolelta.
On tarpeen varmistaa näiden resurssien kommunikointi keskenään sekä tiedonvaihto koko järjestelmän ja ulkomaailman välillä. Järjestelmäsuunnittelun yhteydessä kohtaamme jälleen joukon uusia ja ainutlaatuisia haasteita. Katsotaan kuinka niistä voi olla hyötyä , ja mitä p.
kuva Unsplashista
Järjestettäessä viestintää ulkomaailman kanssa se on aina erittäin tärkeää , jonka tarjoaminen on myös otettava vakavasti ja siihen on pyrittävä aktiivisesti.
Yhteyden jakelu
En ole varma, että tämän aiheen laittaminen erilliseen osioon tuntuu oikeutetulta kaikille. Siitä huolimatta esitän tämän käsitteen tässä yksityiskohtaisesti, ja uskon, että tämän osan materiaalia kuvataan parhaiten termillä "yhteysjako".
Järjestelmät muodostetaan yhdistämällä monet komponentit oikein, ja niiden välinen viestintä järjestetään usein vakiintuneiden protokollien, kuten TCP ja UDP, perusteella. Nämä protokollat sinänsä eivät kuitenkaan usein riitä täyttämään kaikkia nykyaikaisten järjestelmien tarpeita, joita käytetään usein suurella kuormituksella ja jotka ovat myös erittäin riippuvaisia käyttäjien tarpeista. Usein on tarpeen löytää tapoja jakaa yhteydet selviytyäkseen näin suurista järjestelmän kuormituksista.
Tämä jakelu perustuu hyvin tunnettuun (DNS). Tällainen järjestelmä mahdollistaa verkkotunnusten muunnokset, kuten painotetut round robin ja latenssipohjaiset menetelmät kuorman jakamiseksi.
on pohjimmiltaan tärkeä, ja käytännössä kaikki suuret Internet-järjestelmät, joita käsittelemme nykyään, sijaitsevat yhden tai useamman kuormituksen tasapainottimen takana. Kuormantasaajat auttavat jakamaan asiakaspyynnöt useiden käytettävissä olevien esiintymien kesken. Kuormantasaajat tulevat sekä laitteistossa että ohjelmistossa, mutta käytännössä useammin joudutaan käsittelemään ohjelmistoja mm. и . käsitteellisesti myös hyvin samankaltainen kuin kuormantasaajat, vaikka ensimmäisen ja toisen välillä on vaihteluväli . Nämä erot on otettava huomioon suunniteltaessa järjestelmää tarpeidesi mukaan.
Sinun pitäisi myös tietää (CDN). CDN on globaali hajautettu välityspalvelinverkko, joka toimittaa tietoja solmuista, jotka sijaitsevat maantieteellisesti lähempänä tiettyä käyttäjää. CDN-verkkoja kannattaa käyttää, jos työskentelet JavaScript-, CSS- ja HTML-kielellä kirjoitettujen staattisten tiedostojen kanssa. Lisäksi liikenteenohjaajia tarjoavat pilvipalvelut ovat nykyään yleisiä mm. , joka tarjoaa maailmanlaajuisen jakelun ja pienemmän viiveen työskennellessäsi dynaamisen sisällön kanssa. Tällaiset palvelut ovat kuitenkin yleensä hyödyllisiä tapauksissa, joissa joudut työskentelemään valtiottomien verkkopalvelujen kanssa.
Puhutaanpa liikelogiikasta. Liiketoimintalogiikan, tehtävänkulujen ja komponenttien jäsentäminen
Joten onnistuimme keskustelemaan järjestelmän erilaisista infrastruktuurinäkökohdista. Todennäköisesti käyttäjä ei edes ajattele kaikkia näitä järjestelmäsi elementtejä, eikä suoraan sanottuna välitä niistä ollenkaan. Käyttäjä on kiinnostunut siitä, millaista on olla vuorovaikutuksessa järjestelmän kanssa, mitä tällä voidaan saavuttaa, ja myös kuinka järjestelmä suorittaa käyttäjän komentoja, mitä ja miten se tekee käyttäjätiedoilla.
Kuten tämän artikkelin otsikko viittaa, aioin puhua ohjelmistoarkkitehtuurista ja järjestelmäsuunnittelusta. Näin ollen en aikonut kattaa ohjelmistojen suunnittelumalleja, jotka kuvaavat ohjelmistokomponenttien luomista. Mitä enemmän ajattelen sitä, sitä enemmän minusta näyttää kuitenkin siltä, että ohjelmistosuunnittelumallien ja arkkitehtonisten mallien välinen raja on hyvin hämärtynyt ja nämä kaksi käsitettä liittyvät läheisesti toisiinsa. Otetaan esimerkiksi (tapahtuman hankinta). Kun otat tämän arkkitehtonisen mallin käyttöön, se vaikuttaa lähes kaikkiin järjestelmäsi osa-alueisiin: tietojen pitkäaikaiseen säilytykseen, järjestelmässäsi käyttöön otettuun johdonmukaisuuden tasoon, siinä olevien komponenttien muotoon jne., jne. Siksi päätin mainita joitain arkkitehtonisia malleja, jotka liittyvät suoraan liiketoimintalogiikkaan. Vaikka tämän artikkelin on rajoituttava yksinkertaiseen luetteloon, kehotan sinua tutustumaan siihen ja miettimään näihin malleihin liittyviä ideoita. Täällä sinä olet:
- käsite , erityisesti, ,
Yhteistyölähestymistapoja
On erittäin epätodennäköistä, että joudut projektiin osallistujana, joka on yksin vastuussa järjestelmän suunnitteluprosessista. Päinvastoin, joudut todennäköisesti olemaan vuorovaikutuksessa sekä tehtäväsi sisällä että sen ulkopuolella työskentelevien kollegoiden kanssa. Tässä tapauksessa saatat joutua arvioimaan valittuja teknologiaratkaisuja kollegoiden kanssa, tunnistamaan liiketoiminnan tarpeet ja ymmärtämään, kuinka tehtävät voidaan parhaiten rinnastaa.
kuva Unsplashista
Ensimmäinen askel on kehittää tarkka ja yhteinen käsitys siitä, mikä liiketoiminnan tavoite on saavuttaa ja mitä liikkuvia osia joudut käsittelemään. Ryhmämallinnustekniikat erityisesti (tapahtumamyrsky) nopeuttaa merkittävästi tätä prosessia ja lisää onnistumismahdollisuuksiasi. Tämä työ voidaan tehdä ennen hahmottelua tai sen jälkeen ja syvennä sitä sitten tuotteen kypsyessä. Tässä saavutettavan johdonmukaisuuden tason perusteella voit myös muotoilla rajoitettuun kontekstiin, jossa työskentelet. Kun sinun on puhuttava järjestelmäsi arkkitehtuurista, se saattaa olla hyödyllistä , ehdotti , varsinkin kun sinun on ymmärrettävä, kuinka paljon sinun on mentävä ongelman yksityiskohtiin visualisoimalla asiat, joista haluat kommunikoida.
Tästä aiheesta on luultavasti toinenkin kypsä tekniikka, joka on yhtä hyödyllinen kuin Domain Driven Design. Palaamme kuitenkin jollain tapaa ymmärtämään aihealuetta, joten alan tietoa ja kokemusta pitäisi olla sinulle hyödyllistä.
Lähde: will.com